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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <ctpacia@gmail.com>) id 1Z5kdC-0001kz-KD
for bitcoin-development@lists.sourceforge.net;
Fri, 19 Jun 2015 00:58:06 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.174 as permitted sender)
client-ip=209.85.220.174; envelope-from=ctpacia@gmail.com;
helo=mail-qk0-f174.google.com;
Received: from mail-qk0-f174.google.com ([209.85.220.174])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z5kdB-00061C-Nt
for bitcoin-development@lists.sourceforge.net;
Fri, 19 Jun 2015 00:58:06 +0000
Received: by qkfe185 with SMTP id e185so53323040qkf.3
for <bitcoin-development@lists.sourceforge.net>;
Thu, 18 Jun 2015 17:58:00 -0700 (PDT)
X-Received: by 10.55.42.89 with SMTP id q86mr20203674qkh.74.1434675480330;
Thu, 18 Jun 2015 17:58:00 -0700 (PDT)
Received: from ?IPv6:2601:18d:8301:36e:75f8:f367:7d33:df4e?
([2601:18d:8301:36e:75f8:f367:7d33:df4e])
by mx.google.com with ESMTPSA id
p202sm4795591qha.20.2015.06.18.17.57.59
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 18 Jun 2015 17:57:59 -0700 (PDT)
Message-ID: <55836916.6040002@gmail.com>
Date: Thu, 18 Jun 2015 20:57:58 -0400
From: Chris Pacia <ctpacia@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
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>
In-Reply-To: <CAOG=w-tf7qz9XSkDg5POKtFLkHWDA==jf2iVxVL8wz1hqcAVOg@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------080005050102040202090608"
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
(ctpacia[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: 1Z5kdB-00061C-Nt
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: Fri, 19 Jun 2015 00:58:06 -0000
This is a multi-part message in MIME format.
--------------080005050102040202090608
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
On 06/18/2015 06:33 PM, Mark Friedenbach wrote:
>
> * 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.
One of my biggest concerns is that these solutions (lightning network in
particular) could end up being worse, in terms of decentralization, than
would be a bitcoin network using larger blocks. We don't exactly know
what the economies of scale are for pay hubs and could very well end up
with far fewer hubs than nodes at any conceivable block size.
Of course, it could also turn out to be fantastic, but it seems like an
enormous gamble to basically force everyone in the ecosystem to
collectively spend millions of dollars upgrading to Lightning /and then/
see whether it's actually an improvement in terms of decentralization.
To me, a much more sane approach would be to allow people to voluntarily
opt in to those other solutions after we've had an opportunity to
experiment with them and see how they actually function in practice, but
that can't happen if the network runs out of capacity first.
--------------080005050102040202090608
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 06/18/2015 06:33 PM, Mark Friedenbach wrote:<br>
<blockquote
cite="mid:CAOG=w-tf7qz9XSkDg5POKtFLkHWDA==jf2iVxVL8wz1hqcAVOg@mail.gmail.com"
type="cite">
<div><br>
</div>
<div> * Get safe forms of replace-by-fee and
child-pays-for-parent finished and in 0.12.<br>
</div>
<div> * Develop cross-platform libraries for managing
micropayment channels, and get wallet authors to adopt <br>
</div>
<div> * 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> * Deploy soft-fork changes for truly scalable solutions
like Lightning Network.</div>
</blockquote>
<br>
One of my biggest concerns is that these solutions (lightning
network in particular) could end up being worse, in terms of
decentralization, than would be a bitcoin network using larger
blocks. We don't exactly know what the economies of scale are for
pay hubs and could very well end up with far fewer hubs than nodes
at any conceivable block size. <br>
<br>
Of course, it could also turn out to be fantastic, but it seems like
an enormous gamble to basically force everyone in the ecosystem to
collectively spend millions of dollars upgrading to Lightning <i>and
then</i> see whether it's actually an improvement in terms of
decentralization.<br>
<br>
To me, a much more sane approach would be to allow people to
voluntarily opt in to those other solutions after we've had an
opportunity to experiment with them and see how they actually
function in practice, but that can't happen if the network runs out
of capacity first. <br>
<br>
</body>
</html>
--------------080005050102040202090608--
|
