Post
Topic
Board Development & Technical Discussion
Re: Why are all the new proposals for scripting on Bitcoin application specific?
by
vjudeu
on 15/07/2024, 05:38:41 UTC
Quote
OP_CAT does not enable things like inspectoutputvalue
What about: <transactionHead> <amount> <transactionTail> OP_CAT OP_CAT

Quote
Weak curves are utterly irrelevant
Why? Even a simple feature, like "data push" was abused. Getting elliptic curves right is not a trivial task. There are many corner cases. Also, imagine what could happen, if you could combine weak curve with SIGHASH_SINGLE bug: it can potentially allow you to move coins, without knowing the private key, for example: https://mempool.space/testnet/tx/3952b35bde53eb3f4871824f0b6b8c5ad25ca84ce83f04eb1c1d69b83ad6e448#vin=1

Related topic: https://bitcointalk.org/index.php?topic=5373858.0

Quote
Bitcoin does not need more weakly defined hacks establishing themselves as legitimate protocols to unfortunately and inevitably leave end users holding the experimental bags.
Doing a soft-fork is a difficult task. The only reason why those hacks are created, is because if you want to deploy something in a standard way, then it can take years, and there is a huge chance for getting your proposal rejected. Which means, that those "hacks" are actually the simpler way of doing things, because it is very difficult to convince everyone, that some feature is needed. So, tricks like that are created first, and the proper implementation usually comes later, when people see, that some use case is inevitable.

Quote
We need well defined standards that legitimately increase the surface area for innovation.
Of course. But the true answer to the question "how to do it properly", usually comes later. That was the case with public keys: people thought for years, that new address types will be based on P2SH. But then, they noticed, that public keys are needed anyway, so Taproot is more similar to P2PK, than to P2SH. Which also means, that it is more likely, to get new OP_CHECKSIG-based features, than introduce a new opcode, like OP_CHECKLAMPORT.

Quote
the alternative I'm offering is a basic standard that would support all the current proposals and more
Where is the BIP? Is it this one? https://groups.google.com/g/bitcoindev/c/Ts0FEkGvDkM
Because BIP for OP_CAT already exist: https://github.com/bitcoin/bips/blob/master/bip-0347.mediawiki

If you seriously think about your proposal, then you need to write a proper BIP. Or find someone, who will do that for you.

Also, OP_CAT is already active in some signet-like networks, and supported by some nodes. If you want to activate things differently, then you need a similar thing, to show people, that "hey, with OP_CAT, you have this, with my approach, you have that. Choose wisely".

More than that: there are more competing standards for scripting, for example this one: https://delvingbitcoin.org/t/btc-lisp-as-an-alternative-to-script/682
It contains secp256k1_muladd, but I cannot see ecdsa_muladd anywhere.