Erik Aronesty [ARCHIVE] on Nostr: 📅 Original date posted:2023-05-09 🗒️ Summary of this message: Discussion on ...
📅 Original date posted:2023-05-09
🗒️ Summary of this message: Discussion on Bitcoin transaction fees and the need to address long-term security budget problems, with suggestions for spam filtration and delaying halving.
📝 Original message:I would like to point out that I'm not an advocate for doing anything at
this point aside from working on l2
just to make it inconvenient for people
I just think the discussion of outputs and fees is interesting and related
to the game theory portion of Bitcoin
On Tue, May 9, 2023, 8:23 AM Jaroslaw via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> Ok, I need to highlight one important thing well proven by this discussion
> (like it or not)...
>
> Not the spam itself is the real reason of feeling: "something must be done"
> The reason is: $30 fee per transaction (I hope you all agree)
>
>
> Let me paraphrase some quotes used in this discussion, then:
>
> 1. Lack of block subsidy long term and necessity of $40 tx fee to
> compensate it - "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."
>
> 2. "the harmony of Bitcoin transactions is being disrupted right now" due
> to lack of block subsidy and due to exorbitant $40 tx fees as an effect
> necessary to keep the network security untouched
>
> 3. "Fee spikes aren't fun" and it's obvious that keeping the network
> security only on enormous tx fees of active users and having passive users
> as free-riders - isn't fun, too
>
> 4. by ignoring Bitcoin long-term security budget problem - "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
> tremendous $40 tx fees can never happen again"
>
> 5. "Action against exorbitant fees should have been taken months ago.
> (...) It's a mistake that the" tail emission or other necessary solution -
> weren't implemented on time
>
> 6. "we need to find a solution for long-term horrible fees problem - that
> fits everyone's common ground."
>
>
> Yes, we need - instead of being still in a heavy denial state.
>
> No additional comment then, except this little one:
> Delay of halving in case of 4 years long network difficulty regression
> situation.
>
>
> Regards,
> Jaroslaw
>
>
>
>
>
> W dniu 2023-05-09 00:37:57 użytkownik Luke Dashjr via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> napisał:
>
> Action should have been taken months ago. Spam filtration has been a
> standard part of Bitcoin Core since day 1. It's a mistake that the existing
> filters weren't extended to Taproot transactions. We can address that, or
> try a more narrow approach like OP_RETURN (ie, what "Ordisrespector" does).
> Since this is a bugfix, it doesn't really even need to wait for a major
> release.
>
> (We already have pruning. It's not an alternative to spam filtering.)
>
> Luke
>
>
>
>
> On 5/7/23 13:22, 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 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/c994e465/attachment.html>;
🗒️ Summary of this message: Discussion on Bitcoin transaction fees and the need to address long-term security budget problems, with suggestions for spam filtration and delaying halving.
📝 Original message:I would like to point out that I'm not an advocate for doing anything at
this point aside from working on l2
just to make it inconvenient for people
I just think the discussion of outputs and fees is interesting and related
to the game theory portion of Bitcoin
On Tue, May 9, 2023, 8:23 AM Jaroslaw via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> Ok, I need to highlight one important thing well proven by this discussion
> (like it or not)...
>
> Not the spam itself is the real reason of feeling: "something must be done"
> The reason is: $30 fee per transaction (I hope you all agree)
>
>
> Let me paraphrase some quotes used in this discussion, then:
>
> 1. Lack of block subsidy long term and necessity of $40 tx fee to
> compensate it - "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."
>
> 2. "the harmony of Bitcoin transactions is being disrupted right now" due
> to lack of block subsidy and due to exorbitant $40 tx fees as an effect
> necessary to keep the network security untouched
>
> 3. "Fee spikes aren't fun" and it's obvious that keeping the network
> security only on enormous tx fees of active users and having passive users
> as free-riders - isn't fun, too
>
> 4. by ignoring Bitcoin long-term security budget problem - "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
> tremendous $40 tx fees can never happen again"
>
> 5. "Action against exorbitant fees should have been taken months ago.
> (...) It's a mistake that the" tail emission or other necessary solution -
> weren't implemented on time
>
> 6. "we need to find a solution for long-term horrible fees problem - that
> fits everyone's common ground."
>
>
> Yes, we need - instead of being still in a heavy denial state.
>
> No additional comment then, except this little one:
> Delay of halving in case of 4 years long network difficulty regression
> situation.
>
>
> Regards,
> Jaroslaw
>
>
>
>
>
> W dniu 2023-05-09 00:37:57 użytkownik Luke Dashjr via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> napisał:
>
> Action should have been taken months ago. Spam filtration has been a
> standard part of Bitcoin Core since day 1. It's a mistake that the existing
> filters weren't extended to Taproot transactions. We can address that, or
> try a more narrow approach like OP_RETURN (ie, what "Ordisrespector" does).
> Since this is a bugfix, it doesn't really even need to wait for a major
> release.
>
> (We already have pruning. It's not an alternative to spam filtering.)
>
> Luke
>
>
>
>
> On 5/7/23 13:22, 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 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/c994e465/attachment.html>;