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
|
Return-Path: <nbvfour@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 53F02E4B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 13 Dec 2015 08:13:43 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com
[209.85.213.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B2F74A9
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 13 Dec 2015 08:13:42 +0000 (UTC)
Received: by mail-ig0-f177.google.com with SMTP id mv3so64810478igc.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 13 Dec 2015 00:13:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:date:message-id:subject
:from:to:cc:content-type;
bh=XkpXnaw9cGMHVwACOmyMYA2xO9NOKd+HOaXxdToBX8g=;
b=m6gCDYtjmSOzGfpgaaEPj2bpbjpJroRQAWRWgTMZFt42SjZFvwCyGAuTdqeNzmR5n6
Uh28pnsYi6ZHIyMGMejgNyqWAnval3DpZTh46qr2Pz1P6noYtA5o/4c0vM9icUVc4e9m
l7xJ7jstYueX9lAZhPFMCB4wvHOcRmSne4/xBl0UJV8Q+5zcL8AlWcxmAWU8FhRLEY40
KeTFZc58i4hf1fRNnuFmHRP3ELSpn5SOYckd+JIoZPGT1OQlPbWTzUL82N6JITnRMuXZ
JpqPbGdz8dVVqVgQxnHH62B8y8E16fvA8WTxnAY7SwYjOTszocW5Glz17aJdeRJ7t0Pt
Yrtg==
MIME-Version: 1.0
X-Received: by 10.50.153.69 with SMTP id ve5mr11500585igb.80.1449994422177;
Sun, 13 Dec 2015 00:13:42 -0800 (PST)
Sender: nbvfour@gmail.com
Received: by 10.36.20.130 with HTTP; Sun, 13 Dec 2015 00:13:42 -0800 (PST)
In-Reply-To: <CAAS2fgQi7aiwyOaVBiMbp6t9D58aFAmDdKPzFiscB6ouGzBK6A@mail.gmail.com>
References: <50e629572d8de852eb789d50b34da308@xbt.hk>
<1449961269.2210.5.camel@yahoo.com>
<CACrzPenXGQZBrx8QC+1QE2oCE3N=qmfgc_OWrowtjtLjGkZrRA@mail.gmail.com>
<CAAS2fgQi7aiwyOaVBiMbp6t9D58aFAmDdKPzFiscB6ouGzBK6A@mail.gmail.com>
Date: Sun, 13 Dec 2015 00:13:42 -0800
X-Google-Sender-Auth: gnFYNGqC5eJ8Ey9qdvyalHnKp68
Message-ID: <CAAcC9yuSX67ckhBUCsvTk+7PB6vzufuuBsJikSqqqU_4LXoCfA@mail.gmail.com>
From: Chris Priest <cp368202@ohiou.edu>
To: Gregory Maxwell <greg@xiph.org>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, FREEMAIL_FROM, 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, 13 Dec 2015 08:13:43 -0000
I don't like this scheme at all. It doesn't seem to make bitcoin
better, it makes it worse.
Lets say it's 2050 and I want to sweep a paper wallet I created in
2013. I can't just make the TX and send it to the network, I have to
first contact an "archive node" to get the UTXO data in order to make
the TX. How is this better than how the system works today?
Since many people are going to be holding BTC long term (store of
value of a first-class feature of bitcoin), this scheme is going to
effect pretty much all users.
These archive nodes will be essential to network's operation. If there
are no running archive nodes, the effect on the network is the same as
the network today without any full nodes.
Anyways, UTXO size is a function of number of users, rather than a
function of time. If tons of people join the network, UTXO still will
increase no matter what. All this change is going to do is make it
harder for people to use bitcoin. A person can still generate 1GB of
UTXO data, but as long as they spend those UTXOs within the amount
they are still using those resources.
IMO, wildcard inputs is still the best way to limit the UTXO set.
On 12/12/15, Gregory Maxwell via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Sun, Dec 13, 2015 at 1:00 AM, Vincent Truong via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> have run a node/kept their utxo before they were aware of this change and
>> then realise miners have discarded their utxo. Oops?
>
> I believe you have misunderstood jl2012's post. His post does not
> cause the outputs to become discarded. They are still spendable,
> but the transactions must carry a membership proof to spend them.
> They don't have to have stored the data themselves, but they must
> get it from somewhere-- including archive nodes that serve this
> purpose rather than having every full node carry all that data forever.
>
> Please be conservative with the send button. The list loses its
> utility if every moderately complex idea is hit with reflexive
> opposition by people who don't understand it.
>
> Peter Todd has proposed something fairly similar with "STXO
> commitments". The primary argument against this kind of approach that
> I'm aware of is that the membership proofs get pretty big, and if too
> aggressive this trades bandwidth for storage, and storage is usually
> the cheaper resource. Though at least the membership proofs could be
> omitted when transmitting to a node which has signaled that it has
> kept the historical data anyways.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|
