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
|
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 <mh.in.england@gmail.com>) id 1Z4GJj-0002Wp-On
for bitcoin-development@lists.sourceforge.net;
Sun, 14 Jun 2015 22:23:51 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.172 as permitted sender)
client-ip=209.85.212.172; envelope-from=mh.in.england@gmail.com;
helo=mail-wi0-f172.google.com;
Received: from mail-wi0-f172.google.com ([209.85.212.172])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z4GJi-0006pR-F7
for bitcoin-development@lists.sourceforge.net;
Sun, 14 Jun 2015 22:23:51 +0000
Received: by wifx6 with SMTP id x6so60450982wif.0
for <bitcoin-development@lists.sourceforge.net>;
Sun, 14 Jun 2015 15:23:44 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.59.98 with SMTP id y2mr3244729wjq.42.1434320624415; Sun,
14 Jun 2015 15:23:44 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.28.14.196 with HTTP; Sun, 14 Jun 2015 15:23:44 -0700 (PDT)
In-Reply-To: <CALqxMTHrnSS9MGgKO-5+=fVhiOOvk12Recs11S0PcSUxQT1wdQ@mail.gmail.com>
References: <CALqxMTHrnSS9MGgKO-5+=fVhiOOvk12Recs11S0PcSUxQT1wdQ@mail.gmail.com>
Date: Mon, 15 Jun 2015 00:23:44 +0200
X-Google-Sender-Auth: mPK2lBBACTpmyaQ-AL-bhB2fE_U
Message-ID: <CANEZrP1nx9rNf1q-nubP77U8RMABuLtmEB_P7UpY2zyFf-Ns-w@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Adam Back <adam@cypherspace.org>
Content-Type: multipart/alternative; boundary=047d7ba978a04ffb92051881cb20
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: 1Z4GJi-0006pR-F7
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] comments on BIP 100
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, 14 Jun 2015 22:23:51 -0000
--047d7ba978a04ffb92051881cb20
Content-Type: text/plain; charset=UTF-8
>
> One thing that is concerning is that few in industry seem inclined to
> take any development initiatives or even integrate a library.
Um, you mean except all the people who have built more scalable wallets
over the past few years, which is the only reason anyone can even use
Bitcoin from their phone? Or maybe you mean initiatives like Lightning ....
except StrawPay already developed something similar to the Lightning
network (complete with a working GUI wallet) and were ignored by
Blockstream as you prefer to write your own from scratch?
Sure, people in the industry take development initiatives. That doesn't
mean their work will be recognised on this mailing list.
> I suppose eventually that problem would self-correct as new startups would
> make a more scalable wallet and services that are layer2 aware and eat the
> lunch of the laggards.
"The laggards" being *everyone* who has already invested in building
Bitcoin software so far. Not a great way to frame things. Many of those
"laggards" have written orders of magnitude more code than you or Gregory
or Jeff, for instance.
I still think you guys don't recognise what you are actually asking for
here - scrapping virtually the entire existing investment in software,
wallets and tools.
> But it will be helpful if we expose companies to the back-pressure
> actually implied by an O(n^2) scaling protocol and don't just immediately
> increase the block-size to levels that are dangerous for decentralisation
> security
Bitcoin does not have n-squared scaling. I really don't get where this idea
comes from. Computational complexity for the entire network is O(nm) where
n=transactions and m=fully validating nodes. There is no fixed
relationships between those two variables.
"Exposing the companies to back-pressure" sounds quite nice and gentle. Let
me rephrase it to be equivalent but perhaps more direct: you mean "breaking
the current software ecosystem to force people into a new, fictional system
that bears little resemblance to the Bitcoin we use today, whether they
want that or not".
As nothing that has been proposed so far (Lightning, merge mined chains,
extension blocks etc) has much chance of actual deployment any time soon,
that leaves raising the block size limit as the only possible path left.
Which is why there will soon be a fork that does it.
--047d7ba978a04ffb92051881cb20
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:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">One thing that is concerning is that few in indu=
stry seem inclined to<br>
take any development initiatives or even integrate a library.=C2=A0</blockq=
uote><div><br></div><div>Um, you mean except all the people who have built =
more scalable wallets over the past few years, which is the only reason any=
one can even use Bitcoin from their phone? Or maybe you mean initiatives li=
ke Lightning .... except StrawPay already developed something similar to th=
e Lightning network (complete with a working GUI wallet) and were ignored b=
y Blockstream as you prefer to write your own from scratch?</div><div><br><=
/div><div>Sure, people in the industry take development initiatives. That d=
oesn't mean their work will be recognised on this mailing list.</div><d=
iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"> I=C2=A0suppose eventually th=
at problem would self-correct as new startups=C2=A0would make a more scalab=
le wallet and services that are layer2 aware=C2=A0and eat the lunch of the =
laggards.=C2=A0</blockquote><div><br></div><div>"The laggards" be=
ing <i>everyone</i> who has already invested in building Bitcoin software s=
o far. Not a great way to frame things. Many of those "laggards" =
have written orders of magnitude more code than you or Gregory or Jeff, for=
instance.</div><div><br></div><div>I still think you guys don't recogn=
ise what you are actually asking for here - scrapping virtually the entire =
existing investment in software, wallets and tools.</div><div>=C2=A0<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"> But it will be helpful if we=C2=A0expose=
companies to the back-pressure actually implied by an O(n^2)=C2=A0scaling =
protocol and don't just immediately increase the block-size to=C2=A0lev=
els that are dangerous for decentralisation security</blockquote><div><br><=
/div><div>Bitcoin does not have n-squared scaling. I really don't get w=
here this idea comes from. Computational complexity for the entire network =
is O(nm) where n=3Dtransactions and m=3Dfully validating nodes. There is no=
fixed relationships between those two variables.</div><div><br></div><div>=
"Exposing the companies to back-pressure" sounds quite nice and g=
entle. Let me rephrase it to be equivalent but perhaps more direct: you mea=
n "breaking the current software ecosystem to force people into a new,=
fictional system that bears little resemblance to the Bitcoin we use today=
, whether they want that or not".</div><div><br></div><div>As nothing =
that has been proposed so far (Lightning, merge mined chains, extension blo=
cks etc) has much chance of actual deployment any time soon, that leaves ra=
ising the block size limit as the only possible path left. Which is why the=
re will soon be a fork that does it.</div><div><br></div></div></div></div>
--047d7ba978a04ffb92051881cb20--
|
