5 ms·
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://
by apo 8y ago
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 https://github.com/bitcoin/bitcoin/pull/14249/files
checkTransaction is defined in verify.cpp:
https://github.com/bitcoin/bitcoin/blob/master/src/consensus/tx_verify.cpp#L159 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.
- CVE-2018-17144 8y ago> 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.
- apo 8y agoFrom 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 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.
- CVE-2018-17144 8y ago> 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.
- stale2002 8y agoI'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.
- earlz 8y agoThere 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
- stale2002 8y agoO.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!
- deleted 8y ago[deleted]