Quote from: vjudeu on July 08, 2024, 07:50:26 AM

Quote

I forgot to mention scripts like InspectInputValue and InspectOutputValue are probably required too

That's why people are supporting OP_CAT: to not think about all corner cases, and to not activate a new soft-fork, and find out, that "hey, we forgot that one little thing, and we are stuck with what we already have".

OP_CAT does not enable things like inspectoutputvalue, this is part of my point, your philosophy is like "OP_CAT will solve all of this" but you fail to present a formal proof of that. Meanwhile formal proofs for various forms Discrete Log Curve Point cryptography are being built even with no input from Bitcoiners.

Quote from: vjudeu on July 08, 2024, 07:50:26 AM

Quote

it should be up to the protocol developer to determine what curve (and protocol math) they are using

Why do you want to support every possible curve, instead of simply using DLEQ, and having secp256k1 on Bitcoin, and any other curve you want, in some other place, like LN? Do you also want to support weak curves like "p=79, n=67, base=(1,18)"? Because the consequence of having EC_MUL, is to also have weak and unsafe curves, picked by the users. And we don't want to go back to those times again: https://words.filippo.io/dispatches/parameters/

Weak curves are utterly irrelevant, people can ship malware using Bitcoin TODAY, you are simply concern trolling about the extent of potential failures in cryptographic algorithms. This kind of closed minded thinking is exactly what I'm talking about, instead of imagining what kinds of scaling protocols can be made by leveraging well researched cryptosystems, we theorize that one might build a wallet using a weak curve... as if there was no other way to ship Bitcoin wallet malware already.

Quote from: vjudeu on July 08, 2024, 07:50:26 AM

Quote

That may also be used for migrating to different curves without hardforks.

You can do even more than that in the current system. You can actually deploy Lamport Signatures, without any changes at all, not only without hard-forks, but also without soft-forks as well.

I think it's incredibly misleading to suppose that because someone found a hack with known vulnerabilities still and not ready for production way to do Lamports on current Bitcoin, that suddenly that makes this implementation ideal and also means that all other crypto-systems are possible. You seem like you are arguing for halting innovation all together with this mentality. Bitcoin does not need more weakly defined hacks establishing themselves as legitimate protocols to unfortunately and inevitably leave end users holding the experimental bags. We need well defined standards that legitimately increase the surface area for innovation.

Quote from: vjudeu on July 08, 2024, 07:50:26 AM

Quote

Current scaling proposals AFAIK have not considered how to tackle costing for every script that can possibly be written for their templates

The main idea is that you should spend coins by key. Then, a single signature is all you need. All features like OP_CAT, the whole TapScript support, all of those MAST-based branching, is only for disagreements (and for hidden commitments, which will be never pushed on-chain). Which means, that you should use a single signature on a daily basis, and a TapScript only, when another party stops cooperating, so you can say: "You don't want to cooperate? Well, then I am going to use OP_CAT, pay more fees, and enforce this contract on-chain!".

Yea you are describing a scenario in which you would lose to an attacker capable of fee pinning, there's no innovation there again. Sure it's extremely easy to create some contract that's tied to an off-chain script, its also incredibly easy to embed vulnerabilities in the entire process of funding and claiming from such scripts. This is asking for a lack of standardization to proliferate into vulnerabilities, the alternative I'm offering is a basic standard that would support all the current proposals and more. The lack of basic curve point functionality prevents many extremely straightforward approaches to securing these contracts and preventing pinning attacks entirely.