📅 Original date posted:2015-12-09
📝 Original message: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
>>
>>
>
Akiva Lichtner [ARCHIVE] /
npub1xc…q0qxc
2023-06-07 17:45:57
in reply to nevent1q…2d73
Author Public Key
npub1xcyuj09qhdx7l759765zznp0r5lcfw5s4wufvnx4za02tvtlp3wsuq0qxcPublished at
2023-06-07 17:45:57Event JSON
{
"id": "476215ddbd40eae2b21ccb96ffc31f21b02a3100659aae555f01b2cbdeced1c2",
"pubkey": "3609c93ca0bb4deffa85f6a8214c2f1d3f84ba90abb8964cd5175ea5b17f0c5d",
"created_at": 1686159957,
"kind": 1,
"tags": [
[
"e",
"1d3ba80ab0099181bba68d894affa14f996897f03fb26c19893401e942e99a33",
"",
"root"
],
[
"e",
"40728f23b800a03b50a23054e96b36f7c4f0d9c77ccb53777f5f45acebc75cc3",
"",
"reply"
],
[
"p",
"82709cf8f890b4a55118cbbbf4871185e2322052df04151341ba2f2ae7141387"
]
],
"content": "📅 Original date posted:2015-12-09\n📝 Original message:Thanks for giving serious consideration to my post.\n\nWith regard to your question \"if a transaction spends a \"coin\" that\nends in \"1\" and creates a new coin that ends in \"1\", which partition\nshould process the transaction?\", I would answer that only one\npartition is involved. In other words, there are N independent block\nchains that never cross paths.\n\nWith regard to your question \"what is the prior data needed to\nvalidate that kind of TXs?\" I do not understand what this means. If\nyou can dumb it down a bit that would be good because there could be\nsome interesting concern in this question.\n\nSince partitions are completely segregated, there is no need for a\nnode to work on multiple partitions simultaneously. For attacks to be\ndefeated a node needs to be able to work on multiple partitions in\nturn, not at the same time. The reason is because if the computing\npower of the good-faith nodes is unbalanced this gives attackers an\nunfair advantage.\n\nOn 12/9/15, Loi Luu via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e Dear Akiva,\n\u003e\n\u003e Its Loi Luu, one of the authors of the SCP protocol (\n\u003e http://eprint.iacr.org/2015/1168.pdf ).\n\u003e\n\u003e Before SCP, we had been thinking hard about how to do sharding efficiently\n\u003e without degrading any security guarantee. A simple solution which splits\n\u003e the coins, or TXs in to several partitions will just not work. You have to\n\u003e answer more questions to have a good solutions. For example, I wonder in\n\u003e your proposal, if a transaction spends a \"coin\" that ends in \"1\" and\n\u003e creates a new coin that ends in \"1\", which partition should process the\n\u003e transaction? What is the prior data needed to validate that kind of TXs?\n\u003e\n\u003e The problem with other proposals, and probably yours as well, that we see\n\u003e is that the amount of data that you need to broadcast immediately to the\n\u003e network increases linearly with the number of TXs that the network can\n\u003e process. Thus, sharding does not bring any advantage than simply using\n\u003e other techniques to publish more blocks in one epoch (like Bitcoin-NG,\n\u003e Ghost). The whole point of using sharding/ partition is to localize\n\u003e the bandwidth used, and only broadcast only a minimal data to the network.\n\u003e\n\u003e Clearly we are able to localize the bandwidth used with our SCP protocol.\n\u003e The cost is that now recipients need to themselves verify whether a\n\u003e transaction is double spending. However, we think that it is a reasonable\n\u003e tradeoff, given the potential scalability that SCP can provides.\n\u003e\n\u003e Thanks,\n\u003e Loi Luu.\n\u003e\n\u003e On Wed, Dec 9, 2015 at 12:27 AM, Akiva Lichtner via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e Hello,\n\u003e\u003e\n\u003e\u003e I am seeking some expert feedback on an idea for scaling Bitcoin. As a\n\u003e\u003e brief introduction: I work in the payment industry and I have twenty\n\u003e\u003e years'\n\u003e\u003e experience in development. I have some experience with process groups and\n\u003e\u003e ordering protocols too. I think I understand Satoshi's paper but I admit\n\u003e\u003e I\n\u003e\u003e have not read the source code.\n\u003e\u003e\n\u003e\u003e The idea is to run more than one simultaneous chain, each chain defeating\n\u003e\u003e double spending on only part of the coin. The coin would be partitioned\n\u003e\u003e by\n\u003e\u003e radix (or modulus, not sure what to call it.) For example in order to\n\u003e\u003e multiply throughput by a factor of ten you could run ten parallel chains,\n\u003e\u003e one would work on coin that ends in \"0\", one on coin that ends in \"1\",\n\u003e\u003e and\n\u003e\u003e so on up to \"9\".\n\u003e\u003e\n\u003e\u003e The number of chains could increase automatically over time based on the\n\u003e\u003e moving average of transaction volume.\n\u003e\u003e\n\u003e\u003e Blocks would have to contain the number of the partition they belong to,\n\u003e\u003e and miners would have to round-robin through partitions so that an\n\u003e\u003e attacker\n\u003e\u003e would not have an unfair advantage working on just one partition.\n\u003e\u003e\n\u003e\u003e I don't think there is much impact to miners, but clients would have to\n\u003e\u003e send more than one message in order to spend money. Client messages will\n\u003e\u003e need to enumerate coin using some sort of compression, to save space.\n\u003e\u003e This\n\u003e\u003e seems okay to me since often in computing client software does have to\n\u003e\u003e break things up in equal parts (e.g. memory pages, file system blocks,)\n\u003e\u003e and\n\u003e\u003e the client software could hide the details.\n\u003e\u003e\n\u003e\u003e Best wishes for continued success to the project.\n\u003e\u003e\n\u003e\u003e Regards,\n\u003e\u003e Akiva\n\u003e\u003e\n\u003e\u003e P.S. I found a funny anagram for SATOSHI NAKAMOTO: \"NSA IS OOOK AT MATH\"\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e\n\u003e",
"sig": "844389a45f27252cc2413ebc9dfa8bfb720d0eaf05a6087d037e7504614c59b96a7ed4a633e330392df55ffb5ca71f3e26aaf96266ed8dc9f5df409988574213"
}