No input Class Upgrade – A new & sig hash flag class

It is already well-known that Bitcoin transactions contain cryptographic signatures which makes it very easy to prove that the holder of a public key wishes to spend Bitcoin on that transaction. But, contrary to the beliefs of many users, not the entire transaction is signed. The party that is actually signed is signaled in a transaction by the “sighash flag” sign.

Noinput Class Upgrade

A new “sighash flag” class is being proposed by Christian Decker (developer at Blockstream) and Xapo’s Towns. They propose SIGHASH_NOINPUT, SIGHASH_ANYPREVOUT and SIGHASH_ANYPREVOUTANYSCRIPT. All these new types of flags (flags) offer a similar solution. We will refer to them in this article as “Noinput Class”.

If we include in a transaction one of the methods of signing above, we will indicate that the outputs (outputs – the “receiving” part of the transaction) as well as other data from the transaction will be signed using the private key and not the inputs (the inputs – the part). “sending” the transaction). Due to the fact that we do not sign the “inputs”, it is possible to take over the transaction and change it with a different and compatible “input”.

There is usually no other compatible input since the signature corresponds to a unique public key and this public key has control over a unique amount of Bitcoin. By changing the input, the changes on the transaction make it invalid.

On the other hand, there are situations in which the input can be modified. Bitcoin transactions for the new type of payment protocol LN (no: Lightning Network), called Eltoo, can accept the modification of the input (the input part of the transaction) with another compatible one. This greatly simplifies the creation of payment channels. It should be noted that bugs and other mistakes will not lead to the loss of funds from a channel and users will not have to save so often the data for a possible recovery of channels and bitcoin respectively.

So far, the downside to using Noinput Class has been that SIGHASH_NOINPUT can be unsure if it is not known exactly how to use it. SIGHASH_ANYPREVOUT and SIGHASH_ANYPREVOUTANYSCRIP T solves this problem (Taproot compatibility is also solved – see part one) but are a little more complex to use.

However, other developers have mentioned that OP_CHECKTEMPLATEVERIFY or even OP_cat (an OP code that was excluded from the code but could be reintroduced with Tapscript) could offer the same benefits as these proposed new upgrades.

OP_CHECKTEMPLATEVERIFY (CTV) is known to us as OP_SECURETHEBAG from previous versions of the code. OP_CHECKTEMPLATEVERIFY is a new OP code proposed by Jeremy Rubin whose main advantage is the reduction of the fees paid to the miners and the maintenance of the network’s operation when many pending transactions occur. We will discuss further in the next article.

What do you think about the Noinput Class Upgrade, do we keep or modify it?