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
|
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 2867EB88
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Dec 2015 18:30:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com
[209.85.192.47])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 43D5E191
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Dec 2015 18:30:03 +0000 (UTC)
Received: by qgeb1 with SMTP id b1so29632418qge.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 08 Dec 2015 10:30:02 -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=nnUQkzTk0XAJCrgPKPkCJRlissXihdmF2UpYgOZw9ZY=;
b=KvZQGABNnzLJRIkCXmtBTMBAIbAMxGOTDZZsgJByyl6aaWDsEXNPzO9gx9/3QH5jcv
3tEg3LAYFAjZJLTkAq0ZrVMbVpYic5L1g1tHVTTclrc5G93DGMS2I2untqhzAuHY0lVP
WVH5S1cRrMdsvRleB5crexVR5VE4iLG9phVxQxQLE51rUppW+BBX2jyDm6hI29255DTH
udih6F3Pr7oYgCasOsybKE1XOHebVPwMZT/QsS1/og1kgOfcaFDVuXTTvClOG8BI3B8A
rBZF0pnIZd7ELL6+N7AwX1LA3xEnMWTSG5kd5Qvfkmrgn2/XHLZvdhecOX/LBFBQEVJx
Fn2w==
MIME-Version: 1.0
X-Received: by 10.55.75.216 with SMTP id y207mr1421552qka.19.1449599401996;
Tue, 08 Dec 2015 10:30:01 -0800 (PST)
Received: by 10.140.101.112 with HTTP; Tue, 8 Dec 2015 10:30:01 -0800 (PST)
In-Reply-To: <CABaSBazMd4VYhSgM0-=DWU7_AAGxvXiW2yjsft4bKw8gAtpuNg@mail.gmail.com>
References: <CABCnA7Wqz76m8qo5BYT41Z=hBH+fUfOc4xsFAGg=Niv7Jgkqsg@mail.gmail.com>
<CABaSBazMd4VYhSgM0-=DWU7_AAGxvXiW2yjsft4bKw8gAtpuNg@mail.gmail.com>
Date: Tue, 8 Dec 2015 13:30:01 -0500
Message-ID: <CABCnA7UdOg_3nq2SSuzdAwQMSdmPtr1=f0aRj3=MS7OiqdYVDw@mail.gmail.com>
From: Akiva Lichtner <akiva.lichtner@gmail.com>
To: Bryan Bishop <kanzure@gmail.com>
Content-Type: multipart/alternative; boundary=001a114a7e706c388d0526672924
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: Tue, 08 Dec 2015 18:31:56 +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: Tue, 08 Dec 2015 18:30:04 -0000
--001a114a7e706c388d0526672924
Content-Type: text/plain; charset=UTF-8
Thanks for your response and links.
I think the difference is that those proposals all shard the mining work,
whereas what I wrote in my post shards the coin itself. In other words
different parts of the coin space are forever segregated, never ending up
in the same block. It's a big difference conceptually because I could spend
money and a fraction of it makes it into a block in ten minutes and the
rest two hours later.
And I think that's where the potential for the scalability comes in. I am
not really scaling Bitcoin's present requirements, I am relaxing the
requirements in a way that leaves the users and the miners happy, but that
could provoke resistance by the part of of all of us that doesn't want
digital cash as much as it wants to make history.
All the best,
Akiva
P.S. Thanks for pointing out that I hit "reply" instead of "reply all"
earlier ...
On Tue, Dec 8, 2015 at 11:45 AM, Bryan Bishop <kanzure@gmail.com> wrote:
> On Tue, Dec 8, 2015 at 10:27 AM, Akiva Lichtner via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > and miners would have to round-robin through partitions
>
> At first glance this proposal seems most similar to the sharding proposals:
>
> http://diyhpl.us/wiki/transcripts/scalingbitcoin/sharding-the-blockchain/
> https://github.com/vbuterin/scalability_paper/blob/master/scalability.pdf
>
> https://www.reddit.com/r/Bitcoin/comments/3u1m36/why_arent_we_as_a_community_talking_about/cxbamhn
> http://eprint.iacr.org/2015/1168.pdf (committee approach)
>
> > but clients would have to send more than one message in order to spend
> money
>
> Offloading work to the client for spends has in the past been a
> well-received concept, such as the linearized coin history idea.
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507
>
--001a114a7e706c388d0526672924
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div>Thanks for your response and links.<br><br>=
</div>I think the=20
difference is that those proposals all shard the mining work, whereas=20
what I wrote in my post shards the coin itself. In other words different
parts of the coin space are forever segregated, never ending up in the=20
same block. It's a big difference conceptually because I could spend=20
money and a fraction of it makes it into a block in ten minutes and the=20
rest two hours later.<br><br></div><div>And I think that's where the=20
potential for the scalability comes in. I am not really scaling=20
Bitcoin's present requirements, I am relaxing the requirements in a way=
=20
that leaves the users and the miners happy, but that could provoke=20
resistance by the part of of all of us that doesn't want digital cash a=
s
much as it wants to make history.<br></div><div><br></div><div>All the bes=
t,<br></div>Akiva<br><br></div>P.S. Thanks for pointing out that I hit &quo=
t;reply" instead of "reply all" earlier ...<br></div><div cl=
ass=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Dec 8, 2015 at 1=
1:45 AM, Bryan Bishop <span dir=3D"ltr"><<a href=3D"mailto:kanzure@gmail=
.com" target=3D"_blank">kanzure@gmail.com</a>></span> wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">On Tue, Dec 8, 2015 at 10:27 AM, Akiva Lichtner via =
bitcoin-dev<br>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.linuxfoundation.org</a>> wrote:<br>
> and miners would have to round-robin through partitions<br>
<br>
At first glance this proposal seems most similar to the sharding proposals:=
<br>
<br>
<a href=3D"http://diyhpl.us/wiki/transcripts/scalingbitcoin/sharding-the-bl=
ockchain/" rel=3D"noreferrer" target=3D"_blank">http://diyhpl.us/wiki/trans=
cripts/scalingbitcoin/sharding-the-blockchain/</a><br>
<a href=3D"https://github.com/vbuterin/scalability_paper/blob/master/scalab=
ility.pdf" rel=3D"noreferrer" target=3D"_blank">https://github.com/vbuterin=
/scalability_paper/blob/master/scalability.pdf</a><br>
<a href=3D"https://www.reddit.com/r/Bitcoin/comments/3u1m36/why_arent_we_as=
_a_community_talking_about/cxbamhn" rel=3D"noreferrer" target=3D"_blank">ht=
tps://www.reddit.com/r/Bitcoin/comments/3u1m36/why_arent_we_as_a_community_=
talking_about/cxbamhn</a><br>
<a href=3D"http://eprint.iacr.org/2015/1168.pdf" rel=3D"noreferrer" target=
=3D"_blank">http://eprint.iacr.org/2015/1168.pdf</a> (committee approach)<b=
r>
<br>
> but clients would have to send more than one message in order to spend=
money<br>
<br>
Offloading work to the client for spends has in the past been a<br>
well-received concept, such as the linearized coin history idea.<br>
<br>
- Bryan<br>
<a href=3D"http://heybryan.org/" rel=3D"noreferrer" target=3D"_blank">http:=
//heybryan.org/</a><br>
<a href=3D"tel:1%20512%20203%200507" value=3D"+15122030507">1 512 203 0507<=
/a><br>
</blockquote></div><br></div>
--001a114a7e706c388d0526672924--
|
