Feed for tag: sighash_noinput
Summary for December 2018
We’ve been taking a break for the past two months while working on a website upgrade. Since we did not cover news in that time, we decided to make a series of recap articles covering the last two months, starting with news related Bitcoin Core and going through Lightning Network and its related updates.
Safer Noinput With Output Tagging
Regarding NOINPUT, there was a proposal that would try to mitigate the risk of accidental double payment, as NOINPUT brings Bitcoin smarter contracts, these contracts can also be abused or used in a dumber way, the proposal here is that a certain bit will be used as a flag to let wallets know that this transaction can be spent with NOINPUT, the tag must be explicitly made by the payer and can have one of two implementations, the first would be a bit in the tx version, the second would be a bit in the scriptPubKey.
BIP Draft Sighash2

A new SIGHASH scheme is currently being discussed, called SIGHASH2, it is said to have more flexibility without introducing much complexity and it solves a few minor issues with BIP143.

Some of the new hashtype definitions are signing fees to make sure they are correct without signing some inputs, decoupling INPUT and SEQUENCE to have a NOINPUT option with a relative lock-time, signing INPUTINDEX, putting NOVERSION, for enforcing BIP68, and NOSCRIPTCODE, in case the public key is being reused, in the second byte some reserved bits for the future and lastly sigversion to avoid any conflict between past SIGHASH schemes and any future ones.

Sighash noinput update

A few months ago there was a formal proposal for sighash_noinput, it’s a new OPCode to be used in a technology called Eltoo. Eltoo is built on top of Lightning to resolve problems with malicious channel closing, currently the way to solve this is by giving all of the channel’s funds to the victim, but this, in some cases, would require the entire channel’s history to be broadcast, which isn’t remotely efficient.

Sighash_noinput brings a solution to this case, as mentioned in the Bitcoin BIP:

It removes any commitment to the output being spent from the signature verification mechanism. This enables dynamic binding of transactions to outputs, predicated solely on the compatibility of output scripts to input scripts.

But there was some controversy that this enables other malicious use cases if it was used in anything other than LN and Segwit transactions, developer Christian Decker mentioned that this is to be used only in very specific scripts and should not be available for general wallets to sign with.

Eltoo: Lightning Update Mechanism

The Blockstream team published a proposal for a new Lightning network update mechanism called Eltoo.

One of the core innovations that enabled Lightning in the first place was an off-chain update mechanism to renegotiate a new state and ensure that the old state can not be settled on-chain. Today, we’re excited to release our latest research paper on a new, simplified, update mechanism for layer 2 protocols, called eltoo.

[Paper Pick] Eltoo a Simple Layer2 Protocol for Bitcoin

This was published alongside the new Eltoo lightning update mechanism by blockstream.

From the abstract:

Bitcoin, and other blockchain based systems, are inherently limited in their scalability. On-chain payments must be verified and stored by every node in the network, meaning that the node with the least re- sources limits the overall throughput of the system as a whole. Layer 2, also called off-chain protocols, are often seen as the solution to these scalability issues: by renegotiating a shared state among a limited set of participants, and not broadcasting the vast majority of state up- dates to the blockchain, the load on the network is reduced. Central to all Layer 2 protocols is the issue of guaranteeing that an old state may not be committed once it has been replaced. In this work we present eltoo, a simple, yet powerful replacement mechanism for Layer 2 protocols. It introduces the idea of state numbers, an on-chain en- forceable variant of sequence numbers that were already present in the original implementation, but that were not enforceable.