From: jl2012@xbt.hk
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin
Date: Sat, 12 Dec 2015 15:09:03 -0500 [thread overview]
Message-ID: <50e629572d8de852eb789d50b34da308@xbt.hk> (raw)
It is a common practice in commercial banks that a dormant account might
be confiscated. Confiscating or deleting dormant UTXOs might be too
controversial, but allowing the UTXOs set growing without any limit
might not be a sustainable option. People lose their private keys.
People do stupid things like sending bitcoin to 1BitcoinEater. We
shouldn’t be obliged to store everything permanently. This is my
proposal:
Dormant UTXOs are those UTXOs with 420000 confirmations. In every block
X after 420000, it will commit to a hash for all UTXOs generated in
block X-420000. The UTXOs are first serialized into the form:
txid|index|value|scriptPubKey, then a sorted Merkle hash is calculated.
After some confirmations, nodes may safely delete the UTXO records of
block X permanently.
If a user is trying to redeem a dormant UTXO, in addition the signature,
they have to provide the scriptPubKey, height (X), and UTXO value as
part of the witness. They also need to provide the Merkle path to the
dormant UTXO commitment.
To confirm this tx, the miner will calculate a new Merkle hash for the
block X, with the hash of the spent UTXO replaced by 1, and commit the
hash to the current block. All full nodes will keep an index of latest
dormant UTXO commitments so double spending is not possible. (a
"meta-UTXO set")
If all dormant UTXOs under a Merkle branch are spent, hash of the branch
will become 1. If all dormant UTXOs in a block are spent, the record for
this block could be forgotten. Full nodes do not need to remember which
particular UTXO is spent or not, since any person trying to redeem a
dormant UTXO has to provide such information.
It becomes the responsibility of dormant coin holders to scan the
blockchain for the current status of the UTXO commitment for their coin.
They may also need to pay extra fee for the increased tx size.
This is a softfork if there is no hash collision but this is a
fundamental assumption in Bitcoin anyway. The proposal also works
without segregated witness, just by replacing "witness" with "scriptSig"
next reply other threads:[~2015-12-12 20:09 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-12 20:09 jl2012 [this message]
2015-12-12 23:01 ` [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin 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
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=50e629572d8de852eb789d50b34da308@xbt.hk \
--to=jl2012@xbt.hk \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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