To: bitcoin-dev@lists.linuxfoundation.org
References: <CABCnA7Wqz76m8qo5BYT41Z=hBH+fUfOc4xsFAGg=Niv7Jgkqsg@mail.gmail.com>
From: Patrick Strateman <patrick.strateman@gmail.com>
Message-ID: <56674280.3010003@gmail.com>
Date: Tue, 8 Dec 2015 12:50:08 -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: <CABCnA7Wqz76m8qo5BYT41Z=hBH+fUfOc4xsFAGg=Niv7Jgkqsg@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------070207020308020207040303"
Subject: Re: [bitcoin-dev] Scaling by Partitioning
Precedence: list

This is a multi-part message in MIME format.
--------------070207020308020207040303
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

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
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--------------070207020308020207040303
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body 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 class="moz-cite-prefix">On 12/08/2015 08:27 AM, Akiva Lichtner
      via bitcoin-dev wrote:<br>
    </div>
    <blockquote
cite="mid:CABCnA7Wqz76m8qo5BYT41Z=hBH+fUfOc4xsFAGg=Niv7Jgkqsg@mail.gmail.com"
      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 class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------070207020308020207040303--