Super Testnet's avatar
Super Testnet 1 week ago
It is true. Saying "miniscript could do something different than how it does it" does not contradict my point. My point includes that miniscript could and should be modified to work differently. But it is wrong to demand that wallet devs do that, who may not have the requisite expertise, and then give them a 6 month deadline, after which, if they haven't done this thing they may not even know how to do, some of their users may have their money frozen. It would be better to do the work first if changing miniscript and then offering a bip110 compatible variant to them; or modify BIP110 so that it only targets the inscription envelope pattern, which is never used by miniscript.
↑ Parent

Replies (1)

Tauri's avatar
Tauri tauri@mynostr.com 1 week ago
It’s not unreasonable to expect developers to build responsibly instead of defaulting to whatever is cheapest/easiest in the short term. If I understand this correctly, the way they’re using the miniscript in those cases is a suboptimal use of tapscript — less efficient and more expensive than it needs to be. Requiring them to fix that isn’t punitive. It improves efficiency, lowers long-term costs, and ultimately benefits their own users and product. So how exactly is that a bad outcome? If the protocol tolerates sloppy or inefficient constructions, those patterns get cemented. Today’s shortcut becomes tomorrow’s standard.
↑