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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1Yqf7f-0003Ku-Qv
for bitcoin-development@lists.sourceforge.net;
Fri, 08 May 2015 10:03:11 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.175 as permitted sender)
client-ip=209.85.212.175; envelope-from=mh.in.england@gmail.com;
helo=mail-wi0-f175.google.com;
Received: from mail-wi0-f175.google.com ([209.85.212.175])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Yqf7e-0006rB-Hw
for bitcoin-development@lists.sourceforge.net;
Fri, 08 May 2015 10:03:11 +0000
Received: by wiun10 with SMTP id n10so21538511wiu.1
for <bitcoin-development@lists.sourceforge.net>;
Fri, 08 May 2015 03:03:04 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.12.228 with SMTP id b4mr4617584wic.92.1431079384511;
Fri, 08 May 2015 03:03:04 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.194.143.9 with HTTP; Fri, 8 May 2015 03:03:04 -0700 (PDT)
In-Reply-To: <554BE0E1.5030001@bluematt.me>
References: <554BE0E1.5030001@bluematt.me>
Date: Fri, 8 May 2015 12:03:04 +0200
X-Google-Sender-Auth: D4Sz1v65Vtub6viZx-IZhnUJY68
Message-ID: <CANEZrP3uKLvzKi-wXBJWL=pwqB+eAe3FbPjyESD52y5TGkg+Rg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Matt Corallo <bitcoin-list@bluematt.me>
Content-Type: multipart/alternative; boundary=001a11c2a3a85bfc0305158f2236
X-Spam-Score: -0.5 (/)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1Yqf7e-0006rB-Hw
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: Fri, 08 May 2015 10:03:11 -0000
--001a11c2a3a85bfc0305158f2236
Content-Type: text/plain; charset=UTF-8
>
> * Though there are many proposals floating around which could
> significantly decrease block propagation latency, none of them are
> implemented today.
With a 20mb cap, miners still have the option of the soft limit.
I would actually be quite surprised if there were no point along the road
from 1mb to 20mb where miners felt a need to throttle their block sizes
artificially, for the exact reason you point out: propagation delays.
But we don't *need* to have fancy protocol upgrades implemented right now.
All we need is to demolish one bottleneck (the hard cap) so we can then
move on and demolish the next one (whatever that is, probably faster
propagation). Scaling is a series of walls we punch through as we encounter
them. One down, onto the next. We don't have to tackle them all
simultaneously.
FWIW I don't think the GFW just triggers packet loss, these days. It's
blocked port 8333 entirely.
* I'd very much like to see someone working on better scaling
> technology ... I know StrawPay is working on development,
>
So this request is already satisfied, isn't it? As you point out, expecting
more at this stage in development is unreasonable, there's nothing for
anyone to experiment with or commit to.
They have code here, by the way:
https://github.com/strawpay
You can find their fork of MultiBit HD, their implementation library, etc.
They've contributed patches and improvements to the payment channels code
we wrote.
> * I'd like to see some better conclusions to the discussion around
> long-term incentives within the system.
>
What are your thoughts on using assurance contracts to fund network
security?
I don't *know* if hashing assurance contracts (HACs) will work. But I don't
know they won't work either. And right now I'm pretty sure that plain old
fee pressure won't work. Demand doesn't outstrip supply forever - people
find substitutes.
--001a11c2a3a85bfc0305158f2236
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"><blo=
ckquote 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;paddi=
ng-left:1ex">=C2=A0* Though there are many proposals floating around which =
could<br>
significantly decrease block propagation latency, none of them are<br>
implemented today. </blockquote><div><br></div><div>With a 20mb cap, miners=
still have the option of the soft limit.</div><div><br></div><div>I would =
actually be quite surprised if there were no point along the road from 1mb =
to 20mb where miners felt a need to throttle their block sizes artificially=
, for the exact reason you point out: propagation delays.</div><div><br></d=
iv><div>But we don't <i>need</i>=C2=A0to have fancy protocol upgrades i=
mplemented right now. All we need is to demolish one bottleneck (the hard c=
ap) so we can then move on and demolish the next one (whatever that is, pro=
bably faster propagation). Scaling is a series of walls we punch through as=
we encounter them. One down, onto the next. We don't have to tackle th=
em all simultaneously.</div><div><br></div><div>FWIW I don't think the =
GFW just triggers packet loss, these days. It's blocked port 8333 entir=
ely.</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">=C2=A0* I'd very much like to=
see someone working on better scaling<br>
technology ...=C2=A0I know StrawPay is working on development,<br></blockqu=
ote><div><br></div><div>So this request is already satisfied, isn't it?=
As you point out, expecting more at this stage in development is unreasona=
ble, there's nothing for anyone to experiment with or commit to.</div><=
div><br></div><div>They have code here, by the way:</div><div><br></div><di=
v>=C2=A0 =C2=A0<a href=3D"https://github.com/strawpay">https://github.com/s=
trawpay</a><br></div><div><br></div><div>You can find their fork of MultiBi=
t HD, their implementation library, etc. They've contributed patches an=
d improvements to the payment channels code we wrote.</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,204,204);border-left-style:solid;=
padding-left:1ex">
=C2=A0* I'd like to see some better conclusions to the discussion aroun=
d<br>
long-term incentives within the system.<br></blockquote><div><br></div><div=
>What are your thoughts on using assurance contracts to fund network securi=
ty?</div><div><br></div><div>I don't <i>know</i>=C2=A0if hashing assura=
nce contracts (HACs) will work. But I don't know they won't work ei=
ther. And right now I'm pretty sure that plain old fee pressure won'=
;t work. Demand doesn't outstrip supply forever - people find substitut=
es.=C2=A0</div></div></div></div>
--001a11c2a3a85bfc0305158f2236--
|
