> 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](http://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
<bitcoin-dev@lists.linuxfoundation.org> 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
> <bitcoin-dev@lists.linuxfoundation.org> 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/](https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/?outputType=amp)
>>
>> _______________________________________________
>> 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
