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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1UFB3u-0001TE-H2
for bitcoin-development@lists.sourceforge.net;
Mon, 11 Mar 2013 22:19:18 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.170 as permitted sender)
client-ip=209.85.214.170; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f170.google.com;
Received: from mail-ob0-f170.google.com ([209.85.214.170])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UFB3p-0002mA-1p
for bitcoin-development@lists.sourceforge.net;
Mon, 11 Mar 2013 22:19:18 +0000
Received: by mail-ob0-f170.google.com with SMTP id wc20so3887156obb.15
for <bitcoin-development@lists.sourceforge.net>;
Mon, 11 Mar 2013 15:19:07 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.1.10 with SMTP id 10mr10547684obi.15.1363040347642; Mon,
11 Mar 2013 15:19:07 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.86.169 with HTTP; Mon, 11 Mar 2013 15:19:07 -0700 (PDT)
In-Reply-To: <513E2BC6.2050102@gmail.com>
References: <20130310043155.GA20020@savin>
<CABOyFfp9Kd+y=SofWfq6TiR4+xeOhFL7VVHWjtrRn83HMsmPBA@mail.gmail.com>
<CABsx9T1rt+7BQHz1S=NVtL_YV7kfCapQ+3MEf+xyXT7pZOfq7w@mail.gmail.com>
<CABOyFfrO9Xpc=Pdh_6AM1yoHRCeuHxzqL02F-ALkimmsGbheiA@mail.gmail.com>
<CABOyFfqh_VixG7SQMaQUkxU40MGY1f9JO3=OqwitHa1YoT4chQ@mail.gmail.com>
<CANEZrP0gsrd2W3ODfQRSc2k5V7GotJ0vzEAxcAjnaMtDHZ9_JA@mail.gmail.com>
<75F78378-7580-4D69-A5EA-E943AF7CEB0C@benlabs.net>
<513E2BC6.2050102@gmail.com>
Date: Mon, 11 Mar 2013 23:19:07 +0100
X-Google-Sender-Auth: f6G0Lh7mphmQ9W26EbXlHWzSLCk
Message-ID: <CANEZrP1tYTDf6k76=jcBL+10MpCgemV2TP=wZiRuA02vhUP78A@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: =?UTF-8?Q?Tadas_Varanavi=C4=8Dius?= <tadas.varanavicius@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1UFB3p-0002mA-1p
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Blocking uneconomical UTXO creation
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 11 Mar 2013 22:19:18 -0000
> This would be bloating UTXO data at a speed of 52 GB/year. That's a very
> big memory leak. And this is just the unspendable outputs.
Firstly, the UTXO set is a LevelDB, it's not stored in memory. Outputs
that never get spent are not in the working set by definition, after a
while they just end up in the bottom levels and hardly ever get
accessed. If need be we can always help LevelDB out a bit by moving
outputs that we suspect are unlikely to get spent into a separate
database, but I doubt it's needed.
Secondly, if an output can be proven unspendable it can be pruned
immediately. We already reached consensus on adding some standard
template using OP_RETURN that results in insta-pruning. So people who
want to create unspendable outputs can do so with the only side-effect
being long term chain storage. It would be effectively "free" to
pruning nodes.
So the issue is not really with unspendable outputs but with low-value
spendable outputs. Wallets with lots of tiny outputs end up generating
large transactions that take a long time to verify, in situations
where the network redlines those transactions would end up at the
bottom of the priority queue and might take longer to confirm. So
wallet apps already have incentives to try and find a good balance in
output sizes and defragment themselves if their average output gets
too low in value, eg, by send-to-self transactions at night.
|
