MCM-Mike (grinnode.live) — Today at 12:41 @everyone
There is some ongoing investigation about a possible problem with GRIN-Network at the moment.
This is just for your information as I currently do not have more details.
Grin++ Telegram group was set to read only - David will update you there as well.
@davidburkett@bitcoinhackers.org (@DavidBurkett38) @MWgrin_fr This does not just apply to Grin++. Do not use Grin right now at all while we investigate.
Just for clarification, as user we should not resync right now? Otherwise it might make it very slow for mining pools to resync if everyone starts resyncing at the same time.
Grin++ nodes have no need to resync at all since they never accepted the block with the wrong range proof (and therefore never acccepted block 1136081 and all following blocks)
grin-wallet nodes should resync in the near future but maybe wait till all mining pools are done syncing. => Wait for anouncement when to resync
PIBD might have helped there to speed up the re-syncing.
Official announcements will be available soon. Since grin-node/grin-wallet represents 50% of the chain this affects all users anyways. Let’s try wait a bit more.
Block height 1136081 with the hash 0002897182d8cf7631e86d56ad546b7cf0893bda811592aa9312ae633ce04813 contained an invalid rangeproof, due to faulty rangeproof caching logic. Release v5.0.3 · mimblewimble/grin · GitHub contains a fix that :
mitigates the cache issue
rewinds the invalid block
improves peer banning
All miners are urged to upgrade immediately to build work on a valid chain, users and exchanges should update to 5.0.3 before use. Exchanges and users should continue to halt transactions until sufficient work has been built on a valid chain beyond the invalid block.
The former code accepted a rangeproof BP for output commitment O,
if BP appeared in the verifier cache as having been verified before.
This logic was faulty since the earlier verification was not necessarily against the same output commitment. The earlier verification could be against a different output, while the new one commits to a negative value.
Wait, does that mean that it could be exploited to create Grin out of thin air , good thing that bug is squashed in the bud. Nice example of the benefits of having two independent node implementations.
20210318 17:30:53.069 DEBUG grin_chain::chain - init: rewinding and validating before we start... 0000a583044b at 1136917
20210318 17:30:56.797 DEBUG grin_chain::chain - rewind_bad_block: found header: 0002897182d8 at 1136081
20210318 17:30:56.797 DEBUG grin_chain::chain - rewind_bad_block: found block: 0002897182d8 at 1136081
20210318 17:30:56.797 DEBUG grin_chain::chain - rewind_bad_block: rewinding to prev: 000176f6574f at 1136080
so someone created a valid commitment P with rangeproof B which made it on chain, then created P’ with the same rangeproof B which was considered verified because it was in cache where P’ held a negative v? Am I understanding it right that this must have been an attempt to inflate Grin because a wallet would not have done this on its own. Kudos to everyone involved in fixing this and Grin++ for catching the issue
Great job solving this all so quickly! @oryhp yes, this was an attack by someone with good understanding of Grin and the rust implementation. I wonder who🤔
@mcm-mike I cannot change the title anymore, probably since @lehnberg changed the topic it locks me out to prevent me from changing it back. @lehnberg Can you change the title of the topic to something like:
Problem Sovled: Do not use Grin (grin-wallet, Grin++, Ironbelly) until further notice
Or another title altogether if you can think of a better one.
, good thing that bug is squashed in the bud. Nice example of the benefits of having two independent node implementations.