Akiva Lichtner [ARCHIVE] on Nostr: 📅 Original date posted:2015-12-10 📝 Original message:It's an interval (a,b) ...
📅 Original date posted:2015-12-10
📝 Original message: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 <loi.luuthe at gmail.com> 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" <akiva.lichtner at gmail.com>
> 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
>> <bitcoin-dev at 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 at 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 at lists.linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >>
>> >>
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/8f725842/attachment.html>;
📝 Original message: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 <loi.luuthe at gmail.com> 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" <akiva.lichtner at gmail.com>
> 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
>> <bitcoin-dev at 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 at 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 at lists.linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >>
>> >>
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/8f725842/attachment.html>;