1000%

OP_CAT could not be further away from the critical conservatism and caution in protocol stewardship that made #Bitcoin’s very existence possible.

Thats a hard fucking NO from me dawg.

?cid=2154d3d7xhr1cuwir11igxzb74z0o44u4pz2jzp451e1araa&ep=v1_gifs_search&rid=giphy.gif&ct=g nostr:note1prrgyfue7xxaazapa3lg3p568tpd8883hnunta0ddvmu5ptljyhs2quhg8

Reply to this note

Please Login to reply.

Discussion

So it basically enables scripting?

OP_CAT is a pandora's box of *potentially bad* script possibilities.

Iff we have exhausted what we can accomplish with OP_CTV and have decided we need more functionality, I *might* consider OP_CAT, but it's so incredibly out of order to propose activating it now it's insane.

Yikes 😬

I think I’ll pass.

ReardenCode is absolutely a good actor in the space and he thinks OP_CAT is ok, but his "OK" is based on "MEV is actually not as big of a problem as people think". I'm not willing to test that hypothesis on mainnet any time soon, and not without a VERY compelling reason.

What *doesn’t* it enable? The scope of OP_CAT and what it can do seems so arbitrarily large as to make discussion of it difficult. Not to mention developing with it is unintuitive and creates very complex scripts for very simple functions.

Everything I’ve seen suggests it is a recipe for messy development, technical debt, long term bugs/faults that aren’t obvious at the outset, and an avalanche of scams that aren’t secure, decentralized, or anything else we care about but that bring the “crypto” world flooding into Bitcoin selling the same garbage with a fresh coat of paint.

If you have a different perspective and can argue it, be my guest, I’m happy to learn something.

you sold me at 'conservatism' and the diligence and patience to deeply consider a major change

I have a less-pessimistic appraisal of OP_CAT. Yes, it enables more use-cases. Like anything, there are costs and benefits.

What I like about it, personally, is that the additional flexibility provides space for developers/users to defend against attacks. It may enable new and better CoinJoin solutions to mask transactions from censors. It could provide novel vault solutions. It opens up alternative signature schemes potentially with better properties for some kinds of attacks. Defense against a discovered weakness in ECDSA for example.

However, OP_CAT solutions tend to be costlier for the user than the would-be alternatives. An OP_CAT vault will take more bytes than an OP_VAULT TX for instance. But this is OK. Someone who wants the expensive functionality can pay for the bytes. If that type of transaction becomes popular, we can always fork in a specific OP later to reduce costs.

Having said all of that, I don’t think OP_CAT is something that should be rushed through. It’s not urgent. Consensus is paramount. I just don’t share the net-negative appraisal of most hardcore Bitcoiners here.

Bad news about OP_VAULT https://twitter.com/reardencode/status/1756185478716657830

(I have not checked Brandon's work on this, but you can see that I had the intuition about it independently)

I want to remind everyone that CTV alone enables vaults https://github.com/jamesob/simple-ctv-vault

(jamesob designed OP_VAULT around the problems with these simple vaults, so that's not to say they're perfect, but I believe they are useful. In fact, I believe simple vaults gives us 90% of what we want anyway.)

The fact that it's being promoted by inscription scammers is a huge red flag to me

From a scripting perspective we haven’t even exhausted the design space of mini-script yet. In fact it sat on the shelf for years because of apathy, complacency and because it doesn’t enable shitcoin behavior.

Taproot adoption is also still quite small. How many wallets/exchanges still default to segwit? How many even have taproot as a receive option? How many LN wallets use taproot channels?

I have no idea what this means but let me know when it's time to upgrade my two full nodes