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̶!̶

Agreed BTC did a rollback in the early days but the crypto environment was still early and under developed compared to today.
The entire crypto space today has matured from that time.
I have been a supporter of GRIN since the beginning and I view owning any grin at this time as more of a donation of resources for a cause.

But I would disagree to a rollback as well as i think the economic impact from this attack is insignificant compared to the optics risk of a rollback.

The crypto space has matured enough that I think owning and correcting a bad situation would cement strong conviction of the progject’s community years from now as history looks back on the project’s track history.
There is value to consistant track record.
To me a rollback is taking the easy way outand feels more akin to appeasement to investor/share holder monetary values than the projects core values.

I will still continue to support and donate my resources to the project but I would caution against any future rollbacks as I do not believe the immediate economic impact for such a young and immaterially priced coin should take on the risks of damaging its futre intrinsic value.

Risk management should not be viewed with such a singular siloed focus as it was in the case.

That doesn’t matter, programmers make mistakes and that won’t change. The more eyes the higher the chance reviewers spot them in time

I don’t think you understand what happened, rollback was the only option

1 Like

Entirely possible I may not have all the details on what occured.
Can you please explain to everyone as to why “rollback was the only option”?

@oryhp mentioned that with the invalid block inflation could have occured and nobody could tell how many new coins may have entered the system. I guess this is the background for his Bounty suggestion here: Bounty suggestion: Inflation bugs

2 Likes

Is this release of Grin++ safe to use Release Grin++ Wallet and Node v1.2.6-beta.1 · GrinPlusPlus/GrinPlusPlus · GitHub ?

Just wanted to share a general summary as there still seems to be some confusion in this thread.

A potentially catastrophic attack was carried out against the Grin network with block 1136081, hash 0002897182d8cf7631e86d56ad546b7cf0893bda811592aa9312ae633ce04813 by exploiting insufficient rangeproof cache verification logic.

This was a worst-case scenario attempted attack for any privacy coin: potentially undetectable inflation.

Fortunately, the attack was detected and mitigated by our community before any significant damage was caused.

The Grin ecosystem is diverse and robust with multiple implementations, notably Grin++, where logic was able to detect this attack and the creators were able to help mitigate the attack network-wide. With multiple implementations, critical flaws in one implementation may be caught in another, at a risk of potentially diverging on a single valid block etc due to differences across implementations.

Grin requires rangeproofs to ensure that negative commitment values do not create inflation scenarios. Without rangeproofs, it would be possible to create transaction outputs that artificially inflate the supply by using negative values. Without a valid rangeproof to verify that an output is not negative, it is possible for a malicious actor to create transactions containing negative-value outputs along with high-value outputs that appear to balance out to zero new coins being created.

In this case, insufficient validation in an optimization for caching verification for rangeproofs was used to attempt an exploit.

This attempt was discovered by a grin++ user due to their verification process and was relayed to the rest of Grin team by David Burkett as well as a fix to mitigate the faulty rangeproof caching logic.

In addition to fixing the underlying caching validation issue, network nodes needed to perform the following to recover:

  • Rewind block 1136081 that contains invalid rangeproof
  • Rewind headers with bad blocks built on invalid rangeproof block
  • Improve peer banning around serving invalid blocks/headers

As a result, the Grin team released a series of hotfixes addressing the above issues as quickly as possible to minimize downtime for the ecosystem. Initially v5.0.3 was released to address the block rewinds, which was followed by v5.0.4 to address the header sync to properly filter “good” and “bad” blocks for all nodes.

With any coordinated, critical security fix like this we reveal the strengths and weaknesses of our ecosystems. These necessary upgrades were successfully deployed to one of the most decentralized networks in the blockchain ecosystem and are a testimony to the level of talent we have invested in Grin.

We are working to publish a CVE report with all of the technical details in grin-security.

14 Likes

…" it would be possible to create transaction outputs that artificially inflate the supply by using negative values"

I am not sure that is entirely a bad thing if the end goal of GRIN is to eventually displace part of the world monetary system and not just be the next evolution of Bitcoin…
By allowing certain specific checks and scenarios, being able to expand or contract the supply based on certain metrics (population growth/decrease or economic production/compression)…you could really have a decentralised monetary system that can act on autopilot with rule sets that are truly transparent.
As I said, not sure thats entirely a bad thing.

How do we know there’s been no significant damage?

Are exchanges supposed to manually invalidate any deposits they received from block 1136081 until they upgraded to V5.0.3?

I had a similar issues, check your balance on TO, they canceled the transfers after block 1136756 and the coins returned to my account.

I didn’t even have to ask them. They did it automatically.

3 Likes

, Fortunately, the attack was detected and mitigated by our community before any significant damage was caused ".

Who was heroes ?

1 Like

Hello,

I would like to kindly ask you for the help please,
I sent 813 Grin from tradeorge.com exchange into my Ironbelly wallet. On the exchange is status successful, but Ironibelly tell me “send the part of the transaction to the sender”, but in is not possible because there the withdrawal process is done. Is there any way how to fix it please?

Thank you so much.

1 Like

the truth is tradeogre lost 50K+ grin coins

tradeogre is a good exchange, sent my coins back to my account. but grin is shitcoin, I have sold all grin coins.

Provide a source, otherwise what you say is just unfounded FUD :face_with_raised_eyebrow:.

1 Like

Did you contact them?
I would send them this information with you slatepack response so they can re-finalise and publish the transaction on the blockchain. It is little work for them to do so although of course an inconvenience since they have to do it manually.

2 Likes

you can ask tradeogre yourself on twitter

1 Like

Where did you ask them?

3 Likes

So nice, your fast response.
Solved.
I contacted them. They wrote to me back that I should restore my Ironbelly wallet.
It’s worked.

Thank you so much for the help.

Ironbelly resonse:
"There has a been a chain split yesterday and this could’ve been a reason. You can try to repair wallet in the Settings, this way it will search for the outputs on chain again. If this did not help - contact TradeOgre to double check that the transaction indeed went through.

Also, on the screenshot it says: “Date: Invalid Date” - this is disturbing."

2 Likes

3 Likes

With the reorg well behind us, it’s nice to see it captured in these grinscan charts:

If I checked correctly, then GrinScan - Block 1,136,317 at 2021-03-18 23:59:11 UTC (the first of 4 blocks in the final minute of Mar 18) is the lowest difficulty ever block at Network difficulty 15,833,792.
Also, the drop from 174,816,158 at height 1136081 to 37,336,151 at height 1136082, is a record 4.68x reduction, due to (the fixed) GrinScan - Block 1,136,081 taking 14h 44m 44s to mine.

Kudos to our Difficulty Adjustment Algorithm for handling this gracefully.

The reorged branch went as far as height 1137458, 1378 blocks beyond the common ancestor at 1136080, as tracked by GrinExplorer - The first Open-Source Grin Blockchain Explorer

7 Likes