Bitcoin Forum
May 23, 2024, 10:40:08 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Proof of UTXO_set storage  (Read 688 times)
amincd (OP)
Hero Member
*****
Offline Offline

Activity: 772
Merit: 501


View Profile
June 02, 2015, 12:24:20 AM
Last edit: June 05, 2015, 01:07:06 AM by amincd
 #1

The goal of the 'proof of UTXO_set storage' scheme is to give the network a means of automatically gauging how decentralized the full node distribution is. Some parts of it got inspiration from gmaxwell's 'proof of storage' concept, found here:
 
https://bitcointalk.org/index.php?topic=310323.0
 
The idea:
 
Quote
Incentivize users to attach a 'proof of UTXO_set storage' with their txs, by encouraging miners, through a protocol rule, to charge users that don't a higher tx fee.
 
The method by which a user creates this proof is to first create a unique 'signed UTXO_set' for every single privkey with which they want to sign Bitcoin txs. This would require the user to create multiple versions of the UTXO_set - as many as the number of privkeys they want to create bitcoin txs with, and store the nodes further up the tree, and recalculate the bottom nodes as needed.
 
A signed UTXO_set is a hash tree where every leaf is signed by the same privkey.
 
To provide a proof of UTXO_set storage, the user attaches to their Bitcoin transaction a truncated merkle root of the signed UTXO_set generated with the same privkey used to sign the Bitcoin transaction. Every single signature in the tx requires a corresponding truncated merkle root for the transaction to escape the higher tx fee.
 
The hash of the block in which the tx is first confirmed, and the tx hash, are used as inputs to a RNG function that generates an R that is used to select one of the leaves in the UTXO_set. In the following block, the user must present a merkle branch linking the signed UTXO to the previously presented merkle root, to prove they had signed the UTXO with the same private key used to sign the tx at the time that the tx was confirmed. If they do not provide a valid merkle branch, they forfeit the UTXO_set_proof bitcoin deposit they attached with their tx.
 
To ensure users are keeping their UTXO_set up to date, at every block N at which a difficulty adjustment occurs, the valid UTXO_set becomes N-2016. This means users have ~2 weeks to generate new 'signed UTXO_sets' at every difficulty adjustment period, so that they are ready use when the next diff adjustment happens.

The ratio of the sum EBDD (Effective Bitcoin Days Destroyed) of txs without UTXO_set proofs to the sum EBDD of txs with UTXO_set proofs could be considered a measure of full node decentralization, and perhaps be used to determine the block size limit. The 'Effective Bitcoin Days Destroyed' would be the Bitcoin Days Destroys of a spent UTXO, but with a cap on how much of its BDD is used in the calculation of its EBDD, so that spending X BTC distributed among many small UTXOs makes a much larger contribution to the EBDD than if it were all spent from one large UTXO.

This proposal is incomplete and totally impractical in its current form. However, it has the following strengths:

  • BDD is hard (economically) to spoof.
  • Users are not going to trust third parties to store their private key for them. If they want to use their privkey to create signed UTXO_sets, they will have to have a local copy of the UTXO_set so that they can sign them.
  • For trusted third parties who control BTC on behalf of their users, there is an economic cost to creating many txs with UTXO_set proofs just to 'fool' the network, since on-chain txs require fees be paid, while off-chain txs do not.

So maybe someone can utilize the interesting elements in it to create a workable proposal that could provide the network a means of automatically gauging read-access (fully validating node) distribution.
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!