No. By then, then code from the first part of the tutorial - it compiled, and it was broadcasted throughout the network all during the first Begin Transaction (BT ) ↔ Commit Transaction (CT ) sequence meaning - the instructions already affected the entire system. By then, each and every node comprising the system knows that you’ve sacrificed a certain amount of assets.
And that shall remain so until the end of times.
Thus, there is no need to broadcast the same sequence of instructions all over ever again. T
What you need, though, is to proceed with a new Begin Transaction (BT) ↔ Commit Transaction (CT) sequence,- during which you would both generate and register the actual Identity Token.
A Begin Transaction (BT) ↔ Commit Transaction (CT) sequence just like @vega4 described - it is about ‘recording’ your instructions and broadcasting these across the network.
At least that is a good visualisation. Matters are way more complicated than that, but it can be thought of as being so.
Now, after having used CT your code-cache is cleared, for your convenience, Operator - so that if you execute VT (an abbreviation for View Transaction) right after having begun a new sequence - it indeed reports the code cache to be empty. Because it is.
That is by design.
Otherwise, you would need to clear it by yourself. You simply get a new clear page to write your instructions on.
Well, it’s all looking good, besides for the fact that your transaction was not processed and judging by the fact that 3 hours have passed already I would say it’s not going to be processed. You might want to retry.
Your first transaction was processed just fine. The second one never made it.
Now, the what’s the take-away from such a situation? Why did it happen ?
Well, the node @jamie was connected with, during the SSH session, almost certainly it was not the current Leader. Thus almost certainly it wouldn’t be able to process the code bundle @jamie produced.
So the node would try to broadcast the code bundle to other nodes it was connected to during that time. Most likely during that time, the node must had been having some connectivity issues with the rest of the network. There are not so many nodes as of now and and even less nodes capable of GPU mining. The transaction needs to arrive at the GPU-miner who is the current leader. Nodes would cache the code bundle and try to retransmit for some time though.
I went into the lengths of analyzing mem-pool contents with a debugger attached to some of the nodes that we ‘own’. I’ve found three code-bundles produced by @jamie , none of which however corresponds his recent transaction (the one in which he tries to register an Identity Token), I’ve checked 3-4 nodes this way, the current leader also has no mention about it within its log-files.
@CodesInChaos we could consider making a tool available which would allow for browsing of mem-pool contents.
In the meantime I’ve checked-up on code responsible of sharing of the mem-pools’ contents. It’s all looking good. Seems like bad luck. What caught my curiosity though is that as it is, nodes try to share code-bundles among each other almost indefinitely I mean they would not share the same TX to same node twice. Ever. But once a TX is propagated to at least a couple nodes, the same TX has a chance of arriving through multiple paths to the current leader. So the current leader would need to be heavily obstructed from the rest of the network not to receive it. And then leaders change. @jamie may I know which node you were reaching out to in your SSH session? Was it to test.gridnet.org or some other endpoint?
In fact the subdomain test.gridnet.org has multiple A-type DNS entries each of which points to separate endpoints… sure, one could see the currently available endpoints by switching to Events View (CTRL+W ) during an SSH session, each endpoint prints nodes it is connected to from time to time (I think about every ~~20 seconds).
While we offer DNS A entries for free, some endpoints (operated by others) are discovered through our variance of Kademlia decentralized peer discovery protocol and these never make it to be A-entries at test.gridnet.org, unless so desired by Operators.
Then this might be caused by the node, the one which is serving your session, having misconfigured NAT or otherwise being unavailable from the outside.
If the issue still persists, swipe to the left on the signing request, -once it gets shown on the mobile app to see the target IP, kindly report it over here.
should have kept quiet tried further numerous times
same result to ‘transaction result not ready yet’ on last attempt app has no connectivity … when you say ‘swipe left on the signing request -once it gets shown on the mobile app to see the target IP’ , I find that the app does not swipe left to see what you ask for.
@jamie Operator, we’re facing a Storm, a hurricane so to say:
Turns out we’ve been having many nodes facing attacks exploiting cve-2020-1730-like vulnerabilities in libssh which we use (…) we’re having someone on it already.
the network is currently experiencing huge fragmentation, the reason is currently unknown. The current leader 150.254.30.115 is way further (block height 4500) than the rest of the network (one may verify over SSH), the rest of the network is stuck at block 4326.
You need to swipe on the upper portion of the screen ex. on the very question which gets shown once you scan the QR Code. The details of the request would be shown.
When you say ‘ex.’ what is that? not the x to the window on the app, do you mean the question do you agree to sign the transaction?
Sorry if I am being obtuse it is not my intention vega 4
