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