Comment by apo | Hacker News Reader

Comment by apo | Hacker News Reader

From the commit that fixes the issue (CVE-2018-17144), the root cause was failure to call checkTransaction with the third (last) argument set to true:

https://github.com/bitcoin/bitcoin/pull/14249/files

checkTransaction is defined in verify.cpp:

https://github.com/bitcoin/bitcoin/blob/master/src/consensus...

The last argument, fCheckDuplicateInputs, causes inputs to be checked for duplicates. A comment inside this method notes:

// Check for duplicate inputs - note that this check is slow so we skip it in CheckBlock

To summarize, the fix appears to replace the faster call to checkTransaction in CheckBlock with the slower version that checks for duplicate inputs in each transaction of a new block. What's not clear to me yet is how failure to check for duplicate inputs in a block's transactions leads to DoS.

Many consider Bitcoin Core to define the Bitcoin protocol. If this is true, then the new release can be considered a soft fork update.

Previously, blocks containing transactions with duplicate inputs would have been considered valid. Now, such a block will be rejected by patched nodes.

This case is an excellent example of how difficult it is to determine what exactly the Bitcoin protocol actually requires.

We only gradually "discover" the protocol by exhaustively following every branch of the Bitcoin Core code base.

> Previously, blocks containing transactions with duplicate inputs would have been considered valid. Now, such a block will be rejected by patched nodes.

No, they would have crashed the node, they would not have been accepted as valid. This is not a soft fork.

From the Wiki:

A softfork is a change to the bitcoin protocol wherein only previously valid blocks/transactions are made invalid. ...

https://en.bitcoin.it/wiki/Softfork

It's not clear to me yet under what conditions a node would crash. With a single duplicate input? With dozens of duplicate inputs? Duplicate inputs spending segwit outputs?

If some duplicate inputs would have been permitted without crashing nodes then the update appears to fit the definition of soft fork.

edit: also, it appears the DoS vuln doesn't apply to pre-0.14 nodes. Either those nodes would have rejected dup-input blocks (making 0.14 a hard fork?) or the update just released could be seen as a soft fork.

> If some duplicate inputs would have been permitted without crashing nodes then the update appears to fit the definition of soft fork.

If this were the case it would be a complete failure of the system, rather than a DoS.

I've read that there was some sort of assert check, which would fail, and cause the whole node to crash.

Therefore fixing the crash is not a "soft fork* because nothing was accepted in the first place.

Yes, if it actually accepted the duplicate input, that would cause unlimited inflation, which is obviously a huge deal.

Or in other words. We got extremely lucky.

There appears to be a workaround to bypass the assert check in Bitcoin Core 0.16 that allows one to mint new coins by using an input multiple times and it be accepted by the network without crashing. Probably will be waiting until the dust settles on this before publishing that test case though, since it's clearly much more severe than a DoS

O.o wow, that is way worse than I expected.

Do you have a source for where this was written up, or did you come up with this on your own?

I just want to be able to reference back to this in the future. So whenever you decide to publish, I'd love to check it out!

Actually it only seems to be a side effect of our test environment. Using a more realistic environment makes it not effective, sorry for the false alarm

Hey thanks for the update!

But I'd encourage you to do a bit more investigation.

According to Bitcoin core, there is an inflation vulnerability.

https://bitcoincore.org/en/2018/09/20/notice/

So maybe you weren't too far off from independently discovering the vulnerability yourself.

Edit: apparently you were credited in discovering the vulnerability yourself in the very discloser that I linked.

Congrats!

The credit is currently wrong, it should belong to one of the developers on my team, David Jaenson.

My comment was an early disclosure before I fully understood how sensitive the details were. Even without going into detail or providing any code it was very irresponsible of me to off hand just mention that possibility. It didn't click how sensitive things were until a bitcoin core dev confirmed it. Sorry anyone who sees this. I merely reported the exploit, David Jaenson is our genius security researcher that definitely should deserve all credit.

Yeah. I'd rather you hadn't done that personally.

Reply on news.ycombinator.com