public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Danny Thorpe <danny.thorpe@gmail.com>
To: jl2012@xbt.hk
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin
Date: Sun, 13 Dec 2015 08:14:21 -0800	[thread overview]
Message-ID: <CAJN5wHWPtDbCHAYOxYLNZykgqt7a2Jefa1ACz-MOT+Ucn6T+dA@mail.gmail.com> (raw)
In-Reply-To: <50e629572d8de852eb789d50b34da308@xbt.hk>

[-- Attachment #1: Type: text/plain, Size: 2717 bytes --]

What is the current behavior / cost that this proposal is trying to avoid?
Are ancient utxos required to be kept in memory always in a fully
validating node, or can ancient utxos get pushed out of memory like a
normal LRU caching db?

Thanks,
-Danny
On Dec 12, 2015 1:55 PM, "jl2012--- via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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"
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 3174 bytes --]

      parent reply	other threads:[~2015-12-13 16:14 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-12 20:09 [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin 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
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 [this message]

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=CAJN5wHWPtDbCHAYOxYLNZykgqt7a2Jefa1ACz-MOT+Ucn6T+dA@mail.gmail.com \
    --to=danny.thorpe@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jl2012@xbt.hk \
    /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