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
226
227
228
229
230
231
232
233
234
235
236
237
|
Return-Path: <teekhan42@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 879C695D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 Jan 2017 14:28:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f179.google.com (mail-ua0-f179.google.com
[209.85.217.179])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BEA8B138
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 Jan 2017 14:28:28 +0000 (UTC)
Received: by mail-ua0-f179.google.com with SMTP id 88so318223920uaq.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 03 Jan 2017 06:28:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=6E7eZj272jAvGGWVl6wOTvOqciRFbTDcwebU/ZBFRaE=;
b=mVmVaQKrishO9RIT2rxbMGYVreW6anyjRaQwxvV48fSVmb1Sp40fiGKxdNsPO8eg/n
Ws4p1Un57rPgMpMIvrT2jDUVcLA9HvWMQN/Cp4lt/TH6o2h5x+s9/f7aRz4keR2ubHOI
4xh9A1fwP2d1gUpaBaM200H5R8T81Wnpq7x2rzGU7URIB68icZA1S+pS1htF1CfSQKuv
H7iiSCknYKyLhG050emGBE46z7/q1I5QrAZHoG2hd5nyYQray+/Dxjof0wfZjSAU0HN0
a1PsOgLgG6iVK7kOv/fP2Pm3sRgF/geg5zepJc6zOk58NN3y22JfricKFF41oyoqyOSx
E0ZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=6E7eZj272jAvGGWVl6wOTvOqciRFbTDcwebU/ZBFRaE=;
b=OhajMAQa9HMONTt50K39s2VUA7Q9ufRxpvUVOL4t+WfMA9JgRca6kGFbdlGBZh3B8q
N6XI5eRPGh8wc9LK8FSAxHoxHUOGHsDgMhQ+C7eSoad6ro+/ompY9Dg34gj5hb1pOFDj
/AON8sd+kDBt3R6x5Tdlp11fAMJoZeXUOaiq1341Cn+JIvVMcXo3e7/vbc3GozXTQpXx
sX1d9JaM4j9d93oemFy/0piEe6YIuQ51+l/0joHRanW/EyAAAG34tSx/jFOx6+KArDi0
SAbKamTtVqNKhKypyTWQE6S+Y29CnHFExjO3Oz6EOVwDEE2SbbeLfH0+uxWxCfyEWX36
14QQ==
X-Gm-Message-State: AIkVDXKn64UaLbTOX9vDt/ADAg7hlVzFADy0usUep5P+OJBnvqWzihUB3WCqoZhPihu6XLQte2FXKhbDP0HkwA==
X-Received: by 10.176.86.28 with SMTP id y28mr37267461uaa.88.1483453707891;
Tue, 03 Jan 2017 06:28:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.49.144 with HTTP; Tue, 3 Jan 2017 06:28:27 -0800 (PST)
In-Reply-To: <201701022119.11115.luke@dashjr.org>
References: <CAGCNRJoN7u3yvzitH2KSmVty-p0tX9jxWLHPb8uO5CPZmxmoRg@mail.gmail.com>
<CAGCNRJp71NCxQ3jk4hu-kXF94RiqfeD=AVnxR37TrJ7bDG310w@mail.gmail.com>
<1944321.hguq3JoYe1@cherry> <201701022119.11115.luke@dashjr.org>
From: "t. khan" <teekhan42@gmail.com>
Date: Tue, 3 Jan 2017 09:28:27 -0500
Message-ID: <CAGCNRJpKCtyjS9bm15UFh_p=N4o1A=2tzNvnWVZKbq8Tn4x7Lw@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=f403045dc2264cb6220545317b18
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
HTML_MESSAGE,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] BIP - 'Block75' - New algorithm
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Tue, 03 Jan 2017 14:28:29 -0000
--f403045dc2264cb6220545317b18
Content-Type: text/plain; charset=UTF-8
On Mon, Jan 2, 2017 at 4:19 PM, Luke Dashjr <luke@dashjr.org
<javascript:_e(%7B%7D,'cvml','luke@dashjr.org');>> wrote:
> > Using the growth rate over the last year as a model (
> > https://blockchain.info/charts/avg-block-size?daysAverageString=14 ),
> > Block75 would also have frequently decreased the limit. Though, yes, more
> > transactions would equal larger blocks over time, but that's the entire
> > point of this.
>
> Then it doesn't solve the actual problems of either miner spam or growth in
> resource requirements, which are the entire purpose of the block size
> limit.
>
Do you have any direct evidence of "miner spam"? If so, please link to a
transaction. Also, what could a miner possibly gain from this?
For resource requirements (bandwidth/disk space), please run the numbers on
the Block75 algorithm and compare with growth rates of both.
> What is your definition of "spam"?
>
> Anything that consumes more data than necessary to properly convey the
> intended transfer of value (bitcoins) from one entity to another, including
> all data that is not intended for such a purpose.
>
By this definition, any transaction which transfers ownership of an asset
(stock certificate, deeds to property, copyrights, etc.) is spam. But these
are legitimate, fee paying transactions. They are not spam. Yes, they're
only moving 0.0001 btc. Some will eventually move to Lightning (or
something like it), but many will not as they are unsuitable for off-chain.
> > I doubt you'll get consensus for such a fundamentally broken proposal.
> > > I certainly don't foresee any circumstance where I could reasonably
> > > support it... The block size limit exists to restrict miners; it makes
> no
> > > sense to put it in their control.
> >
> > Specifically, what is broken about it?
>
> Putting group X in control of a limit that exists for the sole purpose of
> restricting group X.
>
No, it actually gives them less power than they have now. Consider the
two-week recalculation: the result of any attempt to manipulate the block
size (up or down) will only last for two weeks. There's no way for a miner
to profit from this (in fact, they'd lose money this way). The best outcome
they could hope for is a very small increase or decrease for two weeks. So
why would anyone do this?
As soon as such a manipulation ended, Block75 would correct the max block
size back to an appropriate level (defined as: average block 75% full).
> There would still be a block size limit, it would just change slightly
> > every two weeks. I agree that miners shouldn't have control of this, and
> > Block75 doesn't give them any (at least none they can make a profit on).
>
> It gives miners complete control over the limit. They can make blocks of
> any
> size (within the current limit), thus triggering the conditions by which
> your
> proposal would raise the limit further.
We covered this ad nauseum in the other Block75 thread, but basically no
one has been able to come up with a realistic scenario wherein miners would
be motivated to do this *and* there aren't any pools large enough now (nor
have there ever been) to have anything more than a minor and temporary
effect.
If such a scenario actually does exist, please describe it in detail.
- t.k.
--f403045dc2264cb6220545317b18
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Jan 2, 2017 at 4:19 PM, Luke Dashjr <span dir=3D"ltr"><<a hr=
ef=3D"javascript:_e(%7B%7D,'cvml','luke@dashjr.org');" targ=
et=3D"_blank">luke@dashjr.org</a>></span> wrote:<br><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde=
r-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><sp=
an>> Using the growth rate over the last year as a model (<br>
> <a href=3D"https://blockchain.info/charts/avg-block-size?daysAverageSt=
ring=3D14" rel=3D"noreferrer" target=3D"_blank">https://blockchain.info/cha=
rts<wbr>/avg-block-size?daysAverageStr<wbr>ing=3D14</a> ),<br>
> Block75 would also have frequently decreased the limit. Though, yes, m=
ore<br>
> transactions would equal larger blocks over time, but that's the e=
ntire<br>
> point of this.<br>
<br>
</span>Then it doesn't solve the actual problems of either miner spam o=
r growth in<br>
resource requirements, which are the entire purpose of the block size limit=
.<br></blockquote><div><br></div><div>Do you have any direct evidence of &q=
uot;miner spam"? If so, please link to a transaction. Also, what could=
a miner possibly gain from this?</div><div><br></div><div>For resource req=
uirements (bandwidth/disk space), please run the numbers on the Block75 alg=
orithm and compare with growth rates of both.</div><div><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex"><span>> What is your definition of "spam"?<br>
<br>
</span>Anything that consumes more data than necessary to properly convey t=
he<br>
intended transfer of value (bitcoins) from one entity to another, including=
<br>
all data that is not intended for such a purpose.<br></blockquote><div><br>=
</div><div>By this definition, any transaction which transfers ownership of=
an asset (stock certificate, deeds to property, copyrights, etc.) is spam.=
But these are legitimate, fee paying transactions. They are not spam. Yes,=
they're only moving 0.0001 btc. Some will eventually move to Lightning=
(or something like it), but many will not as they are unsuitable for off-c=
hain.</div><div><br></div><blockquote class=3D"gmail_quote" 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>> > I doubt you'=
ll get consensus for such a fundamentally broken proposal.<br>
> > I certainly don't foresee any circumstance where I could reas=
onably<br>
> > support it... The block size limit exists to restrict miners; it =
makes no<br>
> > sense to put it in their control.<br>
><br>
> Specifically, what is broken about it?<br>
<br>
</span>Putting group X in control of a limit that exists for the sole purpo=
se of<br>
restricting group X.<br></blockquote><div><br></div><div>No, it actually gi=
ves them less power than they have now. Consider the two-week recalculation=
: the result of any attempt to manipulate the block size (up or down) will =
only last for two weeks. There's no way for a miner to profit from this=
(in fact, they'd lose money this way). The best outcome they could hop=
e for is a very small increase or decrease for two weeks. So why would anyo=
ne do this?</div><div><br></div><div>As soon as such a manipulation ended, =
Block75 would correct the max block size back to an appropriate level (defi=
ned as: average block 75% full).</div><div><br></div><blockquote class=3D"g=
mail_quote" 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=
>> There would still be a block size limit, it would just change slightl=
y<br>
> every two weeks. I agree that miners shouldn't have control of thi=
s, and<br>
> Block75 doesn't give them any (at least none they can make a profi=
t on).<br>
<br>
</span>It gives miners complete control over the limit. They can make block=
s of any<br>
size (within the current limit), thus triggering the conditions by which yo=
ur<br>
proposal would raise the limit further.</blockquote><div><br></div><div>We =
covered this ad nauseum in the other Block75 thread, but basically no one h=
as been able to come up with a realistic scenario wherein miners would be m=
otivated to do this *and* there aren't any pools large enough now (nor =
have there ever been) to have anything more than a minor and temporary effe=
ct.</div><div><br></div><div>If such a scenario actually does exist, please=
describe it in detail.</div><div><br></div><div>- t.k.</div></div></div></=
div>
--f403045dc2264cb6220545317b18--
|
