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
|
Return-Path: <jameson.lopp@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 199B2BC7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jun 2015 18:02:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com
[209.85.212.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0CEF6279
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jun 2015 18:02:07 +0000 (UTC)
Received: by wiga1 with SMTP id a1so40650094wig.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jun 2015 11:02:05 -0700 (PDT)
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=Pbhq31jIyepJw+dNyvFXTdIdBZnk16yZivKdN32Gt80=;
b=C1dhEbnQ7xO/HV2MW/DrJliKsKwPikdLkUHwyaoZ4eN2a9Fy3QwfHYO5BovgQuoe+p
vFy4Yno7Ve2shL25eXIwbEomQsJ9aHdLzULhUx67Kk1iZIUZfm74+rxcpuJOIhbJqh0n
QXQ0CmIHvgE7GCTm0A3ULRWaP9ojN8hjUSyhSt4c3KcsAUHGn1Dx2nN4aMxauta0eMTP
n7y/IlBcTimOSvDOaZN2sNB6iS4jpXYY6Xe833qJapNZDGFlviO0AYQiMbdzNNMQ09FK
6n7d3FtW3ImgW+f+k9ktPnLHbZy9gvPFP3sauGc4ag8fDYuycQZsA6/Z+lAv8Vpz6amQ
NohA==
MIME-Version: 1.0
X-Received: by 10.180.84.170 with SMTP id a10mr7744765wiz.52.1435428125887;
Sat, 27 Jun 2015 11:02:05 -0700 (PDT)
Received: by 10.27.171.143 with HTTP; Sat, 27 Jun 2015 11:02:05 -0700 (PDT)
In-Reply-To: <20150627173451.GA28181@muck>
References: <CALgxB7udA85BWetBGc-RN=72ZtVPK9Q5HW8YRDKA08M38XqJqQ@mail.gmail.com>
<CALqxMTHjszPcf=S20kquF=5y3zfYb+foP6tL1okOT2jhdrW08A@mail.gmail.com>
<CALgxB7tdFsQXzGRje=suC7Yaym_Whhtn2qrb3ykx2ZOBwwbE7w@mail.gmail.com>
<20150627163731.GA12820@muck>
<CALgxB7tsmHGiGuCmcdNuwjKxNfBpdq6U+x8eK=7sL6NekAfXow@mail.gmail.com>
<20150627173451.GA28181@muck>
Date: Sat, 27 Jun 2015 14:02:05 -0400
Message-ID: <CADL_X_ekJ_agt+94z-9_cQGdTOQym5t+6X+G4+AxvNBRpYBnTg@mail.gmail.com>
From: Jameson Lopp <jameson.lopp@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=f46d041827e68b53b6051983a74d
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@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] A Proposed Compromise to the Block Size Limit
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: Sat, 27 Jun 2015 18:02:08 -0000
--f46d041827e68b53b6051983a74d
Content-Type: text/plain; charset=UTF-8
On Sat, Jun 27, 2015 at 1:34 PM, Peter Todd <pete@petertodd.org> wrote:
> On Sat, Jun 27, 2015 at 01:25:14PM -0400, Michael Naber wrote:
> > Global network consensus means that there is global network recognition
> > that a particular transaction has occurred and is irreversible. The
> > off-chain solutions you describe, while probably useful for other
> purposes,
> > do not exhibit this characteristic and so they are not global network
> > consensus networks.
>
> Hub-and-spoke payment channels and the Lightning network are not
> off-chain solutions, they are ways to more efficiently use on-chain
> transactions to achive the goal of moving assets from point a to point
> b, resulting in more economic transactions being done with fewer - but
> not zero! - blockchain transactions.
>
> Off-chain transaction systems such as Changetip allow economic
> transactions to happen with no blockchain transactions at all.
>
> > Bitcoin Core scales as O(N), where N is the number of transactions. Can
> we
> > do better than this while still achieving global consensus?
>
> No, Bitcoin the network scales with O(n^2) with your above criteria, as
> each node creates k transactions, thus each node has to verify k*n
> transactions, resulting in O(n^2) total work.
>
> For Bitcoin to have O(n) scaling you have to assume that the number of
> validation nodes doesn't scale with the number of users, thus resulting
> in a system where users trust others to do validation for them. That is
> not a global consensus system; that's a trust-based system.
>
>
Why does it matter what the "total work" of the network is? Anyone who is
participating as a node on the network only cares about the resources
required to run their own node, not the resources everyone else needs to
run their nodes.
Also, no assumption needed, it is quite clear that the number of nodes is
not scaling along with the number of users. If anything it appears to be
inversely proportional.
> There's nothing inherently wrong with that, but why change Bitcoin
> itself into a trust-based system, when you can preserve the global
> consensus functionality, and built a trust-based system on top of it?
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--f46d041827e68b53b6051983a74d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sat, Jun 27, 2015 at 1:34 PM, Peter Todd <span dir=3D"ltr"><<a hr=
ef=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Sat,=
Jun 27, 2015 at 01:25:14PM -0400, Michael Naber wrote:<br>
> Global network consensus means that there is global network recognitio=
n<br>
> that a particular transaction has occurred and is irreversible. The<br=
>
> off-chain solutions you describe, while probably useful for other purp=
oses,<br>
> do not exhibit this characteristic and so they are not global network<=
br>
> consensus networks.<br>
<br>
</span>Hub-and-spoke payment channels and the Lightning network are not<br>
off-chain solutions, they are ways to more efficiently use on-chain<br>
transactions to achive the goal of moving assets from point a to point<br>
b, resulting in more economic transactions being done with fewer - but<br>
not zero! - blockchain transactions.<br>
<br>
Off-chain transaction systems such as Changetip allow economic<br>
transactions to happen with no blockchain transactions at all.<br>
<span class=3D""><br>
> Bitcoin Core scales as O(N), where N is the number of transactions. Ca=
n we<br>
> do better than this while still achieving global consensus?<br>
<br>
</span>No, Bitcoin the network scales with O(n^2) with your above criteria,=
as<br>
each node creates k transactions, thus each node has to verify k*n<br>
transactions, resulting in O(n^2) total work.<br>
<br>
For Bitcoin to have O(n) scaling you have to assume that the number of<br>
validation nodes doesn't scale with the number of users, thus resulting=
<br>
in a system where users trust others to do validation for them. That is<br>
not a global consensus system; that's a trust-based system.<br>
<br></blockquote><div><br></div><div>Why does it matter what the "tota=
l work" of the network is? Anyone who is participating as a node on th=
e network only cares about the resources required to run their own node, no=
t the resources everyone else needs to run their nodes.<br><br></div><div>A=
lso, no assumption needed, it is quite clear that the number of nodes is no=
t scaling along with the number of users. If anything it appears to be inve=
rsely proportional.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
There's nothing inherently wrong with that, but why change Bitcoin<br>
itself into a trust-based system, when you can preserve the global<br>
consensus functionality, and built a trust-based system on top of it?<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
'peter'[:-1]@<a href=3D"http://petertodd.org" rel=3D"noreferrer" ta=
rget=3D"_blank">petertodd.org</a><br>
0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24<br>
</div></div><br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div></div>
--f46d041827e68b53b6051983a74d--
|
