@vega4 And you know that the issue we’ve been facing at block 2399 (if I recall correctly ) it had to do with a ‘sacrificial’ transaction , right ? Just letting you know…
For reference, let me bring up another thread in which someone was having trouble with deployment of an identity token here.
In the other case, it was an invalid sequence of commands and the process succeeded in the end. Thus, these situations do not seem to be co-related.
@coinsgaga I confirm the issue. I was able to reproduce it. See below.
$ cd '/1K7izkBd7QHADT6g3NzDfp8D1gT2sgLPe1/'
Welcome!🦄 Access to local security storage not granted.
You'll need to authenticate with GRIDNETToken🔑 on commit.
1K7izkBd7QHADT6g3NzDfp8D1gT2sgLPe1:/ $ bt
Ad-Hoc Transaction formulation began. You may proceed.
1K7izkBd7QHADT6g3NzDfp8D1gT2sgLPe1:/ $ sacrifice 1
✅ Sacrifice made!
Previous Balance: 50.49 GNC (50499999999999999887 Atto Units)
New Balance: 50.49 GNC (50499999999999999886 Atto Units)
1K7izkBd7QHADT6g3NzDfp8D1gT2sgLPe1:/ $ ct
Attempting to Commit the Transaciton..
❎ Aborting Transaction due to an error. You may retry.
Thread Aborted.
[Blockchain Manager]: Exception v: False (Invalid Transaction ERG-limit)
1K7izkBd7QHADT6g3NzDfp8D1gT2sgLPe1:/ $
I have assigned a ‘critical’ flag to this issue. The resolution is thus expected within a 24hour time-window.
While trying to reproduce the situation on main.gridnet.org (the node running GRIDNT Core 1.1.1 which is currently trying to revalidate the entire history of events from Genesis Block), I’ve stumbled upon an entirely unrelated issue - the Virtual Terminal Interface was extremely unresponsive when processing instructions. Input/output latency was fine but once I tried to execute commands, these were extremely unresponsive.
I’ve proceeded with a comprehensive mutex-congestion analysis.
as one may see, the mutex responsible for protection of the current leader gets locked for period of time longer than 30 seconds…that’s not acceptable.
Undeniably it’s due to the fact the node is under heavy load doing all the processing of the entire history of events and due to the fact that the current leader keeps changing rapidly or is halted during processing of a block. On my way to analyze this further.
Update 2: and indeed, the mutex gets released by a function responsible for block processing:
Update:
The Commands’ Executor requires the ‘leader’ from blockchain manager so that the curren block-heightmay be passed into the GridScript 1.0 processing engine.
While the issue with mutex congestion and perceivable unresponsiveness of the Virtual Terminal Interface has been tackled successfully by @vega4 , the issue has been redirected further to me for assessment of possible security implications. I’ll let you know how it’s going.
The single GBU was as per the tutorial I followed (Your humor is not lost on me though).
I did try to set an ERG value of 100000, not that I know what i was doing .
It is likely that the tutorial was conceived in times when GRIDNET OS did not support Big Integers and before the vast increase of resolution of the currencies’ denomination.
I can see that this indeed is the case and there’s a new switch now supported by the ‘sacrifice’ command which is '-GNC" which would tell the operating system that you are making your sacrifice in GRIDNET Coins, instead of GBUs.
1 GBU is an extremely low amount since 1 GNC= **100000000000000000 GBUs/Atto Coins
Thank you for bringing this issue to our attention. A thorough security report regarding this has been received from @Major and we want to assure you that our dedicated team is already working on addressing it.
Although I am no more directly involved in the process of resolving this specific issue (since its severity level was dropped to low), it is important to clarify the likely cause. A snapshot highlighting the key points is included here for your reference:
Upon analysis, it appears that the problem originated from a bug in the most recent Nightly Build. This bug led to a comparison between the user-provided ERG-Price and ERG-limit against a deprecated 64-bit local variable, rather than the correct Big Int which the user might have provided.
Given that this deprecated variable is not currently in use, its value is invariably zero. As a result, the system’s verification mechanics interpreted the ERG Price/Limit as invalid. This is due to the fact that, from the perspective of these mechanics, the price/limit appeared to be set to zero since the user-provided value was not being accurately processed.
We deeply appreciate your patience while we work on resolving this issue. We will continue to prioritize the stability and functionality of services provided by our decentralized network of nodes to ensure a smooth user experience.
Update:
I’ve just looked up the most recent push into our code repository, here we may see that the deprecated variable was removed, the message displayed to the user was also improved to better suggest that the to be provided value is in GBUs:
I’m pleased to share that we have successfully resolved the issue at hand. However, I’d like to bring your attention to some ongoing developments. As we speak, our dedicated team is conducting a series of rigorous tests on the test-net. These extensive evaluations might temporarily affect the registration of identity tokens.
We understand the importance of keeping you informed and promise to provide regular updates on our progress. Your patience and understanding during this period are much appreciated.
.
