> im unclear as to the purposepaying an onchain transaction fee greater than
> the amount receiving could possibly serve.
If you expect fees to continue to rise and be sustained at abnormally high
levels for a long period of time you might seek to close your Lightning
channel(s) and move whatever value you can from these Lightning channel(s)
onchain even if it means paying a higher fee than the amount you are receiving.
I don't necessarily recommend doing this (it would depend on a number of
factors, both personal and external) but there is no reason to prevent someone
in say the consensus rules from doing this if they wish.
--
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 20:47, Erik Aronesty <e...@q32.com> wrote:
> im unclear as to the purpose paying an onchain transaction fee greater than
> the amount receiving could possibly serve.
>
> what benefit do you get aside from losing bitcoin?
>
> are there any, non-theoretical, benefits to facilitating dust transactions?
>
> we could, of course, have it be non-consensus (no route dust) to start with
>
> On Mon, May 8, 2023 at 1:13 PM Michael Folkson
> <michaelfolk...@protonmail.com> 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](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