> 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

Reply via email to