Quote from: vjudeu on July 15, 2024, 05:38:41 AM

Quote

OP_CAT does not enable things like inspectoutputvalue

What about: <transactionHead> <amount> <transactionTail> OP_CAT OP_CAT

transactionHead and transactionTail are not existing op codes and it fails to be obvious how to concatenations at the end of the script should ever rationally imply to implicitly store the input or output value of the transaction even if it was.

Quote from: vjudeu on July 15, 2024, 05:38:41 AM

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

"Getting elliptic curves right is not a trivial task." first off most people could and probably should stick to secp256k1 anyway, the point is that theres a generic stack for generating the cryptographic protocol, once you make the choice to use a well known curve defining it correctly is just as easily as importing the correct library which is basic programming. Furthermore the generality would allow for MORE surface area as to not lock developers to this curve for VARIOUS potential reasoning. Restrictions could be made on the size of the curve and so on, but enforcing that it can only produce a certain format for covenant key ownership logic is unproductive in my opinion which is why I started this thread.

Quote from: vjudeu on July 15, 2024, 05:38:41 AM

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.

AND YOU'RE ADVOCATING FOR OP_CAT SOMETHING THAT REQUIRES A (DRUMROLL PLEASE) SOFT FORK!!! So why is it suddenly so easy when its OP_CAT sir riddle me that? In reality because of how utterly necessary this will be to make Bitcoin something other than a beta project for cryptographic money, getting it into the chain should not be super difficult. Similarly to how other actual improvements went very smoothly on Bitcoin. Similarly to how OP_CAT was forked out of the chain because it was constantly misused due to its confusing implementation. If it was reconfigured old scripts with OP_CAT are now consensus invalid, not that there would be many but its an extremely non-Bitcoin-like update, that draws from nostalgia instead of practicality. If in-fact OP_CAT is re-added w different functionality it would technically be the first breaking backwards compatibility change to the network as far as I can tell. If the functionality is not changed its just as problematic as it was before and there's no sense in trying to re soft fork it back in just because a couple of hacks were found for it.

Quote from: vjudeu on July 15, 2024, 05:38:41 AM

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.

My proposal is that the proper approach is generalization and modularity, two features held extremely highly in all areas of software development. If you are a software developer you should recognize why these are important immediately. This can happen in the way that an OP_CODE might free you up to provide your own generator point for the curve, it might allow you to perform scalar multiplication and modulo operations wherever it is necessary in your curve point formula, not just wherever it seemed to work with the first design built for a specific kind of covenant. It can combine the features of off chain and on chain script commitments instead of locking you into one or the other. The possibilities go on. When you have CHECKLAMPORT you get one thing, Lamport signatures, and whoever doesn't want to use them can eff themselves as far as you are concerned. I see no reason Bitcoin should be that elitist about cryptographic protocols, I only see reasons for incentivizing it to flourish into a research ground for novel protocols. Failing to scale the l1 due to cryptographic elitism seems very silly. Like I said before there are several alt-chains that have this exact modularity running in practice on their mainnet today.

Quote from: vjudeu on July 15, 2024, 05:38:41 AM

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.

Yes I get that I need to do that, but my thread was directed at trying to identify why it's me coming up with this idea. I might try to but I'm not professing that I have the best implementation for it right now. For now Im still convinced its the best approach towards scaling Bitcoin script. Im not fully against others like lamport and cat and ctv or whatnot but i am suspicious of them being adopted before something that I find to be more general and practical. Mainly that they wont match their hype and fail to scale Bitcoin to the extent it really needs to be scaled even if it does extend Bitcoins throughput by a little bit. Furthermore, I will be attempting a BIP about this and anyone who wants to help can message me. It will probably need to be a community effort if it succeeds at all.