sigop counting

Jun 16, 19

sigop counting

It's all about a message. I'll not sugar coat it. What I'll do is bad. It's a hard call.

But then it got worse. This message was 90% ready. I had to create a new section.

Some background

I'm a Bitcoin Cash supporter. Don't believe me? Read below. It shows how I reverted it.

I first got bitcoin in 2015. I contributed bug fixes to bitcoin core. ABC still has my code. In 2017 I converted all to BCH.

I'm professional security researcher. And I don't like the way things are in BCH. People are convinced everything is fine and better. Is it?

How I found the bug?

In March I read schnorr works in any OP_CHECKSIG. A bug would be catastrophic! I was worried.

I took last week off. I decided to review schnorr in BCH clients. I believed miners used exclusively ABC. ABC got 80% of my time. I lightly reviewed BU and bchd changes.

ABC's code is close to bitcoin core from 2017. I have an eye for vulnerabilities. I'm comfortable navigating other people's code. I do it everyday for a living. I had fuzzers to compare BU and ABC. 7000 hours of computing time. In 5 days of work, I found 5 problems in ABC. 2 with high score. Schnorr is solid. Segwit recovery looked funny, but harmless. None of the problems put coins in risk. I only took notes, no report. I will, probably.

About the other clients. Changes for the HF seemed ok.

This sigop counting bug is medium score. It affects block generation. The risk is hours with no or empty blocks. Unless everyone is ready to detect and take action. This makes it low score.

Why use it?

Monday I read something that triggered me. It was the quintessence of everything that bothers me.

I miss the time we had Tom Harding, Tom Zander, kyuupichan, Andrew Stone and Peter R actively working on BCH. Shadders too was insightful and knowledgeable. Everyone left is completely aligned with ABC. We pushed them out. We're back to a developer centralized system. Is it different than core? Yet WE COLLECTIVELY DENY IT everyday.

ABC has great developers. Bugs happen. But I think even they don't know how bad this singleculture is. A BU singleculture is just as bad. A BSV singleculture is bad.

What happened since November? Where are opposing voices? 10 block finalization? PoW penalty for deep reorgs? Aren't they 'complex systems and technical debt' too? Other clients disagree with these soft-fork changes. Why not remove them? Who decided the features for this HF?

They are allowed to do it. Businesses and miners prefer ABC "because of reliability". I read about historic BU bugs. What about ABC's?

Developers make an impact by choosing where to develop their ideas.

Users make an impact by collectively choosing which coin to use.

Entrepreneurs make an impact by choosing where to build.

I'm just one user. How could I make an (controlled) impact to get a message through?

What I did is bad. It was hard call. It's childish. I've sent 150 reports for open source projects. I do it on free time. Never exploited any. But I prefer to have dirty hands than live to see core 2.0. Than relive 2015 and 2016 again. Isn't BCH all for "making breaking changes while we are small"? If don't change this singleculture now, it won't change in the future. We have other clients. BU and bchd are great options. Why businesses and miners don't run them? How many more bugs they need? One that need one full day to fix?

I decided to wait for the upgrade. Miners and developers would be monitoring. I decided to wait a few blocks after activation. They should see it was not fault of the HF. I decided to donate 1.8BCH. Mostly in miner fees. For the extra work I caused. I had an e-mail ready for ABC. Not needed, soon the fix was in their repo. Nothing less than expected, they are pros. But so are the others.

And I had a way to revert the situation before a fix. And it did revert. On block 582698.

Where did those transactions go?

Those transactions were valid. BU would have some every block.

I had 8 recover transactions. Each respent the one small input of many poison transactions. BU relay double-spends. I connected to many many nodes. I kept mutating them to keep relaying going. Poison transactions were sent only once.

Example of recover transaction: e5c34dcffd3e645e4a770f58276ed35be74fbb815ce46f9b550393858d3b5ca1

(Find other 7 recover transactions in 582698. They link to all coins. You can take them.)

After the 1st poison transaction, I started broadcasting recover transactions. I expected miners to restart and clear the mempool. If they connect to a BU node before the next poison transaction, 50% chance of getting a recover transaction. Once recover transactions got in, a miner had up to 30 minutes free of poison transactions. Had a block been found, all previous poison transactions would go away. This happened on 582698. They all vanished on 15:43Z. See mempool graphs. I stopped broadcasting.

But blocks 582698 and 582699 were reorged. I worried this was a race condition. The miner that reorg wouldn't have the recover transactions from unknown's 582698. They could still be mining empty blocks. Because they could have poison transactions.

Wait. What was that reorg?

Usually block time is close to clock time. Miners get new block templates in fixed periods (except prohashing?).

BTC.TOP mined 582697 at 15:42Z. It was the first block mining transactions. No recover transaction were mined. BTC.TOP was fixed! They have large hash rate. When they move to BCH, a block comes every 3 or 4 minutes. They mine 4 blocks in a row. They should have restarted around 15:38Z. Yet they had no recover transaction, sent every minute. Maybe not connected to a BU node?

Unknown's 582698 came at 15:43Z. It had all recover transactions. Mempool in all nodes was clean of poison. Mempool graphs show this.

Prohashing mined 582699 at 16:04Z. They took a lot of transactions from clean mempool.

BTC.TOP's 582698 was mined eleven minutes after unknown's, 15:54Z. Surprise. It had all recover transactions from unknown's 582698. Exactly the same! But this can't be. I explain why.

I mutated recover transactions by shuffle of input order. Of all already sent recover transactions. Every minute. I can tell when unknown restarted his node. It was right before 15:28Z. BTC.TOP didn't have them. If they had, they would be in BTC.TOP's 582697. If BTC.TOP restarted any other minute, if they had recover transactions, other version of it would be mined.

But they were all the same! The answer: invalidateblock carried by BTC.TOP (582698 and 582699) and BTC.COM (582700). This was not a race condition. This was not because of sigop couting. The network was free from poison. Since unknown's 582698 was mined.

It took hours to understand. Unknown's 582698 spent a few segwit coins. Run getblock on it and see. Five blocks later BTC.TOP's (the same that invalidated that block) spent those same and others segwit coins. That's motive. They were returning those coins. They were not alone. BTC.COM had invalidateblock too, they built on that chain. I believe miners had online meeting with ABC developers to talk about the fix. I assume they used this open channel. To coordinate a reorg to revert unknown's transactions. This is a 51% attack. The absolutely worst attack possible. It's there in the whitepaper. What about (miner and developer) decentralized and uncensorable cash? Only when convenient?

Unknown's actions are doubtful. BTC.TOP recovered coins for owners. Recovering is better. But they were late. "The bitcoin community does not condone the censorship of transactions." Much less a 51% attack. People bashed Binance Zhao for even considering it. For a 7000BTC HACK. It doesn't matter it was a 7000BTC HACK. It doesn't matter unknown took segwit coins. Bitcoin value depends on security. If it's not secure, it has no value. BTC.TOP and BTC.COM know this. A 51% attack happened on BCH under everyone's noses.

Funny this is. People started seeing this was intentional. And they celebrate?

"First they came for the unknown miner's transaction, and I did not speak out--"

"Because I was not unknown miner"

"Then they came for prohashing's block, and I did not speak out--"

"Because I was not prohashing"

"Then they came for me …"

Future

In ABC's code there is a quote. "Never go to sea with two chronometers; take one or three.". Take three, trust the two that match. It could have avoided it all. It benefits the entire community. Multiple clients competing to be one of the three. Instead, what we have is one client controlled by few people. They say you can contribute. Will they merge? They still control the repo.

Call me an idiot. Call me worse. But say no to this singleculture. Don't applaud a 51% attack. Even if it was "ok this one time". I did what I did for the sake of Bitcoin Cash. But now I'm scared. I see you in 6 months. This time only reporting.

bitcoin-cli verifymessage qpsr4mf5mlhysr35lkz6pyaz2pegsydjzuf7qtfwj7 H6QKkPXt2D/WRZYhcIR3sY3GUBCDK3y4xrv88uNEqT88TjMbR0/DkCike91vvrs95H/1BbgIKJHHvIeFKb/p1+Q= "For the sake of Bitcoin Cash"


Upvotes (0)
No one upvoted yet. You can be the first one!

Comments (3)
sort by  /

21 May 19 12:41

If you are willing, I would like to discuss technical aspects of your fuzzing infrastructure. I'm "andrewstone" on keybase, or let me know what you use.

0   0  

18 May 19 08:27

This is a very unfortunate situation, but it is also what proof of work actually is. The miners in this case did choose to drop prohashes block and from what I heard, it is because they deemed a transaction within it to have been invalid.

Invalid in the sense that the HF re-enabled miners to help others recover from misstakenly having sent BCH to a segwit address, but prohashings block is alleged to have sent those funds elsewhere. I don't have all the details, and I would love to get a more consistent view of the events that unfolded.

It might also be worth noting that from the perspective of the miners this might've looked like an active attack on the network and they acted in the way that best safeguards their funds future value.

I strongly and absolutely agree with the monoculture issue though. We truly need a more diverse node and miner software distribution.

2   0  

17 May 19 10:57

Reading this, will try to digest more after another two readings. Meanwhile it seems we have a healthy number of nodes using BU at 714 compared to ABC at 782.

0   0