Pierre Rochard from BitcoinAdvisory.com wrote a great series of articles where he covers in details his participation at the ChainCode Labs Lightning residency event.

He was also a speaker at the event where he presented his lightning project: a plugin for M$ excel ! (Link to the talk and the Transcript)

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.

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.

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.

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.

• Link to paper