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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jgarzik@bitpay.com>) id 1Z5igP-0003b8-16
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 22:53:17 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of bitpay.com
designates 209.85.214.169 as permitted sender)
client-ip=209.85.214.169; envelope-from=jgarzik@bitpay.com;
helo=mail-ob0-f169.google.com;
Received: from mail-ob0-f169.google.com ([209.85.214.169])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z5igO-0004s7-3y
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 22:53:17 +0000
Received: by obbkn5 with SMTP id kn5so35337501obb.0
for <bitcoin-development@lists.sourceforge.net>;
Thu, 18 Jun 2015 15:53:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc:content-type;
bh=pPim39vmQ67k7v1ps+i+AfLFiv8sMEUnNKp979ASEp0=;
b=CwTbjBr9orlfIJMCvPx5vE7bpt3cmHFkgHqqBbnLHZxp7RTG8Uj+XklZA9rTiEvwWV
ZazZ0l9A0aKsy8Yow3m4e0i8l4fBowRxT2DgWXk4fHwBDWS3ucd/f1hCOB1RrnF6h1oG
8OlHR3Kl/ArKl3h9Umz0mhYiihbNZgpXQeoxb6RJwfvJATnY/q3ngSLHNlP+00gm7/NV
SlCZiA2Mae/Jv2K27xseFr+eyIwaw0GCvak1pyt4bIAT5xLWU9jaiBK/XIeW3FQdV/YC
RlFtUVH+7sezRAC9P8i1h1JORgLZdmOLNeLMTsbQUbRmYG5HCA3DzaWt4PFdS+N9bjEm
Q6zQ==
X-Gm-Message-State: ALoCoQknvUPG0LeIo0mjtiQ+YRWtJ6dfo2lU8yfO0D5Bb5Jm5UrWWw9esw/PFuZHGmOOBi4J7kyd
X-Received: by 10.60.92.131 with SMTP id cm3mr10834882oeb.23.1434667990686;
Thu, 18 Jun 2015 15:53:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.108.149 with HTTP; Thu, 18 Jun 2015 15:52:48 -0700 (PDT)
In-Reply-To: <CAOG=w-tf7qz9XSkDg5POKtFLkHWDA==jf2iVxVL8wz1hqcAVOg@mail.gmail.com>
References: <55828737.6000007@riseup.net>
<CABm2gDoa7KxsgvREo3yiNjfd6AeayqAqkjMe2rvX8yyxR_ddcA@mail.gmail.com>
<55831CAB.2080303@jrn.me.uk> <1867667.WXWC1C9quc@crushinator>
<CAOG=w-scXm-46sp2NgR2UUp20R5ujuaAzW-jU_Owh20C4Xc=9A@mail.gmail.com>
<CAJHLa0Mhnma8_ys2ckEA+dLT-EWnqO4j8YKMSaf3Tvv_K14czQ@mail.gmail.com>
<CAOG=w-tf7qz9XSkDg5POKtFLkHWDA==jf2iVxVL8wz1hqcAVOg@mail.gmail.com>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Thu, 18 Jun 2015 15:52:48 -0700
Message-ID: <CAJHLa0PG8C3LShqjY_sTiFw5K+j_vA1Bger2d8QnUVe07gTDDA@mail.gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>
Content-Type: multipart/alternative; boundary=047d7b33d812f4b5850518d2ab53
X-Spam-Score: -0.3 (/)
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 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.3 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Z5igO-0004s7-3y
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>,
Gavin Andresen <gavin@bitcoinfoundation.org>
Subject: Re: [Bitcoin-development] Concerns Regarding Threats by a Developer
to Remove Commit Access from Other Developers
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: Thu, 18 Jun 2015 22:53:17 -0000
--047d7b33d812f4b5850518d2ab53
Content-Type: text/plain; charset=UTF-8
On Thu, Jun 18, 2015 at 3:33 PM, Mark Friedenbach <mark@friedenbach.org>
wrote:
> On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik <jgarzik@bitpay.com> wrote:
>
>>
>> The whole point is getting out in front of the need, to prevent
>> significant negative impact to users when blocks are consistently full.
>>
>> To do that, you need to (a) plan forward, in order to (b) set a hard fork
>> date in the future.
>>
>
> Or alternatively, fix the reasons why users would have negative
> experiences with full blocks, chiefly:
>
> * Get safe forms of replace-by-fee and child-pays-for-parent finished
> and in 0.12.
> * Develop cross-platform libraries for managing micropayment channels,
> and get wallet authors to adopt
> * Use fidelity bonds, solvency proofs, and other tricks to minimize the
> risk of already deployed off-chain solutions as an interim measure until:
> * Deploy soft-fork changes for truly scalable solutions like Lightning
> Network.
>
> Not raising the block size limit does not mean doing nothing to solve the
> problem.
>
This is a long, unreasonable list of work. None of this exists and it
equates to "upgrade all wallets and websites everywhere" It requires all
exchanges, payment processors, merchants, etc. to - basically everybody
but miners - to update.
It is a far, far larger amount of work to write, test and deploy than
simply increasing the block size limit.
Think through roll-out of these ambitious suggestions, before suggesting as
an alternative!
Not a realistic alternative except in an alternate universe where (a)
developer work at all companies is cost free, plus (b) we can pause the
business universe while we wait for The Perfect Solution.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--047d7b33d812f4b5850518d2ab53
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thu, Jun 18, 2015 at 3:33 PM, Mark Friedenbach <span di=
r=3D"ltr"><<a href=3D"mailto:mark@friedenbach.org" target=3D"_blank">mar=
k@friedenbach.org</a>></span> wrote:<br><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span=
class=3D"">On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik <span dir=3D"ltr">=
<<a href=3D"mailto:jgarzik@bitpay.com" target=3D"_blank">jgarzik@bitpay.=
com</a>></span> wrote:<br></span><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><span class=3D""><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><div=
dir=3D"ltr">The whole point is getting out in front of the need, to preven=
t significant negative impact to users when blocks are consistently full.<d=
iv><br></div><div>To do that, you need to (a) plan forward, in order to (b)=
set a hard fork date in the future.</div></div></blockquote><div><br></div=
></span><div>Or alternatively, fix the reasons why users would have negativ=
e experiences with full blocks, chiefly:<br><br></div><div>=C2=A0 * Get saf=
e forms of replace-by-fee and child-pays-for-parent finished and in 0.12.<b=
r></div><div>=C2=A0 * Develop cross-platform libraries for managing micropa=
yment channels, and get wallet authors to adopt <br></div><div>=C2=A0 * Use=
fidelity bonds, solvency proofs, and other tricks to minimize the risk of =
already deployed off-chain solutions as an interim measure until:<br></div>=
<div>=C2=A0 * Deploy soft-fork changes for truly scalable solutions like Li=
ghtning Network.<br><br></div><div>Not raising the block size limit does no=
t mean doing nothing to solve the problem.</div></div></div></div></blockqu=
ote><div><br></div><div>This is a long, unreasonable list of work.=C2=A0 No=
ne of this exists and it equates to "upgrade all wallets and websites =
everywhere" =C2=A0It requires all exchanges, payment processors, merch=
ants, etc. to =C2=A0- basically everybody but miners - to update.</div><div=
><br></div><div>It is a far, far larger amount of work to write, test and d=
eploy than simply increasing the block size limit.</div><div><br></div><div=
>Think through roll-out of these ambitious suggestions, before suggesting a=
s an alternative!</div><div><br></div><div>Not a realistic alternative exce=
pt in an alternate universe where (a) developer work at all companies is co=
st free, plus (b) we can pause the business universe while we wait for The =
Perfect Solution.</div><div><br></div><div><br></div><div><br></div><div><b=
r></div><div><br></div><div><br></div><div>=C2=A0</div></div><br><br clear=
=3D"all"><div><br></div>-- <br><div class=3D"gmail_signature">Jeff Garzik<b=
r>Bitcoin core developer and open source evangelist<br>BitPay, Inc. =C2=A0 =
=C2=A0 =C2=A0<a href=3D"https://bitpay.com/" target=3D"_blank">https://bitp=
ay.com/</a></div>
</div></div>
--047d7b33d812f4b5850518d2ab53--
|
