I've noticed that most recent proposals like CTV and Vault create this tight structure for contracts. It's like we're splitting into groups based on our scaling preferences. And then there’s CAT, which feels so messy and unstandardized that I can’t even imagine the side effects it might cause.
Why are new Bitcoin scripting proposals application specific?
9 replies 477 views
Wait, how does a "basic generic Elliptic Curve Point Contract" even cover all the functionality of these proposals? Can you break it down a bit? Like, how would you handle how coins sent to an address are spent without CTV?
It’s bigger than just multisig. Think about unlocking methods through two messages from different parties. If we had OP_CHECKSIGFROMSTACK, you could have transactions across chains. The same signature could open up coins on Bitcoin and another chain, even if they're totally different.
Kinda crazy he talked about OP_CHECKSIGFROMSTACK before blockchain was a thing. Why wasn’t it in v0.1? But wouldn’t that mean both coins need the same elliptic curve? Like, Bitcoin uses secp256k1, but Monero uses Curve25519. Are we expecting clients to be flexible, or what?
1. Lots of altcoins just cloned secp256k1, so it’s not a huge deal. 2. There are DLEQ proofs that can show the same private key works on different curves. There are ways to make it work.
You're mainly talking about side-chains and off-chain contracts. The scripts you mentioned could fit that, but better ECC conditions could lead to native contracts. This would cut down on needing side chains for validation.
Exactly! OP_CAT is popular because it avoids those corner cases. Activating a soft-fork could lead to forgetting something important and being stuck. Why support every curve? Just stick with secp256k1 on Bitcoin and leave others for different systems.
OP_CAT doesn’t fix everything though. You keep saying it’s a cure-all, but where’s the proof? We need formal proofs for Discrete Log Curve Point stuff. Inspectvalue operations are key for covenants.
What if we just combined transaction heads and tails with OP_CAT? Even a simple data push can be misused. There are so many edge cases with elliptic curves. Imagine a weak curve triggering a vulnerability. Doing a soft-fork is no joke.
transactionHead and transactionTail aren’t even real op codes. How would anyone expect those to work in practice? Getting elliptic curves right isn’t easy, but most should probably just stick to secp256k1. Once you choose a curve, defining it is like using a library.