DireMunchkin

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.

One gap that needs to be closed at some point is dev funding for Knots. AFAICT *all* of the current major dev grant funding organizations have a pro-spam position. OpenSats, Brink, Spiral and HRF are all bad. The existing grant pipeline is essentially just making Bitcoin worse.

nostr:nprofile1qqs83nn04fezvsu89p8xg7axjwye2u67errat3dx2um725fs7qnrqlgzqtdq0 looks like there's something broken

Resist the shitcoiners trying to muddy the waters on what Bitcoin stands for. Our one goal is separating money from the state. On this point we will never waver, and we will never be distracted from it. We will measure the value of data on the blockchain against this goal. If it uses Bitcoin as money, then it's a valid use of the network. If it doesn't, then it's spam, and we will treat it as such. Our networks are closed for the token peddlers and ponzi promoters. They will all learn to have fun staying poor eventually, but we will work to make it sooner rather than later. Fraud is immoral. We will not be a party to it. Our future depends on sound money. We will not let them take it from us. We will make them obsolete. #knots

#LolaLiar