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

[LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev]

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: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit

[LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev]

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.


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

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

[LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev]

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.


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

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

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

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

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

[ZmnSCPxj via bitcoin-dev]

Good morning shymaa,

> The suggested idea I was replying to is to make all dust TXs invalid by some 
> nodes.

Is this supposed to be consensus change or not?
Why "some" nodes and not all?

I think the important bit is for full nodes.
Non-full-nodes already work at reduced security; what is important is the 
security-efficiency tradeoff.

> I suggested a compromise by keeping them in secondary storage for full nodes, 
> and in a separate Merkle Tree for bridge servers.
> -In bridge servers they won't increase any worstcase, on the contrary this 
> will enhance the performance even if slightly.
> -In full nodes, and since they will usually appear in clusters, they will be 
> fetched rarely (either by a dust sweeping action, or a malicious attacker)
> In both cases as a batch
> -To not exhaust the node with DoS(as the reply mentioned)one may think of 
> uploading the whole dust partition if they were called more than certain 
> threshold (say more than 1 Tx in a block)  
> -and then keep them there for "a while", but as a separate partition too to 
> exclude them from any caching mechanism after that block.
> -The "while" could be a tuned parameter.

Assuming you meant "dust tx is considered invalid by all nodes".

* Block has no dust sweep
  * With dust rejected: only non-dust outputs are accessed.
  * With dust in secondary storage: only non-dust outputs are accessed.
* Block has some dust sweeps
  * With dust rejected: only non-dust outputs are accessed, block is rejected.
  * With dust in secondary storage: some data is loaded from secondary storage.
* Block is composed of only dust sweeps
  * With dust rejected: only non-dust outputs are accessed, block is rejected.
  * With dust in secondary storage: significant increase in processing to load 
large secondary storage in memory,

So I fail to see how the proposal ever reduces processing compared to the idea 
of just outright making all dust txs invalid and rejecting the block.
Perhaps you are trying to explain some other mechanism than what I understood?

It is helpful to think in terms always of worst-case behavior when considering 
resistance against attacks.

> -Take care that the more dust is sweeped, the less dust to remain in the UTXO 
> set; as users are already much dis-incentivised to create more.

But creation of dust is also as easy as sweeping them, and nothing really 
prevents a block from *both* creating *and* sweeping dust, e.g. a block 
composed of 1-input-1-output transactions, unless you want to describe some 
kind of restriction here?

Such a degenerate block would hit your secondary storage double: one to read, 
and one to overwrite and add new entries; if the storage is large then the 
index structure you use also is large and updates can be expensive there as 
well.


Again, I am looking solely at fullnode efficiency here, meaning all rules 
validated and all transactions validated, not validating and simply accepting 
some transactions as valid is a degradation of security from full validation to 
SPV validation.
Now of course in practice modern Bitcoin is hard to attack with *only* mining 
hashpower as there are so many fullnodes that an SPV node would be easily able 
to find the "True" history of the chain.
However, as I understand it that proporty of fullnodes protecting against 
attacks on SPV nodes only exists due to fullnodes being cheap to keep online; 
if the cost of fullnodes in the **worst case** (***not*** average, please stop 
talking about average case) increases then it may become feasible for miners to 
attack SPV nodes.

Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[shymaa arafat via bitcoin-dev]

The suggested idea I was replying to is to make all dust TXs invalid by
some nodes. I suggested a compromise by keeping them in secondary storage
for full nodes, and in a separate Merkle Tree for bridge servers.
-In bridge servers they won't increase any worstcase, on the contrary this
will enhance the performance even if slightly.
-In full nodes, and since they will usually appear in clusters, they will
be fetched rarely (either by a dust sweeping action, or a malicious
attacker)
In both cases as a batch
-To not exhaust the node with DoS(as the reply mentioned)one may think of
uploading the whole dust partition if they were called more than certain
threshold (say more than 1 Tx in a block)
-and then keep them there for "a while", but as a separate partition too to
exclude them from any caching mechanism after that block.
-The "while" could be a tuned parameter.
-Take care that the more dust is sweeped, the less dust to remain in the
UTXO set; as users are already much dis-incentivised to create more.
.
Thanks for allowing the reply

On Thu, Oct 7, 2021, 16:43 ZmnSCPxj  wrote:

>
>
> > I don't know what brings up sorting here, unless as an example.
>
> Yes, it is an example: quicksort is bad for network-facing applications
> because its ***worst-case behavior*** is bad.
> Bitcoin is a network-facing application, and similarly, ***worst-case
> behavior*** being bad is something that would strongly discourage
> particular approaches.
> Your proposal risks bad ***worst-case behavior***.
>
> > Anyways, I was comparing to rejecting them completely, not to keeping
> them in one set. In addition, those dust sweep Transactions will probably
> be a dust sweep and thus contain so many inputs which "maybe" makes 1-one
> disk visit  to fetch all their hashes at once, 2-from a smaller subset with
> max size 5-10% the UTXO set, justifiable.
>
> Do not consider the ***average case*** where a block is composed of only a
> few dust sweep transactions and most transactions are normal,
> non-dust-sweep transactions.
>
> Instead, consider the ***worst case*** where ***all*** transactions in a
> block are dust sweep transactions, because that is what attackers will use.
>
> Regards,
> ZmnSCPxj
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[shymaa arafat via bitcoin-dev]

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

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

[ZmnSCPxj via bitcoin-dev]

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

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

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

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

[Erik Aronesty via bitcoin-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
 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-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

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

[Pieter Wuille via bitcoin-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 
 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

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

[LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev]

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

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

[shymaa arafat via bitcoin-dev]

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

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

[Billy Tetrud via bitcoin-dev]

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

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

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

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

[shymaa arafat via bitcoin-dev]

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

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

[Jeremy via bitcoin-dev]

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

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

[shymaa arafat via bitcoin-dev]

Dear Sir,

I'm not discussing the dust limit here, but I'm suggesting some mitigations
to the dust problem which tackles almost the same points mentioned here
especially the scalability of the UTXOS set and the corresponding Merkle
proofs/witnesses in Utreexo or any similar design 
.
I suggest:
1-Dust UTXOS, along with burned & non-standard UTXOS, to be stored
separately in secondary storage; their Hashes in a separate Merkle too in
any accumulator design
(an earlier draft of the idea
https://bitcointalk.org/index.php?topic=5343748.new#new)
.
-In fact, the idea of separating the real UTXO values was first suggested in
https://royalsocietypublishing.org/doi/10.1098/rsos.180817
In their words
"Similarly, one can think of a two-tier data structure where a UTXO subset
containing UTXOs with a low probability of being selected such as dust is
kept on disk, while the other UTXOs are kept in memory."
.
2-I suggest also that existing dust UTXOS (from the same paper, in some
cases a UTXO could be added as an extra input with the cost of 68*fee/byte)
, to be selected with large UTXO whenever they fit in a spending ( use one
large & one small to get rid of the small)
.
3-In general when user is not willing to leave the dust to the fee, and if
there's no dust UTXOS, do not let the coin selection algorithm select the
closest match; let it choose the smallest that doesn't create dust.
For example if there's UTXOS 0.00013 & 0.00012 and user want to spend
0.0001198 choose 0.00013 so that the change is not dust (with same cost).
.
Thank you for your time,
This is the first time I send a suggestion to your emailing list, so sorry
if I missed any regulations
.
Shymaa M. Arafat
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Anthony Towns via bitcoin-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

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

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

[John Tromp via bitcoin-dev]

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

This is pretty much the Mimble Wimble Extension Block (MWEB) design
for Litecoin, as described at
https://vaultoro.com/what-is-mweb-on-litecoin/

True to the Harry Potter background theme of Mimblewimble, the regular
Litecoin transaction responsible for pegging into and out of the
extension block is call the Hogwarts Express (hogex).

If all goes well, it may activate as early as the end of this year...

regards,
-John
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Charlie Lee via bitcoin-dev]

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

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

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

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

[Antoine Riard via bitcoin-dev]

>  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=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  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=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
>
___
bitcoin-dev mailing list

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

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

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

[Billy Tetrud via bitcoin-dev]

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

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

[Billy Tetrud via bitcoin-dev]

> 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  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: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit

[David A. Harding via bitcoin-dev]

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


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jeremy via bitcoin-dev]

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.


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

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

[Antoine Riard via bitcoin-dev]

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 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 
> 
> ___
> Lightning-dev mailing list
> lightning-...@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

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

[Jeremy via bitcoin-dev]

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

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

[Jeremy via bitcoin-dev]

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

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

[David A. Harding via bitcoin-dev]

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 = 0x + 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