A new user sent me this to my inbox, its a description of the events after the fork, with a signed message at the bottom. I've gone through it once but its very late here in my timezone, have to go through it again tomorrow. I'm sure I'm not the the only receipient, but just in case pinging some people here.
https://honest.cash/kiarahpromise/sigop-counting-4528
*** EDIT 2 ***
Before you continue. From the Bitcoin whitepaper:
" The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes."
*** EDIT ***
Ok, I have slept over this.
How big is the chance that these two events, the sigop tx spamming of the network and the intended theft of funds stuck in segwit by an unknown miner, were coordinated and not coincidential? I slept over this message and am wondering if that was one two-phased plan and even this message was planned (probably a bit different but it was adapted afterwards to the new situation, that's why the first half of it is such a mess to read) to spread fear after the two plans got foiled.
The plan consisted of various Acts
Act 1) Distract and spam the network with sigop transactions that exploit a bug to cause distraction and halt all BCH transaction volume. The mempool would become filled with unconfirmed transactions
Act 2) When a patch is deployed, start your mining pool and mine the hell out of it to quickly create a legitimate block. They prepared the theft transactions and would hide them in the (predicted) massive mempool of unconfirmed transactions that would have been accumulated. They would mine a big block, everyone would be so happy that BCH works again, and devs would be busy looking for sigop transactions.
Act 3) Hope that the chain gets locked in via checkpoint so the theft cannot be reverted
Act 4) Leak to the media that plenty of BCH were stolen after the fork and the ABC client is so faulty it caused a halt of the network after the upgrade
Act 5) Make a shitload of money by shorting BCH (there was news about a appearance of a big short position right after the fork)
But the people who planned this attack have underestimated the awareness and speed of the BCH dev team. They were probably sure that Act 1 would take hours or even days so the mempool would be extremely bloated (maybe they speculated that everyone paniced and wanted to get out of BCH) and Act 2 would consequently be successful because no one would spot their theft transactions quick enough.
But they didn't calculate that someone is working together with various BCH pools in precaution to prevent exactly this scenario (segwit theft) and even prepared transactions to move all locked coins back to their owners.
Prohashings orphaned block was likely unpredicted collateral damage as Jonathan suggests below, because they were not involved in the plan of the two pools who prepared to return the segwit coins. I'm guessing that the pools did not expect a miner with an attacking theft block that early and had to decide quickly what to do when they spotted it.
So now that both plans have been foiled, Plan B) is coming into place again. Guerrilla style fear mongering about how BCH is not decentralized. Spread this info secretly in the community with the proof in form of a signed message connected to the transactions. Of course, the attacker worked actually alone, attacked us for our own good, and will do so again, because the evil dictatorship devs have to be eradicated....
As an unwanted side effect of these events the BTC.top and BTC.com "partnership" has been exposed. So what do we do with this new revelation is a question that we probably have to discuss.
They worked together with someone who wanted to return the segwit coins and avoided a theft. They used their combined hashing dominance to avoid a theft. I applaud them for that. From a moral perspective this is defendable and my suspicion that we have more backing for BCH than you can see with your eye by following hash rate charts is now being revealed as true again.
But the dilemma BCH has is revealed again as well. we need more of the SHA-256 hash rate cake because we actually do not want that any entity in this space has more than 50% hash power.
*** EDIT 2 ***
Added Satoshi's quote from the whitepaper.
No comments:
Post a Comment