Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[vjudeu]

> We should remove the dust limit from Bitcoin.

Any node operator can do that. Just put "dustrelayfee=0." in your 
bitcoin.conf.

And there is more: you can also conditionally allow free transactions:

mintxfee=0.0001
minrelaytxfee=0.
blockmintxfee=0.

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


___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[ZmnSCPxj via 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

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[LORD HIS EXCELLENCY JAMES HRMH]

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 
Sent: Thursday, 7 October 2021 7:34 PM
To: Erik Aronesty ; ZmnSCPxj ; Bitcoin 
Protocol Discussion 
Cc: lightning-dev 
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 
Sent: Thursday, 7 October 2021 7:17 PM
To: Erik Aronesty ; ZmnSCPxj ; Bitcoin 
Protocol Discussion 
Cc: lightning-dev 
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.


_

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[LORD HIS EXCELLENCY JAMES HRMH]

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 
Sent: Thursday, 7 October 2021 7:17 PM
To: Erik Aronesty ; ZmnSCPxj ; Bitcoin 
Protocol Discussion 
Cc: lightning-dev 
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.


___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[LORD HIS EXCELLENCY JAMES HRMH]

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.


___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[ZmnSCPxj via 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
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[Pieter Wuille]

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

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[Erik Aronesty]

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
 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 
>  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-...@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[LORD HIS EXCELLENCY JAMES HRMH]

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  on behalf of 
shymaa arafat via bitcoin-dev 
Sent: Friday, 27 August 2021 7:07 PM
To: Billy Tetrud ; Bitcoin Protocol Discussion 

Cc: lightning-dev 
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 
mailto:bitcoin-...@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 
mailto:bitcoin-...@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 

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[shymaa arafat]

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-...@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-...@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-...@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> ___
> bitcoin-dev mailing list
> bitcoin-...@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[Billy Tetrud]

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-...@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-...@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[ZmnSCPxj via 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
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[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.


///

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.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[Anthony Towns]

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

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[Billy Tetrud]

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

.

> 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  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.
>
>
>>>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[Charlie Lee]

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-...@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
> ` <0> OP_EQUAL OP_NOT` with `` 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-...@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[Billy Tetrud]

> 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-...@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  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 

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[Karl]

Why would removing the dust limit impact decentralisation of mining if
miners can reconfigure the dust limit for their mined blocks?
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[Prayank via Lightning-dev]

> 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

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[Oleg Andreev]

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 
>  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
>>  
>> )
>>  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-...@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[ZmnSCPxj via 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
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[ZmnSCPxj via 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 ` 
<0> OP_EQUAL OP_NOT` with `` 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
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[Jeremy]

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.


>>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[Matt Corallo]

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 
) 
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.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev