path: root/77/b5e3f1a441a69b483accd4bea2a1a00b4691d0

Return-Path: <akaramaoun@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 32152CF6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  9 Dec 2015 22:35:10 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D88F919C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  9 Dec 2015 22:35:08 +0000 (UTC)
Received: by wmww144 with SMTP id w144so1086489wmw.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 09 Dec 2015 14:35:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=+AI1kLWXaRiytJVguHo29UB7vTK4klAlUSuysnLbBzQ=;
	b=n1xUoQCXX6Zd/Hp/CaKqSnNNA4jXcdxq6Uma9uMLz5qHdpaKVdOaPpCYIUFu0NLVp9
	AuwezdRNzOV0qgASsr+TK6+FpxlFmxGSE0Gbu3lw4besbdVjuLKgEovTLfHqiiQQXeWn
	elY5f9MJAlXP2hOnKpcF7ZZNj2EFS0c1rAp6nDBByNO3vVKYkJTMoTS+uOa+WLAU7oTg
	4TNbv2+GVoBZNBepwYjrFOd4zvyUTvuvTVVmRLLDNfq+7FBrZzLh5KFpEitWh8vFBM07
	wyH13E1Pa8zAO2QPJPazQAvpMCAuG99CVP8/CkHI4+nXjsnrIEHAsQNnpG5XPmuiPOXS
	xBdA==
MIME-Version: 1.0
X-Received: by 10.28.128.5 with SMTP id b5mr34730589wmd.25.1449700507639; Wed,
	09 Dec 2015 14:35:07 -0800 (PST)
Sender: akaramaoun@gmail.com
Received: by 10.28.223.212 with HTTP; Wed, 9 Dec 2015 14:35:07 -0800 (PST)
Received: by 10.28.223.212 with HTTP; Wed, 9 Dec 2015 14:35:07 -0800 (PST)
In-Reply-To: <CAJmQggC1X5Lgt4xGoMtBZ_v3hC2GXcYaj2FngV2_7A=TDfSuEg@mail.gmail.com>
References: <CABCnA7Wqz76m8qo5BYT41Z=hBH+fUfOc4xsFAGg=Niv7Jgkqsg@mail.gmail.com>
	<CAJmQggC1X5Lgt4xGoMtBZ_v3hC2GXcYaj2FngV2_7A=TDfSuEg@mail.gmail.com>
Date: Wed, 9 Dec 2015 23:35:07 +0100
X-Google-Sender-Auth: o2l1j2r7SwDRT5g_CKHSFtJtATM
Message-ID: <CAL8tG=mxYE97iMO05mPq4_f8VcmFBYqAmyPqTs439bPRGhaVqA@mail.gmail.com>
From: Andrew <onelineproof@gmail.com>
To: Loi Luu <loi.luuthe@gmail.com>
Content-Type: multipart/alternative; boundary=001a114192f0c9e64105267eb3b3
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: Wed, 09 Dec 2015 22:57:30 +0000
Cc: 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: Wed, 09 Dec 2015 22:35:10 -0000

--001a114192f0c9e64105267eb3b3
Content-Type: text/plain; charset=UTF-8

Hi Akiva

I sketched out a similar proposal here:
https://bitcointalk.org/index.php?topic=1083345.0

It's good to see people talking about this :). I'm not quite convinced with
segregated witness, as it might mess up some things, but will take a closer
look.
On Dec 9, 2015 7:32 AM, "Loi Luu via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Dear Akiva,
>
> Its Loi Luu, one of the authors of the SCP protocol (
> http://eprint.iacr.org/2015/1168.pdf ).
>
> Before SCP, we had been thinking hard about how to do sharding efficiently
> without degrading any security guarantee. A simple solution which splits
> the coins, or TXs in to several partitions will just not work. You have to
> answer more questions to have a good solutions. For example, I wonder in
> your proposal, if a transaction spends a "coin" that ends in "1" and
> creates a new coin that ends in "1", which partition should process the
> transaction? What is the prior data needed to validate that kind of TXs?
>
> The problem with other proposals, and probably yours as well,  that we see
> is that the amount of data that you need to broadcast immediately to the
> network increases linearly with the number of TXs that the network can
> process. Thus, sharding does not bring any advantage than simply using
> other techniques to publish more blocks in one epoch (like Bitcoin-NG,
> Ghost). The whole point of using sharding/ partition is to localize
> the bandwidth used, and only broadcast only a minimal data to the network.
>
> Clearly we are able to localize the bandwidth used with our SCP protocol.
> The cost is that now recipients need to  themselves verify whether a
> transaction is double spending. However, we think that it is a reasonable
> tradeoff, given the potential scalability that SCP can provides.
>
> Thanks,
> Loi Luu.
>
> On Wed, Dec 9, 2015 at 12:27 AM, Akiva Lichtner via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hello,
>>
>> I am seeking some expert feedback on an idea for scaling Bitcoin. As a
>> brief introduction: I work in the payment industry and I have twenty years'
>> experience in development. I have some experience with process groups and
>> ordering protocols too. I think I understand Satoshi's paper but I admit I
>> have not read the source code.
>>
>> The idea is to run more than one simultaneous chain, each chain defeating
>> double spending on only part of the coin. The coin would be partitioned by
>> radix (or modulus, not sure what to call it.) For example in order to
>> multiply throughput by a factor of ten you could run ten parallel chains,
>> one would work on coin that ends in "0", one on coin that ends in "1", and
>> so on up to "9".
>>
>> The number of chains could increase automatically over time based on the
>> moving average of transaction volume.
>>
>> Blocks would have to contain the number of the partition they belong to,
>> and miners would have to round-robin through partitions so that an attacker
>> would not have an unfair advantage working on just one partition.
>>
>> I don't think there is much impact to miners, but clients would have to
>> send more than one message in order to spend money. Client messages will
>> need to enumerate coin using some sort of compression, to save space. This
>> seems okay to me since often in computing client software does have to
>> break things up in equal parts (e.g. memory pages, file system blocks,) and
>> the client software could hide the details.
>>
>> Best wishes for continued success to the project.
>>
>> Regards,
>> Akiva
>>
>> P.S. I found a funny anagram for SATOSHI NAKAMOTO: "NSA IS OOOK AT MATH"
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--001a114192f0c9e64105267eb3b3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Hi Akiva</p>
<p dir=3D"ltr">I sketched out a similar proposal here: <a href=3D"https://b=
itcointalk.org/index.php?topic=3D1083345.0">https://bitcointalk.org/index.p=
hp?topic=3D1083345.0</a></p>
<p dir=3D"ltr">It&#39;s good to see people talking about this :). I&#39;m n=
ot quite convinced with segregated witness, as it might mess up some things=
, but will take a closer look.</p>
<div class=3D"gmail_quote">On Dec 9, 2015 7:32 AM, &quot;Loi Luu via bitcoi=
n-dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bi=
tcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br type=3D"attribution">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span style=3D"font-size:12=
.8000001907349px">Dear Akiva,</span><div style=3D"font-size:12.800000190734=
9px"><br></div><div style=3D"font-size:12.8000001907349px">Its Loi Luu, one=
 of the authors of the SCP protocol (<a href=3D"http://eprint.iacr.org/2015=
/1168.pdf" rel=3D"noreferrer" style=3D"font-size:12.8000001907349px" target=
=3D"_blank">http://eprint.iacr.org/2015/1168.pdf</a><span style=3D"font-siz=
e:12.8000001907349px">=C2=A0).</span></div><div style=3D"font-size:12.80000=
01907349px"><span style=3D"font-size:12.8000001907349px"><br></span></div><=
div style=3D"font-size:12.8000001907349px"><span style=3D"font-size:12.8000=
001907349px">Before SCP, we had been thinking hard about how to do sharding=
 efficiently without degrading any security guarantee. A simple solution wh=
ich splits the coins, or TXs in to several partitions will just not work. Y=
ou have to answer more questions to have a good solutions. For example, I w=
onder in your proposal, if a transaction spends a &quot;coin&quot; that end=
s in &quot;1&quot; and creates a new coin that ends in &quot;1&quot;, which=
 partition should process the transaction? What is the prior data needed to=
 validate that kind of TXs?</span></div><div style=3D"font-size:12.80000019=
07349px"><span style=3D"font-size:12.8000001907349px"><br></span></div><div=
 style=3D"font-size:12.8000001907349px"><span style=3D"font-size:12.8000001=
907349px">The problem with other proposals, and probably yours as well,=C2=
=A0=C2=A0that we see is that the amount of data that you need to broadcast =
immediately to the network increases linearly with the number of TXs that t=
he network can process. Thus, sharding does not bring any advantage than si=
mply using other techniques to publish more blocks in one epoch (like Bitco=
in-NG, Ghost). The whole point of using sharding/ partition is to localize =
the=C2=A0bandwidth=C2=A0used, and only broadcast only a=C2=A0minimal=C2=A0d=
ata to the network.</span></div><div style=3D"font-size:12.8000001907349px"=
><span style=3D"font-size:12.8000001907349px"><br></span></div><div style=
=3D"font-size:12.8000001907349px"><span style=3D"font-size:12.8000001907349=
px">Clearly we are able to localize the bandwidth used with our SCP protoco=
l. The cost is that now=C2=A0recipients=C2=A0need to=C2=A0</span><span styl=
e=3D"font-size:12.8000001907349px">=C2=A0</span><span style=3D"font-size:12=
.8000001907349px">themselves=C2=A0verify whether a transaction is double sp=
ending. However, we think that=C2=A0it is=C2=A0a reasonable tradeoff, given=
 the potential scalability that SCP can provides.</span></div><div class=3D=
"gmail_extra"><br clear=3D"all"><div><div><div dir=3D"ltr"><span style=3D"f=
ont-family:arial,sans-serif;font-size:13px;border-collapse:collapse;color:r=
gb(136,136,136)"><span style=3D"color:rgb(0,0,102)"><div>Thanks,</div><div>=
Loi Luu.<br></div></span></span></div></div></div>
<br><div class=3D"gmail_quote">On Wed, Dec 9, 2015 at 12:27 AM, Akiva Licht=
ner via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation=
.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div><div><div><div><div><div><div><div>Hello,<br><br></div>I am seeking=
 some expert feedback on an idea for scaling Bitcoin. As a brief introducti=
on: I work in the payment industry and I have twenty years&#39; experience =
in development. I have some experience with process groups and ordering pro=
tocols too. I think I understand Satoshi&#39;s paper but I admit I have not=
 read the source code.<br><br></div>The idea is to run more than one simult=
aneous chain, each chain defeating double spending on only part of the coin=
. The coin would be partitioned by radix (or modulus, not sure what to call=
 it.) For example in order to multiply throughput by a factor of ten you co=
uld run ten parallel chains, one would work on coin that ends in &quot;0&qu=
ot;, one on coin that ends in &quot;1&quot;, and so on up to &quot;9&quot;.=
<br><br></div>The number of chains could increase automatically over time b=
ased on the moving average of transaction volume.<br><br></div>Blocks would=
 have to contain the number of the partition they belong to, and miners wou=
ld have to round-robin through partitions so that an attacker would not hav=
e an unfair advantage working on just one partition.<br></div><div><br></di=
v><div>I don&#39;t think there is much impact to miners, but clients would =
have to send more than one message in order to spend money. Client messages=
 will need to enumerate coin using some sort of compression, to save space.=
 This seems okay to me since often in computing client software does have t=
o break things up in equal parts (e.g. memory pages, file system blocks,) a=
nd the client software could hide the details.<br></div></div><div><br></di=
v><div>Best wishes for continued success to the project.<br></div><div><br>=
</div>Regards,<br></div>Akiva<br><br></div>P.S. I found a funny anagram for=
 SATOSHI NAKAMOTO: &quot;NSA IS OOOK AT MATH&quot;<br><br></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
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>
<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>

--001a114192f0c9e64105267eb3b3--