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
|
Return-Path: <mickeybob@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B7A23B8B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jun 2015 17:25:16 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com
[209.85.212.170])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D4DF1246
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jun 2015 17:25:15 +0000 (UTC)
Received: by wicnd19 with SMTP id nd19so40290227wic.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jun 2015 10:25:14 -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=BXEClGBZKRpe3CoxZV1Cligh6WIuw5/gumOf3hKZBOU=;
b=GkPD59VYCak6MXgunEWF19Zbskeuewjjfx1bA01v1nxdAQc2lgNcZI0Vr0e//NQhcQ
qZNSj1t+KIE00HNvwzNA0dHtXrnEkS2Jp5YMnrpuWlWjkZtl5bh+iM6HPjUt0aZ/8j2w
SpWhsa3dH8KKCAsonnMlsV5xcTNVXV2bht8xmRlI9Htqn2TdT+vaFyNeQD39WXqvYcpV
SCl1bxj3eapS23vJpbvlln83HJpl9JXLHQm5kYOnWW+VXXTgrAR1qUyY4JISrnlERmyb
xMmGERc9rVwJfNO5RJsvnMF4JPU8fbW9jwj/UP7VKhiT7zCv+WMHBSizCMuXYOXIjesu
AT5A==
MIME-Version: 1.0
X-Received: by 10.194.179.167 with SMTP id dh7mr14149630wjc.15.1435425914584;
Sat, 27 Jun 2015 10:25:14 -0700 (PDT)
Received: by 10.27.10.1 with HTTP; Sat, 27 Jun 2015 10:25:14 -0700 (PDT)
In-Reply-To: <20150627163731.GA12820@muck>
References: <CALgxB7udA85BWetBGc-RN=72ZtVPK9Q5HW8YRDKA08M38XqJqQ@mail.gmail.com>
<CALqxMTHjszPcf=S20kquF=5y3zfYb+foP6tL1okOT2jhdrW08A@mail.gmail.com>
<CALgxB7tdFsQXzGRje=suC7Yaym_Whhtn2qrb3ykx2ZOBwwbE7w@mail.gmail.com>
<20150627163731.GA12820@muck>
Date: Sat, 27 Jun 2015 13:25:14 -0400
Message-ID: <CALgxB7tsmHGiGuCmcdNuwjKxNfBpdq6U+x8eK=7sL6NekAfXow@mail.gmail.com>
From: Michael Naber <mickeybob@gmail.com>
To: Peter Todd <pete@petertodd.org>, Mark Friedenbach <mark@friedenbach.org>,
Adam Back <adam@cypherspace.org>
Content-Type: multipart/alternative; boundary=089e0141a0a4bd86360519832335
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 17:25:16 -0000
--089e0141a0a4bd86360519832335
Content-Type: text/plain; charset=UTF-8
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.
Bitcoin Core scales as O(N), where N is the number of transactions. Can we
do better than this while still achieving global consensus?
On Sat, Jun 27, 2015 at 12:37 PM, Peter Todd <pete@petertodd.org> wrote:
> On Sat, Jun 27, 2015 at 12:09:16PM -0400, Michael Naber wrote:
> > The goal of Bitcoin Core is to meet the demand for global consensus as
> > effectively as possible. Please let's keep the conversation on how to
> best
> > meet that goal.
>
> Keep in mind that Andresen and Hearn both propose that the majority of
> Bitcoin users, even businesses, abandon the global consensus technology
> aspect of Bitcoin - running full nodes - and instead adopt trust
> technology instead - running SPV nodes.
>
> We're very much focused on meeting the demand for global consensus
> technology, but unfortunately global consensus is also has inherently
> O(n^2) scaling with current approaches available. Thus we have a fixed
> capacity system where access is mediated by supply and demand
> transaction fees.
>
> > The off-chain solutions you enumerate are are useful solutions in their
> > respective domains, but none of them solves the global consensus problem
> > with any greater efficiency than Bitcoin does.
>
> Solutions like (hub-and-spoke) payment channels, Lightning, etc. allow
> users of the global consensus technology in Bitcoin to use that
> technology in much more effcient ways, leveraging a relatively small
> amount of global consensus to do large numbers of transactions
> trustlessly.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24
>
--089e0141a0a4bd86360519832335
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Global network consensus means that there is global n=
etwork recognition that a particular transaction has occurred and is irreve=
rsible. The off-chain solutions you describe, while probably useful for oth=
er purposes, do not exhibit this characteristic and so they are not global =
network consensus networks.=C2=A0</div><div><br></div><div>Bitcoin Core sca=
les as O(N), where N is the number of transactions. Can we do better than t=
his while still achieving global consensus?=C2=A0</div><div><br></div></div=
><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Jun 27, =
2015 at 12:37 PM, Peter Todd <span dir=3D"ltr"><<a href=3D"mailto:pete@p=
etertodd.org" target=3D"_blank">pete@petertodd.org</a>></span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><span class=3D"">On Sat, Jun 27, 2015 at 12=
:09:16PM -0400, Michael Naber wrote:<br>
> The goal of Bitcoin Core is to meet the demand for global consensus as=
<br>
> effectively as possible. Please let's keep the conversation on how=
to best<br>
> meet that goal.<br>
<br>
</span>Keep in mind that Andresen and Hearn both propose that the majority =
of<br>
Bitcoin users, even businesses, abandon the global consensus technology<br>
aspect of Bitcoin - running full nodes - and instead adopt trust<br>
technology instead - running SPV nodes.<br>
<br>
We're very much focused on meeting the demand for global consensus<br>
technology, but unfortunately global consensus is also has inherently<br>
O(n^2) scaling with current approaches available. Thus we have a fixed<br>
capacity system where access is mediated by supply and demand<br>
transaction fees.<br>
<span class=3D""><br>
> The off-chain solutions you enumerate are are useful solutions in thei=
r<br>
> respective domains, but none of them solves the global consensus probl=
em<br>
> with any greater efficiency than Bitcoin does.<br>
<br>
</span>Solutions like (hub-and-spoke) payment channels, Lightning, etc. all=
ow<br>
users of the global consensus technology in Bitcoin to use that<br>
technology in much more effcient ways, leveraging a relatively small<br>
amount of global consensus to do large numbers of transactions<br>
trustlessly.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
'peter'[:-1]@<a href=3D"http://petertodd.org" rel=3D"noreferrer" ta=
rget=3D"_blank">petertodd.org</a><br>
0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24<br>
</font></span></blockquote></div><br></div>
--089e0141a0a4bd86360519832335--
|
