Why are all the new proposals for scripting on Bitcoin application specific?

[sha420hashcollision]

Pretty much every proposal ive seen IE CTV, Vault, etc... creates a standardized structure for the contract which creates a literal cultural divide amongst programmers who prefer different scaling implementations.
Other than that you have CAT which as far as Im concerned is pitifully un-standardized and bound to create unimaginable side effects.

Currently there is no basic generic Elliptic Curve Point Contract functionality, that is a BASIC and NEEDED upgrade that should not be controversial what soever. This can easily enable any of the functionality that all above mentioned proposals seek to implement, without restricting anyone to any of the standards created by an individual proposal other than a basic standard for generic Curve Point math in Bitcoin Script.

...?

[BlackHatCoiner]

How could a "basic generic Elliptic Curve Point Contract" enable all of the functionalities of the aforementioned popular proposals? Can you give a little bit more context? For example, how can you specify how any coins received to an address may be spent without introducing CTV?

[vjudeu]

For example, how can you specify how any coins received to an address may be spent without introducing CTV?

Fears about securely buying domains with Bitcoins are a red herring.  It's easy to trade Bitcoins for other non-repudiable commodities.

If you're still worried about it, it's cryptographically possible to make a risk free trade.  The two parties would set up transactions on both sides such that when they both sign the transactions, the second signer's signature triggers the release of both.  The second signer can't release one without releasing the other.

And this is not only about multisig. This is about more general approach of unlocking things, by signing two messages by two parties. If you have OP_CHECKSIGFROMSTACK, then you can have two transactions: one on Bitcoin, one anywhere else (may be also on Bitcoin). And then, you can use the same signature, to release both coins, even if transaction IDs are completely different, and even if both are placed on different chains. It does not matter. If you can have OP_CHECKSIG on BTC, and OP_CHECKSIGFROMSTACK on ALT, then you can use a single signature to release both coins.

Edit: By the way, note that in 2010, in this thread, people talked about buying domains with Bitcoin, not with NameCoin, or some alternative coins, created out of thin air. Which is another confirmation, that introducing any new coins at all, was one of the biggest NameCoin's mistakes. All they should do, is to provide a way to wrap existing Bitcoin signatures into their own consensus rules, and execute contracts on their chain, based on that information.

[BlackHatCoiner]

[...]

It's just amazing how he was talking about things like OP_CHECKSIGFROMSTACK before we even grasp the whole blockchain concept. Is there any reason he didn't include it in v0.1?

And then, you can use the same signature, to release both coins

Doesn't that require both coins using the same elliptic curve? OP_CSFS will run on Bitcoin software, which has no knowledge of e.g., Curve25519, which is used by Monero. Or is the client supposed to be customizable, with extensions like Monero swaps? (As a potential use case, trading BTC for XMR trustlessly, and therefore not needing to run on the same curve, since Curve25519 will be included in the extension.)

By the way, note that in 2010, in this thread, people talked about buying domains with Bitcoin, not with NameCoin

We could have that decentralized DNS with OP_CSFS, but I cannot think of any other ways. (Namecoin obviously isn't the way to go, due to the creation of another token.)


BTW, before, I meant "how to do this without introducing CTV or any other such popular proposal, like OP_CSFS". Do you understand what the OP is talking about?

[vjudeu]

Doesn't that require both coins using the same elliptic curve?

1. A lot of altcoins just copy-pasted secp256k1, so it is not a big deal.
2. Read about DLEQ proofs. It is possible to prove, that the same private key was used on two completely different curves, and then execute a contract in that way.

We could have that decentralized DNS with OP_CSFS, but I cannot think of any other ways.

There are a lot of other ways. The simplest example, which is used even today, is related to vanity addresses: you have a regular Bitcoin address, but you can mine N characters in the name, and have some unique identifier. Even better: imagine what would happen, if you would mine some Silent Payment address, to avoid address reuse.

And that way is not only limited to Bitcoin: people also mine *.onion domains, in exactly the same way.

Do you understand what the OP is talking about?

As far as I know, a "basic generic Elliptic Curve Point Contract functionality" is what you will have, if you introduce OP_CHECKSIGFROMSTACK. But yes, you can have "<pubkey> <pubkey> OP_PUBKEY_ADD" or "<number> <pubkey> OP_PUBKEY_MUL" instead (or even "<numberAdd> <numberMul> <pubkey> OP_PUBKEY_MUL_WITH_ADD"). But in general, a signature is "multiplication and addition". Which means, that if you can sign any given message, then you unlock "mul and add" functionality, just by packing those two 256-bit numbers as a single signature.

Edit: By the way, you already have some "basic generic Elliptic Curve Point Contract functionality". Try this Script: "<signature> OP_SWAP OP_CHECKSIG". Then, you should push the proper public key as a solution.

Even better: try this: "OP_TOALTSTACK <signatureAlice> <signatureBob> 2 OP_FROMALTSTACK OP_DUP 2 OP_CHECKMULTISIG". Then, you just create "OP_0 <pubkey>" as a spending Script, and you have to find a key, which will match both signatures at the same time.

Edit:

There are a lot of other ways.

I guess there are more ways than people can imagine. For example, vanity addresses can be reused. However, there are things, which cannot be reused: transaction IDs. Which means, that you can just mine your transaction ID, and then share it. If anyone will change anything, then the name will be gone, and the ID will also change. It will be confirmed once or never. It will be always unique.

Also, no additional fields are needed. If you disable locktime, you can just use it as a nonce, and mine your transaction quite quickly. Other options, related to tweaking public keys or signatures, are much slower.

[sha420hashcollision]

Doesn't that require both coins using the same elliptic curve?

1. A lot of altcoins just copy-pasted secp256k1, so it is not a big deal.
2. Read about DLEQ proofs. It is possible to prove, that the same private key was used on two completely different curves, and then execute a contract in that way.

We could have that decentralized DNS with OP_CSFS, but I cannot think of any other ways.

There are a lot of other ways. The simplest example, which is used even today, is related to vanity addresses: you have a regular Bitcoin address, but you can mine N characters in the name, and have some unique identifier. Even better: imagine what would happen, if you would mine some Silent Payment address, to avoid address reuse.

And that way is not only limited to Bitcoin: people also mine *.onion domains, in exactly the same way.

Do you understand what the OP is talking about?

As far as I know, a "basic generic Elliptic Curve Point Contract functionality" is what you will have, if you introduce OP_CHECKSIGFROMSTACK. But yes, you can have "<pubkey> <pubkey> OP_PUBKEY_ADD" or "<number> <pubkey> OP_PUBKEY_MUL" instead (or even "<numberAdd> <numberMul> <pubkey> OP_PUBKEY_MUL_WITH_ADD"). But in general, a signature is "multiplication and addition". Which means, that if you can sign any given message, then you unlock "mul and add" functionality, just by packing those two 256-bit numbers as a single signature.

Edit: By the way, you already have some "basic generic Elliptic Curve Point Contract functionality". Try this Script: "<signature> OP_SWAP OP_CHECKSIG". Then, you should push the proper public key as a solution.

Even better: try this: "OP_TOALTSTACK <signatureAlice> <signatureBob> 2 OP_FROMALTSTACK OP_DUP 2 OP_CHECKMULTISIG". Then, you just create "OP_0 <pubkey>" as a spending Script, and you have to find a key, which will match both signatures at the same time.

Edit:

There are a lot of other ways.

I guess there are more ways than people can imagine. For example, vanity addresses can be reused. However, there are things, which cannot be reused: transaction IDs. Which means, that you can just mine your transaction ID, and then share it. If anyone will change anything, then the name will be gone, and the ID will also change. It will be confirmed once or never. It will be always unique.

Also, no additional fields are needed. If you disable locktime, you can just use it as a nonce, and mine your transaction quite quickly. Other options, related to tweaking public keys or signatures, are much slower.

I'm pretty sure you are mainly discussing off chain and side-chain contracts, the scripts you provided might already serve that use case, however more complex / flexible ECC scripting conditions would enable native contracts reducing reliance on a side chain or off chain client side validated contract.

L2s can use this to build more useful UX, for example with Point Time Lock Contracts the lightning network would now be able to build lightning native privacy protocols and multi-sig custody protocols where previously the hash based contracts limit the extensibility of Lightning altogether. That's a relatively simple example, but ultimately more flexibility would open the flood gates in terms of scaling solutions.

This is in juxtaposition to each scaling protocol needing to settle with an extremely strict or at least specific standard which puts more limitations on the flexibility of the end product. I forgot to mention scripts like InspectInputValue and InspectOutputValue are probably required too (they exist on liquid already) however I think that's good because all of this is just very basic straightforward scripting that doesn't require a programmer to study a long document to figure out how it works in detail. Yes one has to study ECC if they want to build a scaling protocol but that is a well documented subject already and wont need redefinition to include into Bitcoin.

You could have PUBKEY_MUL but you could also just have basic EC_MUL I really don't see why not, it should be up to the protocol developer to determine what curve (and protocol math) they are using. That may also be used for migrating to different curves without hardforks. All you have to do is provide the correct generator point which can easily be supplied by a library that you use to build your scripts. Maybe we will never have to change the curve but if we want to be able to flexibly interact with cryptographic protocols that use other curves, this feels necessary. Or in the case where the curve is irrelevant and you simply want to use the points for any kind of cross-protocol computation, the scripts need to be completely functional as to not limit the expressiveness of the protocol.

That also means alt-chains like XMR that use a different curve might gain more compatibility in protocols like atomic swaps which might help reduce interactivity. Atomic swaps are already possible with XMR except they are unidirectional until XMR hard-forks to allow pre-signed txs. The really positive thing is you could potentially use generic curve point scripts to build privacy protocols on top of Bitcoin, maybe a bulletproof or pedersen commitment script or something like that.

I think another positive result would be that the costing of executing these scripts would be transparent, you shouldn't be able to exhaust a nodes resources by creating some kind of hidden verification loop that might go undetected in a script that comes in the form of a large expected template. Current scaling proposals AFAIK have not considered how to tackle costing for every script that can possibly be written for their templates, likely because that is a huge undertaking to consider. Without granularly applying weight to each operation it cant be done in a fair way IMO.

[vjudeu]

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".

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/

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.

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!".

[sha420hashcollision]

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. Inspectvalue OPs are brutally necessary for building covenants. 

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.

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.

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.

[vjudeu]

OP_CAT does not enable things like inspectoutputvalue

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

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

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.

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.

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.

[sha420hashcollision]

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.

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.

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.

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.

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.