> And prevent perfectly reasonable transfers of value Such a transfer can only be reasonable when off-chain value is attached to the coins.  A rule like this is the embodiment of the philosophy that the Bitcoin network is for onchain-economic transactions. Parties could get around the rule by paying miners off-network, and that would be an appropriate penalty for using non-onchain-economic transactions. On 5/8/23 10:13, Michael Folkson via bitcoin-dev wrote: > > probably easier just to reject any transaction where the fee is > higher than the sum of the outputs > > And prevent perfectly reasonable transfers of value and attempted > Lightning channel closes during fee spikes? If I *want*​ to close my > Lightning channel during a protracted fee spike where I have to pay an > onchain transaction fee greater than the amount I am receiving you > want to stop me doing that? You are impinging on a valid use case as > well as requiring a consensus rule change. > > -- Michael Folkson > Email: michaelfolkson at protonmail.com > GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F > Learn about Bitcoin: https://www.youtube.com/@portofbitcoin > > ------- Original Message ------- > On Monday, May 8th, 2023 at 13:58, Erik Aronesty via bitcoin-dev > wrote: > >> probably easier just to reject any transaction where the fee is >> higher than the sum of the outputs >> >> >> >> On Mon, May 8, 2023, 7:55 AM Ali Sherief via bitcoin-dev >> wrote: >> >> Hi guys, >> >> I think everyone on this list knows what has happened to the >> Bitcoin mempool during the past 96 hours. Due to side projects >> such as BRC-20 having such a high volume, real bitcoin >> transactions are being priced out and that is what is causing the >> massive congestion that has arguable not been seen since December >> 2017. I do not count the March 2021 congestion because that was >> only with 1-5sat/vbyte. >> >> Such justifiably worthless ("worthless" is not even my word - >> that's how its creator described them[1]) tokens threaten the >> smooth and normal use of the Bitcoin network as a peer-to-pear >> digital currency, as it was intended to be used as. >> >> If the volume does not die down over the next few weeks, should >> we take an action? The bitcoin network is a triumvirate of >> developers, miners, and users. Considering that miners are >> largely the entities at fault for allowing the system to be >> abused like this, the harmony of Bitcoin transactions is being >> disrupted right now. Although this community has a strong history >> of not putting its fingers into pies unless absolutely necessary >> - an example being during the block size wars and Segwit - should >> similar action be taken now, in the form of i) BIPs and/or ii) >> commits into the Bitcoin Core codebase, to curtail the loophole >> in BIP 342 (which defines the validation rules for Taproot >> scripts) which has allowed these unintended consequences? >> >> An alternative would be to enforce this "censorship" at the node >> level and introduce a run-time option to instantly prune all >> non-standard Taproot transactions. This will be easier to >> implement, but won't hit the road until minimum next release. >> >> I know that some people will have their criticisms about this, >> absolutists/libertarians/maximum-freedom advocates, which is >> fine, but we need to find a solution for this that fits >> everyone's common ground. We indirectly allowed this to happen, >> which previously wasn't possible before. So we also have a >> responsibility to do something to ensure that this kind of >> congestion can never happen again using Taproot. >> >> -Ali >> >> --- >> >> [1]: >> https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/ >> >> _______________________________________________ >> 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