Loi Luu [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-06-09 to 2015-12-09
💬 Posted a total of 3 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 17:45:57

- reply

📅 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>

2023-06-07 17:45:57

- reply

2023-06-07 17:45:56

- reply

📅 Original date posted:2015-12-09
📝 Original message: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/20151209/65affaa5/attachment-0001.html>

2023-06-07 17:45:56

- reply

2023-06-07 15:37:02

- reply

📅 Original date posted:2015-06-09
📝 Original message:>
> The proposed fix is to add a new rule on how
> fees are handled. Some amount of every fee should be considered as burned
> and can never be spent. I will propose 50% of the fee here, but there may
> be better numbers that can be discovered prior to putting this into place.
> If we'd like miners to continue to collect the same fees after this change,
> we can suggest the default fee per transaction to be doubled
I would propose another practical rule rather than burning 50% of the fee.
For example, you can
credit 50% of the transaction fee to the next block. Thus, the attacker
cannot perform
the attack with 0-fee any more, yet you don't have to double the price of
the TX fee for the fix.
Thanks,
Loi Luu.
On Tue, Jun 9, 2015 at 4:07 AM, Raystonn . <raystonn at hotmail.com> wrote:
> When implemented, the block size limit was put in place to prevent the
> potential for a massive block to be used as an attack to benefit the miner
> of that block. The theory goes that such a massive block would enrich its
> miner by delaying other miners who are now busy downloading and validating
> that huge block. The original miner of that large-block would be free to
> continue hashing the next block, giving it an advantage.
>
> Unfortunately, this block size limit opened a different attack. Prior to
> the limit, any attempt to spam the network by anyone other than someone
> mining their own transactions would have been economically unfeasible. As
> every transaction would have a fee, there would have been a real cost for
> every minute of spam. The end result would have been a transfer of wealth
> from spammer to Bitcoin miners, which would have harmed the spammers and
> encouraged further mining of Bitcoin, a very antifragile outcome.
>
> But now we have the block size limit. Things are very different with this
> feature in place. The beginning of a spam attack on the Bitcoin network
> will incur transaction fees, just like before. But if spam continues at a
> rate exceeding the block size limit long enough for transactions to be
> dropped from mempools, the vast majority of spam transaction fees will
> never
> have to be paid. In fact, as real users gain in desperation and pay higher
> fees to get their transactions through in a timely manner, the spammers
> will
> adjust their fees to minimize the cost of the attack and maximize
> effectiveness. Using this method, they keep their fees at a point that
> causes most of the spam transactions to be dropped without confirmation
> (free spam), while forcing a floor for transaction fees. Thus, while spam
> could be used by attackers to disable the network entirely, by paying
> high-enough fees to actually fill the blocks with spam, it can also be used
> by a single entity to force a transaction fee floor. Real users will be
> forced to pay a transaction fee higher than the majority of the spam to get
> their transactions confirmed. So this is an effective means for a minority
> of miners to force higher fees through spam attacks, even in the face of
> benevolent miners who would not support a higher fee floor by policy.
> Miners would simply have no way to fix this, as they can only put in the
> transactions that will fit under the block size limit.
>
> In the face of such a spam attack, Bitcoin's credibility and usability
> would
> be severely undermined. The block size limit enables this attack, and I
> now
> argue for its removal. But we can't just remove it and ignore the problem
> that it was intended to address. We need a new fix for the large-block
> problem described in the first paragraph that does not suffer from the
> dropped-transaction spam-attack problem that is enabled by the block size
> limit today. My proposal is likely to be controversial, and I'm very much
> open to hearing other better proposals.
>
> Large blocks created by a miner as a means to spam other miners out of
> competition is a problem because miners do not pay fees for their own
> transactions when they mine them. They collect the fees they pay. This
> breaks the economic barrier keeping people from spamming the network, as
> the
> spamming is essentially free. The proposed fix is to add a new rule on how
> fees are handled. Some amount of every fee should be considered as burned
> and can never be spent. I will propose 50% of the fee here, but there may
> be better numbers that can be discovered prior to putting this into place.
> If we'd like miners to continue to collect the same fees after this change,
> we can suggest the default fee per transaction to be doubled. Half of
> every
> fee would be burned and disappear forever, effectively distributing the
> value of those bitcoins across the entire money supply. The other half
> would be collected by the miner of the block as is done today. This
> solution would mean large blocks would cost a significant number of bitcoin
> to create, even when all of the transactions are created by the miner of
> that block. For this to work, we'd need to ensure a minimum fee is paid
> for
> most of the transactions in every block, and the new transaction fee rule
> is
> in place. Then the block size limit can be removed.
>
> Raystonn
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150609/3947db5f/attachment.html>

2023-06-07 15:37:02

- reply