September has been a quiet month for Bitcoin, there was the honey badger conference and all the talks but there has also been some technical advancements in the background, enabled by the Eltoo proof of concept created by Richard Meyers and recent work on utreexo by Tadge Dryja.
Today we’re covering technical discussions that were done on the bitcoin-dev mailing list for the past month, have a good read!
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)
Margherita Favaretto, a student working on remediation protocol for Lightning Network double-spend attacks asked for feedback for a proposed solution to double spend attacks using a “trusted remediation” gossip protocol.
ZmnSCPxj pointed out that double spend attacks are not possible on the Lightning Network unless both parties involved in the channel agree to it, which is not likely, first because the man at the other end of the channel will lose money. Secondly even if the other end of the channel is irrational enough to help the other guy double spend, they will still ask for an invoice and give the money using “existing invoice-payment mechanisms.” ZmnSCPxj added:
If the problem you are trying to solve, is the inadvertent publication of revoked commitment transactions, then the correct solution is not to have revocable transactions in the first place, i.e. eltoo. While it can be argued that it would take time for needed features of eltoo to appear on the blockchain layer (SIGHASH_NOINPUT_UNSAFE), it would also take time to implement “trusted remediation”, by which time the problem could be solved by switching over to eltoo.
Content originally published by BitcoinOptech on newsletter #16.
The fifth Scaling Bitcoin conference was held Saturday and Sunday in Tokyo, Japan. In the sections below, we provide brief overviews to some of the talks we think might be most interesting to this newsletter’s readers, but we also recommend watching the complete set of videos provided by the workshop organizers or reading the transcripts provided by Bryan Bishop.
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.
On the Lightning Network, cheating is punishable by a total loss of funds. But how is cheating defined? In order for a LN user to cheat, they have to broadcast and incorrect balance. In some cases, the user could be attempting to hoodwink the user on the other end of the payment channel. In other cases, it could be a software bug or a network delay.
This is where Eltoo channels come into play. Eltoo essentially functions as a buffer, which uses “timelocked transactions” to maintain synchronization on a payment channel.
Currently, developers are designing trustless, blinded WatchTower for eltoo channels as described by ZmnSCPxj via Lightning-dev:
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.