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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1YrBWa-0000E6-DL
for bitcoin-development@lists.sourceforge.net;
Sat, 09 May 2015 20:39:04 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.173 as permitted sender)
client-ip=209.85.217.173; envelope-from=pieter.wuille@gmail.com;
helo=mail-lb0-f173.google.com;
Received: from mail-lb0-f173.google.com ([209.85.217.173])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YrBWZ-0005MG-3N
for bitcoin-development@lists.sourceforge.net;
Sat, 09 May 2015 20:39:04 +0000
Received: by lbcga7 with SMTP id ga7so72655730lbc.1
for <bitcoin-development@lists.sourceforge.net>;
Sat, 09 May 2015 13:38:56 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.87.164 with SMTP id az4mr2875802lab.123.1431203936812;
Sat, 09 May 2015 13:38:56 -0700 (PDT)
Received: by 10.112.19.7 with HTTP; Sat, 9 May 2015 13:38:56 -0700 (PDT)
Received: by 10.112.19.7 with HTTP; Sat, 9 May 2015 13:38:56 -0700 (PDT)
In-Reply-To: <COL402-EAS2801DD28568B04AF7E4005CCDDD0@phx.gbl>
References: <COL402-EAS2801DD28568B04AF7E4005CCDDD0@phx.gbl>
Date: Sat, 9 May 2015 13:38:56 -0700
Message-ID: <CAPg+sBgFAhVA=SBfPyz7dQAsGuyA_gBGexWao6FzUgGuRbqGrQ@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Raystonn <raystonn@hotmail.com>
Content-Type: multipart/alternative; boundary=001a11c354c24144a60515ac22bd
X-Spam-Score: -0.6 (/)
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
(pieter.wuille[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1YrBWZ-0005MG-3N
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] A suggestion for reducing the size of the
UTXO database
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: Sat, 09 May 2015 20:39:04 -0000
--001a11c354c24144a60515ac22bd
Content-Type: text/plain; charset=ISO-8859-1
Miners do not care about the age of a UTXO entry, apart for two exceptions.
It is also economically irrelevant.
* There is a free transaction policy, which sets a small portion of block
space aside for transactions which do not pay sufficient fee. This is
mostly an altruistic way of encouraging Bitcoin adoption. As a DoS
prevention mechanism, there is a requirement that these free transactions
are of sufficient priority (computed as BTC-days-destroyed per byte),
essentially requiring these transactions to consume another scarce
resource, even if not money.
* Coinbase transaction outputs can, as a consensus rule, only be spent
after 100 confirmations. This is to prevent random reorganisations from
invalidating transactions that spend young coinbase transactions (which
can't move to the new chain). In addition, wallets also select more
confirmed outputs first to consume, for the same reason.
On May 9, 2015 1:20 PM, "Raystonn" <raystonn@hotmail.com> wrote:
> That policy is included in Bitcoin Core. Miners use it because it is the
> default. The policy was likely intended to help real transactions get
> through in the face of spam. But it favors those with more bitcoin, as the
> priority is determined by amount spent multiplied by age of UTXOs. At the
> very least the amount spent should be removed as a factor, or fees are
> unlikely to ever be paid by those who can afford them. We can reassess the
> role age plays later. One change at a time is better.
> On 9 May 2015 12:52 pm, Jim Phillips <jim@ergophobia.org> wrote:
>
> On Sat, May 9, 2015 at 2:43 PM, Raystonn <raystonn@hotmail.com> wrote:
>
> How about this as a happy medium default policy: Rather than select UTXOs
> based solely on age and limiting the size of the transaction, we select as
> many UTXOs as possible from as few addresses as possible, prioritizing
> which addresses to use based on the number of UTXOs it contains (more being
> preferable) and how old those UTXOs are (in order to reduce the fee)?
>
> If selecting older UTXOs gives higher priority for a lesser (or at least
> not greater) fee, that is an incentive for a rational user to use the older
> UTXOs. Such policy needs to be defended or removed. It doesn't support
> privacy or a reduction in UTXOs.
>
> Before starting this thread, I had completely forgotten that age was even
> a factor in determining which UTXOs to use. Frankly, I can't think of any
> reason why miners care how old a particular UTXO is when determining what
> fees to charge. I'm sure there is one, I just don't know what it is. I just
> tossed it in there as homage to Andreas who pointed out to me that it was
> still part of the selection criteria.
>
>
--001a11c354c24144a60515ac22bd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Miners do not care about the age of a UTXO entry, apart for =
two exceptions. It is also economically irrelevant.<br>
* There is a free transaction policy, which sets a small portion of block s=
pace aside for transactions which do not pay sufficient fee. This is mostly=
an altruistic way of encouraging Bitcoin adoption. As a DoS prevention mec=
hanism, there is a requirement that these free transactions are of sufficie=
nt priority (computed as BTC-days-destroyed per byte), essentially requirin=
g these transactions to consume another scarce resource, even if not money.=
<br>
* Coinbase transaction outputs can, as a consensus rule, only be spent afte=
r 100 confirmations. This is to prevent random reorganisations from invalid=
ating transactions that spend young coinbase transactions (which can't =
move to the new chain). In addition, wallets also select more confirmed out=
puts first to consume, for the same reason.</p>
<div class=3D"gmail_quote">On May 9, 2015 1:20 PM, "Raystonn" <=
;<a href=3D"mailto:raystonn@hotmail.com">raystonn@hotmail.com</a>> wrote=
:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">Tha=
t policy is included in Bitcoin Core.=A0 Miners use it because it is the de=
fault.=A0 The policy was likely intended to help real transactions get thro=
ugh in the face of spam.=A0 But it favors those with more bitcoin, as the p=
riority is determined by amount spent multiplied by age of UTXOs.=A0 At the=
very least the amount spent should be removed as a factor, or fees are unl=
ikely to ever be paid by those who can afford them.=A0 We can reassess the =
role age plays later.=A0 One change at a time is better.<br>
</p>
<div class=3D"gmail_quote">On 9 May 2015 12:52 pm, Jim Phillips <<a href=
=3D"mailto:jim@ergophobia.org" target=3D"_blank">jim@ergophobia.org</a>>=
wrote:<br type=3D"attribution"><blockquote style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><div><d=
iv>On Sat, May 9, 2015 at 2:43 PM, Raystonn <span dir=3D"ltr"><<a href=
=3D"mailto:raystonn@hotmail.com" target=3D"_blank">raystonn@hotmail.com</a>=
></span> wrote:<br></div></div></div><div><blockquote style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bo=
rder-left-style:solid;padding-left:1ex"><blockquote style=3D"margin:0px 0px=
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-=
left-style:solid;padding-left:1ex"><span style=3D"color:rgb(80,0,80);font-s=
ize:12.8000001907349px">How about this as a happy medium default policy: Ra=
ther than select UTXOs based solely on age and limiting the size of the tra=
nsaction, we select as many UTXOs as possible from as few addresses as poss=
ible, prioritizing which addresses to use based on the number of UTXOs it c=
ontains (more being preferable) and how old those UTXOs are (in order to re=
duce the fee)?=A0</span></blockquote><p dir=3D"ltr">If selecting older UTXO=
s gives higher priority for a lesser (or at least not greater) fee, that is=
an incentive for a rational user to use the older UTXOs.=A0 Such policy ne=
eds to be defended or removed.=A0 It doesn't support privacy or a reduc=
tion in UTXOs.</p></blockquote><div>Before starting this thread, I had comp=
letely forgotten that age was even a factor in determining which UTXOs to u=
se. Frankly, I can't think of any reason why miners care how old a part=
icular UTXO is when determining what fees to charge. I'm sure there is =
one, I just don't know what it is. I just tossed it in there as homage =
to Andreas who pointed out to me that it was still part of the selection cr=
iteria.</div></div></div></div>
</blockquote></div></blockquote></div>
--001a11c354c24144a60515ac22bd--
|
