📅 Original date posted:2015-12-08
📝 Original message:It's true that miners would have to be prepared to work on any partition. I
don't see where the number affects defeating double spending, what matters
is the nonce in the block that keeps the next successful miner random.
I expect that the number of miners would be ten times larger as well, so an
attacker would have no advantage working on one partition.
On Tue, Dec 8, 2015 at 3:50 PM, Patrick Strateman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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 listbitcoin-dev at lists.linuxfoundation.orghttps://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/20151208/9de15dd2/attachment.html>;
Akiva Lichtner [ARCHIVE] /
npub1xc…q0qxc
2023-06-07 17:45:55
in reply to nevent1q…xls3
Author Public Key
npub1xcyuj09qhdx7l759765zznp0r5lcfw5s4wufvnx4za02tvtlp3wsuq0qxcPublished at
2023-06-07 17:45:55Event JSON
{
"id": "3dfc30f69ee4d9511b0f6d289f32ec4d9f353c5592d2927c53356e3cc5673b04",
"pubkey": "3609c93ca0bb4deffa85f6a8214c2f1d3f84ba90abb8964cd5175ea5b17f0c5d",
"created_at": 1686159955,
"kind": 1,
"tags": [
[
"e",
"1d3ba80ab0099181bba68d894affa14f996897f03fb26c19893401e942e99a33",
"",
"root"
],
[
"e",
"e9ec583358ac9f6924fb9714e401e80d0f2eadee163dcf1a22f1dd0d9f3f9925",
"",
"reply"
],
[
"p",
"fc7892eea47289e31dc49660ebe7f00108707eb2ee3b59909accdf0afaa4eb61"
]
],
"content": "📅 Original date posted:2015-12-08\n📝 Original message:It's true that miners would have to be prepared to work on any partition. I\ndon't see where the number affects defeating double spending, what matters\nis the nonce in the block that keeps the next successful miner random.\n\nI expect that the number of miners would be ten times larger as well, so an\nattacker would have no advantage working on one partition.\n\nOn Tue, Dec 8, 2015 at 3:50 PM, Patrick Strateman via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Payment recipients would need to operate a daemon for each chain, thus\n\u003e guaranteeing no scaling advantage.\n\u003e\n\u003e (There are other issues, but I believe that to be enough of a show stopper\n\u003e not to continue).\n\u003e\n\u003e On 12/08/2015 08:27 AM, Akiva Lichtner via bitcoin-dev wrote:\n\u003e\n\u003e Hello,\n\u003e\n\u003e I am seeking some expert feedback on an idea for scaling Bitcoin. As a\n\u003e brief introduction: I work in the payment industry and I have twenty years'\n\u003e experience in development. I have some experience with process groups and\n\u003e ordering protocols too. I think I understand Satoshi's paper but I admit I\n\u003e have not read the source code.\n\u003e\n\u003e The idea is to run more than one simultaneous chain, each chain defeating\n\u003e double spending on only part of the coin. The coin would be partitioned by\n\u003e radix (or modulus, not sure what to call it.) For example in order to\n\u003e multiply throughput by a factor of ten you could run ten parallel chains,\n\u003e one would work on coin that ends in \"0\", one on coin that ends in \"1\", and\n\u003e so on up to \"9\".\n\u003e\n\u003e The number of chains could increase automatically over time based on the\n\u003e moving average of transaction volume.\n\u003e\n\u003e Blocks would have to contain the number of the partition they belong to,\n\u003e and miners would have to round-robin through partitions so that an attacker\n\u003e would not have an unfair advantage working on just one partition.\n\u003e\n\u003e I don't think there is much impact to miners, but clients would have to\n\u003e send more than one message in order to spend money. Client messages will\n\u003e need to enumerate coin using some sort of compression, to save space. This\n\u003e seems okay to me since often in computing client software does have to\n\u003e break things up in equal parts (e.g. memory pages, file system blocks,) and\n\u003e the client software could hide the details.\n\u003e\n\u003e Best wishes for continued success to the project.\n\u003e\n\u003e Regards,\n\u003e Akiva\n\u003e\n\u003e P.S. I found a funny anagram for SATOSHI NAKAMOTO: \"NSA IS OOOK AT MATH\"\n\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing listbitcoin-dev at lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\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/20151208/9de15dd2/attachment.html\u003e",
"sig": "105897d2dfa1921d30c4a8905a2ce65e33ae68ae5a696687d327c7371826018319b55530f31bc44ba0287cb91a23d0e574cc46659a8f3788d13677e8de42b9d3"
}