📅 Original date posted:2015-12-09
📝 Original message:Hi Akiva
I sketched out a similar proposal here:
https://bitcointalk.org/index.php?topic=1083345.0
It's good to see people talking about this :). I'm not quite convinced with
segregated witness, as it might mess up some things, but will take a closer
look.
On Dec 9, 2015 7:32 AM, "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
>>
>>
>
> _______________________________________________
> 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/19e592c7/attachment.html>;
Andrew [ARCHIVE] /
npub1l8…hm88x
2023-06-07 17:45:58
in reply to nevent1q…rmx0
Author Public Key
npub1l899vmy2zhg9zr96jvnxt85ayddd26qu36m02k22759e9djqldnqrhm88xPublished at
2023-06-07 17:45:58Event JSON
{
"id": "c18453e3fa7fdcf623c72f45a231fe0a70527f04d191532aee623c0d6392adbe",
"pubkey": "f9ca566c8a15d0510cba9326659e9d235ad5681c8eb6f5594af50b92b640fb66",
"created_at": 1686159958,
"kind": 1,
"tags": [
[
"e",
"1d3ba80ab0099181bba68d894affa14f996897f03fb26c19893401e942e99a33",
"",
"root"
],
[
"e",
"9a278bfa09067e2ac1465086d5c17a074fb28b583db79c676f0aa2b5f3d8cc86",
"",
"reply"
],
[
"p",
"3609c93ca0bb4deffa85f6a8214c2f1d3f84ba90abb8964cd5175ea5b17f0c5d"
]
],
"content": "📅 Original date posted:2015-12-09\n📝 Original message:Hi Akiva\n\nI sketched out a similar proposal here:\nhttps://bitcointalk.org/index.php?topic=1083345.0\n\nIt's good to see people talking about this :). I'm not quite convinced with\nsegregated witness, as it might mess up some things, but will take a closer\nlook.\nOn Dec 9, 2015 7:32 AM, \"Loi Luu via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\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 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 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 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\", 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 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. 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,) 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\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/19e592c7/attachment.html\u003e",
"sig": "a3efaa5e6cd1e992f056dbeb00caf676d0d05744845549f661f1d354f8b031e25eb0789ddf42818eba21cf82633b27c984b766b6cfc94e75bc0fb8ec951cf5c4"
}