The last time Hackerfall tried to access this page, it returned a not found error. A cached version of the page is below, or clickhereto continue anyway

Undocumented Double-spend Risk in Bitcoin James Hudon Medium

Undocumented Double-spend Risk inBitcoin

A bug report for decentralized block chains.

The ways of double-spending in Bitcoin mostly fall in 2 categories:

  1. Controlling sufficient hash-rate such as in the Majority Attack or 51% attack
  2. Double-spending 0-confirmation transactions such as through a Race Attack

However, there is a third category of double-spends that is barely documented as far as I can tell: double-spending through full node consensus failure. There is a risk that a significant portion of nodes fall out of consensus and this can be taken advantage of to double-spend bitcoin. No one has quantified this risk, therefore we cannot claim that Bitcoin solves the Byzantine Generals problem.

Below is a bug report with potential workarounds.

Setup:

As you know, bitcoin nodes accept the valid block chain with the most work. Now, imagine that there is a majority consensus (eg. 60%) among network nodes that a non-backward-compatible protocol change will happen at block height X and that these nodes are not running the reference client (not Bitcoin Core). This change can be, for example, a change to the PoW algorithm to mitigate miner centralization.

A block chain making non-backward-compatible protocol changes (fromhere)

Expected outcome:

After block height X, bitcoin nodes all follow the valid most work chain because there can only be 1 valid chain.

Actual outcome:

At block height X, bitcoin nodes will disagree on what valid means and perpetuate two chains of bitcoin. For example, the majority-supported chain may claim that valid means uses s-crypt hashing and the minority-supported chain may claim that valid means uses SHA-256 hashing. The majority of nodes will relay new-PoW blocks but the Bitcoin Core nodes will relay a differentstill validblock chain, where valid means something different.

The risk is a loss of funds through double-spending. The potential damage is hard to estimate because double-spending can happen for as long as the majority-supported chain disagrees with the minority-supported chain on the definition of valid. Unlike a hash-rate double-spend, this is not necessarily an attack. It is more simply a system failure.

Reproducing thebug:

  1. On a regtest network, run 10 nodes: 6 bcoin clients and 4 reference clients (Bitcoin Core).
  2. Create three addresses. Label them Alice, Bob and Charlie.
  3. Confirm enough blocks to see the 10 nodes be in consensus and fund Alices bitcoin address.
  4. Have a majority of nodes (the 6 bcoin nodes) accept and relay only blocks with a new PoW hashing function. Keep mining blocks until the block chain forks.
  5. Create a transaction that sends from Alice to Bob and a transaction that sends from Alice to Charlie.
  6. Confirm the Alice-Bob transaction on the majority-supported chain, and the Alice-Charlie transaction on the minority-supported chain.
  7. Keep mining on both chains and observe how consensus on Alices transaction is never reached. Alice has double-spent Bitcoin to both Bob and Charlie.

Potential Workarounds:

Continue reading on medium.com