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
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
|
Return-Path: <dscotese@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 4426FF0F
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Sep 2015 19:26:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com
[209.85.212.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0E261E9
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Sep 2015 19:26:22 +0000 (UTC)
Received: by wicfx3 with SMTP id fx3so75288738wic.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Sep 2015 12:26:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:date:message-id:subject
:from:to:cc:content-type;
bh=u0myEGx8LDhJOpXqpIvFC5u7jO9WTnmOvCCSJ9fvcsY=;
b=pbxvsYN+6EHEgi0WFkPx6TKMLK5N/j4nT0IubiZnmIHOmWbDbUvv+ueBMjIccLS7WS
hQ7xldSZ6HxBo/Tv3mJKQLfmEtJJ/2pqdGkeK2DAtHXF0Q318bpqrIiVQyEXI2easp7N
mdG6bxkODeL8Om1zsQg7RAL+froN0fq8TAcwtlAbuef9nBYPGLqhw/9PqNYoVsASszgg
b0kjP90np4zuZfwQEV51Yxrd6eiVacGxTko/oZ2ne2hixZJ8WOCJHyYxBkTDumoamtwm
cY2Q3XmDOS92ZTD0TQzG4q5JzTRU6Lcr5W2Lte3uhb2I+Z68i7gJFjMUdTLv2T3OKXqL
6VNQ==
MIME-Version: 1.0
X-Received: by 10.194.239.167 with SMTP id vt7mr754026wjc.5.1441999580660;
Fri, 11 Sep 2015 12:26:20 -0700 (PDT)
Sender: dscotese@gmail.com
Received: by 10.27.211.132 with HTTP; Fri, 11 Sep 2015 12:26:20 -0700 (PDT)
In-Reply-To: <CABm2gDoCecK1jk6i_bZMTRCTQUseXYugi5ntykMimzns_dxFug@mail.gmail.com>
References: <CAGLBAhd11-_LNJ-ba6NXmWBXz=yb+pFTmf9tHAgFW_m6S5jnfw@mail.gmail.com>
<CABm2gDpsJdSDTyvTGNSZXX1+UyAHxTB=ODuy6bJvMj3A9BqhqQ@mail.gmail.com>
<CANOOu=8jT++mX_pTHrEnryJqiw3C+J3mWKL27dEkQh=rO0q_Cg@mail.gmail.com>
<CABm2gDoCecK1jk6i_bZMTRCTQUseXYugi5ntykMimzns_dxFug@mail.gmail.com>
Date: Fri, 11 Sep 2015 12:26:20 -0700
X-Google-Sender-Auth: _c0cwW6fze9ldQ7uIyQIyuIsO80
Message-ID: <CAGLBAhdjTYEXZWRU6gouLgUjerWF3i_L4Sj5QrAcfwmFfEgDAw@mail.gmail.com>
From: Dave Scotese <dscotese@litmocracy.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary=089e013c60c0c589db051f7db0a7
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,URIBL_BLACK
autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin Days Destroyed as block selection
heuristic
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Fri, 11 Sep 2015 19:26:23 -0000
--089e013c60c0c589db051f7db0a7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Yes, this proposal is a policy that everyone would be free to ignore. I
should have introduced the situation in which this *unenforceable* policy
makes sense to me. Here it is:
Every miner is listening for valid block solutions but might receive two
valid blocks and then they have to decide which one to use. Choosing the
one you saw first is the default behavior. In that situation, we'd all
like everyone to choose the same block. I propose that a better heuristic
than "first seen" is to compare the BTCDD, *but only of transactions you
already have in your mempool*, and
*weight the BTCDD so that txns you got earlier are more important.*
The heuristic is most useful when the two blocks are received within a
small window of time, opting for the first-seen rule otherwise. I assume
many miners have an idea of how long it takes for anyone's new block to get
across the network, and more specifically, the range of times it takes for
new solutions to get to themselves. During this little time window, the
chances are 50/50 that they'll choose the right block. If the default
behavior were to use BTCDD during that time window (one second? I have no
idea!), then the chances would be significantly better.
I think Jorge is right that it doesn't benefit miners. It doesn't hurt
them either, unless they are trying to do selfish mining. Well, it
benefits them in terms of increased bitcoin stability by A) making it
easier for clients to decide which block is valid when they see two
competing with each other, B) motivating miners to add transactions instead
of mining empty blocks, C) severely decreasing the utility of any global
private network of nodes intended to spread selfishly-mined blocks, and D)
motivating miners to stay well-connected so that they get transactions
quickly.
I sent this to the list because it is only useful if it is set as default
behavior since most miners leave the defaults alone, and the benefits don't
materialize unless a majority follows the policy.
On Fri, Sep 11, 2015 at 11:37 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote=
:
>
> On Sep 11, 2015 1:18 PM, "Christophe Biocca" <christophe.biocca@gmail.com=
>
> wrote:
> >
> > It's pretty obvious that Dave is suggesting an alternate tie-breaker:
>
> I thought he was proposing a new consesnsus rule. I see, this would be
> just a policy validation that everybody would be free to ignore (like the
> "first seen" spend conflict tx replacement policy).
>
> I don't see how miners would benefit from running this policy so I would
> not expect them to run it in the long run (like the "first seen" spend
> conflict tx replacement policy).
> If miners don't use it, I don't see how users can benefit from running
> that policy themselves.
> They will still have to keep waiting some block confirmation to
> exponentially reduce the chances of a successful double-spend attack with
> each new confirmation (as explained in the bitcoin white paper).
>
> > Mind you, that risk doesn't apply if we prefer non-empty blocks to
> > empty blocks and leave it at that, or only switch if the new block
> > doesn't double spend transactions in the old one, so it's a fixable
> > issue.
>
> How do you know which of 2 blocks with the same height is "newer"?
>
> > On 11 September 2015 at 12:32, Jorge Tim=C3=B3n
> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > >
> > > On Sep 11, 2015 12:27 PM, "Dave Scotese via bitcoin-dev"
> > > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > >>
> > >> Rather than (promising to, and when they don't actually, at least
> > >> pretending to) use the first-seen block, I propose that a more
> sophisticated
> > >> method of choosing which of two block solutions to accept.
> > >
> > > There's already a criterion to chose: the one with more work (in vali=
d
> > > blocks) on top of it.
> > >
> > >
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev@lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > >
>
--=20
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
--089e013c60c0c589db051f7db0a7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div>Yes, this proposal is a policy that ev=
eryone would be free to ignore.=C2=A0 I should have introduced the situatio=
n in which this <i>unenforceable</i> policy makes sense to me.=C2=A0 Here i=
t is:<br><br></div>Every miner is listening for valid block solutions but m=
ight receive two valid blocks and then they have to decide which one to use=
.=C2=A0 Choosing the one you saw first is the default behavior.=C2=A0 In th=
at situation, we'd all like everyone to choose the same block.=C2=A0 I =
propose that a better heuristic than "first seen" is to compare t=
he BTCDD, <i>but only of transactions you already have in your mempool</i>,=
and <i>weight the BTCDD so that txns you got earlier are more important.<b=
r><br></i></div>The heuristic is most useful when the two blocks are receiv=
ed within a small window of time, opting for the first-seen rule otherwise.=
=C2=A0 I assume many miners have an idea of how long it takes for anyone=
9;s new block to get across the network, and more specifically, the range o=
f times it takes for new solutions to get to themselves.=C2=A0 During this =
little time window, the chances are 50/50 that they'll choose the right=
block.=C2=A0 If the default behavior were to use BTCDD during that time wi=
ndow (one second? I have no idea!), then the chances would be significantly=
better.<br><br></div>I think Jorge is right that it doesn't benefit mi=
ners.=C2=A0 It doesn't hurt them either, unless they are trying to do s=
elfish mining.=C2=A0 Well, it benefits them in terms of increased bitcoin s=
tability by A) making it easier for clients to decide which block is valid =
when they see two competing with each other, B) motivating miners to add tr=
ansactions instead of mining empty blocks, C) severely decreasing the utili=
ty of any global private network of nodes intended to spread selfishly-mine=
d blocks, and D) motivating miners to stay well-connected so that they get =
transactions quickly.<br></div><div><br></div><div>I sent this to the list =
because it is only useful if it is set as default behavior since most miner=
s leave the defaults alone, and the benefits don't materialize unless a=
majority follows the policy.<br></div></div><div class=3D"gmail_extra"><br=
><div class=3D"gmail_quote">On Fri, Sep 11, 2015 at 11:37 AM, Jorge Tim=C3=
=B3n <span dir=3D"ltr"><<a href=3D"mailto:jtimon@jtimon.cc" target=3D"_b=
lank">jtimon@jtimon.cc</a>></span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><span class=3D""><p dir=3D"ltr"><br>
On Sep 11, 2015 1:18 PM, "Christophe Biocca" <<a href=3D"mailt=
o:christophe.biocca@gmail.com" target=3D"_blank">christophe.biocca@gmail.co=
m</a>> wrote:<br>
><br>
> It's pretty obvious that Dave is suggesting an alternate tie-break=
er:</p>
</span><p dir=3D"ltr">I thought he was proposing a new consesnsus rule. I s=
ee, this would be just a policy validation that everybody would be free to =
ignore (like the "first seen" spend conflict tx replacement polic=
y).</p>
<p dir=3D"ltr">I don't see how miners would benefit from running this p=
olicy so I would not expect them to run it in the long run (like the "=
first seen" spend conflict tx replacement policy).<br>
If miners don't use it, I don't see how users can benefit from runn=
ing that policy themselves.<br>
They will still have to keep waiting some block confirmation to exponential=
ly reduce the chances of a successful double-spend attack with each new con=
firmation (as explained in the bitcoin white paper).</p><span class=3D"">
<p dir=3D"ltr">> Mind you, that risk doesn't apply if we prefer non-=
empty blocks to<br>
> empty blocks and leave it at that, or only switch if the new block<br>
> doesn't double spend transactions in the old one, so it's a fi=
xable<br>
> issue.</p>
</span><p dir=3D"ltr">How do you know which of 2 blocks with the same heigh=
t is "newer"?</p><div class=3D"HOEnZb"><div class=3D"h5">
<p dir=3D"ltr">> On 11 September 2015 at 12:32, Jorge Tim=C3=B3n<br>
> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
> ><br>
> > On Sep 11, 2015 12:27 PM, "Dave Scotese via bitcoin-dev"=
;<br>
> > <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ=
et=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
> >><br>
> >> Rather than (promising to, and when they don't actually, =
at least<br>
> >> pretending to) use the first-seen block, I propose that a mor=
e sophisticated<br>
> >> method of choosing which of two block solutions to accept.<br=
>
> ><br>
> > There's already a criterion to chose: the one with more work =
(in valid<br>
> > blocks) on top of it.<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > bitcoin-dev mailing list<br>
> > <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
> > <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bit=
coin-dev" target=3D"_blank">https://lists.linuxfoundation.org/mailman/listi=
nfo/bitcoin-dev</a><br>
> ><br>
</p>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br><div class=
=3D"gmail_signature"><div dir=3D"ltr">I like to provide some work at no cha=
rge to prove my value. Do you need a techie?=C2=A0 <br>I own <a href=3D"htt=
p://www.litmocracy.com" target=3D"_blank">Litmocracy</a> and <a href=3D"htt=
p://www.memeracing.net" target=3D"_blank">Meme Racing</a> (in alpha). <br>I=
'm the webmaster for <a href=3D"http://www.voluntaryist.com" target=3D"=
_blank">The Voluntaryist</a> which now accepts Bitcoin.<br>I also code for =
<a href=3D"http://dollarvigilante.com/" target=3D"_blank">The Dollar Vigila=
nte</a>.<br>"He ought to find it more profitable to play by the rules&=
quot; - Satoshi Nakamoto</div></div>
</div>
--089e013c60c0c589db051f7db0a7--
|
