Unused Output Tree in the Blockchain


I have been reading about the security of thin clients and I came across the section that discusses the proposal of Unused Output Tree in the Block chain.

Unused Output Tree in the Block chain (UOT) There have been several proposals (the first appears to be this one by gmaxwell, who called it an "open transaction tree", although the term "open" is now taken to mean "not yet mined into the block chain" rather than "unspent") to form a tree of unused transaction outputs at each block in the chain, hash it as a Merkle tree, and encode the root hash in the block chain (probably as part of the coinbase input). This will be called an Unused Output Tree (UOT). The first detailed proposal so far appears to be Alberto Torres' proposal; etotheipi's ultimate block chain compression is a variant of this.

If such UOT hashes were included in the block chain, a client which shipped with a checkpoint block that had a UOT would only need to download blocks after the checkpoint. Moreover, once the client had downloaded those blocks and confirmed their UOTs, it could discard all but the most recent block containing a UOT.

I understand this part, and how the merkle tree is going to be constructed, but the next part that talks about associated risks is what confuses me:

Hostile miners may insert blocks into the chain which have what claims to be a UOT, but which is actually invalid. It is unlikely that such blocks could be kept out of the chain because, again, this would require adding a new block validity criterion, and miners implementing this new criterion would risk "mining on the wrong side" of a fork, which could cost them a lot of money. Therefore, any UOT strategy would need to cope with the fact that not every block containing a UOT entry can be trusted.

So my questions are:

  1. I assume that an invalid UOT means a tree that contains outputs that are either double spend, or doesn't even exist in the chain. Why wouldn't the bitcoin network be able to reject those? Also are full nodes also vulnerable to this attack? I think that Full nodes can always check the outputs in the UOT against the previous to make sure that all outputs are either included in the prev UOT or generated by transactions in the current block.
  2. I understand that implementing this would require some modifications to the current validity criteria, but whhy would nodes up-taking these changes risk "mining on the wrong side"?


Posted 2019-10-07T18:44:16.380

Reputation: 21

No answers