MIME-Version: 1.0
In-Reply-To: <50e629572d8de852eb789d50b34da308@xbt.hk>
References: <50e629572d8de852eb789d50b34da308@xbt.hk>
Date: Sun, 13 Dec 2015 08:14:21 -0800
Message-ID: <CAJN5wHWPtDbCHAYOxYLNZykgqt7a2Jefa1ACz-MOT+Ucn6T+dA@mail.gmail.com>
From: Danny Thorpe <danny.thorpe@gmail.com>
To: jl2012@xbt.hk
Content-Type: multipart/alternative; boundary=001a11487d6c7a32460526c9d991
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin
Precedence: list

--001a11487d6c7a32460526c9d991
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=E2=80=99t=
 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 blo=
ck
> 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 ha=
sh
> 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 fundamenta=
l
> 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
>

--001a11487d6c7a32460526c9d991
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">What is the current behavior / cost that this proposal is tr=
ying 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?</p>
<p dir=3D"ltr">Thanks, <br>
-Danny</p>
<div class=3D"gmail_quote">On Dec 12, 2015 1:55 PM, &quot;jl2012--- via bit=
coin-dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"=
>bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br type=3D"attributio=
n"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">It is a common practice in commercial ban=
ks that a dormant account might be confiscated. Confiscating or deleting do=
rmant UTXOs might be too controversial, but allowing the UTXOs set growing =
without any limit might not be a sustainable option. People lose their priv=
ate keys. People do stupid things like sending bitcoin to 1BitcoinEater. We=
 shouldn=E2=80=99t be obliged to store everything permanently. This is my p=
roposal:<br>
<br>
Dormant UTXOs are those UTXOs with 420000 confirmations. In every block X a=
fter 420000, it will commit to a hash for all UTXOs generated in block X-42=
0000. The UTXOs are first serialized into the form: txid|index|value|script=
PubKey, then a sorted Merkle hash is calculated. After some confirmations, =
nodes may safely delete the UTXO records of block X permanently.<br>
<br>
If a user is trying to redeem a dormant UTXO, in addition the signature, th=
ey 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.<br>
<br>
To confirm this tx, the miner will calculate a new Merkle hash for the bloc=
k 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 &quot;meta-UTXO set&quo=
t;)<br>
<br>
If all dormant UTXOs under a Merkle branch are spent, hash of the branch wi=
ll 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 particu=
lar UTXO is spent or not, since any person trying to redeem a dormant UTXO =
has to provide such information.<br>
<br>
It becomes the responsibility of dormant coin holders to scan the blockchai=
n for the current status of the UTXO commitment for their coin. They may al=
so need to pay extra fee for the increased tx size.<br>
<br>
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 wi=
tness, just by replacing &quot;witness&quot; with &quot;scriptSig&quot;<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--001a11487d6c7a32460526c9d991--