From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 55AA2DE2 for ; Wed, 9 Dec 2015 18:26:10 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 92114195 for ; Wed, 9 Dec 2015 18:26:09 +0000 (UTC) Received: by qgec40 with SMTP id c40so92426330qge.2 for ; Wed, 09 Dec 2015 10:26:08 -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=sDPSIJjXZUFP2sfjTLoTGvP1RmweO6h79NAj82uq0Ck=; b=DiblCvRRvWRb4diarWJ+W4lNkFzn7sqgeQZjBUHTyLGX9ix6k6+i0+mdbooXHf2EBQ V09+KLMLFMEswnIyjwZZ7hbyvwJutZe/JqDkjZ0jLXBOiOsCJhr9XBuj57Q6YhFmX/Sf jrbPFgWamHAXISPGV9G6ToMzpkJ+yzZOv00YFJbVqEaRcsYu9qFoOf2g+weCGwSPviXL 1cNX/Etwbr8ZVaSRSWLW3hvZgXEqJpm+ZskTFIJ2r18Rv50OqaeRC5OU0/AfZwaChaMk GoPEDVGfRvWqeUy1NgoR+Lnvarko0tZRpCzP0Kd5OUq6k3FtJ1h6qqOIoLExVVEp3V0r TLSQ== MIME-Version: 1.0 X-Received: by 10.140.101.233 with SMTP id u96mr9353509qge.70.1449685566826; Wed, 09 Dec 2015 10:26:06 -0800 (PST) Received: by 10.140.101.112 with HTTP; Wed, 9 Dec 2015 10:26:06 -0800 (PST) In-Reply-To: References: Date: Wed, 9 Dec 2015 18:26:06 +0000 Message-ID: From: Akiva Lichtner To: Loi Luu Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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 18:42:14 +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 18:26:10 -0000 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 >> >> >