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
|
Return-Path: <mashuribc@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 4F6C19FB
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 8 Jul 2015 19:15:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com
[209.85.192.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 86367144
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 8 Jul 2015 19:15:17 +0000 (UTC)
Received: by pddu5 with SMTP id u5so63128072pdd.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 08 Jul 2015 12:15:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=from:to:subject:date:message-id:mime-version:content-type
:thread-index:content-language;
bh=wZVqzehmngEBE8OX5KUJpuQkNrzNuiw1P4fQFT0ZGi0=;
b=pFtLm8LjqmU8OtM3HnB0udPMz06mMfZw0JSQ0JS6f5i6aXsHq6YRO5X18sJk+k/8ME
fKjKjuY7n9MuEQ3q3EObJt9/ADHG7aPKtpnhQb147AEpLONK2+lvyX9LZ7Gad80PdOYX
hy4wRWIZoYShIbggZwEnx8kY8pWpQ5JJlJzjmDCYB/zJw26SqRDyQBOM0klMHz/pRxzr
aBKfhODUng+yKcWMbd5HJLt58xjvYUq2ytXRuIzQNWNYIWfYtjWBIntfWmRv95YDVGn1
nGLP9oPhgXvtKurQjPwmRty06hqcq3dgD5UcBXZiijLOboo5bikN8VULBNkOvommGApF
DFEw==
X-Received: by 10.66.146.100 with SMTP id tb4mr23518377pab.70.1436382917346;
Wed, 08 Jul 2015 12:15:17 -0700 (PDT)
Received: from XMClarkiMacP ([168.161.192.15])
by smtp.gmail.com with ESMTPSA id
qg5sm3316265pbc.68.2015.07.08.12.15.16
(version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
Wed, 08 Jul 2015 12:15:16 -0700 (PDT)
From: Mashuri Clark <mashuribc@gmail.com>
X-Google-Original-From: "Mashuri Clark" <MashuriBC@GMail.com>
To: <pieter.wuille@gmail.com>,
<bitcoin-dev@lists.linuxfoundation.org>
Date: Wed, 8 Jul 2015 12:15:08 -0700
Message-ID: <007801d0b9b2$6815f0d0$3841d270$@GMail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0079_01D0B977.BBB78E00"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AdC5skuxXXIgUveNSvCCZEPFOWoEiA==
Content-Language: en-us
X-Antivirus: avast! (VPS 150708-1, 07/08/2015), Outbound message
X-Antivirus-Status: Clean
X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_IMAGE_ONLY_32,
HTML_MESSAGE,
RCVD_IN_DNSWL_LOW,T_REMOTE_IMAGE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [bitcoin-dev] [Bitcoin-development] Mining centralization pressure
from non-uniform propagation speed
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: Wed, 08 Jul 2015 19:15:18 -0000
This is a multipart message in MIME format.
------=_NextPart_000_0079_01D0B977.BBB78E00
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Would it be easy to code in another variable? I think it would be useful to
know how a per-node imposed max block size limit (with this limit, a node
would still accept all incoming blocks, but refuse to relay any above a
specified size) would affect orphan rates and reorgs. Example: What would
the orphan rate be of an 8MB block if 80% of all nodes refuse to relay it?
The resulting data would provide insight into how nodes can enforce a
dynamic maximum block size in absence of a hard limit.
I would do this myself but I am not a coder. I'm hoping someone here who is
capable finds this data worth pursuing.
--
MC
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
------=_NextPart_000_0079_01D0B977.BBB78E00
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
=2EMsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3D"#0563C1=
" vlink=3D"#954F72"><div class=3DWordSection1><p class=3DMsoNormal>Would it=
be easy to code in another variable? I think it would be useful to k=
now how a per-node imposed max block size limit (with this limit, a node wo=
uld still accept all incoming blocks, but refuse to relay any above a speci=
fied size) would affect orphan rates and reorgs. Example: What would =
the orphan rate be of an 8MB block if 80% of all nodes refuse to relay it?&=
nbsp; The resulting data would provide insight into how nodes can enforce a=
dynamic maximum block size in absence of a hard limit.<o:p></o:p></p><p cl=
ass=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>I would do this m=
yself but I am not a coder. I’m hoping someone here who is capa=
ble finds this data worth pursuing.<o:p></o:p></p><p class=3DMsoNormal><o:p=
> </o:p></p><p class=3DMsoNormal>--<o:p></o:p></p><p class=3DMsoNormal=
>MC<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p></div>
<br /><br />
<hr style=3D'border:none; color:#909090; background-color:#B0B0B0; height: =
1px; width: 99%;' />
<table style=3D'border-collapse:collapse;border:none;'>
<tr>
<td style=3D'border:none;padding:0px 15px 0px 8px'>
<a href=3D"https://www.avast.com/antivirus">
<img border=3D0 src=3D"http://static.avast.com/emails/avast-mail-stamp.=
png" alt=3D"Avast logo" />
</a>
</td>
<td>
<p style=3D'color:#3d4d5a; font-family:"Calibri","Verdana","Arial","Helv=
etica"; font-size:12pt;'>
This email has been checked for viruses by Avast antivirus software.
<br><a href=3D"https://www.avast.com/antivirus">www.avast.com</a>
</p>
</td>
</tr>
</table>
<br />
</body></html>
------=_NextPart_000_0079_01D0B977.BBB78E00--
|
