From: Tier Nolan <tier.nolan@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin
Date: Sun, 13 Dec 2015 21:36:06 +0000 [thread overview]
Message-ID: <CAE-z3OXAgvtODDKHTWVyNN1r=T=f-gtGawKtEdOh_H+h-5gqEQ@mail.gmail.com> (raw)
In-Reply-To: <3b28f994d75070ab1fd2d312f29bb706@xbt.hk>
[-- Attachment #1: Type: text/plain, Size: 2043 bytes --]
On Sun, Dec 13, 2015 at 6:11 PM, jl2012--- via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Back to the topic, I would like to further elaborate my proposal.
>
> We have 3 types of full nodes:
>
> Archive nodes: full nodes that store the whole blockchain
> Full UTXO nodes: full nodes that fully store the latest UTXO state, but
> not the raw blockchain
> Lite UTXO nodes: full nodes that store only UTXO created in that past
> 420000 blocks
>
There is a risk that miners would eventually react by just refusing to
accept blocks that spend dormant outputs. This is a risk even without the
protocol, but I think if there are already lots of UTXO-lite nodes
deployed, it would be much easier to just define them as the new
(soft-forked) consensus rule.
There is a precedent for things to be disabled rather than fixed when
security problems arise.
Imagine a crisis caused by a security related bug with the revival proofs.
Disabling them is much lower risk than trying to find/fix the bug and then
deploy the fix. The longer it takes, the longer the security problem
remains.
>
> What extra information is needed?
>
> (1) If your UTXO was generated in block Y, you first need to know the TXO
> state (spent / unspent) of all outputs in block Y at block (Y + 420000).
> Only UTXOs at that time are relevant.
>
> (2) You also need to know if there was any spending of any block Y UTXOs
> after block (Y + 420000).
>
Is this how it works?
Source transaction is included in block Y.
If the output is spent before Y + 420,000, then no further action is taken.
The miner for block Y + 420,000 will include a commitment to
merkle_hash(Block Y's unspent outputs).
It is possible for someone to prove that they didn't spend their
transaction before Y + 420,000.
I think the miners have to remember the "live" UTXO merkle root for every
block?
With the path to the UTXO and the miner can recalculate the root for that
block.
If there were 20 dormant outputs being spent, then the miner would have to
commit to 20 updates.
[-- Attachment #2: Type: text/html, Size: 2760 bytes --]
next prev parent reply other threads:[~2015-12-13 21:36 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-12 20:09 jl2012
2015-12-12 23:01 ` gb
2015-12-13 1:00 ` Vincent Truong
2015-12-13 2:07 ` Gregory Maxwell
2015-12-13 8:13 ` Chris Priest
2015-12-13 8:18 ` Gregory Maxwell
2015-12-13 9:17 ` Chris Priest
2015-12-13 9:24 ` Gregory Maxwell
2015-12-13 18:11 ` jl2012
2015-12-13 21:20 ` Ricardo Filipe
2015-12-13 21:36 ` Tier Nolan [this message]
2015-12-20 11:24 ` Peter Todd
2015-12-20 11:34 ` Jeff Garzik
2015-12-20 11:43 ` s7r
2015-12-20 16:30 ` Chris Pacia
2015-12-20 16:35 ` Peter Todd
2015-12-21 3:34 ` Jeff Garzik
2015-12-21 3:23 ` Tom Harding
2015-12-13 16:14 ` Danny Thorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAE-z3OXAgvtODDKHTWVyNN1r=T=f-gtGawKtEdOh_H+h-5gqEQ@mail.gmail.com' \
--to=tier.nolan@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox