On Thu, Nov 14, 2019 at 10:56:05AM +0100, Joost Jager wrote: > Looking at https://github.com/bitcoin/bitcoin/commit/9022aa3, is > `dustRelayFee` really never going to change? It even is a (hidden) cmd line > parameter that can be set easily. > > If the fee market would rise and stay high for an extended period of time, > why wouldn't people use this flag to raise the dust relay fee?
If feerates are reliably high, then there's less need for the dust limit and I wouldn't expect it to be increased. The dust limit exists to prevent people from filling the UTXO set with non-economical UTXOs when feerates are low. For example, at the current minimum relay fee of 1 sat/vbyte and price of $8,500 USD/BTC, the cost to create a zero-value[1] P2WPKH output is about 30 vbytes = 30 sat = $0.0025 (1/4 cent). The current UTXO set has about 64 million entries, so the cost to double its size would be $160,000---a tidy sum, but probably less than some people spend spreading anti-Bitcoin propaganda on a regular basis. The dust limit helps prevent that by making the minimum cost per created P2WPKH UTXO 30 sat + 294 sat = $0.0275, or about $1,760,000 per UTXO set doubling. If feerates increase, the cost of a UTXO-filling attack rises proportionally. Somewhere around sustained minimum feerates of 11 sat/vbyte, feerates alone become more expensive than the current level of protection provided by the dust limit at 1 sat/vbyte. Additionally, it's worth noting that the dust limit is not incentive-aligned with short-term miner interests. If there's actual legitimate demand to create transactions paying reasonable feerates and containing uneconomical-to-spend outputs, then miners are going to start accepting those transactions no matter what policies are implemented on the P2P transaction relay network. In short, I don't expect dust limits to rise unless the BTC/fiat price drops so far that UTXO-filling attacks become much more affordable than they are with today's limits. Dust limits may instead decrease (or be removed), but I don't think that's a problem for anchor outputs. That said, I think it'd be a nice thing for LN implementations to strive to create anchor outputs that are economical to spend and that may require using a negotiable output amount to compensate for rises in feerates making small-value outputs less economical, especially if you're using different anchor outputs for each channel party. -Dave [1] I believe consensus rules allow creating zero-value outputs. If not, making this a 1 sat output doesn't significantly change any calculations. P.S. Perhaps see also Gregory Maxwell's take: > I suspect that if feerates hadn't tanked after the introduction of > segwit, implementations probably would have removed the dust limit > policy rules in any case: they're a kludge that compensates for fees > being too low to dissuade various antisocial behaviors like spamming > for advertising purposes or de-anonymizing users and don't serve much > purpose if feerates are consistently high enough to discourage these > attacks. Source: https://bitcoin.stackexchange.com/a/85696/21052 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
