Move from Static Dust Limit [330 / 546 sats] to Variable Dust Limit [= to TxFee] #29423

issue DoctorBuzz1 openend this issue on February 11, 2024
  1. DoctorBuzz1 commented at 7:33 pm on February 11, 2024: none

    Please describe the feature you’d like to see added.

    This is the basis for my proposal….

    isDust

    Based on the number of Txs that have been unmovable, unspendable for nearly a solid year, it appears that the static dust limit is still permitting dust attacks, based on how the UTXO system works. Any entity with the ability to print infinite fiat or with the ability to cease hundreds of thousands of Bitcoin (or even miners that collude with or become those performing a dust attack, creating a circular loop of TxFees) could drive TxFees to “unusable levels” for an extended period of time. If TxFees are at 50,000 to 100,000 sats for a year, because there’s 100 million 330 sat Txs, then it’s safe to say that the static dust limit is not working as intended, in the eyes of those that are actually trying to move their Satoshis as a store of value.

    It’s my belief that spam [and TxFees] have been dropping because people are starting to realize that these non-monetary Txs (those that cannot be moved because the UTXO is not large enough to pay for the TxFee) make zero sense from the point of being “transferable NFTs” or what have you, and any transfer of these dust Txs would need to take place off chain.

    Describe the solution you’d like

    A basic coding example of this proposal is simply:

    if (Tx < TxFee) {isDust = True;}

    Obviously, GetDustThreshold and other parts of the code would need to change to reflect this understanding. Hopefully, someone is able to help me/us figure out how to make this basic understanding a reality… as dust attacks and a bloated UTXO set on lightweight nodes (incl. LN nodes) across the globe are a real concern.

    Describe any alternatives you’ve considered

    Rearden made these comments, which sound similar to what I’m proposing, yet I don’t fully understand it or how it would be implemented, but perhaps it is an alternative solution??

    I’d be supportive of a solid proposal to internalize the cost of net UTXO creation to tx fees, which would increase the cost of the most negatively impactful txs we’re currently seeing.

    I was thinking something more like a weight multiplier that is 1 for net out:in UTXO ratio <= 1 and increases exponentially as out:in UTXO ratio goes > 1.

    Please leave any additional context

    There are a few concerns that others have mentioned, which could more than likely be worked around one way or another:

    (1) CPFP Txs. These low sat Txs could be tied to the larger sat, parent Tx to THEN see if (TotalTx < TotalTxFees). (2) LN is currently assuming that the static dust limits will always be valid Txs, so somehow they will need to assume that Txs will more liquidity. Perhaps there can be some liquidity pooling solution to help with this? Regardless, this is a LN problem, NOT a Core problem. (3) LN Anchor Txs. Similar to point (1), it seems like this low sat Tx could be tied to the earlier larger sat, parent Tx. Not sure if these anchor Txs are actually using a CPFP type Tx, but surely there’s a way to peg the latter Tx to the earlier Tx and total the cost of the Txs and TxFees.


    Elsewhere, someone asked me:

    “What would happen if there was a Tx with 1 input and 2 outputs, where the 1st output is larger than the TxFee but the 2nd output is smaller than the TxFee?”

    The end result is that the entire Tx would be invalid, as the 2nd output is dust. This is precisely what would happen now if the 2nd output was only 1 sat. The entire Tx would neither be relayed nor mined, because it’s invalid [dust].

  2. DoctorBuzz1 added the label Feature on Feb 11, 2024
  3. DoctorBuzz1 renamed this:
    Move from a Static Dust Limit [of 330 / 546 sats] to a Variable Dust Limit [= to TxFee]...
    Move from Static Dust Limit [330 / 546 sats] to Variable Dust Limit [= to TxFee]
    on Feb 11, 2024
  4. maflcko commented at 6:07 pm on February 13, 2024: member
    Considering transactions as policy-invalid where any output amount is smaller than the total fee paid by the transaction is going to create issues for payment batching. See https://bitcoinops.org/en/payment-batching/. For example, if many recipients are paid in a large transaction, the fee may be higher than one of the recipients’ amounts. If the payment creator is now forced to pay every recipient individually in a separate transaction, it will consume more block space overall and make the problem you are trying to solve worse. Also, while the fee on each separate transaction is less than the fee for the large batching transaction, the sum of all small fees is larger than the fee of the batch transaction.
  5. DoctorBuzz1 commented at 7:36 am on February 14, 2024: none

    Rate limit the spam, which is overtaking the monetary use-case of Bitcoin, and the batch Txs like you suggest wouldn’t be a real problem. It’s only a problem when the spam continues to jack up fees for no legit reason. See here: https://twitter.com/DoctorBuzz1/status/1757659895426330648

    Even in the current fee market, I think it would be tough to find a legit batch Tx that would be triggered by this change, considering the savings mentioned in your link. And even if you COULD find an example, there’s always the ability to find an appropriate ratio as was done with Segwit. My initial thought was…

    if (3Tx < TxFee) {isDust = True;}

    Which seems too generous, IMHO, but starting at some legit level of consensus is obviously better than ignoring what is preventing the adoption of “freedom money” to be actually used as money. Rijndael admitted that Central Bankers aren’t afraid of Bitcoin’s use as a store of value, but they would be threatened if it could actually be used for coffee payments. Less people are willing to run a node with a consistently high fee environment, like the past year (I know I was looking to start a LN routing node in Feb of last year and scrapped the idea until there was a solution, but there has been none accepted, even tho solutions do exist).

    Can we agree that the laser eyed focus was for Bitcoin to be used as money and not file storage for PooCoins? If decisions are going to be made on what’s in the best short-term interest of miners, then let’s at least rate limit this crap in the long-term interest and value of Bitcoin.

  6. ArmchairCryptologist commented at 8:26 am on February 14, 2024: none

    If we wanted to revamp the dust threshold to, say, increase the cost of ordinals/inscriptions and stop people from junking up the UTXO set without significantly affecting normal usage, a more compatible solution might be to define it as a UTXO that cannot be economically spent at the fee level of the transaction creating it (or a multiplier of said fee), rather than basing it on the total fee of the transaction.

    Of course, seeing as we cannot in general know exactly how much data is required to spend all different types of UTXOs (notably P2SH/P2WSH), it would necessarily have to be based on a fixed size estimate for the type of UTXO in question. So since a P2WPKH UTXO is at least 67 vB, if it’s created by a 100 sat/vB transaction, without using a multiplier it would be considered dust below 6700 sats.

    This could (and probably would) still cause issues for things like anchor outputs, but it might be possible to fine-tune the rules to allow for smaller dust outputs in conjunction with larger outputs specifically. Not that I would be sad to see anchor outputs disappear in favor of something that isn’t based on clogging up the blockchain with CPFPs…

  7. 1440000bytes commented at 1:01 pm on February 14, 2024: none
    So this tx will be considered dust and won’t get relayed if such solution is implemented: bdc168f1d6c38c66c762ccb36655a118436347b074f4a1ff1c8cad4e7429ae0f?
  8. DoctorBuzz1 commented at 0:06 am on February 16, 2024: none

    So this tx will be considered dust and won’t get relayed if such solution is implemented: bdc168f1d6c38c66c762ccb36655a118436347b074f4a1ff1c8cad4e7429ae0f?

    Soo…. if we take my 2nd proposal of

    if (3Tx < TxFee) {isDust = True;}

    And adjust it just a tad to:

    if (4Tx < TxFee) {isDust = True;}

    Then that Tx would be able to be relayed & mined.

    EDIT: I guess I was only considering the inputs…. so that wouldn’t work. Honestly, I’m not even sure how that 2nd input could afford to move. Definitely a weird example. More thinking needed, I guess. Would love to see an example of ArmchairCryptologist’s suggestion of using a UTXO multiplier..

  9. DoctorBuzz1 commented at 2:57 am on February 16, 2024: none

    So this tx will be considered dust and won’t get relayed if such solution is implemented: bdc168f1d6c38c66c762ccb36655a118436347b074f4a1ff1c8cad4e7429ae0f?

    Are you able to explain what’s happening in this Tx? Why is it overpaying 3x what’s necessary to get into the block when 25 sats/vByte definitely would’ve made it into the next block?

    If the TxFee is 25,582 sats…. how is that distributed amongst the input Txs? Is it proportional?

    Again…. if there was some multiple variable of Tx to TxFee that was able to filter a large portion of non-monetary Txs… then fees would be lower for Lightning Txs. That’s the whole point of doing this. Lightning doesn’t make sense with fees like this!

  10. maflcko commented at 8:28 am on February 16, 2024: member

    a more compatible solution might be to define it as a UTXO that cannot be economically spent at the fee level of the transaction creating it (or a multiplier of said fee)

    That doesn’t work either, because it is trivial to side-step. For example, one could create the transaction at a lower fee rate to create the dust, then raise the fee by creating a descendant transaction with a higher fee. (The result would be that the opposite of what this proposal is trying to achieve, is achieved). Another example would be to pay the fee to the miner out of band.

  11. maflcko commented at 8:30 am on February 16, 2024: member

    Not sure what the goal of this issue is. Anyone wanting to change the dust relay fee can already do so with the -dustrelayfee setting. In any case, if there is a technical sound proposal with proper motivation and a complete discussion of the effects on wallet software as well as P2P relay policy interactions, no one is holding anyone back from proposing those changes as a pull request, a BIP, or as a discussion with the broader ecosystem to gather feedback, for example https://groups.google.com/g/bitcoindev, or https://delvingbitcoin.org/.

    If the goal of this issue is to learn about Bitcoin, for example to learn the difference between transaction fee and feerate, a better place would be Bitcoin StackExchange or the #bitcoin IRC channel on Libera Chat, or one of the Bitcoin subreddits, or any other place that you feel is well suited.

  12. maflcko closed this on Feb 16, 2024


github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-12-21 15:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me