Provide a source, otherwise what you say is just unfounded FUD 
.
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
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
Nice to see it bounce up at the same point as it was before and not lower. What does SMA mean?
Simple moving average (sum of the Difficulty or block time over 60 days, devided by 60)
1 Like
@lehnberg Can we get another edit of this topic’s title, with a strikethrough? It makes me jump everytime I see it. 
Copypaste, if there’s no cleaner way to do it:
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̶!̶
2 Likes
Was it a hard-fork? I think it was a soft-fork. If it was a hard-fork, Why?
1 Like
Correct. The bug-fixed code accepts a strict subset of the previously accepted histories. Non updated clients work fine as long as majority graph power runs fixed code.
It is a bit on the boundary, but as long as miners have to chose to support one branch and not the other, I think it officially counts as a hard-fork 
. In this case he old nodes would validate a block with a negative spending/arbitrary inflation this would not be in agreement with the consensus of the newer nodes. This difference in consensus that separates old and new nodes makes it a hard-fork technically. Of course it is a very boring hard-fork since no one supports the chain where an arbitrary amount of Grin can be created from thin air, but it could have been similar to the Ethereum - Ethereum Classic hard-fork if for some deranged philosophical reasons some miners would continue mining with old node software for consensus.
That does not make it a hard-fork. To qualify as a hard-fork, new code must accept some history that the old code rejects. I.e. make new things possible.
If the difference is new code accepting a strict subset of old code, then that by definition is a soft-fork.
1 Like
In other words, soft-fork is when you make consensus rules more strict (some blocks might become invalid with new version), but the new version should never accept a block for which the old version would say it’s invalid. This makes it so that in the end they both end on the same chain with time, the only problem is that the old nodes (assuming majority runs the new ones) might have more reorgs (but in practice that shouldn’t really happen because miners have no financial incentives to stay on the old version, so nobody is mining the old version blocks). Hard fork is when nodes don’t converge to the same chain (eg. you make consensus rules less strict, meaning new version accepts a block which the old version wouldn’t, that way the old version nodes will never converge on the new chain)
A ok, I thought it was bidirectional. So I thought that if any node does not accept a blocks from another node it is a hard-fork, but that is not the case. learned something new today 