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
|
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 <pieter.wuille@gmail.com>) id 1Z3Trs-00069w-FV
for bitcoin-development@lists.sourceforge.net;
Fri, 12 Jun 2015 18:39:52 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.49 as permitted sender)
client-ip=209.85.213.49; envelope-from=pieter.wuille@gmail.com;
helo=mail-yh0-f49.google.com;
Received: from mail-yh0-f49.google.com ([209.85.213.49])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z3Trr-0004DH-Hf
for bitcoin-development@lists.sourceforge.net;
Fri, 12 Jun 2015 18:39:52 +0000
Received: by yhpn97 with SMTP id n97so17128212yhp.0
for <bitcoin-development@lists.sourceforge.net>;
Fri, 12 Jun 2015 11:39:46 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.170.77.194 with SMTP id t185mr20611564ykt.44.1434134386062;
Fri, 12 Jun 2015 11:39:46 -0700 (PDT)
Received: by 10.37.93.67 with HTTP; Fri, 12 Jun 2015 11:39:46 -0700 (PDT)
Received: by 10.37.93.67 with HTTP; Fri, 12 Jun 2015 11:39:46 -0700 (PDT)
In-Reply-To: <20150612183054.GD19199@muck>
References: <CAPg+sBi5fYHGLv4wtWbWE7jov8CX=q9UX=vhxDVepG6JfX30+g@mail.gmail.com>
<CABsx9T1=+S+dAdwASECUCkrVaMFT0TcmL7MiwnCuCx0MkF6sWw@mail.gmail.com>
<20150612183054.GD19199@muck>
Date: Fri, 12 Jun 2015 20:39:46 +0200
Message-ID: <CAPg+sBjD1y6jTzdWqGLhBxve8HfKy0mxg0tYBTWjBH1PAukmow@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a113a4cf4a43c310518566eb3
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: 1Z3Trr-0004DH-Hf
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Mining centralization pressure from
non-uniform propagation speed
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: Fri, 12 Jun 2015 18:39:52 -0000
--001a113a4cf4a43c310518566eb3
Content-Type: text/plain; charset=UTF-8
If there is a benefit in producing larger more-fee blocks if they propagate
slowly, then there is also a benefit in including high-fee transactions
that are unlikely to propagate quickly through optimized relay protocols
(for example: very recent transactions, or out-of-band receoved ones). This
effect is likely an order of magnitude less important still, but the effect
is likely the same.
On Jun 12, 2015 8:31 PM, "Peter Todd" <pete@petertodd.org> wrote:
> On Fri, Jun 12, 2015 at 01:21:46PM -0400, Gavin Andresen wrote:
> > Nice work, Pieter. You're right that my simulation assumed bandwidth for
> > 'block' messages isn't the bottleneck.
> >
> > But doesn't Matt's fast relay network (and the work I believe we're both
> > planning on doing in the near future to further optimize block
> propagation)
> > make both of our simulations irrelevant in the long-run?
>
> Then simulate first the relay network assuming 100% of txs use it, and
> secondly, assuming 100%-x use it.
>
> For instance, is it in miners' advantage in some cases to sabotage the
> relay network? The analyse say yes, so lets simulate that. Equally even
> the relay network isn't instant.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>
--001a113a4cf4a43c310518566eb3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">If there is a benefit in producing larger more-fee blocks if=
they propagate slowly, then there is also a benefit in including high-fee =
transactions that are unlikely to propagate quickly through optimized relay=
protocols (for example: very recent transactions, or out-of-band receoved =
ones). This effect is likely an order of magnitude less important still, bu=
t the effect is likely the same.</p>
<div class=3D"gmail_quote">On Jun 12, 2015 8:31 PM, "Peter Todd" =
<<a href=3D"mailto:pete@petertodd.org">pete@petertodd.org</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">On Fri, Jun 12, 201=
5 at 01:21:46PM -0400, Gavin Andresen wrote:<br>
> Nice work, Pieter. You're right that my simulation assumed bandwid=
th for<br>
> 'block' messages isn't the bottleneck.<br>
><br>
> But doesn't Matt's fast relay network (and the work I believe =
we're both<br>
> planning on doing in the near future to further optimize block propaga=
tion)<br>
> make both of our simulations irrelevant in the long-run?<br>
<br>
Then simulate first the relay network assuming 100% of txs use it, and<br>
secondly, assuming 100%-x use it.<br>
<br>
For instance, is it in miners' advantage in some cases to sabotage the<=
br>
relay network? The analyse say yes, so lets simulate that. Equally even<br>
the relay network isn't instant.<br>
<br>
--<br>
'peter'[:-1]@<a href=3D"http://petertodd.org" rel=3D"noreferrer" ta=
rget=3D"_blank">petertodd.org</a><br>
0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778<br>
</blockquote></div>
--001a113a4cf4a43c310518566eb3--
|
