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
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <odinn.cyberguerrilla@riseup.net>) id 1Z5jCA-0007LB-TB
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 23:26:06 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of riseup.net
designates 198.252.153.129 as permitted sender)
client-ip=198.252.153.129;
envelope-from=odinn.cyberguerrilla@riseup.net;
helo=mx1.riseup.net;
Received: from mx1.riseup.net ([198.252.153.129])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1Z5jC9-0001JQ-Ch
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 23:26:06 +0000
Received: from plantcutter.riseup.net (plantcutter-pn.riseup.net [10.0.1.121])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(Client CN "*.riseup.net",
Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK))
by mx1.riseup.net (Postfix) with ESMTPS id 3B5B6426AD;
Thu, 18 Jun 2015 23:25:59 +0000 (UTC)
Received: from [127.0.0.1] (localhost [127.0.0.1])
(Authenticated sender: odinn.cyberguerrilla)
with ESMTPSA id B093C225D7
Message-ID: <55835385.60908@riseup.net>
Date: Thu, 18 Jun 2015 16:25:57 -0700
From: odinn <odinn.cyberguerrilla@riseup.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Jeff Garzik <jgarzik@bitpay.com>, Mark Friedenbach <mark@friedenbach.org>
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>
<CAJHLa0PG8C3LShqjY_sTiFw5K+j_vA1Bger2d8QnUVe07gTDDA@mail.gmail.com>
In-Reply-To: <CAJHLa0PG8C3LShqjY_sTiFw5K+j_vA1Bger2d8QnUVe07gTDDA@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
X-Virus-Scanned: clamav-milter 0.98.7 at mx1
X-Virus-Status: Clean
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.7 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [198.252.153.129 listed in list.dnswl.org]
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 SPF_PASS SPF: sender matches SPF record
-0.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay
lines
-0.1 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Z5jC9-0001JQ-Ch
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 23:26:06 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Regarding the bit on "getting out in front of the need, to prevent
significant negative impacts to users" I had suggested the following:
On 06/18/2015 03:52 PM, Jeff Garzik wrote:
> On Thu, Jun 18, 2015 at 3:33 PM, Mark Friedenbach
> <mark@friedenbach.org <mailto:mark@friedenbach.org>> wrote:
>=20
> On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik <jgarzik@bitpay.com=20
> <mailto:jgarzik@bitpay.com>> wrote:
>=20
>=20
> The whole point is getting out in front of the need, to prevent=20
> significant negative impact to users when blocks are consistently
> full.
My thoughts on that:
Possible scope narrowing to one of the following concepts (but please,
someone tell me if this "scope narrowing" is unwise, not timely, or if
there is some other factors that would make it just stupid right now
because other things are in the works or whatever:
~ Jeff Garzik, with respect to his BIP 100 (note Evan Mo, CEO of
Huobi's mining project Digcoin, clarified that the big Chinese mining
pools consider further adjustments to the protocol beyond the
suggested 8 MB block size limit adjustment =97 such as the Bitcoin core
developer Jeff Garzik's BIP-100 draft =97 to be feasible)
~ Adam Back, with a simplified soft-fork one-way peg
~ Gavin Andresen, developing an 8 MB block size limit adjustment in
the context of Core (as an example) with one or more of the above
authors rather than focusing on XT. (This is a big assumption but,
roll with it)
All of this assumes that developer(s) are willing to abandon
intentionally contentious proposals such as the "hard fork to XT w/ 20
MB," remain within the context of Core and be reasonable.
Here I am being aware of the fact that "Pushing a hard fork in the
face of such controversy is a folly, a danger to the network, and that
deserves to be said." - Wladimir J. van der Laan
https://github.com/bitcoin/bitcoin.org/pull/894#issuecomment-112113917
>=20
> To do that, you need to (a) plan forward, in order to (b) set a=20
> hard fork date in the future.
>=20
>=20
> Or alternatively, fix the reasons why users would have negative=20
> experiences with full blocks, chiefly:
>=20
> * Get safe forms of replace-by-fee and child-pays-for-parent=20
> 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.
>=20
> Not raising the block size limit does not mean doing nothing to=20
> solve the problem.
>=20
>=20
> 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.
>=20
> It is a far, far larger amount of work to write, test and deploy
> than simply increasing the block size limit.
>=20
> Think through roll-out of these ambitious suggestions, before
> suggesting as an alternative!
>=20
> 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.
>=20
>=20
>=20
Something else I wanted to point out here in this thread is the
subject of the problem of "developers going off the deep end" which is
what started this thread:
Suppose you have a developer with full commit access who happens to
start threatening to revoking the other developers' commit access on
the repository, or that person doesn't even threaten, one day it just
happens.
What do you have then? Peter Todd has stated that all one "would
achieve by that sabotage is setting a key-value pair in a centralised
registry." But is that what we want?
The answer, obviously, is no.
This leads to other questions. What technical mechanisms exist to keep
developers from (in some dubious emotional or psycho state) to just
going off the deep and doing exactly what has been described above, if
they have full commit access? Is there a process whereby that can't
actually happen unless another developer provides a signature (e.g. a
multisignature type of process)? What keeps bitcoin safe from "The
Hearn Threat?"
If nothing does, then how would you change that?
And go ahead and tell me if these are dumb questions and I should just
be quiet, but if they are, please do explain why they are such dumb
questions.
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> -- Jeff Garzik Bitcoin core developer and open source evangelist=20
> BitPay, Inc. https://bitpay.com/
>=20
>=20
> ----------------------------------------------------------------------
- --------
>
>=20
>=20
>=20
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development@lists.sourceforge.net=20
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>=20
- --=20
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVg1OFAAoJEGxwq/inSG8COpAIAJrH9Uj9bcKr+UUR7ePV6/Yj
MmNTY2VKAtiQhwHM+Mqk2VvQANs7/uRBdZjzGnw1NRcca/m8Q0yZUHQiP8avCUOE
3MHqGviYjfeJdu1pcf+PO2pAImM5FCFdrfbbiWUt+ZoOKTxZjsLtF4RE+mc13AXJ
dktvy6SFdvQUgEx8pdXEDpmaUSYUr7syFP4sgHZmyMlhvCsXyE/8dC3sZTzEpVnC
xy1dyBmXHPW3W4FfBSblwwWgJWMcIcGJn8OLQKK5pni/iSVL6IMoRI/MLwOJdRr4
lr83g9FR/qxMqAT9UIZtATnePlkkWPU1szvak/tU/49fGioyYOF4b4KPg/bHYSc=3D
=3DhBcE
-----END PGP SIGNATURE-----
|
