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
|
Return-Path: <akiva.lichtner@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3F1C7E1E
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 Dec 2015 03:58:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com
[209.85.192.51])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A151E151
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 Dec 2015 03:58:11 +0000 (UTC)
Received: by qgcc31 with SMTP id c31so119172371qgc.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 09 Dec 2015 19:58:11 -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=6BbotEkdrUIU/e0/CW2Nr/epKJuljTNAmRJ9pjP3PBQ=;
b=W9NMKNc6RetTBylRG7X7to246OwdI1YGm+cfK7xf+ypUoHDHKQUa/pVtPbRa9I1FsW
xQ+bWi29N+kIBCveGgr9rDP5i0bzC9Xbau//8UcJg9KzdXOJ/diRWP0EKWq3MP375dkw
IEevrGsDIq9XHIDobM0ng25yCEoEDaLyP2f5459B4K2l9HzilPBW1HnVoRxplJklfdoQ
yR+CRNFfIM5ADd0nd6Dt2aLMpYttQmapZREcG7xgJdsvucVICSeQec+c1S4SQs4VTTqn
k/eQ43yHu3doSC/ENVFn86KMGxxIze6eKAU8G1wtJTM7AkARcFbBa6M33RtQcnQDj0YU
/5zQ==
MIME-Version: 1.0
X-Received: by 10.141.6.9 with SMTP id i9mr3736137qhd.68.1449719890900; Wed,
09 Dec 2015 19:58:10 -0800 (PST)
Received: by 10.140.101.112 with HTTP; Wed, 9 Dec 2015 19:58:10 -0800 (PST)
In-Reply-To: <CAL8tG=mxYE97iMO05mPq4_f8VcmFBYqAmyPqTs439bPRGhaVqA@mail.gmail.com>
References: <CABCnA7Wqz76m8qo5BYT41Z=hBH+fUfOc4xsFAGg=Niv7Jgkqsg@mail.gmail.com>
<CAJmQggC1X5Lgt4xGoMtBZ_v3hC2GXcYaj2FngV2_7A=TDfSuEg@mail.gmail.com>
<CAL8tG=mxYE97iMO05mPq4_f8VcmFBYqAmyPqTs439bPRGhaVqA@mail.gmail.com>
Date: Wed, 9 Dec 2015 22:58:10 -0500
Message-ID: <CABCnA7W25KoHuSuB3Az250_PiRcFd5MjjKJfrm_qv4oaYUT5mg@mail.gmail.com>
From: Akiva Lichtner <akiva.lichtner@gmail.com>
To: Andrew <onelineproof@gmail.com>
Content-Type: multipart/alternative; boundary=001a113a66901efdd305268337eb
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: Thu, 10 Dec 2015 04:01:49 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Scaling by Partitioning
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: Thu, 10 Dec 2015 03:58:12 -0000
--001a113a66901efdd305268337eb
Content-Type: text/plain; charset=UTF-8
Hi Andrew,
What you suggested is much more sophisticated than what I suggested. I am
strictly talking about independent chains - that's all.
I am struck by the fact that the topic of "scaling bitcoin" seems to be a
mix of different problems, and when people are really trying to solve
different problems, or arguing about applying the same solution in
different settings, it's easy to argue back and forth endlessly. Your post
talks about validating transactions without seeing all transactions. This
is a different problem than what I am addressing. My view of Bitcoin is
colored by my experience with process groups and total ordering. I view
Bitcoin as a timestamp service on all transactions, a total order. A total
order is difficult to scale. Period.
I am just addressing how to change the system so that blocks can be
generated faster if a) the transaction volume increases and b) you are
willing to have more miners. But you are also talking about transaction
verification and making sure that you don't need to verify everything. I
think these are two problems that should have two different names.
Correct me if I am wrong, but the dream of a virtual currency where
everybody is equal and runs the client on their mobile device went out the
window long ago. I think that went out with the special mining hardware. If
my organization had to accept bitcoin payments I would assume that we'll
need a small server farm for transaction verification, and that we would
see all the transactions. Figure 10,000 transactions per second, like VISA.
As far as small organizations or private individuals are concerned, I think
it would be entirely okay for a guy on a smartphone to delegate
verification to a trusted party, as long as the trust chain stops there and
there is plenty of choice.
I am guessing the trustless virtual currency police would get pretty upset
about such a pragmatic approach, but it's not really a choice, the failure
to scale has already occurred. All things considered I think that Bitcoin
will only scale when pragmatic considerations take center stage and the
academic goals take a lower priority. I would think companies would make a
good living out of running trusted verification services.
Once again, it doesn't mean that there is a bank, the network still allows
malicious nodes, but there can be pockets of trust. This is only natural,
most people trust at least one other person, so it's not that weird.
Akiva
--001a113a66901efdd305268337eb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div>Hi Andrew,<br><br></div>What you suggested =
is much more sophisticated than what I suggested. I am strictly talking abo=
ut independent chains - that's all.<br><br></div>I am struck by the fac=
t that the topic of "scaling bitcoin" seems to be a mix of differ=
ent problems, and when people are really trying to solve different problems=
, or arguing about applying the same solution in different settings, it'=
;s easy to argue back and forth endlessly. Your post talks about validating=
transactions without seeing all transactions. This is a different problem =
than what I am addressing. My view of Bitcoin is colored by my experience w=
ith process groups and total ordering. I view Bitcoin as a timestamp servic=
e on all transactions, a total order. A total order is difficult to scale. =
Period.<br><br>I am just addressing how to change the system so that blocks=
can be generated faster if a) the transaction volume increases and b) you =
are willing to have more miners. But you are also talking about transaction=
verification and making sure that you don't need to verify everything.=
I think these are two problems that should have two different names.<br><b=
r></div><div>Correct me if I am wrong, but the dream of a virtual currency =
where everybody is equal and runs the client on their mobile device went ou=
t the window long ago. I think that went out with the special mining hardwa=
re. If my organization had to accept bitcoin payments I would assume that w=
e'll need a small server farm for transaction verification, and that we=
would see all the transactions. Figure 10,000 transactions per second, lik=
e VISA. As far as small organizations or private individuals are concerned,=
I think it would be entirely okay for a guy on a smartphone to delegate ve=
rification to a trusted party, as long as the trust chain stops there and t=
here is plenty of choice.<br><br></div><div>I am guessing the trustless vir=
tual currency police would get pretty upset about such a pragmatic approach=
, but it's not really a choice, the failure to scale has already occurr=
ed. All things considered I think that Bitcoin will only scale when pragmat=
ic considerations take center stage and the academic goals take a lower pri=
ority. I would think companies would make a good living out of running trus=
ted verification services.<br><br></div><div>Once again, it doesn't mea=
n that there is a bank, the network still allows malicious nodes, but there=
can be pockets of trust. This is only natural, most people trust at least =
one other person, so it's not that weird.<br></div><div><br></div><div>=
Akiva<br></div><div><br></div></div>
--001a113a66901efdd305268337eb--
|
