Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 45CC9EB4 for ; Thu, 10 Dec 2015 04:04:19 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0EE82151 for ; Thu, 10 Dec 2015 04:04:18 +0000 (UTC) Received: by qgec40 with SMTP id c40so118245614qge.2 for ; Wed, 09 Dec 2015 20:04:17 -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=669lmVKyRia1hRc6jqj/qqKDXwR76c14MBfV5/uN0js=; b=wjUlHWy07RXEvb+Kn9t8R/1vg6ij4/I7fngeyK7t8epeGujj70X4zPoq7pA82CdSPn LMlGJKrlOMjkoYLE01U+qzeroyhokGqacrnaxasKo70bFio7cBAH4u5J6tMzV9NzeOxO 5xTwbUZcbjjgwZWJJACT4Sw2ZQYrJC9+4SR6WELvYTuyjO2+5LCPokI/MuLjNu+D32re 11xUTfFfIx2GWfYRGBKxAO8eJ3/xozkdU4Vi4EwqLHrvCM94dzqOp65VN/VStgkxJmVj 8VNloHDryNNuWwYZssHPvriZshPxWNcgLGj/824Ti5ofqOiDicq6Dp842gatjeVoEiql G9gA== MIME-Version: 1.0 X-Received: by 10.140.43.135 with SMTP id e7mr12312056qga.11.1449720257261; Wed, 09 Dec 2015 20:04:17 -0800 (PST) Received: by 10.140.101.112 with HTTP; Wed, 9 Dec 2015 20:04:17 -0800 (PST) In-Reply-To: References: Date: Wed, 9 Dec 2015 23:04:17 -0500 Message-ID: From: Akiva Lichtner To: Loi Luu Content-Type: multipart/alternative; boundary=001a113a986ef538bc0526834c44 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:33:55 +0000 Cc: Bitcoin Dev 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: Thu, 10 Dec 2015 04:04:19 -0000 --001a113a986ef538bc0526834c44 Content-Type: text/plain; charset=UTF-8 It's an interval (a,b) where a, b are between 0 and 21*10^6*10^8 . Somebody pointed out that this is not easily accomplished using the current code because there are no coin ids. On Wed, Dec 9, 2015 at 4:16 PM, Loi Luu wrote: > I guess the most basic question is how do you define a coin here? > > Thanks, > Loi Luu > On 10 Dec 2015 2:26 a.m., "Akiva Lichtner" > wrote: > >> Thanks for giving serious consideration to my post. >> >> With regard to your question "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?", I would answer that only one >> partition is involved. In other words, there are N independent block >> chains that never cross paths. >> >> With regard to your question "what is the prior data needed to >> validate that kind of TXs?" I do not understand what this means. If >> you can dumb it down a bit that would be good because there could be >> some interesting concern in this question. >> >> Since partitions are completely segregated, there is no need for a >> node to work on multiple partitions simultaneously. For attacks to be >> defeated a node needs to be able to work on multiple partitions in >> turn, not at the same time. The reason is because if the computing >> power of the good-faith nodes is unbalanced this gives attackers an >> unfair advantage. >> >> On 12/9/15, Loi Luu via bitcoin-dev >> 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 >> >> >> >> >> > >> > --001a113a986ef538bc0526834c44 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's an interval (a,b) where a, b are between 0 a= nd 21*10^6*10^8 .

Somebody pointed out that this is not e= asily accomplished using the current code because there are no coin ids.

= On Wed, Dec 9, 2015 at 4:16 PM, Loi Luu <loi.luuthe@gmail.com> wrote:

I guess the m= ost basic question is how do you define a coin here?

Thanks,
Loi Luu

On 10 Dec 2015 2:26 a.m., "Akiva Lichtner&q= uot; <akiv= a.lichtner@gmail.com> wrote:
Thanks for giving serious consideration to my post.

With regard to your question "if a transaction spends a "coin&quo= t; that
ends in "1" and creates a new coin that ends in "1", wh= ich partition
should process the transaction?", I would answer that only one
partition is involved. In other words, there are N independent block
chains that never cross paths.

With regard to your question "what is the prior data needed to
validate that kind of TXs?" I do not understand what this means. If you can dumb it down a bit that would be good because there could be
some interesting concern in this question.

Since partitions are completely segregated, there is no need for a
node to work on multiple partitions simultaneously. For attacks to be
defeated a node needs to be able to work on multiple partitions in
turn, not at the same time. The reason is because if the computing
power of the good-faith nodes is unbalanced this gives attackers an
unfair advantage.

On 12/9/15, 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 efficie= ntly
> without degrading any security guarantee. A simple solution which spli= ts
> the coins, or TXs in to several partitions will just not work. You hav= e 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 TX= s?
>
> The problem with other proposals, and probably yours as well,=C2=A0 th= at we see
> is that the amount of data that you need to broadcast immediately to t= he
> 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 netw= ork.
>
> Clearly we are able to localize the bandwidth used with our SCP protoc= ol.
> The cost is that now recipients need to=C2=A0 themselves verify whethe= r a
> transaction is double spending. However, we think that it is a reasona= ble
> 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 twen= ty
>> years'
>> experience in development. I have some experience with process gro= ups and
>> ordering protocols too. I think I understand Satoshi's paper b= ut I admit
>> I
>> have not read the source code.
>>
>> The idea is to run more than one simultaneous chain, each chain de= feating
>> double spending on only part of the coin. The coin would be partit= ioned
>> 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 tha= t 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 belo= ng 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.<= br> >>
>> I don't think there is much impact to miners, but clients woul= d have to
>> send more than one message in order to spend money. Client message= s will
>> need to enumerate coin using some sort of compression, to save spa= ce.
>> This
>> seems okay to me since often in computing client software does hav= e to
>> break things up in equal parts (e.g. memory pages, file system blo= cks,)
>> 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 OO= OK AT MATH"
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation= .org/mailman/listinfo/bitcoin-dev
>>
>>
>

--001a113a986ef538bc0526834c44--