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
|
Return-Path: <kanzure@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7D6D58EF
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 8 Nov 2015 17:19:16 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f181.google.com (mail-io0-f181.google.com
[209.85.223.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 99F4C179
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 8 Nov 2015 17:19:15 +0000 (UTC)
Received: by iody8 with SMTP id y8so165699485iod.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 08 Nov 2015 09:19:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=NKaSVZH3Im4DOpePiG/+6V+DSIvtQKfARNEpC9hM8eM=;
b=fjAQ6gXrKhWGsI8YtEflE62DC0i3Lv7j1Fe4s8JKNeAIhRxwOHQKKSBpT+/w0E3Oph
KgJNEeAnXgSJQXj9VbDwi1j7eGZDCA2EzE68TZXSEu9UvlGx9umrXVYlJn0k9Aztd7U/
E5KDMlL2nvStumHMURCsmKaKEH1suLV59T/t6d/jCtv3rAlUNw51zFfjz2UB5hZx4VEE
wvV2H+t9viM/jsvXk5NJtVNVrokpELQjAO37sxT41PlGonq8myxkxZ/44S0kFzQDBBEx
T6SeJoDF4HMz9mOTa/7SXtZLBTKxF/FCwE52MVCNU7K35VpFOwmRbuUWl1fvI2aG4d7S
FRaQ==
MIME-Version: 1.0
X-Received: by 10.107.17.160 with SMTP id 32mr15066628ior.28.1447003155097;
Sun, 08 Nov 2015 09:19:15 -0800 (PST)
Received: by 10.36.66.65 with HTTP; Sun, 8 Nov 2015 09:19:15 -0800 (PST)
In-Reply-To: <CABsx9T0T6QuYRmNyF_F124GyQ2EX5w93HCPLvrd4L5P6=xj_Xw@mail.gmail.com>
References: <CALqxMTE1JDsT8fSoDZVTUWfnw4Cmb9LkDa+B-XUyXGPxAYernA@mail.gmail.com>
<CABsx9T0T6QuYRmNyF_F124GyQ2EX5w93HCPLvrd4L5P6=xj_Xw@mail.gmail.com>
Date: Sun, 8 Nov 2015 11:19:15 -0600
Message-ID: <CABaSBaxKQe2SnMuwHq-7482BmY+vvD4SefKjXxEPhxZTOoyHrA@mail.gmail.com>
From: Bryan Bishop <kanzure@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>, Bryan Bishop <kanzure@gmail.com>
Content-Type: multipart/alternative; boundary=001a113ed6780c74b005240aad2f
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sun, 08 Nov 2015 17:20:33 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] summarising security assumptions (re cost metrics)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Nov 2015 17:19:16 -0000
--001a113ed6780c74b005240aad2f
Content-Type: text/plain; charset=UTF-8
On Sun, Nov 8, 2015 at 8:54 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I'm very disappointed you don't mention the tradeoff at "the other end of
> the bathtub" -- Key-holder versus Validator decentralization balance
Gavin, could you please provide some clarity around the definition and
meaning of "key-holder [decentralization]"? Is this about the absolute
number of key-holders? or rather about the number of transactions (per unit
time?) that key-holders make? Both/other?
Anyone can generate a private key, and anyone can sign a transaction
spending to a new commitment. Child-pays-for-parent could be used when
transaction fees are too high. Perhaps more interesting would be something
like lightning network payment channels, where only the commitment
transaction needs to be in the blockchain history; does that count as
key-holder decentralization at all?
Also, consider the following scenario. Suppose there's a bunch of
merge-mined sidechains that are mainnet BTC-pegged, and these sidechains
are accessible by the lightning network protocol (multi-chain payments).
Suppose also that on the different sidechains there are different
transaction fee trends because of various technical differences underlying
consensus or a different blockchain implementation (who knows). When
someone routes payments to one of those different sidechains, because UTXOs
could be cheaper over there due to different fee pressures, ... would that
count as key-holder decentralization? Some of this scenario is described
here, although not in more detail:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/010909.html
Previously there has been the suggestion to use BTC-pegged merge-mined
chains to handle excess transaction demand:
http://diyhpl.us/wiki/transcripts/scalingbitcoin/sharding-the-blockchain/
https://github.com/vbuterin/scalability_paper/blob/master/scalability.pdf
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-March/004797.html
I notice that in the Poon file there is a concern regarding "only 10 key
holders", but how does that scenario really work? I think the actual
scenario they mean to describe is "there's always a transaction backlog
where the fees are so high that lower fee transactions can never get
confirmations". So, more specifically, the scenario would have to be
"lightning network exists and is working, and no lightning node can ever
route enough different payments to commit to the blockchain under any
circumstance". How would that be possible? Wouldn't most participants
prefer the relatively instantaneous transactions of lightning, even if they
can afford extremely high fees? Seems like the settlements have all
necessary reason to actually happen, don't know what your concern is,
please send help.
I don't mean to put words in anyone's mouth, everything above is mostly
asking for clarification around definitions. Some of these questions are
repeats from:
http://gnusha.org/bitcoin-wizards/2015-11-08.log
Thank you.
- Bryan
http://heybryan.org/
1 512 203 0507
--001a113ed6780c74b005240aad2f
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">On S=
un, Nov 8, 2015 at 8:54 AM, Gavin Andresen via bitcoin-dev <span dir=3D"ltr=
"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_b=
lank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding=
-left:1ex">I'm very disappointed you don't mention the tradeoff at =
"the other end of the bathtub" -- Key-holder versus Validator dec=
entralization balance</blockquote></div><br>Gavin, could you please provide=
some clarity around the definition and meaning of "key-holder [decent=
ralization]"? Is this about the absolute number of key-holders? or rat=
her about the number of transactions (per unit time?) that key-holders make=
? Both/other?</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail=
_extra">Anyone can generate a private key, and anyone can sign a transactio=
n spending to a new commitment. Child-pays-for-parent could be used when tr=
ansaction fees are too high. Perhaps more interesting would be something li=
ke lightning network payment channels, where only the commitment transactio=
n needs to be in the blockchain history; does that count as key-holder dece=
ntralization at all?</div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">Also, consider the following scenario. Suppose there's=
a bunch of merge-mined sidechains that are mainnet BTC-pegged, and these s=
idechains are accessible by the lightning network protocol (multi-chain pay=
ments). Suppose also that on the different sidechains there are different t=
ransaction fee trends because of various technical differences underlying c=
onsensus or a different blockchain implementation (who knows). When someone=
routes payments to one of those different sidechains, because UTXOs could =
be cheaper over there due to different fee pressures, ... would that count =
as key-holder decentralization? Some of this scenario is described here, al=
though not in more detail:=C2=A0<a href=3D"https://lists.linuxfoundation.or=
g/pipermail/bitcoin-dev/2015-September/010909.html">https://lists.linuxfoun=
dation.org/pipermail/bitcoin-dev/2015-September/010909.html</a></div><div c=
lass=3D"gmail_extra"><div><br></div><div>Previously there has been the sugg=
estion to use BTC-pegged merge-mined chains to handle excess transaction de=
mand:</div><div><a href=3D"http://diyhpl.us/wiki/transcripts/scalingbitcoin=
/sharding-the-blockchain/">http://diyhpl.us/wiki/transcripts/scalingbitcoin=
/sharding-the-blockchain/</a><br></div><div><a href=3D"https://github.com/v=
buterin/scalability_paper/blob/master/scalability.pdf">https://github.com/v=
buterin/scalability_paper/blob/master/scalability.pdf</a><br></div><div><a =
href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-March/0=
04797.html">http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-Mar=
ch/004797.html</a><br></div><div><br></div><div>I notice that in the Poon f=
ile there is a concern regarding "only 10 key holders", but how d=
oes that scenario really work? I think the actual scenario they mean to des=
cribe is "there's always a transaction backlog where the fees are =
so high that lower fee transactions can never get confirmations". So, =
more specifically, the scenario would have to be "lightning network ex=
ists and is working, and no lightning node can ever route enough different =
payments to commit to the blockchain under any circumstance". How woul=
d that be possible? Wouldn't most participants prefer the relatively in=
stantaneous transactions of lightning, even if they can afford extremely hi=
gh fees? Seems like the settlements have all necessary reason to actually h=
appen, don't know what your concern is, please send help.</div><div><br=
></div><div>I don't mean to put words in anyone's mouth, everything=
above is mostly asking for clarification around definitions. Some of these=
questions are repeats from:</div><div><a href=3D"http://gnusha.org/bitcoin=
-wizards/2015-11-08.log">http://gnusha.org/bitcoin-wizards/2015-11-08.log</=
a><br></div><div><br></div><div>Thank you.</div><div><br></div><div class=
=3D"gmail_signature">- Bryan<br><a href=3D"http://heybryan.org/" target=3D"=
_blank">http://heybryan.org/</a><br>1 512 203 0507</div>
</div></div>
--001a113ed6780c74b005240aad2f--
|
