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
|
Return-Path: <jgarzik@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6AFBDB3F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Dec 2015 11:34:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com
[209.85.213.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E1606A0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Dec 2015 11:34:29 +0000 (UTC)
Received: by mail-ig0-f180.google.com with SMTP id to4so20376078igc.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Dec 2015 03:34:29 -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=r8Jcusi9eaoV9XsUbFipSnAO0iqSiHuVSVVM/jQKG4o=;
b=D9bxgRAO5eXvy7pgJKEt41SnouuwQBEEJubUjlEKQztoyd0pVFShQcYCTkVe2/7xIf
crcjLAnLN82eq9MatyKN2YiGUPxI5yZXRTV3HVSIUtatg5jkBQjV5eBjrF9ulqk7n7oM
Nxmxz/kgCByoDcXXA4DxGDZBFUmv1UakzYfdnwelPx5Hh6YuSUbNlzhTp7Y1X5foqShu
EVMOCjizFDIMBA1gWYpAGhuUZPi5KWeIzcF+5+HW/JvMvVzdz+VSkmjwiy8yyV+8vfoq
LqSnmugOIDtqtqCobl0l8IQKB2tmmW/hbh5ty0/1Jep51E4mEeCXOsJMEl02pihtS1iO
Bf0w==
MIME-Version: 1.0
X-Received: by 10.50.36.105 with SMTP id p9mr13700146igj.54.1450611269412;
Sun, 20 Dec 2015 03:34:29 -0800 (PST)
Received: by 10.79.8.198 with HTTP; Sun, 20 Dec 2015 03:34:29 -0800 (PST)
In-Reply-To: <20151220112454.GB16187@muck>
References: <50e629572d8de852eb789d50b34da308@xbt.hk>
<1449961269.2210.5.camel@yahoo.com>
<CACrzPenXGQZBrx8QC+1QE2oCE3N=qmfgc_OWrowtjtLjGkZrRA@mail.gmail.com>
<CAAS2fgQi7aiwyOaVBiMbp6t9D58aFAmDdKPzFiscB6ouGzBK6A@mail.gmail.com>
<20151220112454.GB16187@muck>
Date: Sun, 20 Dec 2015 06:34:29 -0500
Message-ID: <CADm_Wca0cWRvcVaJ+p47A49yffQ1vP=u4807j7axn=mdBdsUGQ@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=089e011763436bb233052752c15c
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
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, 20 Dec 2015 11:34:30 -0000
--089e011763436bb233052752c15c
Content-Type: text/plain; charset=UTF-8
On Sun, Dec 20, 2015 at 6:24 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> What I proprosed is that a consensus-critical maximum UTXO age be part
> of the protocol; UTXO's younger than that age are expected to be cached.
> For UTXO's older than that age, they can be dropped from the cache,
> however to spend them you are required to provide the proof, and that
> proof counts as blockchain space to account for the fact that they do
> need to be broadcast on the network.
Yes, this is almost what -has- to happen in the long term.
Ideally we should start having wallets generate those proofs now, and then
introduce the max-age as a second step as a planned hard fork a couple
years down the line.
However,
1) There is also the open question of "grandfathered" UTXOs - for those
wallets generated in 2009, buried in a landfill and then dug out 10 years
ago
2) This reverses the useful minimization attribute of HD wallets - "just
backup the seed"
--089e011763436bb233052752c15c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sun, Dec 20, 2015 at 6:24 AM, Peter Todd via bitcoin-de=
v <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span=
> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">What I proprosed is that a consensus-critical maximum=
UTXO age be part<br>
of the protocol; UTXO's younger than that age are expected to be cached=
.<br>
For UTXO's older than that age, they can be dropped from the cache,<br>
however to spend them you are required to provide the proof, and that<br>
proof counts as blockchain space to account for the fact that they do<br>
need to be broadcast on the network.</blockquote><div></div></div><br></div=
><div class=3D"gmail_extra">Yes, this is almost what -has- to happen in the=
long term.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_e=
xtra">Ideally we should start having wallets generate those proofs now, and=
then introduce the max-age as a second step as a planned hard fork a coupl=
e years down the line.</div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">However,</div><div class=3D"gmail_extra">1) There is also =
the open question of "grandfathered" UTXOs - for those wallets ge=
nerated in 2009, buried in a landfill and then dug out 10 years ago</div><d=
iv class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">2) This rever=
ses the useful minimization attribute of HD wallets - "just backup the=
seed"</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_e=
xtra"><br></div></div>
--089e011763436bb233052752c15c--
|
