summaryrefslogtreecommitdiff
path: root/8c/8e9d41da36448d3a7154f2b8aaf7d72378b156
blob: 2f03f933970b3f60aaf2b9b50a9f1daf710ef3d9 (plain)
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-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 <jjlegoupil@gmail.com>) id 1YzP5w-0007dA-89
	for bitcoin-development@lists.sourceforge.net;
	Mon, 01 Jun 2015 12:45:32 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.41 as permitted sender)
	client-ip=74.125.82.41; envelope-from=jjlegoupil@gmail.com;
	helo=mail-wg0-f41.google.com; 
Received: from mail-wg0-f41.google.com ([74.125.82.41])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YzP5r-0007Ke-7z
	for bitcoin-development@lists.sourceforge.net;
	Mon, 01 Jun 2015 12:45:32 +0000
Received: by wgbgq6 with SMTP id gq6so113364432wgb.3
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 01 Jun 2015 05:45:21 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.59.79 with SMTP id x15mr24169278wjq.81.1433162721283;
	Mon, 01 Jun 2015 05:45:21 -0700 (PDT)
Received: by 10.194.109.163 with HTTP; Mon, 1 Jun 2015 05:45:21 -0700 (PDT)
Date: Mon, 1 Jun 2015 14:45:21 +0200
Message-ID: <CAFnMCfd8N_2nvspXF+Tro_SsofUUrMy4_QG9tRbPm1pUWtUCXQ@mail.gmail.com>
From: =?UTF-8?B?SsOpcsO0bWUgTGVnb3VwaWw=?= <jjlegoupil@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=047d7b8737aee852db0517743258
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
	(jjlegoupil[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
X-Headers-End: 1YzP5r-0007Ke-7z
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step
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: Mon, 01 Jun 2015 12:45:32 -0000

--047d7b8737aee852db0517743258
Content-Type: text/plain; charset=UTF-8

>What do other people think?
>
>
>If we can't come to an agreement soon, then I'll ask for help
>reviewing/submitting patches to Mike's Bitcoin-Xt project that implement a
>big increase now that grows over time so we may never have to go through
>all this rancor and debate again."
>
>
>I'll then ask for help lobbying the merchant services and exchanges and
>hosted wallet companies and other bitcoind-using-infrastructure companies


It's surprising to see a core dev going to the public to defend a proposal
most other core devs disagree on, and then lobbying the Bitcoin ecosystem.

This is an very unhealthy way to go because it incentives the other core
devs to stop their technical work and go public and lobby too (cf G.Maxwell
trying to raise redditters awareness).

We need core devs to work on technical issues, not waste time doing
politics, but Gavin's confrontational approach doesn't give them much of a
choice.

I fear that because of this approach, in the next monthes, core devs with
be lobbying and doing politics : precious time will be wasted for everyone
having stake in Bitcoin.


Regarding the 20MB proposal content:

Decentralization is the core of Bitcoin's security model and thus that's
what gives Bitcoin its value.

The danger is that decentralization tends naturally towards centralization,
because centralization is more efficient. Going from decentralization to
centralization is easy, going the other way is a lot harder :
decentralization we lose, may never be gained back.

Regarding "the urgency to do something":

I believe it would be extremely healthy for the network to bump into any
limit ASAP ... (let it be 1MB) : to incentive layer 2 and offchain
solutions to scale Bitcoin : there are promising designs/solutions out
there (LN, ChainDB, OtherCoin protocole, ...), but most don't get much
attention, because there is right now no need for them. And, I am sure new
solutions will be invented.

If during the "1MB bumpy period" something goes wrong, consensus among the
community would be reached easily if necessary.

Pretending there is urgency and that Apocalypse is approaching is a fallacy.

The Gavin 20MB proposal is compromising Bitcoin's long-term security in an
irreversible way, for gaining short-term better user experience.

I oppose the Gavin proposal in both content and form.

Cheers,
Jerome

--047d7b8737aee852db0517743258
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>&gt;What do other people think?<br>
&gt;<br>
&gt;<br>
&gt;If we can&#39;t come to an agreement soon, then I&#39;ll ask for help<b=
r>
&gt;reviewing/submitting patches to Mike&#39;s Bitcoin-Xt project that impl=
ement a<br>
&gt;big increase now that grows over time so we may never have to go throug=
h<br>
&gt;all this rancor and debate again.&quot;<br>&gt;<br>&gt;<br>
&gt;I&#39;ll then ask for help lobbying the merchant services and exchanges=
 and<br>&gt;hosted wallet companies and other bitcoind-using-infrastructure=
 companies<br><br><br>It&#39;s surprising to see a core dev going to the pu=
blic to defend a proposal most other core devs disagree on, and then lobbyi=
ng the Bitcoin ecosystem.<br><br>This
 is an very unhealthy way to go because it incentives the other core=20
devs to stop their technical work and go public and lobby too (cf=20
G.Maxwell trying to raise redditters awareness). <br><br>We need core devs =
to=20
work on technical issues, not waste time doing politics, but Gavin&#39;s=20
confrontational approach doesn&#39;t give them much of a choice.<br><br>I f=
ear
 that because of this approach, in the next monthes, core devs with be lobb=
ying and doing=20
politics : precious time will be wasted for everyone=20
having stake in Bitcoin.<br><br></div><div><br>Regarding the 20MB proposal =
content:<br><br>Decentralization is the core of Bitcoin&#39;s security mode=
l and thus that&#39;s what gives Bitcoin its value.<br><br>The
 danger is that decentralization tends naturally towards centralization,
 because centralization is more efficient. Going from decentralization=20
to centralization is easy, going the other way is a lot harder :=20
decentralization we lose, may never be gained back.<br><br>Regarding &quot;=
the urgency to do something&quot;:<br><br>I believe it would be extremely h=
ealthy for the network to bump into any limit ASAP ... (let it be 1MB) : to=
 incentive layer 2 and offchain solutions to scale Bitcoin : there=20
are promising designs/solutions out there (LN, ChainDB, OtherCoin=20
protocole, ...), but most don&#39;t get much attention, because there is=20
right now no need for them. And, I am sure new solutions will be=20
invented.<br><br>If during the &quot;1MB bumpy period&quot; something goes =
wrong, consensus among the community would be reached easily if necessary.<=
br><br>Pretending there is urgency and that Apocalypse is approaching is a =
fallacy.<br><br>The
 Gavin 20MB proposal is compromising Bitcoin&#39;s long-term security in an=
=20
irreversible way, for gaining short-term better user experience. <br><br>I =
oppose the Gavin proposal in both content and form.<div class=3D"gmail_extr=
a"><br></div><div class=3D"gmail_extra">Cheers,<br></div><div class=3D"gmai=
l_extra">Jerome<br></div></div></div>

--047d7b8737aee852db0517743258--