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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tier.nolan@gmail.com>) id 1Yr58h-0007tU-JH
for bitcoin-development@lists.sourceforge.net;
Sat, 09 May 2015 13:49:59 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.174 as permitted sender)
client-ip=209.85.216.174; envelope-from=tier.nolan@gmail.com;
helo=mail-qc0-f174.google.com;
Received: from mail-qc0-f174.google.com ([209.85.216.174])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Yr58g-0008Ut-QP
for bitcoin-development@lists.sourceforge.net;
Sat, 09 May 2015 13:49:59 +0000
Received: by qcyk17 with SMTP id k17so49880607qcy.1
for <bitcoin-development@lists.sourceforge.net>;
Sat, 09 May 2015 06:49:53 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.33.227 with SMTP id j90mr3426992qgj.6.1431179393376;
Sat, 09 May 2015 06:49:53 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Sat, 9 May 2015 06:49:53 -0700 (PDT)
In-Reply-To: <CABsx9T0Y84CSb-RohV1Cy=qYyFK0LYN0t-wbhkTt4wqhD5GpgQ@mail.gmail.com>
References: <16096345.A1MpJQQkRW@crushinator>
<CAOG=w-szbLgc1jLpkE_uMa3bkFTi-RiBEaQ6Y-u5aKLBC2HvUg@mail.gmail.com>
<CAAS2fgQRS7w7RRNXVK_+=4CQ7=AWxWQQ7+Tf4tNUPTTZOf7rEQ@mail.gmail.com>
<CABsx9T0Y84CSb-RohV1Cy=qYyFK0LYN0t-wbhkTt4wqhD5GpgQ@mail.gmail.com>
Date: Sat, 9 May 2015 14:49:53 +0100
Message-ID: <CAE-z3OVcXN4d9HFds_w90+g_ZhrVrFdveiRFX8_d9etVgAqW-g@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=001a113a7d025a2af60515a66b16
X-Spam-Score: 0.3 (/)
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
(tier.nolan[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
0.9 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Yr58g-0008Ut-QP
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step
function
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 13:49:59 -0000
--001a113a7d025a2af60515a66b16
Content-Type: text/plain; charset=UTF-8
On Sat, May 9, 2015 at 12:58 PM, Gavin Andresen <gavinandresen@gmail.com>
wrote:
> RE: fixing sigop counting, and building in UTXO cost: great idea! One of
> the problems with this debate is it is easy for great ideas get lost in all
> the noise.
>
If the UTXO set cost is built in, UTXO database entries suddenly are worth
something, in addition to the bitcoin held in that entry.
A user's client might display how many they own. When sending money to a
merchant, the user might demand the merchant indicate a slot to pay to.
The user could send an ANYONE_CAN_PAY partial transaction. The transaction
would guarantee that the user has at least as many UTXOs as before.
Discussing the possibility of doing this creates an incentive to bloat the
UTXO set right now, since UTXOs would be valuable in the future.
The objective would be to make them valuable enough to encourage
conservation, but not so valuable that the UTXO contains more value than
the bitcoins in the output.
Gmaxwell's suggested "tx_size = MAX( real_size >> 1, real_size +
4*utxo_created_size - 3*utxo_consumed_size)" for a 250 byte transaction
with 1 input and 2 outputs has very little effect.
real_size + 4 * (2) - 3 * 1 = 255
That gives a 2% size penalty for adding an extra UTXO. I doubt that is
enough to change behavior.
The UTXO set growth could be limited directly. A block would be invalid if
it increases the number of UTXO entries above the charted path.
RE: a hard upper limit, with a dynamic limit under it:
>
If the block is greater than 32MB, then it means an update to how blocks
are broadcast, so that could be a reasonable hard upper limit (or maybe
31MB, or just the 20MB already suggested).
--001a113a7d025a2af60515a66b16
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=
at, May 9, 2015 at 12:58 PM, Gavin Andresen <span dir=3D"ltr"><<a href=
=3D"mailto:gavinandresen@gmail.com" target=3D"_blank">gavinandresen@gmail.c=
om</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><div dir=3D"ltr">RE: fixing sigop counting, and building in UTXO cost: g=
reat idea! One of the problems with this debate is it is easy for great ide=
as get lost in all the noise.</div></blockquote><div><br></div><div>If the =
UTXO set cost is built in, UTXO database entries suddenly are worth somethi=
ng, in addition to the bitcoin held in that entry.<br><br></div><div>A user=
's client might display how many they own.=C2=A0 When sending money to =
a merchant, the user might demand the merchant indicate a slot to pay to.<b=
r><br></div><div>The user could send an ANYONE_CAN_PAY partial transaction.=
=C2=A0 The transaction would guarantee that the user has at least as many U=
TXOs as before.<br><br></div><div>Discussing the possibility of doing this =
creates an incentive to bloat the UTXO set right now, since UTXOs would be =
valuable in the future.=C2=A0 <br><br></div><div>The objective would be to =
make them valuable enough to encourage conservation, but not so valuable th=
at the UTXO contains more value than the bitcoins in the output.<br><br></d=
iv><div>Gmaxwell's suggested "tx_size =3D MAX( real_size >> =
1,=C2=A0 real_size + 4*utxo_created_size - 3*utxo_consumed_size)" for =
a 250 byte transaction with 1 input and 2 outputs has very little effect.<b=
r><br></div><div></div><div>real_size + 4 * (2) - 3 * 1 =3D 255<br><br></di=
v><div>That gives a 2% size penalty for adding an extra UTXO.=C2=A0 I doubt=
that is enough to change behavior.<br><br></div><div>The UTXO set growth c=
ould be limited directly.=C2=A0 A block would be invalid if it increases th=
e number of UTXO entries above the charted path.<br></div><div><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>RE: a=
hard upper limit, with a dynamic limit under it:</div></div></blockquote><=
div><br></div><div>If the block is greater than 32MB, then it means an upda=
te to how blocks are broadcast, so that could be a reasonable hard upper li=
mit (or maybe 31MB, or just the 20MB already suggested).<br></div></div></d=
iv></div>
--001a113a7d025a2af60515a66b16--
|
