Bitcoin Forum
April 28, 2024, 03:00:47 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: How does unused output tree work (Improvement Proposal for SPV Node)?  (Read 101 times)
codeNight (OP)
Newbie
*
Offline Offline

Activity: 1
Merit: 0


View Profile
October 08, 2019, 08:03:30 AM
Last edit: October 08, 2019, 09:55:24 AM by codeNight
 #1

I have been reading about the security of thin clients https://en.bitcoin.it/wiki/Thin_Client_Security and I came across the section that discusses the proposal of Unused Output Tree in the Block chain.

Quote
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:

Quote
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:

  • 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.
  • 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"?

I am quite new to this, so I would really appreciate some more experienced help.
1714316447
Hero Member
*
Offline Offline

Posts: 1714316447

View Profile Personal Message (Offline)

Ignore
1714316447
Reply with quote  #2

1714316447
Report to moderator
1714316447
Hero Member
*
Offline Offline

Posts: 1714316447

View Profile Personal Message (Offline)

Ignore
1714316447
Reply with quote  #2

1714316447
Report to moderator
1714316447
Hero Member
*
Offline Offline

Posts: 1714316447

View Profile Personal Message (Offline)

Ignore
1714316447
Reply with quote  #2

1714316447
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
odolvlobo
Legendary
*
Offline Offline

Activity: 4298
Merit: 3209



View Profile
October 08, 2019, 05:16:19 PM
 #2

I believe the second quote is just saying that enforcing a valid UOT requires a hard fork.

Join an anti-signature campaign: Click ignore on the members of signature campaigns.
PGP Fingerprint: 6B6BC26599EC24EF7E29A405EAF050539D0B2925 Signing address: 13GAVJo8YaAuenj6keiEykwxWUZ7jMoSLt
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!