* [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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ messages in thread
* Re: [bitcoin-dev] Removing the Dust Limit
@ 2021-08-09 10:25 Prayank
2021-08-09 11:58 ` Karl
0 siblings, 1 reply; 36+ messages in thread
From: Prayank @ 2021-08-09 10:25 UTC (permalink / raw)
To: lf-lists; +Cc: Bitcoin Dev, lightning-dev
[-- Attachment #1: Type: text/plain, Size: 856 bytes --]
> 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.
I have no opinion on changing or removing dust limit. However, fee rates are not going up. Yes, we expect them to go up and miners revenue from fees as well. Although, fees/day (in terms of BTC) has been decreasing in each cycle. Fee rates have been ranging between 1 sat/vByte to 200-300 sat/vByte, regularly reset to 1-5 sat/vByte and very low since long time now except when hash rate went down.
Fees per MB since 2016: https://i.imgur.com/XEkkf99.png
Highest in this cycle on April 19 2021: 2.5 BTC
Highest in previous cycle on December 18 2017: 10 BTC
It stays low all the time except few days in each cycle.
--
Prayank
A3B1 E430 2298 178F
[-- Attachment #2: Type: text/html, Size: 3711 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [bitcoin-dev] Removing the Dust Limit
@ 2022-03-12 13:02 vjudeu
0 siblings, 0 replies; 36+ messages in thread
From: vjudeu @ 2022-03-12 13:02 UTC (permalink / raw)
To: Jeremy, lightning-dev, Bitcoin development mailing list
> We should remove the dust limit from Bitcoin.
Any node operator can do that. Just put "dustrelayfee=0.00000000" in your bitcoin.conf.
And there is more: you can also conditionally allow free transactions:
mintxfee=0.00000001
minrelaytxfee=0.00000000
blockmintxfee=0.00000000
Then, when using getblocktemplate you will get transactions with the highest fees first anyway, and you include cheap or free transactions in the end, if there will be enough room for them.
So, all of those settings are in the hands of node operators, there is no need to change the source code, all you need is to convince nodes to change their settings.
On 2021-08-08 20:53:28 user Jeremy via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
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
^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2022-03-12 13:02 UTC | newest]
Thread overview: 36+ 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-09 10:25 [bitcoin-dev] " Prayank
2021-08-09 11:58 ` Karl
2022-03-12 13:02 vjudeu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox