4 ms·

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

by 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 ago
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 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 ago
  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.
  - earlz 8y ago
    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
    - stale2002 8y ago
      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!
      - earlz 8y ago
        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
        stale2002 8y ago
        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/ 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!
        earlz 8y ago
        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.
deleted 8y ago
[deleted]

apo 8y ago

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 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 ago
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.
- earlz 8y ago
  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
  - stale2002 8y ago
    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!
    - earlz 8y ago
      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
      - stale2002 8y ago
        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/ 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!
        earlz 8y ago
        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.

deleted 8y ago

[deleted]