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
|
Return-Path: <gavinandresen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 98D5E405
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 9 Nov 2015 16:27:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com
[209.85.217.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D510317A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 9 Nov 2015 16:27:24 +0000 (UTC)
Received: by lbbkw15 with SMTP id kw15so96560553lbb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 09 Nov 2015 08:27:23 -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=1PrdxDLrmftCMId5c1Aea38Z/uDv6wEsbgaQ0DJakfc=;
b=1IXKY1lLkV5hkf3EqAtXPzE/Oc+B14otZu4yXtsEzPpiTu+P+zkczmgAU69A1/LNHF
9s/qOYCSUiP23/+K5fblzrbss+H9/0AF/wT9oOTJUNg+d43+QfhAp6rnPlvj43uBMnM+
4PullScJgQkEKJQrpbniCA6vPDgCvWFA6K9+amUCPH4DlGQJYbgt5QdphupbvwNnVxVT
WDdDXiIu0SRhdDftO6SWwzzsj5rvyC0yg4/zjX2MV8/Q4gtluTSRgndI2acAtscyjeWb
SgqTVg8hY78zDoFoty9/ni4y5X1FIj679v3ykMClUOPxNeFFF6cBID9ZAoAjZwMHfFn3
FiDw==
MIME-Version: 1.0
X-Received: by 10.112.141.201 with SMTP id rq9mr8108338lbb.4.1447086442902;
Mon, 09 Nov 2015 08:27:22 -0800 (PST)
Received: by 10.25.22.95 with HTTP; Mon, 9 Nov 2015 08:27:22 -0800 (PST)
In-Reply-To: <CABaSBaxKQe2SnMuwHq-7482BmY+vvD4SefKjXxEPhxZTOoyHrA@mail.gmail.com>
References: <CALqxMTE1JDsT8fSoDZVTUWfnw4Cmb9LkDa+B-XUyXGPxAYernA@mail.gmail.com>
<CABsx9T0T6QuYRmNyF_F124GyQ2EX5w93HCPLvrd4L5P6=xj_Xw@mail.gmail.com>
<CABaSBaxKQe2SnMuwHq-7482BmY+vvD4SefKjXxEPhxZTOoyHrA@mail.gmail.com>
Date: Mon, 9 Nov 2015 11:27:22 -0500
Message-ID: <CABsx9T081xkFgwGQ-vrnm_yDAVpZunQFxAEbBBJXXaSxOOoXcA@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Bryan Bishop <kanzure@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c38b5a637ab405241e11bc
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
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: Mon, 09 Nov 2015 16:27:25 -0000
--001a11c38b5a637ab405241e11bc
Content-Type: text/plain; charset=UTF-8
On Sun, Nov 8, 2015 at 12:19 PM, Bryan Bishop <kanzure@gmail.com> wrote:
> 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?
>
Both. If few transactions are possible, then that limits the number of
key-holders who can participate in the system.
Imagine the max block size was really small, and stretch your imagination
and just assume there would be enough demand that those small number of
transactions pay enough transaction fees to secure the network. Each
transaction must, therefore, pay a high fee. That limits the number of
keyholders to institutions with very-large-value transactions-- it is the
"Bitcoin as a clearing network for big financial players" model.
Using the Lightning Network doesn't help, since every Lightning Network
transaction IS a set of Bitcoin transactions, ready to be dropped onto the
main chain. If those Lightning Network transactions don't have enough fees,
then the whole security of the Lightning Protocol falls apart (since it
relies on being able to get timelocked transactions confirmed on the main
chain in case your trading partner cheats).
There is video of the Poon/Dryja talk:
https://youtu.be/TgjrS-BPWDQ?t=41m58s
--
--
Gavin Andresen
--001a11c38b5a637ab405241e11bc
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 12:19 PM, Bryan Bishop <span dir=3D"ltr"><<a href=3D"=
mailto:kanzure@gmail.com" target=3D"_blank">kanzure@gmail.com</a>></span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex"><div class=3D"gmail_extra">Gavin, could you pl=
ease provide some clarity around the definition and meaning of "key-ho=
lder [decentralization]"? Is this about the absolute number of key-hol=
ders? or rather about the number of transactions (per unit time?) that key-=
holders make? Both/other?</div><div class=3D"gmail_extra"></div></blockquot=
e></div><br></div><div class=3D"gmail_extra">Both.=C2=A0 If few transaction=
s are possible, then that limits the number of key-holders who can particip=
ate in the system.</div><div class=3D"gmail_extra"><br></div><div class=3D"=
gmail_extra">Imagine the max block size was really small, and stretch your =
imagination and just assume there would be enough demand that those small n=
umber of transactions pay enough transaction fees to secure the network. Ea=
ch transaction must, therefore, pay a high fee. That limits the number of k=
eyholders to institutions with very-large-value transactions-- it is the &q=
uot;Bitcoin as a clearing network for big financial players" model.</d=
iv><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Using th=
e Lightning Network doesn't help, since every Lightning Network transac=
tion IS a set of Bitcoin transactions, ready to be dropped onto the main ch=
ain. If those Lightning Network transactions don't have enough fees, th=
en the whole security of the Lightning Protocol falls apart (since it relie=
s on being able to get timelocked transactions confirmed on the main chain =
in case your trading partner cheats).</div><div class=3D"gmail_extra"><br><=
/div><div class=3D"gmail_extra">There is video of the Poon/Dryja talk: =C2=
=A0<a href=3D"https://youtu.be/TgjrS-BPWDQ?t=3D41m58s">https://youtu.be/Tgj=
rS-BPWDQ?t=3D41m58s</a><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature">--<br>Gavin Andresen<br></div><div class=3D"gmail_sign=
ature"><br></div>
</div></div>
--001a11c38b5a637ab405241e11bc--
|
