summaryrefslogtreecommitdiff
path: root/67/404e91d1acf75b46a802c37e47d8fefecc59d0
blob: fabfaab4b39ff08fa6498840595f5c657e7375e1 (plain)
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
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id DF72AD16
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 13 Dec 2015 21:36:07 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f170.google.com (mail-io0-f170.google.com
	[209.85.223.170])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6F66E144
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 13 Dec 2015 21:36:07 +0000 (UTC)
Received: by iow186 with SMTP id 186so7464847iow.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 13 Dec 2015 13:36:06 -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:cc
	:content-type; bh=oxmybyM4euDGbOQOAPqBwvCEOQpbzNDlqXS/O/NJhIw=;
	b=hvdNhdEMS4Uq3UQ/d7itlGvo+xjD9AAw7qkgHeuWCj34QsufJ2WxzEo9exnsZ94gTA
	w693GC2+/1sZUbax/nFCLSX7njArjtkhwWDqd3rmlt2tOrrTdNTbB5JS59os1VFWnx+q
	8/PbSJIpXQL5dwgsis/35K8uJUyiEfnE65eL+AGgD2T3aEaFhYjv3F6uSZDTZVjANnDW
	XhmR7y3IVqv2k2Py6Krm9vKf072znFej2/pvnSMKD4jKPUeUketXPEKtp5Tbmc5Ornb6
	0SjHC3kdwdvTp2Su+DyBGCE4tL17s3XsBfgmUr4u42/QbmmiiXRmQQdFnAyHtedaHf+m
	SIaA==
MIME-Version: 1.0
X-Received: by 10.107.131.226 with SMTP id n95mr24820150ioi.135.1450042566916; 
	Sun, 13 Dec 2015 13:36:06 -0800 (PST)
Received: by 10.79.77.75 with HTTP; Sun, 13 Dec 2015 13:36:06 -0800 (PST)
In-Reply-To: <3b28f994d75070ab1fd2d312f29bb706@xbt.hk>
References: <50e629572d8de852eb789d50b34da308@xbt.hk>
	<1449961269.2210.5.camel@yahoo.com>
	<CACrzPenXGQZBrx8QC+1QE2oCE3N=qmfgc_OWrowtjtLjGkZrRA@mail.gmail.com>
	<CAAS2fgQi7aiwyOaVBiMbp6t9D58aFAmDdKPzFiscB6ouGzBK6A@mail.gmail.com>
	<CAAcC9yuSX67ckhBUCsvTk+7PB6vzufuuBsJikSqqqU_4LXoCfA@mail.gmail.com>
	<CAAS2fgSchJFk1Ejd8ZfMSzxEO-1TWYR6ag-seQNH_QHrc9Cn3w@mail.gmail.com>
	<CAAcC9ysovzcm1SD_4XyxxofmwdXrcQqs0ckQBw626vYsdPftKw@mail.gmail.com>
	<3b28f994d75070ab1fd2d312f29bb706@xbt.hk>
Date: Sun, 13 Dec 2015 21:36:06 +0000
Message-ID: <CAE-z3OXAgvtODDKHTWVyNN1r=T=f-gtGawKtEdOh_H+h-5gqEQ@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113ed5661c401d0526ce589e
X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	MALFORMED_FREEMAIL, 
	MISSING_HEADERS,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.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 21:36:08 -0000

--001a113ed5661c401d0526ce589e
Content-Type: text/plain; charset=UTF-8

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.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Dec 13, 2015 at 6:11 PM, jl2012--- via bitcoin-dev <span dir=3D"ltr">&l=
t;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank=
">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><span class=3D""></span> Back to the topic, I would li=
ke to further elaborate my proposal.<br>
<br>
We have 3 types of full nodes:<br>
<br>
Archive nodes: full nodes that store the whole blockchain<br>
Full UTXO nodes: full nodes that fully store the latest UTXO state, but not=
 the raw blockchain<br>
Lite UTXO nodes: full nodes that store only UTXO created in that past 42000=
0 blocks<br></blockquote><div><br></div><div>There is a risk that miners wo=
uld eventually react by just refusing to accept blocks that spend dormant o=
utputs.=C2=A0 This is a risk even without the protocol, but I think if ther=
e are already lots of UTXO-lite nodes deployed, it would be much easier to =
just define them as the new (soft-forked) consensus rule.<br><br></div><div=
>There is a precedent for things to be disabled rather than fixed when secu=
rity problems arise.<br><br></div><div>Imagine a crisis caused by a securit=
y related bug with the revival proofs.=C2=A0 Disabling them is much lower r=
isk than trying to find/fix the bug and then deploy the fix.=C2=A0 The long=
er it takes, the longer the security problem remains.<br>=C2=A0<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">
<br>
What extra information is needed?<br>
<br>
(1) If your UTXO was generated in block Y, you first need to know the TXO s=
tate (spent / unspent) of all outputs in block Y at block (Y + 420000). Onl=
y UTXOs at that time are relevant.<br>
<br>
(2) You also need to know if there was any spending of any block Y UTXOs af=
ter block (Y + 420000).<br></blockquote><div><br></div><div>Is this how it =
works?<br><br></div><div>Source transaction is included in block Y.<br></di=
v><div><br></div><div>If the output is spent before Y + 420,000, then no fu=
rther action is taken.<br><br></div><div>The miner for block Y + 420,000 wi=
ll include a commitment to merkle_hash(Block Y&#39;s unspent outputs).<br><=
br></div><div>It is possible for someone to prove that they didn&#39;t spen=
d their transaction before Y + 420,000.<br><br></div><div>I think the miner=
s have to remember the &quot;live&quot; UTXO merkle root for every block?<b=
r><br></div><div>With the path to the UTXO and the miner can recalculate th=
e root for that block.<br><br></div><div>If there were 20 dormant outputs b=
eing spent, then the miner would have to commit to 20 updates.<br></div></d=
iv></div></div>

--001a113ed5661c401d0526ce589e--