I think that both "filter teams" I mentioned (OCEAN-led datacarriersize proposal and Chaincodelabs-led bare-multisig proposal) are skeptical of important higher order effects of updating current Core's filter due to the fact that current Core's filter seamingly didn't produce such effects, and the new proposals don't change their fundamental logic. The stronger arguments I've seen about why these new updates would be worse are actually by the team proposing to remove non-fee-based filters from Core completely. But I'm quite sure that would have important higher order effects as well.
I'm not sure Luke or Murch want to wish away any economic game theory, but it's clear it's not a game theory "that makes Bitcoin work", since Core currently filters away high-fee-paying txs from mempool.
I think is entirely reasonabe on their part to suggest only mempool-level upgrades and not soft fork: mempool policy is a matter of local preference, relatively safe & dynamic, block validity is a matter of global consensus, very risky, hard to change and very hard to change back once changed. So far the only one I've seen suggesting a consensus change was a malicious troll by an "ordinals" developer, trying to lure anti-spam users into running a disastrous fork without even an activation date (I don't remember his name, but he's friend with some Bitcoiners so he gets a pass for such irresponsible behavior, sadly). In general, managing something as dynamic as spam with consensus rules seems frankly crazy to me. Spam attacks and DDoS are preferable to consensus failures and splits.
Bitcoin deva always advocated for whitelisted script templates, nothing new: currently Core stansardness rule explicitly whitelist 5 types of txs, while all the other possible types are nonstandard, regardless of the fees. Not having whitelists in mempool policies is *most definitely not* "what makes Bitcoin bitcoin".
I can't prevent malicious or apatic miners get their massive stack of fees coming from "NFT" frauds and spam attacks: I can just refuse to cooperate actively and shame them publicly.
I absolutely agree with you that one can think all of the inscriptions are spam, and accept nothing can be done about it. It may be the case. One could also think that something may be done to some degree (as I suspect) but that it's still better to focus efforts on other things: totally honest and respectable take.
giacomozucco /
npub1au…9t53j
2024-01-06 16:04:21
in reply to nevent1q…r59f
Author Public Key
npub1au23c73cpaq2whtazjf6cdrmvam6nkd4lg928nwmgl78374kn29sq9t53jPublished at
2024-01-06 16:04:21Event JSON
{
"id": "68564f9dab814105cc25288ba91d857d422ad08f7e88fd430cabc8c168b68736",
"pubkey": "ef151c7a380f40a75d7d1493ac347b6777a9d9b5fa0aa3cddb47fc78fab69a8b",
"created_at": 1704557061,
"kind": 1,
"tags": [
[
"e",
"e4b87b8b4cd0d6e824a741e578cb6cb7809af2a11b749a6725df78398a454277",
"",
"root"
],
[
"e",
"e2ed40826d7b1545cdfb7636c3e50e307ed5d6a0517c7c49c7c0065d783e5186"
],
[
"e",
"5a102e6fed4729d1be35bb5f490e37b9424e05133ea28a78d022b1c6fb630aff",
"",
"reply"
],
[
"p",
"ef151c7a380f40a75d7d1493ac347b6777a9d9b5fa0aa3cddb47fc78fab69a8b"
],
[
"p",
"ef151c7a380f40a75d7d1493ac347b6777a9d9b5fa0aa3cddb47fc78fab69a8b"
],
[
"p",
"cedab81be42ef47dbde653f4ba7ab25ac3aa32cfc2b672ee0f89c0faf882f13e"
]
],
"content": "I think that both \"filter teams\" I mentioned (OCEAN-led datacarriersize proposal and Chaincodelabs-led bare-multisig proposal) are skeptical of important higher order effects of updating current Core's filter due to the fact that current Core's filter seamingly didn't produce such effects, and the new proposals don't change their fundamental logic. The stronger arguments I've seen about why these new updates would be worse are actually by the team proposing to remove non-fee-based filters from Core completely. But I'm quite sure that would have important higher order effects as well.\n\nI'm not sure Luke or Murch want to wish away any economic game theory, but it's clear it's not a game theory \"that makes Bitcoin work\", since Core currently filters away high-fee-paying txs from mempool. \n\nI think is entirely reasonabe on their part to suggest only mempool-level upgrades and not soft fork: mempool policy is a matter of local preference, relatively safe \u0026 dynamic, block validity is a matter of global consensus, very risky, hard to change and very hard to change back once changed. So far the only one I've seen suggesting a consensus change was a malicious troll by an \"ordinals\" developer, trying to lure anti-spam users into running a disastrous fork without even an activation date (I don't remember his name, but he's friend with some Bitcoiners so he gets a pass for such irresponsible behavior, sadly). In general, managing something as dynamic as spam with consensus rules seems frankly crazy to me. Spam attacks and DDoS are preferable to consensus failures and splits.\n\nBitcoin deva always advocated for whitelisted script templates, nothing new: currently Core stansardness rule explicitly whitelist 5 types of txs, while all the other possible types are nonstandard, regardless of the fees. Not having whitelists in mempool policies is *most definitely not* \"what makes Bitcoin bitcoin\". \n\nI can't prevent malicious or apatic miners get their massive stack of fees coming from \"NFT\" frauds and spam attacks: I can just refuse to cooperate actively and shame them publicly.\n\nI absolutely agree with you that one can think all of the inscriptions are spam, and accept nothing can be done about it. It may be the case. One could also think that something may be done to some degree (as I suspect) but that it's still better to focus efforts on other things: totally honest and respectable take.",
"sig": "05de9c681caa1853b83934ea5fadd032404072c2fa76610216a028f6185e444c46046d1f55ec3c856b052abde415fa4e61a581de56b3fe611cbfedfcdfb68784"
}