1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
|
Return-Path: <danny.thorpe@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 113DFC8D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 13 Dec 2015 16:14:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f175.google.com (mail-qk0-f175.google.com
[209.85.220.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4F21F162
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 13 Dec 2015 16:14:23 +0000 (UTC)
Received: by qkdp187 with SMTP id p187so104789635qkd.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 13 Dec 2015 08:14:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=CsE8PW1UGkQ09Qievesf60TknuO0G2WrMCMruwy80Zs=;
b=VdYrTiRrZdMBdrZxrOFh7HxpFOlnVkle8mv4lIOLiAnaD2mJQIk00k40KDfG0Ug5cL
ZOb/CPINm5rMIptHC2fjat9EPcNs0Iljz/yxSZvKO0leklNiJmxFcpYk9zlTAwtTeksY
A2BZqp2l+BStsPs+cItN6vymx0cTBWWv4rTjfVwP79vQIK5h6x1swp2f5mjxB2z2FC3R
9YBHLyW33Tir8O8Ebf6aFIw/TXE3EfdbdmloqYJ0dTkxf2MiXMCLi8ZJePQ0R01EUJeB
m8xUA6Y3eWUgbjSnoc9/RAc8wUb++zn9H89KATEsh7dJdj9LRvUcfodsbtiD7vf0Pt0Z
MEgw==
MIME-Version: 1.0
X-Received: by 10.55.76.14 with SMTP id z14mr29521603qka.14.1450023262497;
Sun, 13 Dec 2015 08:14:22 -0800 (PST)
Received: by 10.140.20.228 with HTTP; Sun, 13 Dec 2015 08:14:21 -0800 (PST)
Received: by 10.140.20.228 with HTTP; Sun, 13 Dec 2015 08:14:21 -0800 (PST)
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
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sun, 13 Dec 2015 17:12:52 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Dec 2015 16:14:26 -0000
--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, "jl2012--- via bit=
coin-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"=
>bitcoin-dev@lists.linuxfoundation.org</a>> 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 "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 "witness" with "scriptSig"<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--
|
