DireMunchkin

The world is healing https://www.swissinfo.ch/eng/geneva-organisations/the-davos-set-in-decline-can-the-world-economic-forum-save-itself/90139318

BIP-444 will be an excellent chance to judge the honesty of your Bitcoin personality. We keep hearing from various such that they, too, hate spam and would like to get rid of it. And that they too think Bitcoin is money primarily. But it's just not really possible to do that with relay policy. I disagree with that, but regardless now we have a soft fork instead. Let's see how many in this group support the fork, since they allegedly want the same thing as we do, just disagree with the means. I know what I think will happen - They will find some other place to move the goal posts to. Just as we were initially told to run our own client, just not like that. Activate BIP-444 to send this clown posse to hades.

The latest coretard narrative is the OCEAN/Luke/whoever is coercing you into activating BIP-444 with legal threats. This is untrue of course. It is true that running a full node with data carrying will have legal risk. Warning you of this risk is not a threat or coercion. You are free to disregard warnings, but not of the consequences of doing so. Lots of people either don't understand the distinction or pretend not to. #knots

I've read up on: https://github.com/bitcoin/bips/pull/2017 The main substance of the fork is restricting the size of potentially data carrying fields in transactions to be below the limit where illegal content can be stored. > 1. New output scriptPubKeys exceeding 34 bytes are invalid, unless the first opcode is OP_RETURN, in which case up to 83 bytes are valid. > 2. OP_PUSHDATA* with payloads larger than 256 bytes are invalid, except for the redeemScript push in BIP16 scriptSigs. > 3. Spending undefined witness (or Tapleaf) versions (i.e, not Witness v0/BIP 141 nor Taproot/BIP 341) is invalid. > 4. Witness stacks with a Taproot annex are invalid. > 5. Taproot control blocks larger than 257 bytes (a merkle tree with 128 script leaves) are invalid. > 6. Tapscripts including OP_SUCCESS* opcodes anywhere (even unexecuted) are invalid. > 7. Tapscripts executing the OP_IF or OP_NOTIF instruction (regardless of result) are invalid. So basically hit most of the potential ways to finagle data into a Bitcoin transaction and reduce their max size to below 256 bytes. I.E inscriptions, `OP_RETURN`, tapscripts and taproot annex. The main downside of this soft fork is that it limits space for future upgrades, mainly by invalidating the taproot annex and unknown Tapleaf versions. It will also by limiting tapscript size make some second layers like BitVM invalid. I would be fine if BitVM never worked again personally. So the largest downside is really that future upgrades are more difficult and would need in some cases to be designed as a hard fork instead of a soft fork. For mostly this reason the soft fork is designed to expire after one year. It is of course possible to renew it after that point. I think the risk of unintended consequences of this soft fork are minimal, since it's only taking space away. Worst case it will expire so if there are valid and desirable use cases we can discuss after one year what value they have vs. preventing large data carrying. Another minor limitation is that this does not address all shitcoins on Bitcoin, it's more narrowly focused on illegal content. But this could be addressed separately via relay policy or another soft fork. Overall, I'm personally in favor of this upgrade! It's low risk and affirms what Bitcoin is about and what it is not. And it mitigates reputational/legal risk. At the moment the biggest question mark is around activation. The soft fork has two activation methods, one proactive, and one reactive in case of emergency. In the latter case it is valid immediately and will cause a chain split. The proactive method is still TBD.