9 ms·

Crippling DDoS vulnerability put the entire Bitcoin market at risk

92 points by sahin-boydas 8y ago

stephengillie 8y ago
> The bug relates to its consensus code. It meant that some miners had the option to send transaction data twice, causing the Bitcoin network to crash when attempting to validate them. As such invalid blocks need to be mined anyway, only those willing to disregard block reward of 12.5BTC ($80,000) could actually do any real damage. Do the blocks need to be mined twice? Or do you just have to submit a garbage block for the second one?
- CVE-2018-17144 8y ago
  > Do the blocks need to be mined twice? Or do you just have to submit a garbage block for the second one? No. One transaction included twice in a single block.
guidovranken 8y ago
I spend a lot of time looking for bugs in cryptocurrency code. In spite of this finding, I'd say that Bitcoin Core is among the safest cryptocurrency applications. The average random C/C++ open source project suffers from far more potential issues, for example [1]. Related, here's an unfixed btcd (Go Bitcoin client) DoS [2]. [1] https://bugs.chromium.org/p/oss-fuzz/issues/list?q=imagemagick https://bugs.chromium.org/p/oss-fuzz/issues/list?q=imagemagi... [2] https://github.com/btcsuite/btcd/issues/1287 https://github.com/btcsuite/btcd/issues/1287
- simias 8y ago
  You may be right about the relative security of Bitcoin (given that it's the oldest and one of the most audited codebases while also missing some of the more complex and potentially problematic features of other cryptocurrencies it seems like a reasonable assumption) however I'm not sure if it makes a lot of sense to compare it with other "random" open source projects. The problem with Bitcoin is that any vulnerability can usually be exploited very easily for huge gains. You have a DDoS? Short BTC, run it, make millions. Remote code execution in the client? Steal funds, make millions. Easy and untraceable if you're careful. That's the whole drawback of the immutable ledger approach, if you get screwed the only solution is to convince everybody else to do a hardfork. If you're a bitcoin billionaire with relations in the big bitcoin shops you could get it to work, if you're a rando with a dozen bitcoins stolen from your account you're on your own. Even something as bad as heartbleed seems almost benign in comparison since it's significantly harder to exploit, especially at a large scale.
  - CVE-2018-17144 8y ago
    Bitcoin Core has, from day one, been a remarkably safe code base generally speaking. The protocol is free (or used to be) of any string manipulation or other behavior that often leads to code execution. Many major issue causing features were added after the departure of Satoshi, and are generally considered to be mistakes for other reasons (BIP70 introduced a dependency on OpenSSL for the GUI wallet, which is being deprecated and is now a compile time option). For the most part any issues in the original code are to do with consensus level understanding of how the system operated, which is to be expected given that the entire construction was novel at the time of its creation. People often repeat a mantra that the Satoshi code was bad, when it was surprisingly problem free given the enormous amount it accomplishes. I personally pondered if this particular issue would have any market effects and concluded that it would not substantially. This is based on fact that there's altcoins in existence with > 800 day consensus level failures disclosed privately, or publicly known, which still have reasonably active trading. Some altcoins manage to exist with almost no operational network at all, just a pool, a node or two run by the creator, and an exchange with substantial internal volume and not a lot else. For altcoins in particular it's difficult to actually know if this is representative of what would happen in Bitcoin, some of the issues I'm aware of in altcoins simply haven't been exploited because there's not enough profit in it at the moment, even though the design decisions in these altcoins (eg, facets of proof of stake) are then used to justify the safety of other systems.
    - the_clarence 8y ago
      For what is worth, Ethereum main clients are developed in Go and Rust, their security stance is even more impressive imo.
      - CVE-2018-17144 8y ago
        The ethereum network has substantial issues stemming from very poorly defined consensus rules, which manage to grow in complexity every time you look away. The sheer scale of the consensus critical code makes it review resistant. I've been in the room with proficient auditors and struggled to make heads or tails of exactly what some forms of the code are doing. The scripting languages people use being compiled down into a very strange bytecode complicates matters even worse. The underlying type of the VM being 256 bit has caused the compilers to do heavy amounts of bit packing for efficiency, which makes reasoning about their behavior substantially harder than it should be. It's a struggle to call any of this system well designed with a straight face. To all of this, I have sat with developers in exchanges who are at a complete loss how to deal with the poor RPC interfaces given. Simple tasks like receiving money as deposits from clients have a never ending stream of edge cases due to contracts and addresses being in the same name space, dealing with combining inputs using multiple transactions with some confirming and some not (leading to partial withdraws, or partial deposits), sequence number behavior driving everybody insane. I can't speak to the hype around "building on ethereum" as I've never been a part of that, but on a basic level the tools presented are unusable, regardless of what language the client you have chosen to use are written in. The RPC interface in Bitcoin is at least straight forward, with primitives that largely make sense. It's not without fault and some things require kludges or result in head scratching, but it's not as crazy as Ethereum's.
- roasbeef 8y ago
  For your second, link, the PoC example there by passes the regular strict signature encoding checks. These are on by default, with some being policy, and some being consensus. As a result, this won't be hit in practice by regular nodes, but may be hit by developers using the library for other purposes: https://github.com/btcsuite/btcd/issues/1287#issuecomment-423384745 https://github.com/btcsuite/btcd/issues/1287#issuecomment-42...
londons_explore 8y ago
Had this been exploited, it wouldn't have caused that much damage. Some exchanges would probably have gone offline for a few hours. Nobody would have lost any money or bitcoins.
- CVE-2018-17144 8y ago
  > Nobody would have lost any money or bitcoins. That's not entirely true. The current crop of Lightning Network nodes rely on their host being up for the safety of their channels. If their node is not contactable for more than 24 hours they risk having their money stolen. Large changes in the network graph has been shown in Bitcoin to take quite a while to sort out, due to the way the rumoring network attempts to find stable and reliable peers. This is still a substantial problem now, as there's only a few thousand listening peers that can accept incoming connections out of over 10,000 total. If only those nodes were remaining online there would be substantially reduced capacity to relay blocks and transactions for a period.
- village-idiot 8y ago
  No coins would be stolen, but those who trade on bitcoin futures would be heavily affected.
ndury 8y ago
The title is kind of clickbaitish... Taken into consideration that a miner has to sacrifice ~$80000 (12.5 BTC) I don't see this happening.
- mtrycz2 8y ago
  ...assuming "rational" behaviour. A state-actoru, could certainly burn that, and much more.
- sschueller 8y ago
  I guess we have some time before the block rewards drops to 6.75 BTC. (~21 May 2020 21:49:54) [1] [1] https://www.bitcoinblockhalf.com/ https://www.bitcoinblockhalf.com/
- snarf21 8y ago
  It also isn't entirely true the entire network is/was at risk. Not all nodes connect to all other nodes. So a malicious actor would have to waste the money and only bring down the nodes directly connected. Most nodes today aren't accepting new connections. Also it only affects full nodes not SPV. I think the best attack vector would be to crash competing nodes but remember they have to spend a block reward to do so and all they get in reward is a block reward. The miners have enlightened self interest to not do so. I think the risk has been blown out of proportion but they are being smart and showing an abundance of caution to make sure this does allow for use case they aren't considering or some other cascading failure.
  - CVE-2018-17144 8y ago
    You can walk the network and crash all nodes with listening sockets, this ruins pretty much everything. There's some non-public infrastructure that would perhaps make mining continue, but non-listening nodes can't exist without sockets, and neither can SPV nodes.
- HashBasher 8y ago
  Plus cost of electricity of keeping his miners on until he manages to mine a full block.
KasianFranks 8y ago
We're witnessing the maturation of crypto as these kinds of resolutions only make it stronger. It's going to be used as a flight-to-quality asset class after the traditional markets crack in a few months.
- swift532 8y ago
  Why do you think traditional markets should crack in a few months?
  - KasianFranks 8y ago
    1. They always do. 2. We've been in the longest bull market in history 3. Black Swans exists 4. The 'message of the markets' in this case, the yield curve along with a few other related reliable predictors: https://fred.stlouisfed.org/series/T10Y3MM https://fred.stlouisfed.org/series/T10Y3MM
    - jrockway 8y ago
      Why does Bitcoin help here? The traditional markets attempt to assign a value to the expected future value of all (public) companies. As technology advances, goods and services can be produced and delivered more efficiently, allowing $1 to buy more. Investing in the stock market is using your money to drive the improvements, and selling your stock is reaping those rewards. Bitcoin is just a list of financial transactions that a couple of different computers agreed on the order of. I don't see how they are comparable.
      - madeuptempacct 8y ago
        Because people hoard stuff with a "limited amount" (i.e. gold and silver) when they are afraid of hyper-inflation.
- ceejayoz 8y ago
  You know the "this is good for Bitcoin!" response to any negative news is mostly a joke these days, right?
ccnafr 8y ago
This article is wrong and plain ol' fearmongering. A coordinated denial of service on network nodes is theoretical at best, as it would require a series of further, orchestrated actions on the rest of the blocks to achieve it. This flaw alone isn't likely enable such an attack. Furthermore, most nodes will upgrade very quickly, greatly reducing the attack surface.
- CVE-2018-17144 8y ago
  > This article is wrong and plain ol' fearmongering. A coordinated denial of service on network nodes is theoretical at best, as it would require a series of further, orchestrated actions on the rest of the blocks to achieve it. This requires no action other than pushing a specific binary to an unpatched node in order for it to crash. The cost of producing the binary is one time, approximately $80k USD depending on luck.
  - HashBasher 8y ago
    Wouldn't the cost be significantly higher than $80k since the miner would have to keep his machines on for quite some time at a loss in order to mine a full block?
- stale2002 8y ago
  It is not fear mongering. Someone else in the thread pointed out that there is a way to get around the crashing node assert check, and instead create infinite inflation. The bug is significantly more network destroying than what was previously thought, if this claim is true.
decentralised 8y ago
>This could have been waaaaay worse The cost of the attack would far exceed ~80k USD in bitcoin block rewards because it requires a substantial amount of hashing power to have a realistic chance of successfully producing a block that reaches consensus and is added to the canonical chain.
- CVE-2018-17144 8y ago
  > The cost of the attack would far exceed ~80k USD in bitcoin block rewards because it requires a substantial amount of hashing power to have a realistic chance of successfully producing a block that reaches consensus and is added to the canonical chain. No, the cost is simply $80k on average to find a block, or around $5k for BCash. If the cost to produce a block exceeded its value substantially, it would be on a whole unprofitable for Bitcoin miners to continue existing at this point in time (network difficulty, bitcoin price).
  - HashBasher 8y ago
    $80k on average regardless of hashpower? Then it would be a total cost of ~$160k with the loss of potential revenue.
  - lawn 8y ago
    > BCash It's Bitcoin Cash. https://medium.com/@jonaldfyookball/why-some-people-call-bitcoin-cash-bcash-this-will-be-shocking-to-new-readers-956558da12fb https://medium.com/@jonaldfyookball/why-some-people-call-bit...
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 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.
nickbauman 8y ago
Isn't the proof-of-work algorithm itself a DDoS? PoW requires all nodes in the network to see a consistent state of a transaction for it to be correct. By definition this violates the CAP theorem.
- muthdra 8y ago
  Small addendum to the shortcomings of the CAP conjecture: https://codahale.com/you-cant-sacrifice-partition-tolerance/ https://codahale.com/you-cant-sacrifice-partition-tolerance/
koolba 8y ago
> As such invalid blocks need to be mined anyway, only those willing to disregard block reward of 12.5BTC ($80,000) could actually do any real damage. > While this certainly seems unlikely (barring any digital Tyler Durden-types wanting to destroy something beautiful), it does raise eyebrows. The great defence of Bitcoin is that it’s far too decentralized to be brought down by any single entity. Generic turmoil of the platform could panic selling. $80K to cause mass disruption could pay off considerably for someone shorting either bitcoin or an altcoin.
dev_dull 8y ago
How long until a 0day wipes out the entire market?
- rebuilder 8y ago
  What would it take to do that? Something entirely unpatchable, I expect. I'm having trouble imagining what kind of exploit would be that powerful.
  - earlz 8y ago
    This has happened with other, much smaller, cryptocurrencies. The choice usually agreed upon by exchanges, developers, and community is to pick a known good block before the attack and fork the chain backwards from that point. It requires significant downtime and is of course very complicated, but several different cryptocurrencies have used this method and recovered to a functioning blockchain
    - once_inc 8y ago
      > several different cryptocurrencies have used this method and recovered to a functioning blockchain The most notable is Ethereum, with the DAO hack and the subsequent bailout. Did lead to Ethereum Classic, which is a fork that gained some traction.
runciblespoon 8y ago
Are these bitcoin exchanges just a gigantic implimentation of a pyramid scheme. I mean where is the added value coming from? Are they similar to “over unity” machines in physics?

92 points by sahin-boydas 8y ago

> The bug relates to its consensus code. It meant that some miners had the option to send transaction data twice, causing the Bitcoin network to crash when attempting to validate them. As such invalid blocks need to be mined anyway, only those willing to disregard block reward of 12.5BTC ($80,000) could actually do any real damage. Do the blocks need to be mined twice? Or do you just have to submit a garbage block for the second one?

CVE-2018-17144 8y ago
> Do the blocks need to be mined twice? Or do you just have to submit a garbage block for the second one? No. One transaction included twice in a single block.

guidovranken 8y ago

I spend a lot of time looking for bugs in cryptocurrency code. In spite of this finding, I'd say that Bitcoin Core is among the safest cryptocurrency applications. The average random C/C++ open source project suffers from far more potential issues, for example [1]. Related, here's an unfixed btcd (Go Bitcoin client) DoS [2]. [1] https://bugs.chromium.org/p/oss-fuzz/issues/list?q=imagemagick https://bugs.chromium.org/p/oss-fuzz/issues/list?q=imagemagi... [2] https://github.com/btcsuite/btcd/issues/1287 https://github.com/btcsuite/btcd/issues/1287

simias 8y ago
You may be right about the relative security of Bitcoin (given that it's the oldest and one of the most audited codebases while also missing some of the more complex and potentially problematic features of other cryptocurrencies it seems like a reasonable assumption) however I'm not sure if it makes a lot of sense to compare it with other "random" open source projects. The problem with Bitcoin is that any vulnerability can usually be exploited very easily for huge gains. You have a DDoS? Short BTC, run it, make millions. Remote code execution in the client? Steal funds, make millions. Easy and untraceable if you're careful. That's the whole drawback of the immutable ledger approach, if you get screwed the only solution is to convince everybody else to do a hardfork. If you're a bitcoin billionaire with relations in the big bitcoin shops you could get it to work, if you're a rando with a dozen bitcoins stolen from your account you're on your own. Even something as bad as heartbleed seems almost benign in comparison since it's significantly harder to exploit, especially at a large scale.
- CVE-2018-17144 8y ago
  Bitcoin Core has, from day one, been a remarkably safe code base generally speaking. The protocol is free (or used to be) of any string manipulation or other behavior that often leads to code execution. Many major issue causing features were added after the departure of Satoshi, and are generally considered to be mistakes for other reasons (BIP70 introduced a dependency on OpenSSL for the GUI wallet, which is being deprecated and is now a compile time option). For the most part any issues in the original code are to do with consensus level understanding of how the system operated, which is to be expected given that the entire construction was novel at the time of its creation. People often repeat a mantra that the Satoshi code was bad, when it was surprisingly problem free given the enormous amount it accomplishes. I personally pondered if this particular issue would have any market effects and concluded that it would not substantially. This is based on fact that there's altcoins in existence with > 800 day consensus level failures disclosed privately, or publicly known, which still have reasonably active trading. Some altcoins manage to exist with almost no operational network at all, just a pool, a node or two run by the creator, and an exchange with substantial internal volume and not a lot else. For altcoins in particular it's difficult to actually know if this is representative of what would happen in Bitcoin, some of the issues I'm aware of in altcoins simply haven't been exploited because there's not enough profit in it at the moment, even though the design decisions in these altcoins (eg, facets of proof of stake) are then used to justify the safety of other systems.
  - the_clarence 8y ago
    For what is worth, Ethereum main clients are developed in Go and Rust, their security stance is even more impressive imo.
    - CVE-2018-17144 8y ago
      The ethereum network has substantial issues stemming from very poorly defined consensus rules, which manage to grow in complexity every time you look away. The sheer scale of the consensus critical code makes it review resistant. I've been in the room with proficient auditors and struggled to make heads or tails of exactly what some forms of the code are doing. The scripting languages people use being compiled down into a very strange bytecode complicates matters even worse. The underlying type of the VM being 256 bit has caused the compilers to do heavy amounts of bit packing for efficiency, which makes reasoning about their behavior substantially harder than it should be. It's a struggle to call any of this system well designed with a straight face. To all of this, I have sat with developers in exchanges who are at a complete loss how to deal with the poor RPC interfaces given. Simple tasks like receiving money as deposits from clients have a never ending stream of edge cases due to contracts and addresses being in the same name space, dealing with combining inputs using multiple transactions with some confirming and some not (leading to partial withdraws, or partial deposits), sequence number behavior driving everybody insane. I can't speak to the hype around "building on ethereum" as I've never been a part of that, but on a basic level the tools presented are unusable, regardless of what language the client you have chosen to use are written in. The RPC interface in Bitcoin is at least straight forward, with primitives that largely make sense. It's not without fault and some things require kludges or result in head scratching, but it's not as crazy as Ethereum's.
roasbeef 8y ago
For your second, link, the PoC example there by passes the regular strict signature encoding checks. These are on by default, with some being policy, and some being consensus. As a result, this won't be hit in practice by regular nodes, but may be hit by developers using the library for other purposes: https://github.com/btcsuite/btcd/issues/1287#issuecomment-423384745 https://github.com/btcsuite/btcd/issues/1287#issuecomment-42...

londons_explore 8y ago

Had this been exploited, it wouldn't have caused that much damage. Some exchanges would probably have gone offline for a few hours. Nobody would have lost any money or bitcoins.

CVE-2018-17144 8y ago
> Nobody would have lost any money or bitcoins. That's not entirely true. The current crop of Lightning Network nodes rely on their host being up for the safety of their channels. If their node is not contactable for more than 24 hours they risk having their money stolen. Large changes in the network graph has been shown in Bitcoin to take quite a while to sort out, due to the way the rumoring network attempts to find stable and reliable peers. This is still a substantial problem now, as there's only a few thousand listening peers that can accept incoming connections out of over 10,000 total. If only those nodes were remaining online there would be substantially reduced capacity to relay blocks and transactions for a period.
village-idiot 8y ago
No coins would be stolen, but those who trade on bitcoin futures would be heavily affected.

ndury 8y ago

The title is kind of clickbaitish... Taken into consideration that a miner has to sacrifice ~$80000 (12.5 BTC) I don't see this happening.

mtrycz2 8y ago
...assuming "rational" behaviour. A state-actoru, could certainly burn that, and much more.
sschueller 8y ago
I guess we have some time before the block rewards drops to 6.75 BTC. (~21 May 2020 21:49:54) [1] [1] https://www.bitcoinblockhalf.com/ https://www.bitcoinblockhalf.com/
snarf21 8y ago
It also isn't entirely true the entire network is/was at risk. Not all nodes connect to all other nodes. So a malicious actor would have to waste the money and only bring down the nodes directly connected. Most nodes today aren't accepting new connections. Also it only affects full nodes not SPV. I think the best attack vector would be to crash competing nodes but remember they have to spend a block reward to do so and all they get in reward is a block reward. The miners have enlightened self interest to not do so. I think the risk has been blown out of proportion but they are being smart and showing an abundance of caution to make sure this does allow for use case they aren't considering or some other cascading failure.
- CVE-2018-17144 8y ago
  You can walk the network and crash all nodes with listening sockets, this ruins pretty much everything. There's some non-public infrastructure that would perhaps make mining continue, but non-listening nodes can't exist without sockets, and neither can SPV nodes.
HashBasher 8y ago
Plus cost of electricity of keeping his miners on until he manages to mine a full block.

KasianFranks 8y ago

We're witnessing the maturation of crypto as these kinds of resolutions only make it stronger. It's going to be used as a flight-to-quality asset class after the traditional markets crack in a few months.

swift532 8y ago
Why do you think traditional markets should crack in a few months?
- KasianFranks 8y ago
  1. They always do. 2. We've been in the longest bull market in history 3. Black Swans exists 4. The 'message of the markets' in this case, the yield curve along with a few other related reliable predictors: https://fred.stlouisfed.org/series/T10Y3MM https://fred.stlouisfed.org/series/T10Y3MM
  - jrockway 8y ago
    Why does Bitcoin help here? The traditional markets attempt to assign a value to the expected future value of all (public) companies. As technology advances, goods and services can be produced and delivered more efficiently, allowing $1 to buy more. Investing in the stock market is using your money to drive the improvements, and selling your stock is reaping those rewards. Bitcoin is just a list of financial transactions that a couple of different computers agreed on the order of. I don't see how they are comparable.
    - madeuptempacct 8y ago
      Because people hoard stuff with a "limited amount" (i.e. gold and silver) when they are afraid of hyper-inflation.
ceejayoz 8y ago
You know the "this is good for Bitcoin!" response to any negative news is mostly a joke these days, right?

ccnafr 8y ago

This article is wrong and plain ol' fearmongering. A coordinated denial of service on network nodes is theoretical at best, as it would require a series of further, orchestrated actions on the rest of the blocks to achieve it. This flaw alone isn't likely enable such an attack. Furthermore, most nodes will upgrade very quickly, greatly reducing the attack surface.

CVE-2018-17144 8y ago
> This article is wrong and plain ol' fearmongering. A coordinated denial of service on network nodes is theoretical at best, as it would require a series of further, orchestrated actions on the rest of the blocks to achieve it. This requires no action other than pushing a specific binary to an unpatched node in order for it to crash. The cost of producing the binary is one time, approximately $80k USD depending on luck.
- HashBasher 8y ago
  Wouldn't the cost be significantly higher than $80k since the miner would have to keep his machines on for quite some time at a loss in order to mine a full block?
stale2002 8y ago
It is not fear mongering. Someone else in the thread pointed out that there is a way to get around the crashing node assert check, and instead create infinite inflation. The bug is significantly more network destroying than what was previously thought, if this claim is true.

decentralised 8y ago

>This could have been waaaaay worse The cost of the attack would far exceed ~80k USD in bitcoin block rewards because it requires a substantial amount of hashing power to have a realistic chance of successfully producing a block that reaches consensus and is added to the canonical chain.

CVE-2018-17144 8y ago
> The cost of the attack would far exceed ~80k USD in bitcoin block rewards because it requires a substantial amount of hashing power to have a realistic chance of successfully producing a block that reaches consensus and is added to the canonical chain. No, the cost is simply $80k on average to find a block, or around $5k for BCash. If the cost to produce a block exceeded its value substantially, it would be on a whole unprofitable for Bitcoin miners to continue existing at this point in time (network difficulty, bitcoin price).
- HashBasher 8y ago
  $80k on average regardless of hashpower? Then it would be a total cost of ~$160k with the loss of potential revenue.
- lawn 8y ago
  > BCash It's Bitcoin Cash. https://medium.com/@jonaldfyookball/why-some-people-call-bitcoin-cash-bcash-this-will-be-shocking-to-new-readers-956558da12fb https://medium.com/@jonaldfyookball/why-some-people-call-bit...

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 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.

nickbauman 8y ago

Isn't the proof-of-work algorithm itself a DDoS? PoW requires all nodes in the network to see a consistent state of a transaction for it to be correct. By definition this violates the CAP theorem.

muthdra 8y ago
Small addendum to the shortcomings of the CAP conjecture: https://codahale.com/you-cant-sacrifice-partition-tolerance/ https://codahale.com/you-cant-sacrifice-partition-tolerance/

koolba 8y ago

> As such invalid blocks need to be mined anyway, only those willing to disregard block reward of 12.5BTC ($80,000) could actually do any real damage. > While this certainly seems unlikely (barring any digital Tyler Durden-types wanting to destroy something beautiful), it does raise eyebrows. The great defence of Bitcoin is that it’s far too decentralized to be brought down by any single entity. Generic turmoil of the platform could panic selling. $80K to cause mass disruption could pay off considerably for someone shorting either bitcoin or an altcoin.

dev_dull 8y ago

How long until a 0day wipes out the entire market?

rebuilder 8y ago
What would it take to do that? Something entirely unpatchable, I expect. I'm having trouble imagining what kind of exploit would be that powerful.
- earlz 8y ago
  This has happened with other, much smaller, cryptocurrencies. The choice usually agreed upon by exchanges, developers, and community is to pick a known good block before the attack and fork the chain backwards from that point. It requires significant downtime and is of course very complicated, but several different cryptocurrencies have used this method and recovered to a functioning blockchain
  - once_inc 8y ago
    > several different cryptocurrencies have used this method and recovered to a functioning blockchain The most notable is Ethereum, with the DAO hack and the subsequent bailout. Did lead to Ethereum Classic, which is a fork that gained some traction.

runciblespoon 8y ago

Are these bitcoin exchanges just a gigantic implimentation of a pyramid scheme. I mean where is the added value coming from? Are they similar to “over unity” machines in physics?