* [bitcoin-dev] Removing the Dust Limit
@ 2021-08-08 18:52 Jeremy
2021-08-08 21:14 ` Matt Corallo
` (2 more replies)
0 siblings, 3 replies; 34+ messages in thread
From: Jeremy @ 2021-08-08 18:52 UTC (permalink / raw)
To: lightning-dev, Bitcoin development mailing list
[-- Attachment #1: Type: text/plain, Size: 1221 bytes --]
We should remove the dust limit from Bitcoin. Five reasons:
1) it's not our business what outputs people want to create
2) dust outputs can be used in various authentication/delegation smart
contracts
3) dust sized htlcs in lightning (
https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light)
force channels to operate in a semi-trusted mode which has implications
(AFAIU) for the regulatory classification of channels in various
jurisdictions; agnostic treatment of fund transfers would simplify this
(like getting a 0.01 cent dividend check in the mail)
4) thinly divisible colored coin protocols might make use of sats as value
markers for transactions.
5) should we ever do confidential transactions we can't prevent it without
compromising privacy / allowed transfers
The main reasons I'm aware of not allow dust creation is that:
1) dust is spam
2) dust fingerprinting attacks
1 is (IMO) not valid given the 5 reasons above, and 2 is preventable by
well behaved wallets to not redeem outputs that cost more in fees than they
are worth.
cheers,
jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
[-- Attachment #2: Type: text/html, Size: 3569 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [bitcoin-dev] Removing the Dust Limit 2021-08-08 18:52 [bitcoin-dev] Removing the Dust Limit Jeremy @ 2021-08-08 21:14 ` Matt Corallo 2021-08-08 21:41 ` Oleg Andreev 2021-08-08 21:51 ` [bitcoin-dev] [Lightning-dev] " David A. Harding 2021-08-09 13:22 ` Antoine Riard 2 siblings, 1 reply; 34+ messages in thread From: Matt Corallo @ 2021-08-08 21:14 UTC (permalink / raw) To: Jeremy, Bitcoin Protocol Discussion, lightning-dev If it weren't for the implications in changing standardness here, I think we should consider increasing the dust limit instead. The size of the UTXO set is a fundamental scalability constraint of the system. In fact, with proposals like assume-utxo/background history sync it is arguably *the* fundamental scalability constraint of the system. Today's dust limit is incredibly low - its based on a feerate of only 3 sat/vByte in order for claiming the UTXO to have *any* value, not just having enough value to be worth bothering. As feerates have gone up over time, and as we expect them to go up further, we should be considering drastically increasing the 3 sat/vByte basis to something more like 20 sat/vB. Matt On 8/8/21 14:52, Jeremy via bitcoin-dev wrote: > We should remove the dust limit from Bitcoin. Five reasons: > > 1) it's not our business what outputs people want to create It is precisely our business - the costs are born by us, not the creator. If someone wants to create outputs which don't make sense to spend, they can do so using OP_RETURN, since they won't spend it anyway. > 2) dust outputs can be used in various authentication/delegation smart contracts So can low-value-but-enough-to-be-worth-spending-when-you're-done-with-them outputs. > 3) dust sized htlcs in lightning > (https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light > <https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light>) > force channels to operate in a semi-trusted mode which has implications (AFAIU) for the regulatory classification of > channels in various jurisdictions; agnostic treatment of fund transfers would simplify this (like getting a 0.01 cent > dividend check in the mail) This is unrelated to the consensus dust limit. This is related to the practical question about the value of claiming an output. Again, the appropriate way to solve this instead of including spendable dust outputs would be an OP_RETURN output (though I believe this particular problem is actually better solved elsewhere in the lightning protocol). > 4) thinly divisible colored coin protocols might make use of sats as value markers for transactions. These schemes can and should use values which make them economical to spend. The whole *point* of the dust limit is to encourage people to use values which make sense economically to "clean up" after they're done with them. If people want to use outputs which they will not spend/"clean up" later, they should be using OP_RETURN. > 5) should we ever do confidential transactions we can't prevent it without compromising privacy / allowed transfers This is the reason the dust limit is not a *consensus* limit. If and when CT were to happen we can and would relax the standardness rules around the dust limit to allow for CT. > > The main reasons I'm aware of not allow dust creation is that: > > 1) dust is spam > 2) dust fingerprinting attacks 3) The significant costs to every miner and full node operator. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] Removing the Dust Limit 2021-08-08 21:14 ` Matt Corallo @ 2021-08-08 21:41 ` Oleg Andreev 0 siblings, 0 replies; 34+ messages in thread From: Oleg Andreev @ 2021-08-08 21:41 UTC (permalink / raw) To: Matt Corallo, Bitcoin Protocol Discussion; +Cc: lightning-dev I agree with Jeremy. Dust limit works due to design accident: that outputs are not encrypted. But outputs are private business and the real issue is only the cost of utxo set storage born by every user. There are two ways to address this: 1) either make ppl pay for renting that storage (which creates a ton of problems of its own) 2) or make storage extremely cheap so it remains cheap at any scale. This is perfectly solved by Utreexo. But looking at the private data because you can is a hack that creates issues of its own. > On 9 Aug 2021, at 00:16, Matt Corallo via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > > If it weren't for the implications in changing standardness here, I think we should consider increasing the dust limit instead. > > The size of the UTXO set is a fundamental scalability constraint of the system. In fact, with proposals like assume-utxo/background history sync it is arguably *the* fundamental scalability constraint of the system. Today's dust limit is incredibly low - its based on a feerate of only 3 sat/vByte in order for claiming the UTXO to have *any* value, not just having enough value to be worth bothering. As feerates have gone up over time, and as we expect them to go up further, we should be considering drastically increasing the 3 sat/vByte basis to something more like 20 sat/vB. > > Matt > >> On 8/8/21 14:52, Jeremy via bitcoin-dev wrote: >> We should remove the dust limit from Bitcoin. Five reasons: >> 1) it's not our business what outputs people want to create > > It is precisely our business - the costs are born by us, not the creator. If someone wants to create outputs which don't make sense to spend, they can do so using OP_RETURN, since they won't spend it anyway. > >> 2) dust outputs can be used in various authentication/delegation smart contracts > > So can low-value-but-enough-to-be-worth-spending-when-you're-done-with-them outputs. > >> 3) dust sized htlcs in lightning (https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light <https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light>) force channels to operate in a semi-trusted mode which has implications (AFAIU) for the regulatory classification of channels in various jurisdictions; agnostic treatment of fund transfers would simplify this (like getting a 0.01 cent dividend check in the mail) > > This is unrelated to the consensus dust limit. This is related to the practical question about the value of claiming an output. Again, the appropriate way to solve this instead of including spendable dust outputs would be an OP_RETURN output (though I believe this particular problem is actually better solved elsewhere in the lightning protocol). > >> 4) thinly divisible colored coin protocols might make use of sats as value markers for transactions. > > These schemes can and should use values which make them economical to spend. The whole *point* of the dust limit is to encourage people to use values which make sense economically to "clean up" after they're done with them. If people want to use outputs which they will not spend/"clean up" later, they should be using OP_RETURN. > >> 5) should we ever do confidential transactions we can't prevent it without compromising privacy / allowed transfers > > This is the reason the dust limit is not a *consensus* limit. If and when CT were to happen we can and would relax the standardness rules around the dust limit to allow for CT. > >> The main reasons I'm aware of not allow dust creation is that: >> 1) dust is spam >> 2) dust fingerprinting attacks > > 3) The significant costs to every miner and full node operator. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit 2021-08-08 18:52 [bitcoin-dev] Removing the Dust Limit Jeremy 2021-08-08 21:14 ` Matt Corallo @ 2021-08-08 21:51 ` David A. Harding 2021-08-08 22:46 ` Jeremy ` (2 more replies) 2021-08-09 13:22 ` Antoine Riard 2 siblings, 3 replies; 34+ messages in thread From: David A. Harding @ 2021-08-08 21:51 UTC (permalink / raw) To: Jeremy; +Cc: Bitcoin development mailing list, lightning-dev [-- Attachment #1: Type: text/plain, Size: 5284 bytes --] On Sun, Aug 08, 2021 at 11:52:55AM -0700, Jeremy wrote: > We should remove the dust limit from Bitcoin. Five reasons: Jeremy knows this, but to be clear for other readers, the dust limit is a policy in Bitcoin Core (and other software) where it refuses by default to relay or mine transactions with outputs below a certain amount. If nodes or miners running with non-default policy choose to relay or mine those transactions, they are not penalized (not directly, at least; there's BIP152 to consider). Question for Jeremy: would you also allow zero-value outputs? Or would you just move the dust limit down to a fixed 1-sat? I think the dust limit is worth keeping: > 1) it's not our business what outputs people want to create Every additional output added to the UTXO set increases the amount of work full nodes need to do to validate new transactions. For miners for whom fast validation of new blocks can significantly affect their revenue, larger UTXO sets increase their costs and so contributes towards centralization of mining. Allowing 0-value or 1-sat outputs minimizes the cost for polluting the UTXO set during periods of low feerates. If your stuff is going to slow down my node and possibly reduce my censorship resistance, how is that not my business? > 2) dust outputs can be used in various authentication/delegation smart > contracts All of which can also use amounts that are economically rational to spend on their own. If you're gonna use the chain for something besides value transfer, and you're already wiling to pay X in fees per onchain use, why is it not reasonable for us to ask you to put up something on the order of X as a bond that you'll actually clean up your mess when you're no longer interested in your thing? > 3) dust sized htlcs in lightning ( > https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light) > force channels to operate in a semi-trusted mode Nope, nothing is forced. Any LN node can simply refuse to accept/route HTLCs below the dust limit. > which has implications > (AFAIU) for the regulatory classification of channels in various > jurisdictions Sucks for the people living there. They should change their laws. If they can't do that, they should change their LN node policies not to route uneconomic HTLCs. We shouldn't make Bitcoin worse to make complying with regulations easier. I also doubt your proposed solution fixes the problem. Any LN node that accepts an uneconomic HTLC cannot recover that value, so the money is lost either way. Any sane regulation would treat losing value to transaction fees the same as losing value to uneconomical conditions. Finally, if LN nodes start polluting the UTXO set with no economic way to clean up their mess, I think that's going to cause tension between full node operators and LN node operators. > agnostic treatment of fund transfers would simplify this > (like getting a 0.01 cent dividend check in the mail) I'm not sure I understand this point. It sounds to me like you're comparing receiving an uneconomic output to receiving a check that isn't worth the time to cash. But the costs of checks are borne only by the people who send, receive, and process them. The costs of uneconomic outputs polluting the UTXO set are borne by every full node forever (or for every archival full node forever if non-archival nodes end up using something like utreexo). > 4) thinly divisible colored coin protocols might make use of sats as value > markers for transactions. I'm not exactly sure what you're talking about, but if Alice wants to communicate the number n onchain, she can do: if n < dust: nSequence = 0x0000 + n # should probably check endianess else: nValue = n There's at least 15 bits of nSequence currently without consensus or policy meaning, and the dust limits are currently in the hundreds of sat, so there's plenty of space. Alice could probably also communicate the same thing by grinding her output script's hash or pubkey; again, with dust limits just being hundreds of sats, that's not too much grinding. > 5) should we ever do confidential transactions we can't prevent it without > compromising privacy / allowed transfers I'm not an expert, but it seems to me that you can do that with range proofs. The range proof for >dust doesn't need to become part of the block chain, it can be relay only. I haven't looked since they upgraded to bulletproofs, but ISTR the original CT implementation leaked the most significant digits or something (that kept down the byte size of the proofs), so maybe it was already possible to know what was certainly not dust and what might be dust. In short, it's my opinion that the dust limit is not creating any real problems, so it should be kept for its contribution to keeping full nodes faster, cheaper, and more efficient. -Dave P.S. As I prepared to send this, Matt's email arrived about "If it weren't for the implications in changing standardness here, I think we should consider increasing the dust limit instead." I'm in agreement with both parts of that statement. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit 2021-08-08 21:51 ` [bitcoin-dev] [Lightning-dev] " David A. Harding @ 2021-08-08 22:46 ` Jeremy 2021-08-08 23:07 ` Jeremy 2021-09-30 22:07 ` Pieter Wuille 2 siblings, 0 replies; 34+ messages in thread From: Jeremy @ 2021-08-08 22:46 UTC (permalink / raw) Cc: Bitcoin development mailing list, lightning-dev [-- Attachment #1: Type: text/plain, Size: 2846 bytes --] Under no circumstances do I think we should *increase* the dust limit. That would have a mildly confiscatory effect on current Lightning Channel operators, among others. Generally, the UTXO set will grow. We should work to accommodate the worst case scenario under current consensus rules. I think this points to using things like Utreexo or similar rather than meddling in the user's business. I am skeptical that 0 value outputs are a real spam problem given the cost to create. Generally one creates an output when one either believes it would make sense to redeem it in the future. So surely this is a market problem, if people want them they can pay what it is worth for them to have it. Again, it's not my business. Matt proposes that people might use a nominal amount of bitcoin on a zero value input so that it doesn't look like dust. What Matt is asking for is that in any protocol you pay for your space not via fees, but instead via an assurance bond that you will eventually redeem it and clean the state up. In my opinion, this is worse than just allowing a zero value input since then you might accrue the need for an additional change output to which the bond's collateral be returned. With respect to the check in the mail analogy, cutting down trees for paper is bad for everyone and shipping things using fossil fuels contributes to climate change. Therefore it's a cost borne by society in some respects. Still, if someone else decides it's worth sending a remittance of whichever value, it is still not my business. With respect to CT and using the range proofs to exclude dust, I'm aware that can be done (hence compromising allowed transfers). Again, I don't think it's quite our business what people do, but on a technical level, this would have the impact of shrinking the anonymity set so is also suspect to me. --------------- If we really want to create incentives for state clean up, I think it's a decent design space to consider. e.g., we could set up a bottle deposit program whereby miners contribute an amount of funds from fee revenue from creating N outputs to a "rolling utxo" (e.g., a coinbase utxo that gets spent each block op_true to op_true under some miner rules) and the rolling utxo can either disperse funds to the miner reward or soak up funds from the fees in order to encourage blocks which have a better ratio of inputs to outputs than the mean. Miners can then apply this rule in the mempool to prioritize transactions that help their block's ratio. This is all without directly interfering with the user's intent to create whatever outputs they want, it just provides a way of paying miners to clean up the public common. Gas Token by Daian et al comes to mind, from Eth, w.r.t. many pitfalls arbing these state space freeing return curves, but it's worth thinking through nonetheless. [-- Attachment #2: Type: text/html, Size: 5099 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit 2021-08-08 21:51 ` [bitcoin-dev] [Lightning-dev] " David A. Harding 2021-08-08 22:46 ` Jeremy @ 2021-08-08 23:07 ` Jeremy 2021-09-30 22:07 ` Pieter Wuille 2 siblings, 0 replies; 34+ messages in thread From: Jeremy @ 2021-08-08 23:07 UTC (permalink / raw) To: David A. Harding; +Cc: Bitcoin development mailing list, lightning-dev, tarun [-- Attachment #1: Type: text/plain, Size: 3463 bytes --] some additional answers/clarifications > Question for Jeremy: would you also allow zero-value outputs? Or would > you just move the dust limit down to a fixed 1-sat? > I would remove it entirely -- i don't think there's a difference between the two realistically. > > Allowing 0-value or 1-sat outputs minimizes the cost for polluting the > UTXO set during periods of low feerates. > > Maybe that incentivizes people to make better use of the low feerate periods to do more important work like consolidations so that others do not have the opportunity to pollute (therefore eliminating the low fee period ;) > If your stuff is going to slow down my node and possibly reduce my > censorship resistance, how is that not my business? > You don't know that's what I'm doing, it's a guess as to my future behavior. If it weren't worth it to me, I wouldn't be doing it. Market will solve what is worth v.s. not worth. > > > 2) dust outputs can be used in various authentication/delegation smart > > contracts > > All of which can also use amounts that are economically rational to > spend on their own. If you're gonna use the chain for something besides > value transfer, and you're already wiling to pay X in fees per onchain > use, why is it not reasonable for us to ask you to put up something on > the order of X as a bond that you'll actually clean up your mess when > you're no longer interested in your thing? > These authentication/delegation smart contracts can be a part of value transfer e.g. some type of atomic swaps or other escrowed payment. A bond to clean it up is a fair reason; but perhaps in a protocol it might not make sense to clean up the utxo otherwise and so you're creating a cleanup transaction (potentially has to be presigned in a way it can't be done as a consolidation) and then some future consolidation to make the dusts+eps aggregately convenient to spend. So you'd be trading a decent amount more chainspace v.s. just ignoring the output and writing it to disk and maybe eventually into a utreexo (e.g. imagine utreexo where the last N years of outputs are held in memory, but eventually things get tree'd up) so the long term costs need not be entirely bourne in permanent storage. > > Nope, nothing is forced. Any LN node can simply refuse to accept/route > HTLCs below the dust limit. > I'd love to hear some broad thoughts on the impact of this on routing (cc Tarun who thinks about these things a decent amount) as this means for things like multipath routes you have much stricter constraints on which nodes you can route payments through. The impact on capacity from every user's pov might be not insubstantial. > > I also doubt your proposed solution fixes the problem. Any LN node that > accepts an uneconomic HTLC cannot recover that value, so the money is > lost either way. Any sane regulation would treat losing value to > transaction fees the same as losing value to uneconomical conditions. > > Finally, if LN nodes start polluting the UTXO set with no economic way > to clean up their mess, I think that's going to cause tension between > full node operators and LN node operators. > My anticipation is that the LN operators would stick the uneconomic HTLCs aggregately into a fan out utxo and try to cooperate, but failing that only pollute the chain by O(1) for O(n) non economic HTLCs. There is a difference between losing money and knowing exactly where it is but not claiming it. [-- Attachment #2: Type: text/html, Size: 6284 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit 2021-08-08 21:51 ` [bitcoin-dev] [Lightning-dev] " David A. Harding 2021-08-08 22:46 ` Jeremy 2021-08-08 23:07 ` Jeremy @ 2021-09-30 22:07 ` Pieter Wuille 2021-10-01 13:40 ` Erik Aronesty 2021-10-08 22:47 ` ZmnSCPxj 2 siblings, 2 replies; 34+ messages in thread From: Pieter Wuille @ 2021-09-30 22:07 UTC (permalink / raw) To: Bitcoin Protocol Discussion; +Cc: lightning-dev Jumping in late to this thread. I very much agree with how David Harding presents things, with a few comments inline. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, August 8th, 2021 at 5:51 PM, David A. Harding via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > > 1. it's not our business what outputs people want to create > > Every additional output added to the UTXO set increases the amount of > work full nodes need to do to validate new transactions. For miners > for whom fast validation of new blocks can significantly affect their > revenue, larger UTXO sets increase their costs and so contributes > towards centralization of mining. > Allowing 0-value or 1-sat outputs minimizes the cost for polluting the > UTXO set during periods of low feerates. > If your stuff is going to slow down my node and possibly reduce my > censorship resistance, how is that not my business? Indeed - UTXO set size is an externality that unfortunately Bitcoin's consensus rules fail to account for. Having a relay policy that avoids at the very least economically irrational behavior makes perfect sense to me. It's also not obvious how consensus rules could deal with this, as you don't want consensus rules with hardcoded prices/feerates. There are possibilities with designs like transactions getting a size/weight bonus/penalty, but that's both very hardforky, and hard to get right without introducing bad incentives. > > 2. dust outputs can be used in various authentication/delegation smart > > contracts > > > 3. dust sized htlcs in lightning ( > > https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light) > > force channels to operate in a semi-trusted mode > > > 4. thinly divisible colored coin protocols might make use of sats as value > > markers for transactions. My personal, and possibly controversial, opinion is that colored coin protocols have no business being on the Bitcoin chain, possibly beyond committing to an occasional batched state update or so. Both because there is little benefit for tokens with a trusted issuer already, and because it competes with using Bitcoin for BTC - the token that pays for its security (at least as long as the subsidy doesn't run out). Of course, personal opinions are no reason to dictate what people should or can use the chain for, but I do think it's reason to voice hesitancy to worsening the system's scalability properties only to benefit what I consider misguided use. > > 5. should we ever do confidential transactions we can't prevent it without > > compromising privacy / allowed transfers > > I'm not an expert, but it seems to me that you can do that with range > proofs. The range proof for >dust doesn't need to become part of the > block chain, it can be relay only. Yeah, range proofs have a non-hidden range; the lower bound can be nonzero, which could be required as part of a relay policy. Cheers, -- Pieter ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit 2021-09-30 22:07 ` Pieter Wuille @ 2021-10-01 13:40 ` Erik Aronesty 2021-10-07 4:52 ` ZmnSCPxj 2021-10-08 22:47 ` ZmnSCPxj 1 sibling, 1 reply; 34+ messages in thread From: Erik Aronesty @ 2021-10-01 13:40 UTC (permalink / raw) To: Pieter Wuille, Bitcoin Protocol Discussion; +Cc: lightning-dev mostly thinking out loud suppose there is a "lightweight" node: 1. ignores utxo's below the dust limit 2. doesn't validate dust tx 3. still validates POW, other tx, etc. these nodes could possibly get forked - accepting a series of valid, mined blocks where there is an invalid but ignored dust tx, however this attack seems every bit as expensive as a 51% attack On Fri, Oct 1, 2021 at 3:45 AM Pieter Wuille via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > > Jumping in late to this thread. > > I very much agree with how David Harding presents things, with a few comments inline. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Sunday, August 8th, 2021 at 5:51 PM, David A. Harding via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > > > > 1. it's not our business what outputs people want to create > > > > Every additional output added to the UTXO set increases the amount of > > work full nodes need to do to validate new transactions. For miners > > for whom fast validation of new blocks can significantly affect their > > revenue, larger UTXO sets increase their costs and so contributes > > towards centralization of mining. > > Allowing 0-value or 1-sat outputs minimizes the cost for polluting the > > UTXO set during periods of low feerates. > > If your stuff is going to slow down my node and possibly reduce my > > censorship resistance, how is that not my business? > > Indeed - UTXO set size is an externality that unfortunately Bitcoin's consensus rules fail to account > for. Having a relay policy that avoids at the very least economically irrational behavior makes > perfect sense to me. > > It's also not obvious how consensus rules could deal with this, as you don't want consensus rules > with hardcoded prices/feerates. There are possibilities with designs like transactions getting > a size/weight bonus/penalty, but that's both very hardforky, and hard to get right without > introducing bad incentives. > > > > 2. dust outputs can be used in various authentication/delegation smart > > > contracts > > > > > 3. dust sized htlcs in lightning ( > > > https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light) > > > force channels to operate in a semi-trusted mode > > > > > 4. thinly divisible colored coin protocols might make use of sats as value > > > markers for transactions. > > My personal, and possibly controversial, opinion is that colored coin protocols have no business being on the Bitcoin chain, possibly > beyond committing to an occasional batched state update or so. Both because there is little benefit for tokens with a trusted > issuer already, and because it competes with using Bitcoin for BTC - the token that pays for its security (at least as long as > the subsidy doesn't run out). > > Of course, personal opinions are no reason to dictate what people should or can use the chain for, but I do think it's reason to > voice hesitancy to worsening the system's scalability properties only to benefit what I consider misguided use. > > > > 5. should we ever do confidential transactions we can't prevent it without > > > compromising privacy / allowed transfers > > > > I'm not an expert, but it seems to me that you can do that with range > > proofs. The range proof for >dust doesn't need to become part of the > > block chain, it can be relay only. > > Yeah, range proofs have a non-hidden range; the lower bound can be nonzero, which could be required as part of a relay policy. > > Cheers, > > -- > Pieter > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit 2021-10-01 13:40 ` Erik Aronesty @ 2021-10-07 4:52 ` ZmnSCPxj 2021-10-07 8:17 ` LORD HIS EXCELLENCY JAMES HRMH 2021-10-07 9:13 ` shymaa arafat 0 siblings, 2 replies; 34+ messages in thread From: ZmnSCPxj @ 2021-10-07 4:52 UTC (permalink / raw) To: Erik Aronesty; +Cc: Bitcoin Protocol Discussion, lightning-dev Good morning e, > mostly thinking out loud > > suppose there is a "lightweight" node: > > 1. ignores utxo's below the dust limit > 2. doesn't validate dust tx > 3. still validates POW, other tx, etc. > > these nodes could possibly get forked - accepting a series of valid, > mined blocks where there is an invalid but ignored dust tx, however > this attack seems every bit as expensive as a 51% attack How would such a node treat a transaction that spends multiple dust UTXOs and creates a single non-dust UTXO out of them (after fees)? Is it valid (to such a node) or not? I presume from #1 it never stores dust UTXOs, so the node cannot know if the UTXO being spent by such a tx is spending dust, or trying to spend an already-spent TXO, or even inventing a TXO out of `/dev/random`. Regards, ZmnSCPxj ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit 2021-10-07 4:52 ` ZmnSCPxj @ 2021-10-07 8:17 ` LORD HIS EXCELLENCY JAMES HRMH 2021-10-07 8:34 ` LORD HIS EXCELLENCY JAMES HRMH 2021-10-07 9:13 ` shymaa arafat 1 sibling, 1 reply; 34+ messages in thread From: LORD HIS EXCELLENCY JAMES HRMH @ 2021-10-07 8:17 UTC (permalink / raw) To: Erik Aronesty, ZmnSCPxj, Bitcoin Protocol Discussion; +Cc: lightning-dev [-- Attachment #1: Type: text/plain, Size: 1912 bytes --] Good Afternoon, Returning to this subject, there should be no restriction to the value of utxo's that keep in one's own wallet as change can be created in any value. With obvious intent, the wallet should avoid creating utxo's below the current dust limit at the time the transaction is created but it cannot guarantee it. The wallet should avoid including utxo's that by weight sat/KB are more expensive to include that their value at the time a transaction is created, ie. do not include utxo's in a transaction that lower the input value after fees for automatic utxo selection, however, perhaps consider this is valid for manual utxo selection since it is in every example 'my money' and I can spend some of it if I decide. There is no discipline in complaining that the dust set of utxo's slows down the process of block validation during mining. Every conceivable computerised business bears the expense of the cost of a database transaction. The actual answer to this genuine business concern of database speed is to build a faster database. It is correct knowledge to know that the Bitcoin protocol cannot speculate as to the future but we can. The case exists where it is conceivable for example, that the transaction fee is paid only for the first utxo inclusion in a transaction due to changes to the calculation of block-size. There are other easily plausible examples where the inclusion of what is today considered dust may not be ill-considered. KING JAMES HRMH Great British Empire Regards, The Australian LORD HIS EXCELLENCY JAMES HRMH (& HMRH) of Hougun Manor & Glencoe & British Empire MR. Damian A. James Williamson Wills et al. Willtech www.willtech.com.au www.go-overt.com duigco.org DUIGCO API and other projects m. 0487135719 f. +61261470192 This email does not constitute a general advice. Please disregard this email if misdelivered. [-- Attachment #2: Type: text/html, Size: 3921 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit 2021-10-07 8:17 ` LORD HIS EXCELLENCY JAMES HRMH @ 2021-10-07 8:34 ` LORD HIS EXCELLENCY JAMES HRMH 2021-10-07 10:35 ` LORD HIS EXCELLENCY JAMES HRMH 0 siblings, 1 reply; 34+ messages in thread From: LORD HIS EXCELLENCY JAMES HRMH @ 2021-10-07 8:34 UTC (permalink / raw) To: Erik Aronesty, ZmnSCPxj, Bitcoin Protocol Discussion; +Cc: lightning-dev [-- Attachment #1: Type: text/plain, Size: 3966 bytes --] Good Afternoon, The underlying consideration is the same concerning the handling of 1c and 2c coins in an economy. Although you may argue the cost of counting those coins throughout the course of minting, drafting to banks, paying to bank customers, including in change, and at every handling counting, is less than the value of those coins, hpwever, the solution in traditional currency is to round the value of the transaction either per line of goods or per total before calculating the Grand Total, in which case the payment either from a non-utxo set of accumulation in a traditional account or, from a known series of denominations, is adjusted. In the case of Bitcoin, the denominations available are effectively the utxo set and there is no effective way to round the transactions without accepting overpayments as valid, and with what consideration, in which case the protocol may avoid creating dust in change by sending the additional rounded amount that would otherwise be dust to the recipient. I suppose that this gets difficult where the transaction has multiple outputs and you could argue to distribute to all outputs as an overpayment. It is the same effectively as rounding to 10c. KING JAMES HRMH Great British Empire Regards, The Australian LORD HIS EXCELLENCY JAMES HRMH (& HMRH) of Hougun Manor & Glencoe & British Empire MR. Damian A. James Williamson Wills et al. Willtech www.willtech.com.au www.go-overt.com duigco.org DUIGCO API and other projects m. 0487135719 f. +61261470192 This email does not constitute a general advice. Please disregard this email if misdelivered. ________________________________ From: LORD HIS EXCELLENCY JAMES HRMH <willtech@live•com.au> Sent: Thursday, 7 October 2021 7:17 PM To: Erik Aronesty <erik@q32•com>; ZmnSCPxj <ZmnSCPxj@protonmail•com>; Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org> Cc: lightning-dev <lightning-dev@lists•linuxfoundation.org> Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit Good Afternoon, Returning to this subject, there should be no restriction to the value of utxo's that keep in one's own wallet as change can be created in any value. With obvious intent, the wallet should avoid creating utxo's below the current dust limit at the time the transaction is created but it cannot guarantee it. The wallet should avoid including utxo's that by weight sat/KB are more expensive to include that their value at the time a transaction is created, ie. do not include utxo's in a transaction that lower the input value after fees for automatic utxo selection, however, perhaps consider this is valid for manual utxo selection since it is in every example 'my money' and I can spend some of it if I decide. There is no discipline in complaining that the dust set of utxo's slows down the process of block validation during mining. Every conceivable computerised business bears the expense of the cost of a database transaction. The actual answer to this genuine business concern of database speed is to build a faster database. It is correct knowledge to know that the Bitcoin protocol cannot speculate as to the future but we can. The case exists where it is conceivable for example, that the transaction fee is paid only for the first utxo inclusion in a transaction due to changes to the calculation of block-size. There are other easily plausible examples where the inclusion of what is today considered dust may not be ill-considered. KING JAMES HRMH Great British Empire Regards, The Australian LORD HIS EXCELLENCY JAMES HRMH (& HMRH) of Hougun Manor & Glencoe & British Empire MR. Damian A. James Williamson Wills et al. Willtech www.willtech.com.au www.go-overt.com duigco.org DUIGCO API and other projects m. 0487135719 f. +61261470192 This email does not constitute a general advice. Please disregard this email if misdelivered. [-- Attachment #2: Type: text/html, Size: 7813 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit 2021-10-07 8:34 ` LORD HIS EXCELLENCY JAMES HRMH @ 2021-10-07 10:35 ` LORD HIS EXCELLENCY JAMES HRMH 0 siblings, 0 replies; 34+ messages in thread From: LORD HIS EXCELLENCY JAMES HRMH @ 2021-10-07 10:35 UTC (permalink / raw) To: Erik Aronesty, ZmnSCPxj, Bitcoin Protocol Discussion; +Cc: lightning-dev [-- Attachment #1: Type: text/plain, Size: 5284 bytes --] Good Afternoon, Further, if it is entirely necessary to prevent the creation of utxo's that are considered dust, and I am not by any means convinced, then it is simple to provide the most circumspect solution to transfer the value of any dust utxo that would be created in a transaction to the fee. I do not believe this answer is any more than robbery of the future value of the wallet as my wallet must be able to keep any change but if it is must then this is the answer. KING JAMES HRMH Great British Empire Regards, The Australian LORD HIS EXCELLENCY JAMES HRMH (& HMRH) of Hougun Manor & Glencoe & British Empire MR. Damian A. James Williamson Wills et al. Willtech www.willtech.com.au www.go-overt.com duigco.org DUIGCO API and other projects m. 0487135719 f. +61261470192 This email does not constitute a general advice. Please disregard this email if misdelivered. ________________________________ From: LORD HIS EXCELLENCY JAMES HRMH <willtech@live•com.au> Sent: Thursday, 7 October 2021 7:34 PM To: Erik Aronesty <erik@q32•com>; ZmnSCPxj <ZmnSCPxj@protonmail•com>; Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org> Cc: lightning-dev <lightning-dev@lists•linuxfoundation.org> Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit Good Afternoon, The underlying consideration is the same concerning the handling of 1c and 2c coins in an economy. Although you may argue the cost of counting those coins throughout the course of minting, drafting to banks, paying to bank customers, including in change, and at every handling counting, is less than the value of those coins, hpwever, the solution in traditional currency is to round the value of the transaction either per line of goods or per total before calculating the Grand Total, in which case the payment either from a non-utxo set of accumulation in a traditional account or, from a known series of denominations, is adjusted. In the case of Bitcoin, the denominations available are effectively the utxo set and there is no effective way to round the transactions without accepting overpayments as valid, and with what consideration, in which case the protocol may avoid creating dust in change by sending the additional rounded amount that would otherwise be dust to the recipient. I suppose that this gets difficult where the transaction has multiple outputs and you could argue to distribute to all outputs as an overpayment. It is the same effectively as rounding to 10c. KING JAMES HRMH Great British Empire Regards, The Australian LORD HIS EXCELLENCY JAMES HRMH (& HMRH) of Hougun Manor & Glencoe & British Empire MR. Damian A. James Williamson Wills et al. Willtech www.willtech.com.au www.go-overt.com duigco.org DUIGCO API and other projects m. 0487135719 f. +61261470192 This email does not constitute a general advice. Please disregard this email if misdelivered. ________________________________ From: LORD HIS EXCELLENCY JAMES HRMH <willtech@live•com.au> Sent: Thursday, 7 October 2021 7:17 PM To: Erik Aronesty <erik@q32•com>; ZmnSCPxj <ZmnSCPxj@protonmail•com>; Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org> Cc: lightning-dev <lightning-dev@lists•linuxfoundation.org> Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit Good Afternoon, Returning to this subject, there should be no restriction to the value of utxo's that keep in one's own wallet as change can be created in any value. With obvious intent, the wallet should avoid creating utxo's below the current dust limit at the time the transaction is created but it cannot guarantee it. The wallet should avoid including utxo's that by weight sat/KB are more expensive to include that their value at the time a transaction is created, ie. do not include utxo's in a transaction that lower the input value after fees for automatic utxo selection, however, perhaps consider this is valid for manual utxo selection since it is in every example 'my money' and I can spend some of it if I decide. There is no discipline in complaining that the dust set of utxo's slows down the process of block validation during mining. Every conceivable computerised business bears the expense of the cost of a database transaction. The actual answer to this genuine business concern of database speed is to build a faster database. It is correct knowledge to know that the Bitcoin protocol cannot speculate as to the future but we can. The case exists where it is conceivable for example, that the transaction fee is paid only for the first utxo inclusion in a transaction due to changes to the calculation of block-size. There are other easily plausible examples where the inclusion of what is today considered dust may not be ill-considered. KING JAMES HRMH Great British Empire Regards, The Australian LORD HIS EXCELLENCY JAMES HRMH (& HMRH) of Hougun Manor & Glencoe & British Empire MR. Damian A. James Williamson Wills et al. Willtech www.willtech.com.au www.go-overt.com duigco.org DUIGCO API and other projects m. 0487135719 f. +61261470192 This email does not constitute a general advice. Please disregard this email if misdelivered. [-- Attachment #2: Type: text/html, Size: 10302 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit 2021-10-07 4:52 ` ZmnSCPxj 2021-10-07 8:17 ` LORD HIS EXCELLENCY JAMES HRMH @ 2021-10-07 9:13 ` shymaa arafat 2021-10-07 10:01 ` ZmnSCPxj 1 sibling, 1 reply; 34+ messages in thread From: shymaa arafat @ 2021-10-07 9:13 UTC (permalink / raw) To: ZmnSCPxj, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1552 bytes --] If u allow me to discuss,,, I previously suggested storing dust UTXOS in a separate Merkle tree or strucutre in general if we are talking about the original set. I'm a kind of person who doesn't like to throw any thing; if it's not needed now keep it in the basement for example. So, if dust UTXOS making a burden keep them in secondary storage, where in such cases u can verify then delete them. On Thu, Oct 7, 2021, 06:52 ZmnSCPxj via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > Good morning e, > > > mostly thinking out loud > > > > suppose there is a "lightweight" node: > > > > 1. ignores utxo's below the dust limit > > 2. doesn't validate dust tx > > 3. still validates POW, other tx, etc. > > > > these nodes could possibly get forked - accepting a series of valid, > > mined blocks where there is an invalid but ignored dust tx, however > > this attack seems every bit as expensive as a 51% attack > > How would such a node treat a transaction that spends multiple dust UTXOs > and creates a single non-dust UTXO out of them (after fees)? > Is it valid (to such a node) or not? > > I presume from #1 it never stores dust UTXOs, so the node cannot know if > the UTXO being spent by such a tx is spending dust, or trying to spend an > already-spent TXO, or even inventing a TXO out of `/dev/random`. > > Regards, > ZmnSCPxj > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 2304 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit 2021-10-07 9:13 ` shymaa arafat @ 2021-10-07 10:01 ` ZmnSCPxj [not found] ` <CAM98U8kKud-7QoJKYd5o245o8vGeUD7YD2OnXF_QeKaO33dSTw@mail.gmail.com> 0 siblings, 1 reply; 34+ messages in thread From: ZmnSCPxj @ 2021-10-07 10:01 UTC (permalink / raw) To: shymaa arafat; +Cc: Bitcoin Protocol Discussion Good morning shymaa > If u allow me to discuss,,, > I previously suggested storing dust UTXOS in a separate Merkle tree or strucutre in general if we are talking about the original set. > I'm a kind of person who doesn't like to throw any thing; if it's not needed now keep it in the basement for example. > So, if dust UTXOS making a burden keep them in secondary storage, where in such cases u can verify then delete them. While this technique helps reduce *average* CPU cost, it does not reduce *worst-case* CPU cost (and if the secondary storage trades off to gain increased capacity per satoshi by sacrificing speed, it can worse the worst-case time). It is helpful to remember that attacks will always target worst-case behavior. This is why quicksort is strongly disrecommended for processing data coming from external sources, its worst-case time is O(n^2). And we should switch to algorithms like mergesort or similar whose average times are generally worse than quicksort but have the major advantage of keeping an O(n log n) worst-case. Moving data we think is unlikely to be referenced to secondary storage (presumably in a construction that is slower but gets more storage per economic unit) moves us closer to quicksort than mergesort, and we should avoid quicksort-like solutions as it is always the worst-case behavior that is targeted in attacks. Regards, ZmnSCPxj ^ permalink raw reply [flat|nested] 34+ messages in thread
[parent not found: <CAM98U8kKud-7QoJKYd5o245o8vGeUD7YD2OnXF_QeKaO33dSTw@mail.gmail.com>]
[parent not found: <MCYvJzqskIC56X-ylVCNgdaVk6SNnpCE6GgssXxK-znwwK4MoA41a2A-yNuCG8s99ll3h__YjCjBlP99A27Clbip-aYbF2ZwLpZ0SJT0j2U=@protonmail.com>]
* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit [not found] ` <MCYvJzqskIC56X-ylVCNgdaVk6SNnpCE6GgssXxK-znwwK4MoA41a2A-yNuCG8s99ll3h__YjCjBlP99A27Clbip-aYbF2ZwLpZ0SJT0j2U=@protonmail.com> @ 2021-10-08 7:44 ` shymaa arafat 2021-10-08 10:38 ` ZmnSCPxj 0 siblings, 1 reply; 34+ messages in thread From: shymaa arafat @ 2021-10-08 7:44 UTC (permalink / raw) To: lightning-dev, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2239 bytes --] The suggested idea I was replying to is to make all dust TXs invalid by some nodes. I suggested a compromise by keeping them in secondary storage for full nodes, and in a separate Merkle Tree for bridge servers. -In bridge servers they won't increase any worstcase, on the contrary this will enhance the performance even if slightly. -In full nodes, and since they will usually appear in clusters, they will be fetched rarely (either by a dust sweeping action, or a malicious attacker) In both cases as a batch -To not exhaust the node with DoS(as the reply mentioned)one may think of uploading the whole dust partition if they were called more than certain threshold (say more than 1 Tx in a block) -and then keep them there for "a while", but as a separate partition too to exclude them from any caching mechanism after that block. -The "while" could be a tuned parameter. -Take care that the more dust is sweeped, the less dust to remain in the UTXO set; as users are already much dis-incentivised to create more. . Thanks for allowing the reply On Thu, Oct 7, 2021, 16:43 ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote: > > > > I don't know what brings up sorting here, unless as an example. > > Yes, it is an example: quicksort is bad for network-facing applications > because its ***worst-case behavior*** is bad. > Bitcoin is a network-facing application, and similarly, ***worst-case > behavior*** being bad is something that would strongly discourage > particular approaches. > Your proposal risks bad ***worst-case behavior***. > > > Anyways, I was comparing to rejecting them completely, not to keeping > them in one set. In addition, those dust sweep Transactions will probably > be a dust sweep and thus contain so many inputs which "maybe" makes 1-one > disk visit to fetch all their hashes at once, 2-from a smaller subset with > max size 5-10% the UTXO set, justifiable. > > Do not consider the ***average case*** where a block is composed of only a > few dust sweep transactions and most transactions are normal, > non-dust-sweep transactions. > > Instead, consider the ***worst case*** where ***all*** transactions in a > block are dust sweep transactions, because that is what attackers will use. > > Regards, > ZmnSCPxj > [-- Attachment #2: Type: text/html, Size: 2852 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit 2021-10-08 7:44 ` shymaa arafat @ 2021-10-08 10:38 ` ZmnSCPxj 0 siblings, 0 replies; 34+ messages in thread From: ZmnSCPxj @ 2021-10-08 10:38 UTC (permalink / raw) To: shymaa arafat, Bitcoin Protocol Discussion; +Cc: lightning-dev Good morning shymaa, > The suggested idea I was replying to is to make all dust TXs invalid by some nodes. Is this supposed to be consensus change or not? Why "some" nodes and not all? I think the important bit is for full nodes. Non-full-nodes already work at reduced security; what is important is the security-efficiency tradeoff. > I suggested a compromise by keeping them in secondary storage for full nodes, and in a separate Merkle Tree for bridge servers. > -In bridge servers they won't increase any worstcase, on the contrary this will enhance the performance even if slightly. > -In full nodes, and since they will usually appear in clusters, they will be fetched rarely (either by a dust sweeping action, or a malicious attacker) > In both cases as a batch > -To not exhaust the node with DoS(as the reply mentioned)one may think of uploading the whole dust partition if they were called more than certain threshold (say more than 1 Tx in a block) > -and then keep them there for "a while", but as a separate partition too to exclude them from any caching mechanism after that block. > -The "while" could be a tuned parameter. Assuming you meant "dust tx is considered invalid by all nodes". * Block has no dust sweep * With dust rejected: only non-dust outputs are accessed. * With dust in secondary storage: only non-dust outputs are accessed. * Block has some dust sweeps * With dust rejected: only non-dust outputs are accessed, block is rejected. * With dust in secondary storage: some data is loaded from secondary storage. * Block is composed of only dust sweeps * With dust rejected: only non-dust outputs are accessed, block is rejected. * With dust in secondary storage: significant increase in processing to load large secondary storage in memory, So I fail to see how the proposal ever reduces processing compared to the idea of just outright making all dust txs invalid and rejecting the block. Perhaps you are trying to explain some other mechanism than what I understood? It is helpful to think in terms always of worst-case behavior when considering resistance against attacks. > -Take care that the more dust is sweeped, the less dust to remain in the UTXO set; as users are already much dis-incentivised to create more. But creation of dust is also as easy as sweeping them, and nothing really prevents a block from *both* creating *and* sweeping dust, e.g. a block composed of 1-input-1-output transactions, unless you want to describe some kind of restriction here? Such a degenerate block would hit your secondary storage double: one to read, and one to overwrite and add new entries; if the storage is large then the index structure you use also is large and updates can be expensive there as well. Again, I am looking solely at fullnode efficiency here, meaning all rules validated and all transactions validated, not validating and simply accepting some transactions as valid is a degradation of security from full validation to SPV validation. Now of course in practice modern Bitcoin is hard to attack with *only* mining hashpower as there are so many fullnodes that an SPV node would be easily able to find the "True" history of the chain. However, as I understand it that proporty of fullnodes protecting against attacks on SPV nodes only exists due to fullnodes being cheap to keep online; if the cost of fullnodes in the **worst case** (***not*** average, please stop talking about average case) increases then it may become feasible for miners to attack SPV nodes. Regards, ZmnSCPxj ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit 2021-09-30 22:07 ` Pieter Wuille 2021-10-01 13:40 ` Erik Aronesty @ 2021-10-08 22:47 ` ZmnSCPxj 1 sibling, 0 replies; 34+ messages in thread From: ZmnSCPxj @ 2021-10-08 22:47 UTC (permalink / raw) To: Pieter Wuille, Bitcoin Protocol Discussion; +Cc: lightning-dev Good morning Pieter, > Indeed - UTXO set size is an externality that unfortunately Bitcoin's consensus rules fail to account > for. Having a relay policy that avoids at the very least economically irrational behavior makes > perfect sense to me. > > It's also not obvious how consensus rules could deal with this, as you don't want consensus rules > with hardcoded prices/feerates. There are possibilities with designs like transactions getting > a size/weight bonus/penalty, but that's both very hardforky, and hard to get right without > introducing bad incentives. Why is a +weight malus *very* hardforky? Suppose a new version of a node adds, say, +20 sipa per output of a transaction (in order to economically discourage the creation of additional outputs in the UTXO set). Older versions would see the block as being lower weight than usual, but as the consensus rule is "smaller than 4Msipa" they should still accept any block acceptable to newer versions. It seems to me that only a -weight bonus is hardforky (but then xref SegWit and its -weight bonus on inputs). I suppose the effect is primarily felt on mining nodes? Miners might refuse to activate such a fork, as they would see fewer transactions per block on average? Regards, ZmnSCPxj ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit 2021-08-08 18:52 [bitcoin-dev] Removing the Dust Limit Jeremy 2021-08-08 21:14 ` Matt Corallo 2021-08-08 21:51 ` [bitcoin-dev] [Lightning-dev] " David A. Harding @ 2021-08-09 13:22 ` Antoine Riard 2021-08-10 0:30 ` Billy Tetrud 2021-08-10 6:14 ` David A. Harding 2 siblings, 2 replies; 34+ messages in thread From: Antoine Riard @ 2021-08-09 13:22 UTC (permalink / raw) To: Jeremy; +Cc: Bitcoin development mailing list, lightning-dev [-- Attachment #1: Type: text/plain, Size: 4289 bytes --] I'm pretty conservative about increasing the standard dust limit in any way. This would convert a higher percentage of LN channels capacity into dust, which is coming with a lowering of funds safety [0]. Of course, we can adjust the LN security model around dust handling to mitigate the safety risk in case of adversarial settings, but ultimately the standard dust limit creates a "hard" bound, and as such it introduces a trust vector in the reliability of your peer to not goes onchain with a commitment heavily-loaded with dust-HTLC you own. LN node operators might be willingly to compensate this "dust" trust vector by relying on side-trust model, such as PKI to authenticate their peers or API tokens (LSATs, PoW tokens), probably not free from consequences for the "openness" of the LN topology... Further, I think any authoritative setting of the dust limit presents the risk of becoming ill-adjusted w.r.t to market realities after a few months or years, and would need periodic reevaluations. Those reevaluations, if not automated, would become a vector of endless dramas and bikeshedding as the L2s ecosystems grow bigger... Note, this would also constrain the design space of newer fee schemes. Such as negotiated-with-mining-pool and discounted consolidation during low feerate periods deployed by such producers of low-value outputs. ` Moreover as an operational point, if we proceed to such an increase on the base-layer, e.g to 20 sat/vb, we're going to severely damage the propagation of any LN transaction, where a commitment transaction is built with less than 20 sat/vb outputs. Of course, core's policy deployment on the base layer is gradual, but we should first give a time window for the LN ecosystem to upgrade and as of today we're still devoid of the mechanism to do it cleanly and asynchronously (e.g dynamic upgrade or quiescence protocol [1]). That said, as raised by other commentators, I don't deny we have a long-term tension between L2 nodes and full-nodes operators about the UTXO set growth, but for now I would rather solve this with smarter engineering such as utreexo on the base-layer side or multi-party shared-utxo or compressed colored coins/authentication smart contracts (e.g opentimestamp's merkle tree in OP_RETURN) on the upper layers rather than altering the current equilibrium. I think the status quo is good enough for now, and I believe we would be better off to learn from another development cycle before tweaking the dust limit in any sense. Antoine [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-May/002714.html [1] https://github.com/lightningnetwork/lightning-rfc/pull/869 Le dim. 8 août 2021 à 14:53, Jeremy <jlrubin@mit•edu> a écrit : > We should remove the dust limit from Bitcoin. Five reasons: > > 1) it's not our business what outputs people want to create > 2) dust outputs can be used in various authentication/delegation smart > contracts > 3) dust sized htlcs in lightning ( > https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light) > force channels to operate in a semi-trusted mode which has implications > (AFAIU) for the regulatory classification of channels in various > jurisdictions; agnostic treatment of fund transfers would simplify this > (like getting a 0.01 cent dividend check in the mail) > 4) thinly divisible colored coin protocols might make use of sats as value > markers for transactions. > 5) should we ever do confidential transactions we can't prevent it without > compromising privacy / allowed transfers > > The main reasons I'm aware of not allow dust creation is that: > > 1) dust is spam > 2) dust fingerprinting attacks > > 1 is (IMO) not valid given the 5 reasons above, and 2 is preventable by > well behaved wallets to not redeem outputs that cost more in fees than they > are worth. > > cheers, > > jeremy > > -- > @JeremyRubin <https://twitter.com/JeremyRubin> > <https://twitter.com/JeremyRubin> > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > [-- Attachment #2: Type: text/html, Size: 7282 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit 2021-08-09 13:22 ` Antoine Riard @ 2021-08-10 0:30 ` Billy Tetrud 2021-08-10 5:04 ` Jeremy 2021-08-10 6:14 ` David A. Harding 1 sibling, 1 reply; 34+ messages in thread From: Billy Tetrud @ 2021-08-10 0:30 UTC (permalink / raw) To: Antoine Riard, Bitcoin Protocol Discussion; +Cc: lightning-dev [-- Attachment #1: Type: text/plain, Size: 5918 bytes --] > 5) should we ever do confidential transactions we can't prevent it without compromising privacy / allowed transfers I wanted to mention the dubiousness of adding confidential transactions to bitcoin. Because adding CT would eliminate the ability for users to audit the supply of Bitcoin, I think its incredibly unlikely to ever happen. I'm in the camp that we shouldn't do anything that prevents people from auditing the supply. I think that camp is probably pretty large. Regardless of what I think should happen there, and even if CT were to eventually happen in bitcoin, I don't think that future possibility is a good reason to change the dust limit today. It seems like dust is a scalability problem regardless of whether we use Utreexo eventually or not, tho an accumulator would help a ton. One idea would be to destroy/delete dust at some point in the future. However, even if we were to plan to do this, I still don't think the dust limit should be removed. But the dust limit should probably be lowered a bit, given that the 546 sats limit is about 7 cents and its very doable to send 1 sat/vbyte transactions, so lowering it to 200 sats seems reasonable. On Mon, Aug 9, 2021 at 6:24 AM Antoine Riard via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > I'm pretty conservative about increasing the standard dust limit in any > way. This would convert a higher percentage of LN channels capacity into > dust, which is coming with a lowering of funds safety [0]. Of course, we > can adjust the LN security model around dust handling to mitigate the > safety risk in case of adversarial settings, but ultimately the standard > dust limit creates a "hard" bound, and as such it introduces a trust > vector in the reliability of your peer to not goes > onchain with a commitment heavily-loaded with dust-HTLC you own. > > LN node operators might be willingly to compensate this "dust" trust > vector by relying on side-trust model, such as PKI to authenticate their > peers or API tokens (LSATs, PoW tokens), probably not free from > consequences for the "openness" of the LN topology... > > Further, I think any authoritative setting of the dust limit presents the > risk of becoming ill-adjusted w.r.t to market realities after a few months > or years, and would need periodic reevaluations. Those reevaluations, if > not automated, would become a vector of endless dramas and bikeshedding as > the L2s ecosystems grow bigger... > > Note, this would also constrain the design space of newer fee schemes. > Such as negotiated-with-mining-pool and discounted consolidation during low > feerate periods deployed by such producers of low-value outputs. > ` > Moreover as an operational point, if we proceed to such an increase on the > base-layer, e.g to 20 sat/vb, we're going to severely damage the > propagation of any LN transaction, where a commitment transaction is built > with less than 20 sat/vb outputs. Of course, core's policy deployment on > the base layer is gradual, but we should first give a time window for the > LN ecosystem to upgrade and as of today we're still devoid of the mechanism > to do it cleanly and asynchronously (e.g dynamic upgrade or quiescence > protocol [1]). > > That said, as raised by other commentators, I don't deny we have a > long-term tension between L2 nodes and full-nodes operators about the UTXO > set growth, but for now I would rather solve this with smarter engineering > such as utreexo on the base-layer side or multi-party shared-utxo or > compressed colored coins/authentication smart contracts (e.g > opentimestamp's merkle tree in OP_RETURN) on the upper layers rather than > altering the current equilibrium. > > I think the status quo is good enough for now, and I believe we would be > better off to learn from another development cycle before tweaking the dust > limit in any sense. > > Antoine > > [0] > https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-May/002714.html > [1] https://github.com/lightningnetwork/lightning-rfc/pull/869 > > Le dim. 8 août 2021 à 14:53, Jeremy <jlrubin@mit•edu> a écrit : > >> We should remove the dust limit from Bitcoin. Five reasons: >> >> 1) it's not our business what outputs people want to create >> 2) dust outputs can be used in various authentication/delegation smart >> contracts >> 3) dust sized htlcs in lightning ( >> https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light) >> force channels to operate in a semi-trusted mode which has implications >> (AFAIU) for the regulatory classification of channels in various >> jurisdictions; agnostic treatment of fund transfers would simplify this >> (like getting a 0.01 cent dividend check in the mail) >> 4) thinly divisible colored coin protocols might make use of sats as >> value markers for transactions. >> 5) should we ever do confidential transactions we can't prevent it >> without compromising privacy / allowed transfers >> >> The main reasons I'm aware of not allow dust creation is that: >> >> 1) dust is spam >> 2) dust fingerprinting attacks >> >> 1 is (IMO) not valid given the 5 reasons above, and 2 is preventable by >> well behaved wallets to not redeem outputs that cost more in fees than they >> are worth. >> >> cheers, >> >> jeremy >> >> -- >> @JeremyRubin <https://twitter.com/JeremyRubin> >> <https://twitter.com/JeremyRubin> >> _______________________________________________ >> Lightning-dev mailing list >> Lightning-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 9496 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit 2021-08-10 0:30 ` Billy Tetrud @ 2021-08-10 5:04 ` Jeremy 2021-08-10 5:44 ` Billy Tetrud 0 siblings, 1 reply; 34+ messages in thread From: Jeremy @ 2021-08-10 5:04 UTC (permalink / raw) To: Billy Tetrud; +Cc: Bitcoin Protocol Discussion, lightning-dev [-- Attachment #1: Type: text/plain, Size: 468 bytes --] You might be interested in https://eprint.iacr.org/2017/1066.pdf which claims that you can make CT computationally hiding and binding, see section 4.6. with respect to utreexo, you might review https://github.com/mit-dci/utreexo/discussions/249?sort=new which discusses tradeoffs between different accumulator designs. With a swap tree, old things that never move more or less naturally "fall leftward", although there are reasons to prefer alternative designs. >> [-- Attachment #2: Type: text/html, Size: 1514 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit 2021-08-10 5:04 ` Jeremy @ 2021-08-10 5:44 ` Billy Tetrud 2021-08-10 11:37 ` ZmnSCPxj 0 siblings, 1 reply; 34+ messages in thread From: Billy Tetrud @ 2021-08-10 5:44 UTC (permalink / raw) To: Jeremy; +Cc: Bitcoin Protocol Discussion, lightning-dev [-- Attachment #1: Type: text/plain, Size: 1650 bytes --] For sure, CT can be done with computational soundness. The advantage of unhidden amounts (as with current bitcoin) is that you get unconditional soundness. My understanding is that there is a fundamental tradeoff between unconditional soundness and unconditional privacy. I believe Monero has taken this alternate tradeoff path with unconditional privacy but only computational soundness <https://www.reddit.com/r/Monero/comments/8erg8e/what_should_monero_do_about_the_soundness_problem/dxy59ad?utm_source=share&utm_medium=web2x&context=3> . > old things that never move more or less naturally "fall leftward" Ah yes, something like that would definitely be interesting to basically make dust a moot point. Sounds like the tradeoff mentioned is that proofs would be twice as big? Except newer UTXOs would have substantially shorter proofs. It sounds like the kind of thing where there's some point where there would be so many old UTXOs that proofs would be smaller on average in the swap tree version vs the dead-leaf version. Maybe someone smarter than me could estimate where that point is. On Mon, Aug 9, 2021 at 10:04 PM Jeremy <jlrubin@mit•edu> wrote: > You might be interested in https://eprint.iacr.org/2017/1066.pdf which > claims that you can make CT computationally hiding and binding, see section > 4.6. > > with respect to utreexo, you might review > https://github.com/mit-dci/utreexo/discussions/249?sort=new which > discusses tradeoffs between different accumulator designs. With a swap > tree, old things that never move more or less naturally "fall leftward", > although there are reasons to prefer alternative designs. > > >>> [-- Attachment #2: Type: text/html, Size: 3165 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit 2021-08-10 5:44 ` Billy Tetrud @ 2021-08-10 11:37 ` ZmnSCPxj 2021-08-10 18:39 ` Charlie Lee 0 siblings, 1 reply; 34+ messages in thread From: ZmnSCPxj @ 2021-08-10 11:37 UTC (permalink / raw) To: Billy Tetrud, Bitcoin Protocol Discussion; +Cc: lightning-dev Good morning Billy, et al., > For sure, CT can be done with computational soundness. The advantage of unhidden amounts (as with current bitcoin) is that you get unconditional soundness. My understanding is that it should be possible to have unconditional soundness with the use of El-Gamal commitment scheme, am I wrong? Alternately, one possible softforkable design would be for Bitcoin to maintain a non-CT block (the current scheme) and a separately-committed CT block (i.e. similar to how SegWit has a "separate" "block"/Merkle tree that includes witnesses). When transferring funds from the legacy non-CT block, on the legacy block you put it into a "burn" transaction that magically causes the same amount to be created (with a trivial/publicly known salt) in the CT block. Then to move from the CT block back to legacy non-CT you would match one of those "burn" TXOs and spend it, with a proof that the amount you are removing from the CT block is exactly the same value as the "burn" TXO you are now spending. (for additional privacy, the values of the "burn" TXOs might be made into some fixed single allowed value, so that transfers passing through the CT portion would have fewer identifying features) The "burn" TXOs would be some trivial anyone-can-spend, such as `<saltpoint> <0> OP_EQUAL OP_NOT` with `<saltpoint>` being what is used in the CT to cover the value, and knowledge of the scalar behind this point would allow the CT output to be spent (assuming something very much like MimbleWimble is used; otherwise it could be the hash of some P2WSH or similar analogue on the CT side). Basically, this is "CT as a 'sidechainlike' that every fullnode runs". In the legacy non-CT block, the total amount of funds that are in all CT outputs is known (it would be the sum total of all the "burn" TXOs) and will have a known upper limit, that cannot be higher than the supply limit of the legacy non-CT block, i.e. 21 million BTC. At the same time, *individual* CT-block TXOs cannot have their values known; what is learnable is only how many BTC are in all CT block TXOs, which should be sufficient privacy if there are a large enough number of users of the CT block. This allows the CT block to use an unconditional privacy and computational soundness scheme, and if somehow the computational soundness is broken then the first one to break it would be able to steal all the CT coins, but not *all* Bitcoin coins, as there would not be enough "burn" TXOs on the legacy non-CT blockchain. This may be sufficient for practical privacy. On the other hand, I think the dust limit still makes sense to keep for now, though. Regards, ZmnSCPxj ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit 2021-08-10 11:37 ` ZmnSCPxj @ 2021-08-10 18:39 ` Charlie Lee 0 siblings, 0 replies; 34+ messages in thread From: Charlie Lee @ 2021-08-10 18:39 UTC (permalink / raw) To: ZmnSCPxj, Bitcoin Protocol Discussion; +Cc: lightning-dev, Billy Tetrud [-- Attachment #1: Type: text/plain, Size: 3517 bytes --] ZmnSCPxj, what you are describing is pretty much what Litecoin is doing with MWEB. Basically MimbleWimble (which has CT) with extension blocks. If you are interested: https://github.com/litecoin-project/lips/blob/master/lip-0002.mediawiki https://github.com/litecoin-project/lips/blob/master/lip-0003.mediawiki Sorry to derail the conversation with non-Bitcoin stuff. 😀 - Charlie On Tue, Aug 10, 2021 at 5:38 AM ZmnSCPxj via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > Good morning Billy, et al., > > > For sure, CT can be done with computational soundness. The advantage of > unhidden amounts (as with current bitcoin) is that you get unconditional > soundness. > > My understanding is that it should be possible to have unconditional > soundness with the use of El-Gamal commitment scheme, am I wrong? > > Alternately, one possible softforkable design would be for Bitcoin to > maintain a non-CT block (the current scheme) and a separately-committed CT > block (i.e. similar to how SegWit has a "separate" "block"/Merkle tree that > includes witnesses). > When transferring funds from the legacy non-CT block, on the legacy block > you put it into a "burn" transaction that magically causes the same amount > to be created (with a trivial/publicly known salt) in the CT block. > Then to move from the CT block back to legacy non-CT you would match one > of those "burn" TXOs and spend it, with a proof that the amount you are > removing from the CT block is exactly the same value as the "burn" TXO you > are now spending. > > (for additional privacy, the values of the "burn" TXOs might be made into > some fixed single allowed value, so that transfers passing through the CT > portion would have fewer identifying features) > > The "burn" TXOs would be some trivial anyone-can-spend, such as > `<saltpoint> <0> OP_EQUAL OP_NOT` with `<saltpoint>` being what is used in > the CT to cover the value, and knowledge of the scalar behind this point > would allow the CT output to be spent (assuming something very much like > MimbleWimble is used; otherwise it could be the hash of some P2WSH or > similar analogue on the CT side). > > Basically, this is "CT as a 'sidechainlike' that every fullnode runs". > > In the legacy non-CT block, the total amount of funds that are in all CT > outputs is known (it would be the sum total of all the "burn" TXOs) and > will have a known upper limit, that cannot be higher than the supply limit > of the legacy non-CT block, i.e. 21 million BTC. > At the same time, *individual* CT-block TXOs cannot have their values > known; what is learnable is only how many BTC are in all CT block TXOs, > which should be sufficient privacy if there are a large enough number of > users of the CT block. > > This allows the CT block to use an unconditional privacy and computational > soundness scheme, and if somehow the computational soundness is broken then > the first one to break it would be able to steal all the CT coins, but not > *all* Bitcoin coins, as there would not be enough "burn" TXOs on the legacy > non-CT blockchain. > > This may be sufficient for practical privacy. > > > On the other hand, I think the dust limit still makes sense to keep for > now, though. > > Regards, > ZmnSCPxj > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 4466 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit 2021-08-09 13:22 ` Antoine Riard 2021-08-10 0:30 ` Billy Tetrud @ 2021-08-10 6:14 ` David A. Harding 2021-08-10 22:37 ` Antoine Riard 1 sibling, 1 reply; 34+ messages in thread From: David A. Harding @ 2021-08-10 6:14 UTC (permalink / raw) To: Antoine Riard; +Cc: Bitcoin development mailing list, lightning-dev [-- Attachment #1: Type: text/plain, Size: 2537 bytes --] On Mon, Aug 09, 2021 at 09:22:28AM -0400, Antoine Riard wrote: > I'm pretty conservative about increasing the standard dust limit in any > way. This would convert a higher percentage of LN channels capacity into > dust, which is coming with a lowering of funds safety [0]. I think that reasoning is incomplete. There are two related things here: - **Uneconomical outputs:** outputs that would cost more to spend than the value they contain. - **Dust limit:** an output amount below which Bitcoin Core (and other nodes) will not relay the transaction containing that output. Although raising the dust limit can have the effect you describe, increases in the minimum necessary feerate to get a transaction confirmed in an appropriate amount of time also "converts a higher percentage of LN channel capacity into dust". As developers, we have no control over prevailing feerates, so this is a problem LN needs to deal with regardless of Bitcoin Core's dust limit. (Related to your linked thread, that seems to be about the risk of "burning funds" by paying them to a miner who may be a party to the attack. There's plenty of other alternative ways to burn funds that can change the risk profile.) > the standard dust limit [...] introduces a trust vector My point above is that any trust vector is introduced not by the dust limit but by the economics of outputs being worth less than they cost to spend. > LN node operators might be willingly to compensate this "dust" trust vector > by relying on side-trust model They could also use trustless probabalistic payments, which have been discussed in the context of LN for handling the problem of payments too small to be represented onchain since early 2016: https://docs.google.com/presentation/d/1G4xchDGcO37DJ2lPC_XYyZIUkJc2khnLrCaZXgvDN0U/edit?pref=2&pli=1#slide=id.g85f425098_0_178 (Probabalistic payments were discussed in the general context of Bitcoin well before LN was proposed, and Elements even includes an opcode for creating them.) > smarter engineering such as utreexo on the base-layer side Utreexo doesn't solve this problem. Many nodes (such as miners) will still want to store the full UTXO set and access it quickly, Utreexo proofs will grow in size with UTXO set size (though, at best, only log(n)), so full node operators will still not want their bandwidth wasted by people who create UTXOs they have no reason to spend. > I think the status quo is good enough for now I agree. -Dave [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit 2021-08-10 6:14 ` David A. Harding @ 2021-08-10 22:37 ` Antoine Riard 2021-08-11 0:46 ` ZmnSCPxj 2021-08-12 22:03 ` Anthony Towns 0 siblings, 2 replies; 34+ messages in thread From: Antoine Riard @ 2021-08-10 22:37 UTC (permalink / raw) To: David A. Harding; +Cc: Bitcoin development mailing list, lightning-dev [-- Attachment #1: Type: text/plain, Size: 5051 bytes --] > As developers, we have no control over prevailing feerates, so this is a problem LN needs to deal with regardless of Bitcoin Core's dust limit. Right, as of today, we're going to trim-to-dust any commitment output of which the value is inferior to the transaction owner's `dust_limit_satoshis` plus the HTLC-claim (either success/timeout) fee at the agreed on feerate. So the feerate is the most significant variable in defining what's a LN *uneconomical output*. IMO this approach presents annoying limitations. First, you still need to come with an agreement among channel operators on the mempools feerate. Such agreement might be problematic to find, as on one side you would like to let your counterparty free to pick up a feerate gauged as efficient for the confirmation of their transactions but at the same time not too high to burn to fees your low-values HTLCs that *your* fee-estimator judged as sane to claim. Secondly, the trim-to-dust evaluation doesn't correctly match the lifetime of the HTLC. A HTLC might be considered as dust at block 100, at which mempools are full. Though its expiration only occurs at block 200, at which mempools are empty and this HTLC is fine to claim again. I think this inaccuracy will even become worse with a wider deployment of long-lived routed packets over LN, such as DLCs or hodl invoices. All this to say, if for those reasons LN devs remove feerate negotiation from the trim-to-dust definition to a static feerate, it would likely put a higher pressure on the full-nodes operators, as the number of uneconomical outputs might increase. (From a LN viewpoint, I would say we're trying to solve a price discovery issue, namely the cost to write on the UTXO set, in a distributed system, where any deviation from the "honest" price means you trust more your LN counterparty) > They could also use trustless probabalistic payments, which have been discussed in the context of LN for handling the problem of payments too small to be represented onchain since early 2016: https://docs.google.com/presentation/d/1G4xchDGcO37DJ2lPC_XYyZIUkJc2khnLrCaZXgvDN0U/edit?pref=2&pli=1#slide=id.g85f425098 Thanks to bringing to the surface probabilistic payments, yes that's a worthy alternative approach for low-value payments to keep in mind. Le mar. 10 août 2021 à 02:15, David A. Harding <dave@dtrt•org> a écrit : > On Mon, Aug 09, 2021 at 09:22:28AM -0400, Antoine Riard wrote: > > I'm pretty conservative about increasing the standard dust limit in any > > way. This would convert a higher percentage of LN channels capacity into > > dust, which is coming with a lowering of funds safety [0]. > > I think that reasoning is incomplete. There are two related things here: > > - **Uneconomical outputs:** outputs that would cost more to spend than > the value they contain. > > - **Dust limit:** an output amount below which Bitcoin Core (and other > nodes) will not relay the transaction containing that output. > > Although raising the dust limit can have the effect you describe, > increases in the minimum necessary feerate to get a transaction > confirmed in an appropriate amount of time also "converts a higher > percentage of LN channel capacity into dust". As developers, we have no > control over prevailing feerates, so this is a problem LN needs to deal > with regardless of Bitcoin Core's dust limit. > > (Related to your linked thread, that seems to be about the risk of > "burning funds" by paying them to a miner who may be a party to the > attack. There's plenty of other alternative ways to burn funds that can > change the risk profile.) > > > the standard dust limit [...] introduces a trust vector > > My point above is that any trust vector is introduced not by the dust > limit but by the economics of outputs being worth less than they cost to > spend. > > > LN node operators might be willingly to compensate this "dust" trust > vector > > by relying on side-trust model > > They could also use trustless probabalistic payments, which have been > discussed in the context of LN for handling the problem of payments too > small to be represented onchain since early 2016: > > https://docs.google.com/presentation/d/1G4xchDGcO37DJ2lPC_XYyZIUkJc2khnLrCaZXgvDN0U/edit?pref=2&pli=1#slide=id.g85f425098_0_178 > > (Probabalistic payments were discussed in the general context of Bitcoin > well before LN was proposed, and Elements even includes an opcode for > creating them.) > > > smarter engineering such as utreexo on the base-layer side > > Utreexo doesn't solve this problem. Many nodes (such as miners) will > still want to store the full UTXO set and access it quickly, Utreexo > proofs will grow in size with UTXO set size (though, at best, only > log(n)), so full node operators will still not want their bandwidth > wasted by people who create UTXOs they have no reason to spend. > > > I think the status quo is good enough for now > > I agree. > > -Dave > [-- Attachment #2: Type: text/html, Size: 5914 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit 2021-08-10 22:37 ` Antoine Riard @ 2021-08-11 0:46 ` ZmnSCPxj 2021-08-12 22:03 ` Anthony Towns 1 sibling, 0 replies; 34+ messages in thread From: ZmnSCPxj @ 2021-08-11 0:46 UTC (permalink / raw) To: Antoine Riard, Bitcoin Protocol Discussion; +Cc: lightning-dev Good morning all, Thinking a little more, if the dust limit is intended to help keep UTXO sets down, then on the LN side, this could be achieved as well by using channel factories (including "one-shot" factories which do not allow changing the topology of the subgraph inside the factory, but have the advantage of not requiring either `SIGHASH_NOINPUT` or an extra CSV constraint that is difficult to weigh in routing algorithms), where multiple channels are backed by a single UTXO. Of course, with channel factories there is now a greater set of participants who will have differing opinions on appropriate feerate. So I suppose one can argue that the dust limit becomes less material to higher layers, than actual onchain feerates. Regards, ZmnSCPxj ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit 2021-08-10 22:37 ` Antoine Riard 2021-08-11 0:46 ` ZmnSCPxj @ 2021-08-12 22:03 ` Anthony Towns 2021-08-20 4:51 ` Jeremy 1 sibling, 1 reply; 34+ messages in thread From: Anthony Towns @ 2021-08-12 22:03 UTC (permalink / raw) To: Antoine Riard, Bitcoin Protocol Discussion; +Cc: lightning-dev On Tue, Aug 10, 2021 at 06:37:48PM -0400, Antoine Riard via bitcoin-dev wrote: > Secondly, the trim-to-dust evaluation doesn't correctly match the lifetime of > the HTLC. Right: but that just means it's not something you should determine once for the HTLC, but something you should determine each time you update the channel commitment -- if fee rates are at 1sat/vb, then a 10,000 sat HTLC that's going to cost 100 sats to create the utxo and eventually claim it might be worth committing to, but if fee rates suddenly rise to 75sat/vb, then the combined cost of 7500 sat probably isn't worthwhile (and it certainly isn't worthwhile if fees rise to above 100sat/vb). That's independent of dust limits -- those only give you a fixed size lower limit or about 305sats for p2wsh outputs. Things become irrational before they become uneconomic as well: ie the 100vb is perhaps 40vb to create then 60vb to spend, so if you create the utxo anyway then the 40vb is a sunk cost, and redeeming the 10k sats might still be marginally wortwhile up until about 167sat/vb fee rate. But note the logic there: it's an uneconomic output if fees rise above 167sat/vb, but it was already economically irrational for the two parties to create it in the first place when fees were at or above 100sat/vb. If you're trying to save every sat, dust limits aren't your problem. If you're not trying to save every sat, then just add 305 sats to your output so you avoid the dust limit. (And the dust limit is only preventing you from creating outputs that would be irrational if they only required a pubkey reveal and signature to spend -- so a HTLC that requires revealing a script, two hashes, two pubkeys, a hash preimage and two signatures with the same dust threshold value for p2wsh of ~305sats would already be irrational at about 2.1sat/vb and unconomic at 2.75 sat/vb). > (From a LN viewpoint, I would say we're trying to solve a price discovery > issue, namely the cost to write on the UTXO set, in a distributed system, where > any deviation from the "honest" price means you trust more your LN > counterparty) At these amounts you're already trusting your LN counterparty to not just close the channel unilaterally at a high fee rate time and waste your funds in fees, vs doing a much for efficient mutual/cooperative close. Cheers, aj ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit 2021-08-12 22:03 ` Anthony Towns @ 2021-08-20 4:51 ` Jeremy 2021-08-20 5:45 ` shymaa arafat 2021-08-21 3:10 ` ZmnSCPxj 0 siblings, 2 replies; 34+ messages in thread From: Jeremy @ 2021-08-20 4:51 UTC (permalink / raw) To: Bitcoin Protocol Discussion; +Cc: lightning-dev [-- Attachment #1: Type: text/plain, Size: 1287 bytes --] one interesting point that came up at the bitdevs in austin today that favors remove that i believe is new to this discussion (it was new to me): the argument can be reduced to: - dust limit is a per-node relay policy. - it is rational for miners to mine dust outputs given their cost of maintenance (storing the output potentially forever) is lower than their immediate reward in fees. - if txn relaying nodes censor something that a miner would mine, users will seek a private/direct relay to the miner and vice versa. - if direct relay to miner becomes popular, it is both bad for privacy and decentralization. - therefore the dust limit, should there be demand to create dust at prevailing mempool feerates, causes an incentive to increase network centralization (immediately) the tradeoff is if a short term immediate incentive to promote network centralization is better or worse than a long term node operator overhead. /////////////////// my take is that: 1) having a dust limit is worse since we'd rather not have an incentive to produce or roll out centralizing software, whereas not having a dust limit creates an mild incentive for node operators to improve utreexo decentralizing software. 2) it's hard to quantify the magnitude of the incentives, which does matter. [-- Attachment #2: Type: text/html, Size: 3477 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit 2021-08-20 4:51 ` Jeremy @ 2021-08-20 5:45 ` shymaa arafat 2021-08-21 3:10 ` ZmnSCPxj 1 sibling, 0 replies; 34+ messages in thread From: shymaa arafat @ 2021-08-20 5:45 UTC (permalink / raw) To: Jeremy, Bitcoin Protocol Discussion; +Cc: lightning-dev [-- Attachment #1: Type: text/plain, Size: 2211 bytes --] On Fri, Aug 20, 2021, 06:52 Jeremy via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > one interesting point that came up at the bitdevs in austin today that > favors remove that i believe is new to this discussion (it was new to me): > > the argument can be reduced to: > > - dust limit is a per-node relay policy. > - it is rational for miners to mine dust outputs given their cost of > maintenance (storing the output potentially forever) is lower than their > immediate reward in fees. > -Here, u r assuming miners not running full nodes, or even stateless nodes as in Utreexo -otherwise they suffer from storing dust UTXOS/their effect on proof length, right? - if txn relaying nodes censor something that a miner would mine, users > will seek a private/direct relay to the miner and vice versa. > - if direct relay to miner becomes popular, it is both bad for privacy and > decentralization. > - therefore the dust limit, should there be demand to create dust at > prevailing mempool feerates, causes an incentive to increase network > centralization (immediately) > > the tradeoff is if a short term immediate incentive to promote network > centralization is better or worse than a long term node operator overhead. > > > /////////////////// > > my take is that: > > 1) having a dust limit is worse since we'd rather not have an incentive to > produce or roll out centralizing software, whereas not having a dust limit > creates an mild incentive for node operators to improve utreexo > decentralizing software. > Why not having dust limit improves Utreexo, I think (and tried to suggest many times) separate storing of dust&other non spendable UTXOS (and their hashes) so that they do not affect other UTXOS proofs ( and not brought into main memory unless called as a TXO) 2) it's hard to quantify the magnitude of the incentives, which does matter. > I honestly don't get the long term perspective of miners Incentivised to storing small dust UTXOS instead of having their values added to the fee. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 5552 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit 2021-08-20 4:51 ` Jeremy 2021-08-20 5:45 ` shymaa arafat @ 2021-08-21 3:10 ` ZmnSCPxj 2021-08-26 21:21 ` Billy Tetrud 1 sibling, 1 reply; 34+ messages in thread From: ZmnSCPxj @ 2021-08-21 3:10 UTC (permalink / raw) To: Jeremy; +Cc: Bitcoin Protocol Discussion, lightning-dev Good morning Jeremy, > one interesting point that came up at the bitdevs in austin today that favors remove that i believe is new to this discussion (it was new to me): > > the argument can be reduced to: > > - dust limit is a per-node relay policy. > - it is rational for miners to mine dust outputs given their cost of maintenance (storing the output potentially forever) is lower than their immediate reward in fees. > - if txn relaying nodes censor something that a miner would mine, users will seek a private/direct relay to the miner and vice versa. > - if direct relay to miner becomes popular, it is both bad for privacy and decentralization. > - therefore the dust limit, should there be demand to create dust at prevailing mempool feerates, causes an incentive to increase network centralization (immediately) > > the tradeoff is if a short term immediate incentive to promote network centralization is better or worse than a long term node operator overhead. Against the above, we should note that in the Lightning spec, when an output *would have been* created that is less than the dust limit, the output is instead put into fees. https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#trimmed-outputs Thus, the existence of a dust limit encourages L2 protocols to have similar rules, where outputs below the dust limit are just given over as fees to miners, so the existence of a dust limit might very well be incentivize-compatible for miners, regardless of centralization effects or not. Regards, ZmnSCPxj ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit 2021-08-21 3:10 ` ZmnSCPxj @ 2021-08-26 21:21 ` Billy Tetrud 2021-08-27 9:07 ` shymaa arafat 0 siblings, 1 reply; 34+ messages in thread From: Billy Tetrud @ 2021-08-26 21:21 UTC (permalink / raw) To: ZmnSCPxj, Bitcoin Protocol Discussion; +Cc: lightning-dev [-- Attachment #1: Type: text/plain, Size: 2696 bytes --] One interesting thing I thought of: the cost of maintenance of the dust creates a (very) small incentive to mine transactions that *use* dust outputs with a slightly lower fee that contain dust, in order to reduce the future maintenance cost for themselves. However, the rational discount would likely be vanishingly small. It would be interesting to add something to the consensus rules to decrease the vbytes for a transaction that consumes dust outputs such that the value of removing them from the system (saving the future cost of maintenance) is approximately equal to the amount that the fee could be made lower for such transactions. Even measuring this as a value over the whole (future) bitcoin network, I'm not sure how to evaluate the magnitude of this future cost. On Fri, Aug 20, 2021 at 8:12 PM ZmnSCPxj via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > Good morning Jeremy, > > > one interesting point that came up at the bitdevs in austin today that > favors remove that i believe is new to this discussion (it was new to me): > > > > the argument can be reduced to: > > > > - dust limit is a per-node relay policy. > > - it is rational for miners to mine dust outputs given their cost of > maintenance (storing the output potentially forever) is lower than their > immediate reward in fees. > > - if txn relaying nodes censor something that a miner would mine, users > will seek a private/direct relay to the miner and vice versa. > > - if direct relay to miner becomes popular, it is both bad for privacy > and decentralization. > > - therefore the dust limit, should there be demand to create dust at > prevailing mempool feerates, causes an incentive to increase network > centralization (immediately) > > > > the tradeoff is if a short term immediate incentive to promote network > centralization is better or worse than a long term node operator overhead. > > Against the above, we should note that in the Lightning spec, when an > output *would have been* created that is less than the dust limit, the > output is instead put into fees. > > https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#trimmed-outputs > > Thus, the existence of a dust limit encourages L2 protocols to have > similar rules, where outputs below the dust limit are just given over as > fees to miners, so the existence of a dust limit might very well be > incentivize-compatible for miners, regardless of centralization effects or > not. > > > Regards, > ZmnSCPxj > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 3886 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit 2021-08-26 21:21 ` Billy Tetrud @ 2021-08-27 9:07 ` shymaa arafat 2021-08-30 3:31 ` LORD HIS EXCELLENCY JAMES HRMH 0 siblings, 1 reply; 34+ messages in thread From: shymaa arafat @ 2021-08-27 9:07 UTC (permalink / raw) To: Billy Tetrud, Bitcoin Protocol Discussion; +Cc: lightning-dev [-- Attachment #1: Type: text/plain, Size: 4404 bytes --] Allow me to ask: -Untill you find a mitigation that consolidate all dust UTXOS, why don't you separate them and all probably Unspendable UTXOS in a different partition? -I'm talking at the real UTXO storage level (to be kept in secondary storage), and at the Merkleization level in any accumulator design Utreexo or what so ever(putting them in one or two subtree/forest with hardly changing roots according to the categorization will reduce the proof size, even if slightly) -This will also help things like Bloom filters, assume UTXOs,...etc when about 10% with almost zero probability are trimmed from the pool you are withdrawing from. . -The paper I mentioned earlier says in Feb 2018, there was about 2.4m UTXOS less than 1000 Satoshi, of which ~824,892 holds exactly 1 Satoshi -I don't think any of those were spent since that time, in fact there could be a possibility that the numbers may have increased -As the last previous reply mentioned you have to consider the long run effect on the UTXO set forever, this is a straight forward improvement that comes with almost no effort . Ps. -If there is something wrong, something I missed in this idea please explain it to me -Or do you find the improvement itself a "dust" that doesn't worth the effort??? . Regards & thank you all for your time in reading & replying Shymaa M. Arafat On Fri, Aug 27, 2021, 00:06 Billy Tetrud via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > > One interesting thing I thought of: the cost of maintenance of the dust > creates a (very) small incentive to mine transactions that *use* dust > outputs with a slightly lower fee that contain dust, in order to reduce the > future maintenance cost for themselves. However, the rational discount > would likely be vanishingly small. It would be interesting to add > something to the consensus rules to decrease the vbytes for a transaction > that consumes dust outputs such that the value of removing them from the > system (saving the future cost of maintenance) is approximately equal to > the amount that the fee could be made lower for such transactions. Even > measuring this as a value over the whole (future) bitcoin network, I'm not > sure how to evaluate the magnitude of this future cost. > > > > > > On Fri, Aug 20, 2021 at 8:12 PM ZmnSCPxj via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > >> Good morning Jeremy, >> >> > one interesting point that came up at the bitdevs in austin today that >> favors remove that i believe is new to this discussion (it was new to me): >> > >> > the argument can be reduced to: >> > >> > - dust limit is a per-node relay policy. >> > - it is rational for miners to mine dust outputs given their cost of >> maintenance (storing the output potentially forever) is lower than their >> immediate reward in fees. >> > - if txn relaying nodes censor something that a miner would mine, users >> will seek a private/direct relay to the miner and vice versa. >> > - if direct relay to miner becomes popular, it is both bad for privacy >> and decentralization. >> > - therefore the dust limit, should there be demand to create dust at >> prevailing mempool feerates, causes an incentive to increase network >> centralization (immediately) >> > >> > the tradeoff is if a short term immediate incentive to promote network >> centralization is better or worse than a long term node operator overhead. >> >> Against the above, we should note that in the Lightning spec, when an >> output *would have been* created that is less than the dust limit, the >> output is instead put into fees. >> >> https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#trimmed-outputs >> >> Thus, the existence of a dust limit encourages L2 protocols to have >> similar rules, where outputs below the dust limit are just given over as >> fees to miners, so the existence of a dust limit might very well be >> incentivize-compatible for miners, regardless of centralization effects or >> not. >> >> >> Regards, >> ZmnSCPxj >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 6694 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit 2021-08-27 9:07 ` shymaa arafat @ 2021-08-30 3:31 ` LORD HIS EXCELLENCY JAMES HRMH 0 siblings, 0 replies; 34+ messages in thread From: LORD HIS EXCELLENCY JAMES HRMH @ 2021-08-30 3:31 UTC (permalink / raw) To: Billy Tetrud, Bitcoin Protocol Discussion, shymaa arafat; +Cc: lightning-dev [-- Attachment #1: Type: text/plain, Size: 6411 bytes --] Good Afternoon, It is worth reconsidering the value accumulated in dust. Speculatively, when the value of 1 BTC reaches US$ 1,000,000.00 then the value of one satoshi will be US$ 0.01 so, for 1 satoshi to be of any substantial value the value of Bitcoin will have to rise substantially higher. I ask what then should the value of fees be? Is there not a future case foreseeable at least in consideration of Bitcoin's comparison with Gold that the value may be so high as to allow that 1 satoshi may cover the mining cost of any transaction despite the reduction in sat/B for including the additional transaction. Is it not that we can foresee the dust has value and that the wealthy may have in fact millions of dust transactions that are inheritable, though I hesitate to make my business collecting them I may set up a website. The current reason for excluding dust is because it costs more to the transaction to add the dust than its value but that does not say that will always be the case. KING JAMES HRMH Great British Empire Regards, The Australian LORD HIS EXCELLENCY JAMES HRMH (& HMRH) of Hougun Manor & Glencoe & British Empire MR. Damian A. James Williamson Wills et al. Willtech www.willtech.com.au www.go-overt.com and other projects earn.com/willtech linkedin.com/in/damianwilliamson m. 0487135719 f. +61261470192 This email does not constitute a general advice. Please disregard this email if misdelivered. ---- ________________________________ From: bitcoin-dev <bitcoin-dev-bounces@lists•linuxfoundation.org> on behalf of shymaa arafat via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> Sent: Friday, 27 August 2021 7:07 PM To: Billy Tetrud <billy.tetrud@gmail•com>; Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org> Cc: lightning-dev <lightning-dev@lists•linuxfoundation.org> Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit Allow me to ask: -Untill you find a mitigation that consolidate all dust UTXOS, why don't you separate them and all probably Unspendable UTXOS in a different partition? -I'm talking at the real UTXO storage level (to be kept in secondary storage), and at the Merkleization level in any accumulator design Utreexo or what so ever(putting them in one or two subtree/forest with hardly changing roots according to the categorization will reduce the proof size, even if slightly) -This will also help things like Bloom filters, assume UTXOs,...etc when about 10% with almost zero probability are trimmed from the pool you are withdrawing from. . -The paper I mentioned earlier says in Feb 2018, there was about 2.4m UTXOS less than 1000 Satoshi, of which ~824,892 holds exactly 1 Satoshi -I don't think any of those were spent since that time, in fact there could be a possibility that the numbers may have increased -As the last previous reply mentioned you have to consider the long run effect on the UTXO set forever, this is a straight forward improvement that comes with almost no effort . Ps. -If there is something wrong, something I missed in this idea please explain it to me -Or do you find the improvement itself a "dust" that doesn't worth the effort??? . Regards & thank you all for your time in reading & replying Shymaa M. Arafat On Fri, Aug 27, 2021, 00:06 Billy Tetrud via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote: One interesting thing I thought of: the cost of maintenance of the dust creates a (very) small incentive to mine transactions that *use* dust outputs with a slightly lower fee that contain dust, in order to reduce the future maintenance cost for themselves. However, the rational discount would likely be vanishingly small. It would be interesting to add something to the consensus rules to decrease the vbytes for a transaction that consumes dust outputs such that the value of removing them from the system (saving the future cost of maintenance) is approximately equal to the amount that the fee could be made lower for such transactions. Even measuring this as a value over the whole (future) bitcoin network, I'm not sure how to evaluate the magnitude of this future cost. On Fri, Aug 20, 2021 at 8:12 PM ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote: Good morning Jeremy, > one interesting point that came up at the bitdevs in austin today that favors remove that i believe is new to this discussion (it was new to me): > > the argument can be reduced to: > > - dust limit is a per-node relay policy. > - it is rational for miners to mine dust outputs given their cost of maintenance (storing the output potentially forever) is lower than their immediate reward in fees. > - if txn relaying nodes censor something that a miner would mine, users will seek a private/direct relay to the miner and vice versa. > - if direct relay to miner becomes popular, it is both bad for privacy and decentralization. > - therefore the dust limit, should there be demand to create dust at prevailing mempool feerates, causes an incentive to increase network centralization (immediately) > > the tradeoff is if a short term immediate incentive to promote network centralization is better or worse than a long term node operator overhead. Against the above, we should note that in the Lightning spec, when an output *would have been* created that is less than the dust limit, the output is instead put into fees. https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#trimmed-outputs Thus, the existence of a dust limit encourages L2 protocols to have similar rules, where outputs below the dust limit are just given over as fees to miners, so the existence of a dust limit might very well be incentivize-compatible for miners, regardless of centralization effects or not. Regards, ZmnSCPxj _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists•linuxfoundation.org> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists•linuxfoundation.org> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 10518 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit @ 2021-08-18 19:06 shymaa arafat 0 siblings, 0 replies; 34+ messages in thread From: shymaa arafat @ 2021-08-18 19:06 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1690 bytes --] Dear Sir, I'm not discussing the dust limit here, but I'm suggesting some mitigations to the dust problem which tackles almost the same points mentioned here especially the scalability of the UTXOS set and the corresponding Merkle proofs/witnesses in Utreexo or any similar design .... . I suggest: 1-Dust UTXOS, along with burned & non-standard UTXOS, to be stored separately in secondary storage; their Hashes in a separate Merkle too in any accumulator design (an earlier draft of the idea https://bitcointalk.org/index.php?topic=5343748.new#new) . -In fact, the idea of separating the real UTXO values was first suggested in https://royalsocietypublishing.org/doi/10.1098/rsos.180817 In their words "Similarly, one can think of a two-tier data structure where a UTXO subset containing UTXOs with a low probability of being selected such as dust is kept on disk, while the other UTXOs are kept in memory." . 2-I suggest also that existing dust UTXOS (from the same paper, in some cases a UTXO could be added as an extra input with the cost of 68*fee/byte) , to be selected with large UTXO whenever they fit in a spending ( use one large & one small to get rid of the small) . 3-In general when user is not willing to leave the dust to the fee, and if there's no dust UTXOS, do not let the coin selection algorithm select the closest match; let it choose the smallest that doesn't create dust. For example if there's UTXOS 0.00013 & 0.00012 and user want to spend 0.0001198 choose 0.00013 so that the change is not dust (with same cost). . Thank you for your time, This is the first time I send a suggestion to your emailing list, so sorry if I missed any regulations . Shymaa M. Arafat [-- Attachment #2: Type: text/html, Size: 2501 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2021-10-08 22:47 UTC | newest]
Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-08 18:52 [bitcoin-dev] Removing the Dust Limit Jeremy
2021-08-08 21:14 ` Matt Corallo
2021-08-08 21:41 ` Oleg Andreev
2021-08-08 21:51 ` [bitcoin-dev] [Lightning-dev] " David A. Harding
2021-08-08 22:46 ` Jeremy
2021-08-08 23:07 ` Jeremy
2021-09-30 22:07 ` Pieter Wuille
2021-10-01 13:40 ` Erik Aronesty
2021-10-07 4:52 ` ZmnSCPxj
2021-10-07 8:17 ` LORD HIS EXCELLENCY JAMES HRMH
2021-10-07 8:34 ` LORD HIS EXCELLENCY JAMES HRMH
2021-10-07 10:35 ` LORD HIS EXCELLENCY JAMES HRMH
2021-10-07 9:13 ` shymaa arafat
2021-10-07 10:01 ` ZmnSCPxj
[not found] ` <CAM98U8kKud-7QoJKYd5o245o8vGeUD7YD2OnXF_QeKaO33dSTw@mail.gmail.com>
[not found] ` <MCYvJzqskIC56X-ylVCNgdaVk6SNnpCE6GgssXxK-znwwK4MoA41a2A-yNuCG8s99ll3h__YjCjBlP99A27Clbip-aYbF2ZwLpZ0SJT0j2U=@protonmail.com>
2021-10-08 7:44 ` shymaa arafat
2021-10-08 10:38 ` ZmnSCPxj
2021-10-08 22:47 ` ZmnSCPxj
2021-08-09 13:22 ` Antoine Riard
2021-08-10 0:30 ` Billy Tetrud
2021-08-10 5:04 ` Jeremy
2021-08-10 5:44 ` Billy Tetrud
2021-08-10 11:37 ` ZmnSCPxj
2021-08-10 18:39 ` Charlie Lee
2021-08-10 6:14 ` David A. Harding
2021-08-10 22:37 ` Antoine Riard
2021-08-11 0:46 ` ZmnSCPxj
2021-08-12 22:03 ` Anthony Towns
2021-08-20 4:51 ` Jeremy
2021-08-20 5:45 ` shymaa arafat
2021-08-21 3:10 ` ZmnSCPxj
2021-08-26 21:21 ` Billy Tetrud
2021-08-27 9:07 ` shymaa arafat
2021-08-30 3:31 ` LORD HIS EXCELLENCY JAMES HRMH
2021-08-18 19:06 shymaa arafat
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox