Tom Harding [ARCHIVE] on Nostr: 📅 Original date posted:2023-05-09 🗒️ Summary of this message: Rejecting ...
📅 Original date posted:2023-05-09
🗒️ Summary of this message: Rejecting transactions with fees higher than outputs may prevent reasonable transfers. Off-network payments could be penalized to maintain on-chain transactions.
📝 Original message:> 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 <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 at 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 at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230509/54e03016/attachment.html>;
🗒️ Summary of this message: Rejecting transactions with fees higher than outputs may prevent reasonable transfers. Off-network payments could be penalized to maintain on-chain transactions.
📝 Original message:> 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 <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 at 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 at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230509/54e03016/attachment.html>;