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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1Yz2hr-0001P0-2a
for bitcoin-development@lists.sourceforge.net;
Sun, 31 May 2015 12:51:11 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.169 as permitted sender)
client-ip=209.85.214.169; envelope-from=gavinandresen@gmail.com;
helo=mail-ob0-f169.google.com;
Received: from mail-ob0-f169.google.com ([209.85.214.169])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Yz2hp-00047A-SC
for bitcoin-development@lists.sourceforge.net;
Sun, 31 May 2015 12:51:11 +0000
Received: by obbea2 with SMTP id ea2so86459456obb.3
for <bitcoin-development@lists.sourceforge.net>;
Sun, 31 May 2015 05:51:04 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.202.136.139 with SMTP id k133mr13610012oid.7.1433076664312;
Sun, 31 May 2015 05:51:04 -0700 (PDT)
Received: by 10.60.28.65 with HTTP; Sun, 31 May 2015 05:51:04 -0700 (PDT)
In-Reply-To: <20150531070530.GD12966@muck>
References: <554BE0E1.5030001@bluematt.me>
<CAFzgq-xByQ1E_33_m3UpXQFUkGc78HKnA=7XXMshANDuTkNsvA@mail.gmail.com>
<20150531070530.GD12966@muck>
Date: Sun, 31 May 2015 08:51:04 -0400
Message-ID: <CABsx9T1jpOTxm3c4RYqK7sTF2YShL_ZYDsOWQuNZZXdBKa3Ytw@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a113e12b8835273051760295e
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
(gavinandresen[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
0.0 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Yz2hp-00047A-SC
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase Requirements
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: Sun, 31 May 2015 12:51:11 -0000
--001a113e12b8835273051760295e
Content-Type: text/plain; charset=UTF-8
On Sun, May 31, 2015 at 3:05 AM, Peter Todd <pete@petertodd.org> wrote:
> Yeah, I'm pretty surprised myself that Gavin never accepted the
> compromises offered by others in this space for a slow growth solution
>
What compromise? I haven't seen a specific proposal that could be turned
into a pull request.
> Something important to note in Gavin Andresen's analysises of this issue
> is that he's using quite optimistic scenarios for how nodes are
> connected to each other.
NO I AM NOT.
I simulated a variety of connectivities; see the .cfg files at
https://github.com/gavinandresen/bitcoin_miningsim
The results I give in the "are bigger blocks better" blog post are for
WORST CASE connectivity (one dominant big miner, multiple little miners,
big miner connects to only 30% of little miners, but all the little miners
connected directly to each other).
> For instance, assuming that connections between
> miners are direct is a very optimistic assumption
Again, I did not simulate all miners directly connected to each other.
I will note that miners are VERY HIGHLY connected today. It is in their
best interest to be highly connected to each other.
> that depends on a
> permissive, unregulated, environment where miners co-operate with each
> other - obviously that's easily subject to change!
Really? How is that easily subject to change? If it is easily subject to
change, do bigger blocks have any effect? Why are 1MB blocks not subject to
change?
I talk about "what if your government bans Bitcoin entirely" here:
http://gavinandresen.ninja/big-blocks-and-tor
... and the issues are essentially the same, independent of block size.
--
--
Gavin Andresen
--001a113e12b8835273051760295e
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 S=
un, May 31, 2015 at 3:05 AM, Peter Todd <span dir=3D"ltr"><<a href=3D"ma=
ilto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>></span=
> wrote:<br><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-s=
tyle:solid;padding-left:1ex">Yeah, I'm pretty surprised myself that Gav=
in never accepted the<br>
compromises offered by others in this space for a slow growth solution<br><=
/blockquote><div><br></div><div>What compromise? I haven't seen a speci=
fic proposal that could be turned into a pull request.</div><div><br></div>=
<div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,20=
4,204);border-left-style:solid;padding-left:1ex">Something important to not=
e in Gavin Andresen's analysises of this issue<br>
is that he's using quite optimistic scenarios for how nodes are<br>
connected to each other.</blockquote><div><br></div><div>NO I AM NOT.</div>=
<div><br></div><div>I simulated a variety of connectivities; see the .cfg f=
iles at</div><div>=C2=A0=C2=A0<a href=3D"https://github.com/gavinandresen/b=
itcoin_miningsim">https://github.com/gavinandresen/bitcoin_miningsim</a></d=
iv><div><br></div><div>The results I give in the "are bigger blocks be=
tter" blog post are for WORST CASE connectivity (one dominant big mine=
r, multiple little miners, big miner connects to only 30% of little miners,=
but all the little miners connected directly to each other).</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex"> For instance, assuming that connections between<=
br>
miners are direct is a very optimistic assumption</blockquote><div><br></di=
v><div>Again, I did not simulate all miners directly connected to each othe=
r.</div><div><br></div><div>I will note that miners are VERY HIGHLY connect=
ed today. It is in their best interest to be highly connected to each other=
.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;padding-left:1ex"> that depends on a<br>
permissive, unregulated, environment where miners co-operate with each<br>
other - obviously that's easily subject to change! </blockquote><div><b=
r></div><div>Really? How is that easily subject to change? If it is easily =
subject to change, do bigger blocks have any effect? Why are 1MB blocks not=
subject to change?</div><div><br></div><div>I talk about "what if you=
r government bans Bitcoin entirely" here:</div><div>=C2=A0 =C2=A0<a hr=
ef=3D"http://gavinandresen.ninja/big-blocks-and-tor">http://gavinandresen.n=
inja/big-blocks-and-tor</a></div><div><br></div><div>... and the issues are=
essentially the same, independent of block size.</div><div><br></div></div=
><div><br></div>-- <br><div class=3D"gmail_signature">--<br>Gavin Andresen<=
br></div>
</div></div>
--001a113e12b8835273051760295e--
|
