📅 Original date posted:2015-12-08
📝 Original message:If the system is modified to scale up that means the number of transactions
is going up. That means the number of miners can also go up, and so will
the portion of malicious nodes. At least this seems reasonable. The problem
with partitions is that an attacker can focus on one partition. However
because the number of miners also increases any attacks will fail as long
as the miners are willing to work on any partition, which is easily
accomplished by round-robin.
Since there are N times more miners each miner still does the same amount
of work. The system scales by partitioning the money supply and increasing
the number of miners.
On Tue, Dec 8, 2015 at 4:29 PM, Patrick Strateman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> If partition is selected from a random key (the hash of the output for
> example) then payment recipients would need to operate a full node on each
> of the chains.
>
> What's the point of partitioning if virtually everybody needs to operate
> each partition?
>
> The mining aspect has it's own set of issues, but I'm not going to get
> into those.
>
> On 12/08/2015 01:23 PM, Akiva Lichtner wrote:
>
> 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>
> 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
>>
>>
>
>
> _______________________________________________
> 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/bbd37f43/attachment-0001.html>;
Akiva Lichtner [ARCHIVE] /
npub1xc…q0qxc
2023-06-07 17:45:56
in reply to nevent1q…vmhg
Author Public Key
npub1xcyuj09qhdx7l759765zznp0r5lcfw5s4wufvnx4za02tvtlp3wsuq0qxcPublished at
2023-06-07 17:45:56Event JSON
{
"id": "1a1768826c20b5e82b3e5405c36ab07b99da40668ac26cdefd5d07723007064e",
"pubkey": "3609c93ca0bb4deffa85f6a8214c2f1d3f84ba90abb8964cd5175ea5b17f0c5d",
"created_at": 1686159956,
"kind": 1,
"tags": [
[
"e",
"1d3ba80ab0099181bba68d894affa14f996897f03fb26c19893401e942e99a33",
"",
"root"
],
[
"e",
"92726cbc0169b1178169c8477af3c2079655868af1bc6f5008fc7d0d204a905c",
"",
"reply"
],
[
"p",
"fc7892eea47289e31dc49660ebe7f00108707eb2ee3b59909accdf0afaa4eb61"
]
],
"content": "📅 Original date posted:2015-12-08\n📝 Original message:If the system is modified to scale up that means the number of transactions\nis going up. That means the number of miners can also go up, and so will\nthe portion of malicious nodes. At least this seems reasonable. The problem\nwith partitions is that an attacker can focus on one partition. However\nbecause the number of miners also increases any attacks will fail as long\nas the miners are willing to work on any partition, which is easily\naccomplished by round-robin.\n\nSince there are N times more miners each miner still does the same amount\nof work. The system scales by partitioning the money supply and increasing\nthe number of miners.\n\n\n\nOn Tue, Dec 8, 2015 at 4:29 PM, Patrick Strateman via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e If partition is selected from a random key (the hash of the output for\n\u003e example) then payment recipients would need to operate a full node on each\n\u003e of the chains.\n\u003e\n\u003e What's the point of partitioning if virtually everybody needs to operate\n\u003e each partition?\n\u003e\n\u003e The mining aspect has it's own set of issues, but I'm not going to get\n\u003e into those.\n\u003e\n\u003e On 12/08/2015 01:23 PM, Akiva Lichtner wrote:\n\u003e\n\u003e It's true that miners would have to be prepared to work on any partition.\n\u003e I don't see where the number affects defeating double spending, what\n\u003e matters is the nonce in the block that keeps the next successful miner\n\u003e random.\n\u003e\n\u003e I expect that the number of miners would be ten times larger as well, so\n\u003e an attacker would have no advantage working on one partition.\n\u003e\n\u003e On Tue, Dec 8, 2015 at 3:50 PM, Patrick Strateman via bitcoin-dev \u003c\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e Payment recipients would need to operate a daemon for each chain, thus\n\u003e\u003e guaranteeing no scaling advantage.\n\u003e\u003e\n\u003e\u003e (There are other issues, but I believe that to be enough of a show\n\u003e\u003e stopper not to continue).\n\u003e\u003e\n\u003e\u003e On 12/08/2015 08:27 AM, Akiva Lichtner via bitcoin-dev wrote:\n\u003e\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 _______________________________________________\n\u003e\u003e bitcoin-dev mailing listbitcoin-dev at lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\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 _______________________________________________\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/bbd37f43/attachment-0001.html\u003e",
"sig": "5dc56a321d8607fb014699b018d807b2b871ec8e7cd2e636852a9dade2f37a26d6c2e06c6925d8cc87643e30340f8ff672b6f97aca14f67d812fb0d8ec721a1a"
}