thank you, i do want to hear more, yes. another question i have now is: you're considering writing a proof of concept for a ursf, but since you're aligned on the anti spam topic why not instead propose a bip that does not have the two parts you dislike?

Replies (2)

Super Testnet's avatar
Super Testnet 3 months ago
> why not instead propose a bip that does not have the two parts you dislike? Why not both? If I do not like X it seems wise to help prevent X from happening And if I *do* like Y it seems wise to also help ensure Y happens
Super Testnet's avatar
Super Testnet 3 months ago
> i do want to hear more, yes See the last paragraph of this post:
Super Testnet's avatar Super Testnet
BIP110 does two bad things. First, in certain circumstances, it freezes the funds of wallets that use the miniscript language in a certain way. Miniscript is a bitcoin smart contracting language with a bunch of built in functions, and it is designed to "compile" a bitcoin wallet that uses one or more of those functions as selected by users and/or developers. Some of those functions sometimes violate one of BIP110's proposed rules (the rule against using the OP_IF function in taproot wallets), which could cause users of some miniscript wallets to lose funds, depending on how they use it. This potential problem was brought up before the BIP110 software was written, including by me, and a fix was proposed, but the BIP110 devs decided to move forward without fixing it. I think it is a bad idea to potentially freeze the funds of innocent miniscript users. I think it would be better to provide wallet devs with a variant of miniscript that doesn't violate BIP110's proposed rules, and enough time to upgrade. Alternatively, BIP110 itself could be modified so that it doesn't break current versions of miniscript, but BIP110's developers have rejected that option because one of the most popular spam formats uses OP_IF in taproot transactions and they want to be sure to block that. Apart from breaking miniscript in certain cases, there is another reason I do not like BIP110: I think most bitcoin node runners are currently largely indifferent to the forms of spam that BIP110 tries to block, and are therefore unlikely to run BIP110 on their nodes. With insufficient support from node runners, I think BIP110 will fail to sway miners to enforce its rules, and the small number of people who do run BIP110 will probably fork off the bitcoin network sometime close to September. I would prefer to continue winning people over to the anti-spam movement, and only do an anti-spam soft fork once there are more signs that a sufficient number of people will run it, including economic signals.
View quoted note →