public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Akiva Lichtner <akiva.lichtner@gmail.com>
To: Loi Luu <loi.luuthe@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Scaling by Partitioning
Date: Wed, 9 Dec 2015 18:26:06 +0000	[thread overview]
Message-ID: <CABCnA7VAO2XKLwd4axaYcttUHzhvXXEvYrwg7XDKH9nfo1k7RA@mail.gmail.com> (raw)
In-Reply-To: <CAJmQggC1X5Lgt4xGoMtBZ_v3hC2GXcYaj2FngV2_7A=TDfSuEg@mail.gmail.com>

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


  reply	other threads:[~2015-12-09 18:26 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-08 16:27 [bitcoin-dev] Scaling by Partitioning Akiva Lichtner
2015-12-08 16:45 ` Bryan Bishop
2015-12-08 18:30   ` Akiva Lichtner
2015-12-08 20:50 ` Patrick Strateman
2015-12-08 21:23   ` Akiva Lichtner
2015-12-08 21:29     ` Patrick Strateman
2015-12-08 21:41       ` Akiva Lichtner
2015-12-09  6:30 ` Loi Luu
2015-12-09 18:26   ` Akiva Lichtner [this message]
2015-12-09 21:16     ` Loi Luu
2015-12-10  4:04       ` Akiva Lichtner
2015-12-09 22:35   ` Andrew
2015-12-10  3:58     ` Akiva Lichtner
2015-12-10  4:31       ` Bryan Bishop
2015-12-10  4:08     ` Dave Scotese
2015-12-10  4:14       ` Dave Scotese

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CABCnA7VAO2XKLwd4axaYcttUHzhvXXEvYrwg7XDKH9nfo1k7RA@mail.gmail.com \
    --to=akiva.lichtner@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=loi.luuthe@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox