Resolved: D̶o̶ ̶n̶o̶t̶ ̶u̶s̶e̶ ̶G̶r̶i̶n̶ ̶(̶g̶r̶i̶n̶-̶w̶a̶l̶l̶e̶t̶,̶ ̶G̶r̶i̶n̶+̶+̶,̶ ̶I̶r̶o̶n̶b̶e̶l̶l̶y̶)̶ ̶u̶n̶t̶i̶l̶ ̶f̶u̶r̶t̶h̶e̶r̶ ̶n̶o̶t̶i̶c̶e̶!̶

Announcements
#1

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.

We will keep you updated in #announcements

@davidburkett@bitcoinhackers.org (@DavidBurkett38)
@MWgrin_fr This does not just apply to Grin++. Do not use Grin right now at all while we investigate.

Twitter•Today at 11:34

3 Likes
Why all the exchange closed GRIN deposit?
Grin exchanges caution
#2

Anyone with admin rights e.g. @lehnberg, please move this post to the Announcement category!

#3

I did try but I dont have the rights, I can only move them to the regular categories.
Perhaps someone can pass me the rights and I will do it.

2 Likes
#4
4 Likes
#5

EDIT: Let’s wait until v5.0.3

4 Likes
#6

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.

1 Like
#7

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.

2 Likes
#8

5.0.3 release will be available very shortly.
This will not need “resync from scratch” and will work in-place on existing node.

5 Likes
#9

What’s the current explanation as to what happened? I look forward to reading the case report if one will be compiled.

#10

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.

3 Likes
#11

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.

1 Like
#12

Wait, does that mean that it could be exploited to create Grin out of thin air :thinking:, good thing that bug is squashed in the bud. Nice example of the benefits of having two independent node implementations.

2 Likes
#13

We (https://grinnode.live/) upgraded all our big archive-nodes to the latest tag 5.0.3

/opt/grin/server# ./grin --version 
grin 5.0.3

Also the rewind was successful:

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

(time in logs is CET)

1 Like
#14

Yes, this allowed for arbitrary inflation…

#15

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 :clap:

8 Likes
#16

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🤔

4 Likes
#17

Now that is solved, should you @Anynomous change the topic to something linke “solved” ?

3 Likes
#18

@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.

2 Likes
#19

will a new security audit be done?

1 Like
#20

Anyway, I’m not surprised that something like this happened, otherwise it wouldn’t be Grin