📅 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>;
Erik Aronesty [ARCHIVE] /
npub1y2…5taj0
2023-06-07 23:21:35
in reply to nevent1q…8ad6
Author Public Key
npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0Published at
2023-06-07 23:21:35Event JSON
{
"id": "72b93c132298f0f8cb21cfcf41429fc25d63c86e8fe4033305251cf114575e43",
"pubkey": "22944ce1e29904e3826d25013a614e4665693ec514003efacc1b7586e8e5d0aa",
"created_at": 1686180095,
"kind": 1,
"tags": [
[
"e",
"99c4bf84b18ff56e33caa2ea8f0dff269c71fbc07db2947c8f69f4bfab247070",
"",
"root"
],
[
"e",
"c5411c15e1b183b4da2af262e75ee94ece5c7cdf349301fcf316dccf2b5dede8",
"",
"reply"
],
[
"p",
"6f7eed8b9a4bc806fdf821c19ef742c0c56e8fb195cf2933c2b12907af840f57"
]
],
"content": "📅 Original date posted:2023-05-09\n🗒️ 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.\n📝 Original message:I would like to point out that I'm not an advocate for doing anything at\nthis point aside from working on l2\n\njust to make it inconvenient for people\n\nI just think the discussion of outputs and fees is interesting and related\nto the game theory portion of Bitcoin\n\n\n\nOn Tue, May 9, 2023, 8:23 AM Jaroslaw via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e\n\u003e\n\u003e Ok, I need to highlight one important thing well proven by this discussion\n\u003e (like it or not)...\n\u003e\n\u003e Not the spam itself is the real reason of feeling: \"something must be done\"\n\u003e The reason is: $30 fee per transaction (I hope you all agree)\n\u003e\n\u003e\n\u003e Let me paraphrase some quotes used in this discussion, then:\n\u003e\n\u003e 1. Lack of block subsidy long term and necessity of $40 tx fee to\n\u003e compensate it - \"threaten the smooth and normal use of the Bitcoin network\n\u003e as a peer-to-pear digital currency, as it was intended to be used as.\"\n\u003e\n\u003e 2. \"the harmony of Bitcoin transactions is being disrupted right now\" due\n\u003e to lack of block subsidy and due to exorbitant $40 tx fees as an effect\n\u003e necessary to keep the network security untouched\n\u003e\n\u003e 3. \"Fee spikes aren't fun\" and it's obvious that keeping the network\n\u003e security only on enormous tx fees of active users and having passive users\n\u003e as free-riders - isn't fun, too\n\u003e\n\u003e 4. by ignoring Bitcoin long-term security budget problem - \"we indirectly\n\u003e allowed this to happen, which previously wasn't possible before. So we also\n\u003e have a responsibility to do something to ensure that this kind of\n\u003e tremendous $40 tx fees can never happen again\"\n\u003e\n\u003e 5. \"Action against exorbitant fees should have been taken months ago.\n\u003e (...) It's a mistake that the\" tail emission or other necessary solution -\n\u003e weren't implemented on time\n\u003e\n\u003e 6. \"we need to find a solution for long-term horrible fees problem - that\n\u003e fits everyone's common ground.\"\n\u003e\n\u003e\n\u003e Yes, we need - instead of being still in a heavy denial state.\n\u003e\n\u003e No additional comment then, except this little one:\n\u003e Delay of halving in case of 4 years long network difficulty regression\n\u003e situation.\n\u003e\n\u003e\n\u003e Regards,\n\u003e Jaroslaw\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e W dniu 2023-05-09 00:37:57 użytkownik Luke Dashjr via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e napisał:\n\u003e\n\u003e Action should have been taken months ago. Spam filtration has been a\n\u003e standard part of Bitcoin Core since day 1. It's a mistake that the existing\n\u003e filters weren't extended to Taproot transactions. We can address that, or\n\u003e try a more narrow approach like OP_RETURN (ie, what \"Ordisrespector\" does).\n\u003e Since this is a bugfix, it doesn't really even need to wait for a major\n\u003e release.\n\u003e\n\u003e (We already have pruning. It's not an alternative to spam filtering.)\n\u003e\n\u003e Luke\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e On 5/7/23 13:22, Ali Sherief via bitcoin-dev wrote:\n\u003e Hi guys,\n\u003e\n\u003e\n\u003e I think everyone on this list knows what has happened to the Bitcoin\n\u003e mempool during the past 96 hours. Due to side projects such as BRC-20\n\u003e having such a high volume, real bitcoin transactions are being priced out\n\u003e and that is what is causing the massive congestion that has arguable not\n\u003e been seen since December 2017. I do not count the March 2021 congestion\n\u003e because that was only with 1-5sat/vbyte.\n\u003e\n\u003e\n\u003e Such justifiably worthless (\"worthless\" is not even my word - that's how\n\u003e its creator described them[1]) tokens threaten the smooth and normal use of\n\u003e the Bitcoin network as a peer-to-pear digital currency, as it was intended\n\u003e to be used as.\n\u003e\n\u003e\n\u003e If the volume does not die down over the next few weeks, should we take an\n\u003e action? The bitcoin network is a triumvirate of developers, miners, and\n\u003e users. Considering that miners are largely the entities at fault for\n\u003e allowing the system to be abused like this, the harmony of Bitcoin\n\u003e transactions is being disrupted right now. Although this community has a\n\u003e strong history of not putting its fingers into pies unless absolutely\n\u003e necessary - an example being during the block size wars and Segwit - should\n\u003e similar action be taken now, in the form of i) BIPs and/or ii) commits into\n\u003e the Bitcoin Core codebase, to curtail the loophole in BIP 342 (which\n\u003e defines the validation rules for Taproot scripts) which has allowed these\n\u003e unintended consequences?\n\u003e\n\u003e\n\u003e An alternative would be to enforce this \"censorship\" at the node level and\n\u003e introduce a run-time option to instantly prune all non-standard Taproot\n\u003e transactions. This will be easier to implement, but won't hit the road\n\u003e until minimum next release.\n\u003e\n\u003e\n\u003e I know that some people will have their criticisms about this,\n\u003e absolutists/libertarians/maximum-freedom advocates, which is fine, but we\n\u003e need to find a solution for this that fits everyone's common ground. We\n\u003e indirectly allowed this to happen, which previously wasn't possible before.\n\u003e So we also have a responsibility to do something to ensure that this kind\n\u003e of congestion can never happen again using Taproot.\n\u003e\n\u003e\n\u003e -Ali\n\u003e\n\u003e\n\u003e ---\n\u003e\n\u003e\n\u003e [1]:\n\u003e https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230509/c994e465/attachment.html\u003e",
"sig": "91910a746fd96fa06a9d402132eab624dede50bbb55faa1759c2c71d2bc49eb38e265c0ccb6906c8439bdb7084dc19a01570ac94f387de168ea7592b52299a29"
}