Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 32152CF6 for ; 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 ; Wed, 9 Dec 2015 22:35:08 +0000 (UTC) Received: by wmww144 with SMTP id w144so1086489wmw.0 for ; 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: References: Date: Wed, 9 Dec 2015 23:35:07 +0100 X-Google-Sender-Auth: o2l1j2r7SwDRT5g_CKHSFtJtATM Message-ID: From: Andrew To: Loi Luu 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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

Hi Akiva

I sketched out a similar proposal here: https://bitcointalk.org/index.p= hp?topic=3D1083345.0

It's good to see people talking about this :). I'm n= ot 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 bitcoi= n-dev" <bi= tcoin-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=C2=A0).

<= div style=3D"font-size:12.8000001907349px">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 "coin" that end= s 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,=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.

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=C2=A0themselves=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.

Thanks,
= Loi Luu.

On Wed, Dec 9, 2015 at 12:27 AM, Akiva Licht= ner 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 introducti= on: I work in the payment industry and I have twenty years' experience = in development. I have some experience with process groups and ordering pro= tocols 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 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 "0&qu= ot;, one on coin that ends in "1", and so on up to "9".=

The number of chains could increase automatically over time b= ased on the moving average of transaction volume.

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.

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 t= o break things up in equal parts (e.g. memory pages, file system blocks,) a= nd 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/mail= man/listinfo/bitcoin-dev



_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--001a114192f0c9e64105267eb3b3--