+Return-Path: <patrick.strateman@gmail.com>

+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org

+ [172.17.192.35])

+ by mail.linuxfoundation.org (Postfix) with ESMTPS id EA75BD46

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Tue, 8 Dec 2015 21:28:42 +0000 (UTC)

+X-Greylist: whitelisted by SQLgrey-1.7.6

+Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com

+ [209.85.220.43])

+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2FE4C16E

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Tue, 8 Dec 2015 21:28:42 +0000 (UTC)

+Received: by pacdm15 with SMTP id dm15so17941937pac.3

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Tue, 08 Dec 2015 13:28:42 -0800 (PST)

+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;

+ h=subject:references:to:from:message-id:disposition-notification-to

+ :date:user-agent:mime-version:in-reply-to:content-type;

+ bh=47u9jj+xUBYZEsQQCBt4Hc8Vj5Aw1ZcaS2V0OEEU5qg=;

+ b=ofwqkTvR0eFZb3xDsA8rDuSAS8zh2rqC2rwS2S5C+ap8JH4gmio9nt6bbpdQzrChP+

+ fnP83PMbV7GXyOoH/Cs4kR0a7ecMxIu6qgzDjO5AjbBcwsDzA2Jktpl0UObzc2LTE07N

+ 1meI/OKt6Exs9Ia6UQ32IayutFfbRTZMKccZfziN/CnBarhEq5pxL1YFIAdG+96/LLix

+ LrWI7usvVFDr8UL4tmviFdjSBpibicN0hwWHHm0povkMaGA3BfWRCjysHFlnVckbs3Ju

+ S2BRLWRB7iju3Sv0s9ZgxWFbkJTg6lE/ZKw4OoYndi6dssk+0yTUsKnEDg+mhE90TUxq

+ 6fzQ==

+X-Received: by 10.66.227.129 with SMTP id sa1mr3068108pac.132.1449610121932;

+ Tue, 08 Dec 2015 13:28:41 -0800 (PST)

+Received: from [10.45.134.131] (strateman.ninja. [66.175.221.254])

+ by smtp.googlemail.com with ESMTPSA id

+ c79sm6698653pfj.71.2015.12.08.13.28.40

+ for <bitcoin-dev@lists.linuxfoundation.org>

+ (version=TLSv1/SSLv3 cipher=OTHER);

+ Tue, 08 Dec 2015 13:28:41 -0800 (PST)

+References: <CABCnA7Wqz76m8qo5BYT41Z=hBH+fUfOc4xsFAGg=Niv7Jgkqsg@mail.gmail.com>

+ <56674280.3010003@gmail.com>

+ <CABCnA7Vb1JA6E+heXZZ=DKcsK9gusa6tSNEL5AkGRLOT2ZND6w@mail.gmail.com>

+To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>

+From: Patrick Strateman <patrick.strateman@gmail.com>

+Message-ID: <56674BA9.8090702@gmail.com>

+Date: Tue, 8 Dec 2015 13:29:13 -0800

+User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101

+ Icedove/38.4.0

+MIME-Version: 1.0

+In-Reply-To: <CABCnA7Vb1JA6E+heXZZ=DKcsK9gusa6tSNEL5AkGRLOT2ZND6w@mail.gmail.com>

+Content-Type: multipart/alternative;

+ boundary="------------030207000608050705060609"

+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 21:31:08 +0000

+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 21:28:43 -0000

+

+This is a multi-part message in MIME format.

+--------------030207000608050705060609

+Content-Type: text/plain; charset=utf-8

+Content-Transfer-Encoding: 7bit

+

+If partition is selected from a random key (the hash of the output for

+example) then payment recipients would need to operate a full node on

+each of the chains.

+

+What's the point of partitioning if virtually everybody needs to operate

+each partition?

+

+The mining aspect has it's own set of issues, but I'm not going to get

+into those.

+

+On 12/08/2015 01:23 PM, Akiva Lichtner wrote:

+> It's true that miners would have to be prepared to work on any

+> partition. I don't see where the number affects defeating double

+> spending, what matters is the nonce in the block that keeps the next

+> successful miner random.

+>

+> I expect that the number of miners would be ten times larger as well,

+> so an attacker would have no advantage working on one partition.

+>

+> On Tue, Dec 8, 2015 at 3:50 PM, Patrick Strateman via bitcoin-dev

+> <bitcoin-dev@lists.linuxfoundation.org

+> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:

+>

+> Payment recipients would need to operate a daemon for each chain,

+> thus guaranteeing no scaling advantage.

+>

+> (There are other issues, but I believe that to be enough of a show

+> stopper not to continue).

+>

+> On 12/08/2015 08:27 AM, Akiva Lichtner via bitcoin-dev 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

+>> <mailto:bitcoin-dev@lists.linuxfoundation.org>

+>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

+>

+>

+> _______________________________________________

+> bitcoin-dev mailing list

+> bitcoin-dev@lists.linuxfoundation.org

+> <mailto:bitcoin-dev@lists.linuxfoundation.org>

+> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

+>

+>

+

+

+--------------030207000608050705060609

+Content-Type: text/html; charset=utf-8

+Content-Transfer-Encoding: 7bit

+

+<html>

+ <head>

+ <meta content="text/html; charset=utf-8" http-equiv="Content-Type">

+ </head>

+ <body bgcolor="#FFFFFF" text="#000000">

+ If partition is selected from a random key (the hash of the output

+ for example) then payment recipients would need to operate a full

+ node on each of the chains.<br>

+ <br>

+ What's the point of partitioning if virtually everybody needs to

+ operate each partition?<br>

+ <br>

+ The mining aspect has it's own set of issues, but I'm not going to

+ get into those.<br>

+ <br>

+ <div class="moz-cite-prefix">On 12/08/2015 01:23 PM, Akiva Lichtner

+ wrote:<br>

+ </div>

+ <blockquote

+cite="mid:CABCnA7Vb1JA6E+heXZZ=DKcsK9gusa6tSNEL5AkGRLOT2ZND6w@mail.gmail.com"

+ type="cite">

+ <div dir="ltr">

+ <div>It's true that miners would have to be prepared to work on

+ any partition. I don't see where the number affects defeating

+ double spending, what matters is the nonce in the block that

+ keeps the next successful miner random.<br>

+ <br>

+ </div>

+ I expect that the number of miners would be ten times larger as

+ well, so an attacker would have no advantage working on one

+ partition.<br>

+ </div>

+ <div class="gmail_extra"><br>

+ <div class="gmail_quote">On Tue, Dec 8, 2015 at 3:50 PM, Patrick

+ Strateman via bitcoin-dev <span dir="ltr">&lt;<a

+ moz-do-not-send="true"

+ href="mailto:bitcoin-dev@lists.linuxfoundation.org"

+ target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a></a>&gt;</span>

+ wrote:<br>

+ <blockquote class="gmail_quote" style="margin:0 0 0

+ .8ex;border-left:1px #ccc solid;padding-left:1ex">

+ <div bgcolor="#FFFFFF" text="#000000"> Payment recipients

+ would need to operate a daemon for each chain, thus

+ guaranteeing no scaling advantage.<br>

+ <br>

+ (There are other issues, but I believe that to be enough

+ of a show stopper not to continue).<br>

+ <br>

+ <div>On 12/08/2015 08:27 AM, Akiva Lichtner via

+ bitcoin-dev wrote:<br>

+ </div>

+ <blockquote type="cite">

+ <div dir="ltr">

+ <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

+ 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.<br>

+ <br>

+ </div>

+ 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".<br>

+ <br>

+ </div>

+ The number of chains could increase

+ automatically over time based 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 would

+ have to round-robin through partitions so that

+ an attacker would not have an unfair advantage

+ working on just one partition.<br>

+ </div>

+ <div><br>

+ </div>

+ <div>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.<br>

+ </div>

+ </div>

+ <div><br>

+ </div>

+ <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:

+ "NSA IS OOOK AT MATH"<br>

+ <br>

+ </div>

+ <br>

+ <fieldset></fieldset>

+ <br>

+ <pre>_______________________________________________

+bitcoin-dev mailing list

+<a moz-do-not-send="true" href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>

+<a moz-do-not-send="true" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>

+</pre>

+ </blockquote>

+ <br>

+ </div>

+ <br>

+ _______________________________________________<br>

+ bitcoin-dev mailing list<br>

+ <a moz-do-not-send="true"

+ href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br>

+ <a moz-do-not-send="true"

+ href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"

+ rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>

+ <br>

+ </blockquote>

+ </div>

+ <br>

+ </div>

+ </blockquote>

+ <br>

+ </body>

+</html>

+

+--------------030207000608050705060609--

+