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
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
|
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 <tier.nolan@gmail.com>) id 1YudN9-0004on-2y
for bitcoin-development@lists.sourceforge.net;
Tue, 19 May 2015 08:59:35 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.170 as permitted sender)
client-ip=209.85.220.170; envelope-from=tier.nolan@gmail.com;
helo=mail-qk0-f170.google.com;
Received: from mail-qk0-f170.google.com ([209.85.220.170])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YudN7-0002qy-6V
for bitcoin-development@lists.sourceforge.net;
Tue, 19 May 2015 08:59:35 +0000
Received: by qkgw4 with SMTP id w4so4995735qkg.3
for <bitcoin-development@lists.sourceforge.net>;
Tue, 19 May 2015 01:59:27 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.229.185.193 with SMTP id cp1mr36049137qcb.18.1432025967817;
Tue, 19 May 2015 01:59:27 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Tue, 19 May 2015 01:59:27 -0700 (PDT)
In-Reply-To: <878ucmslu4.fsf@rustcorp.com.au>
References: <16096345.A1MpJQQkRW@crushinator>
<CAOG=w-szbLgc1jLpkE_uMa3bkFTi-RiBEaQ6Y-u5aKLBC2HvUg@mail.gmail.com>
<CAAS2fgQRS7w7RRNXVK_+=4CQ7=AWxWQQ7+Tf4tNUPTTZOf7rEQ@mail.gmail.com>
<CAE-z3OUzYZDvsOYEDT229vnvNBa9ntW+86O3uA-K5-KaneMF_g@mail.gmail.com>
<87a8x5l6bt.fsf@rustcorp.com.au>
<CAE-z3OXue5E0TzRhx6y8eTOTy=EARsrGwJ1qv8Kv1nbCsjVE_g@mail.gmail.com>
<878ucmslu4.fsf@rustcorp.com.au>
Date: Tue, 19 May 2015 09:59:27 +0100
Message-ID: <CAE-z3OVLwZzyc0JSjdqqSXctQMJfRRdRi3OAm9hRB_dVDHhELA@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a1134b5681ef8be05166b87a1
X-Spam-Score: 3.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.2 MISSING_HEADERS Missing To: header
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
2.7 MALFORMED_FREEMAIL Bad headers on message from free email service
X-Headers-End: 1YudN7-0002qy-6V
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: Tue, 19 May 2015 08:59:35 -0000
--001a1134b5681ef8be05166b87a1
Content-Type: text/plain; charset=UTF-8
On Mon, May 18, 2015 at 2:42 AM, Rusty Russell <rusty@rustcorp.com.au>
wrote:
> OK. Be nice if these were cleaned up, but I guess it's a sunk cost.
>
Yeah.
On the plus side, as people spend their money, old UTXOs would be used up
and then they would be included in the cost function. It is only people
who are storing their money long term that wouldn't.
They are unlikely to have consumed their UTXOs anyway, unless miners
started paying for UTXOs.
We could make it a range.
UTXOs from below 355,000 and above 375,000 are included. That can create
incentive problems for the next similar change, I think a future threshold
is better.
> He said "utxo_created_size" not "utxo_created" so I assumed scriptlen?
>
Maybe I mis-read.
> But you made that number up? The soft cap and hard byte limit are
> different beasts, so there's no need for soft cost cap < hard byte
> limit.
>
I was thinking about it being a soft-fork.
If it was combined with the 20MB limit change, then it can be anything.
I made a suggestion somewhere (her or forums not sure), that transactions
should be allowed to store bytes.
For example, a new opcode could be added, <byte_count> OP_LOCK_BYTES.
This makes the transaction seem <byte_count> larger. However, when
spending the UTXO, that transaction counts as <byte_count> smaller, even
against the hard-cap.
This would be useful for channels. If channels were 100-1000X the
blockchain volume and someone caused lots of channels to close, there
mightn't be enough space for all the close channel transactions. Some
people might be able to get their refund transactions included in the
blockchain because the timeout expires.
If transactions could store enough space to be spent, then a mass channel
close would cause some very large blocks, but then they would have to be
followed by lots of tiny blocks.
The block limit would be an average not fixed per block. There would be 3
limits
Absolute hard limit (max bytes no matter what): 100MB
Hard limit (max bytes after stored bytes offset): 30MB
Soft limit (max bytes equivalents): 10MB
Blocks lager than ~32MB require a new network protocol, which makes the
hard fork even "harder". The protocol change could be "messages can now be
150MB max" though, so maybe not so complex.
>
> > This requires that transactions include scriptPubKey information when
> > broadcasting them.
>
> Brilliant! I completely missed that possibility...
>
I have written a BIP about it. It is still in the draft stage. I had a
look into writing up the code for the protocol change.
https://github.com/TierNolan/bips/blob/extended_transactions/bip-etx.mediawiki
https://github.com/TierNolan/bips/blob/extended_transactions/bip-etx-fork.mediawiki
--001a1134b5681ef8be05166b87a1
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 M=
on, May 18, 2015 at 2:42 AM, Rusty Russell <span dir=3D"ltr"><<a href=3D=
"mailto:rusty@rustcorp.com.au" target=3D"_blank">rusty@rustcorp.com.au</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">OK.=
=C2=A0 Be nice if these were cleaned up, but I guess it's a sunk cost.<=
br></blockquote><div><br></div><div>Yeah.=C2=A0 <br><br></div><div>On the p=
lus side, as people spend their money, old UTXOs would be used up and then =
they would be included in the cost function.=C2=A0 It is only people who ar=
e storing their money long term that wouldn't.<br><br></div><div>They a=
re unlikely to have consumed their UTXOs anyway, unless miners started payi=
ng for UTXOs.<br><br></div><div>We could make it a range.<br><br></div><div=
>UTXOs from below 355,000 and above 375,000 are included.=C2=A0 That can cr=
eate incentive problems for the next similar change, I think a future thres=
hold is better.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">
<span>
</span>He said "utxo_created_size" not "utxo_created" s=
o I assumed scriptlen?<br></blockquote><div><br></div><div>Maybe I mis-read=
.<br></div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex"><span>
</span>But you made that number up?=C2=A0 The soft cap and hard byte limit =
are<br>
different beasts, so there's no need for soft cost cap < hard byte<b=
r>
limit.<br></blockquote><div><br></div><div>I was thinking about it being a =
soft-fork.<br><br></div><div>If it was combined with the 20MB limit change,=
then it can be anything.<br><br></div><div>I made a suggestion somewhere (=
her or forums not sure), that transactions should be allowed to store bytes=
.<br><br></div><div>For example, a new opcode could be added, <byte_coun=
t> OP_LOCK_BYTES.<br><br></div><div>This makes the transaction seem <=
byte_count> larger.=C2=A0 However, when spending the UTXO, that transact=
ion counts as <byte_count> smaller, even against the hard-cap.<br><br=
></div><div>This would be useful for channels.=C2=A0 If channels were 100-1=
000X the blockchain volume and someone caused lots of channels to close, th=
ere mightn't be enough space for all the close channel transactions.=C2=
=A0 Some people might be able to get their refund transactions included in =
the blockchain because the timeout expires.<br><br></div><div>If transactio=
ns could store enough space to be spent, then a mass channel close would ca=
use some very large blocks, but then they would have to be followed by lots=
of tiny blocks.<br><br></div><div>The block limit would be an average not =
fixed per block.=C2=A0 There would be 3 limits<br><br></div><div>Absolute h=
ard limit (max bytes no matter what): 100MB<br></div><div>Hard limit (max b=
ytes after stored bytes offset): 30MB<br></div><div>Soft limit (max bytes e=
quivalents): 10MB<br></div><div><br></div><div>Blocks lager than ~32MB requ=
ire a new network protocol, which makes the hard fork even "harder&quo=
t;.=C2=A0 The protocol change could be "messages can now be 150MB max&=
quot; though, so maybe not so complex.<br></div><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex">
<span><br>
> This requires that transactions include scriptPubKey information when<=
br>
> broadcasting them.<br>
<br>
</span>Brilliant!=C2=A0 I completely missed that possibility...<br></blockq=
uote><div><br></div><div>I have written a BIP about it.=C2=A0 It is still i=
n the draft stage.=C2=A0 I had a look into writing up the code for the prot=
ocol change.<br><br><a href=3D"https://github.com/TierNolan/bips/blob/exten=
ded_transactions/bip-etx.mediawiki" target=3D"_blank">https://github.com/Ti=
erNolan/bips/blob/extended_transactions/bip-etx.mediawiki</a><br><a href=3D=
"https://github.com/TierNolan/bips/blob/extended_transactions/bip-etx-fork.=
mediawiki" target=3D"_blank">https://github.com/TierNolan/bips/blob/extende=
d_transactions/bip-etx-fork.mediawiki</a><br></div></div></div></div>
--001a1134b5681ef8be05166b87a1--
|
