Bitcoin’s Lightning Network — the overlay protocol for fast and cheap transactions — consists of payment channels. These payment channels today rely on a somewhat complex fallback mechanism to keep everyone honest and require some level of alertness from its users.
This could soon be simplified.
A small group of Bitcoin and Lightning developers is working on a new class of “sighash flags,” with names like SIGHASH_NOINPUT (“Noinput”), SIGHASH_ANYPREVOUT (“Anyprevout”) and SIGHASH_ANYPREVOUTANYSCRIPT (“Anyprevoutanyscript”). One or several of these could see deployment as a soft fork protocol upgrade in the not-too-distant future to help streamline the Lightning user experience in two big ways.
Here’s how.
The “Noinput Class”
Any Bitcoin transaction consists of several pieces of information. These, for example, include inputs (the data that “unlocks” coins), outputs (which “lock” the coins up again, specifying what is needed to spend them in the future) and more.
Additionally, at least one cryptographic signature is added. This signature corresponds to the public key (and thus the Bitcoin address) of the coins being spent, so it proves that the coin owner indeed wants to spend them. The signature signs the new transaction, proving that the owner agrees with how the coins are spent.
However, this signature does not need to sign each part of the new transaction. Using a “sighash flag,” the creator of a signature indicates exactly which parts of the transaction are being signed. For example, while “SIGHASH_ALL” indicates that most transaction data is signed (just not the signature scripts), “SIGHASH_NONE” indicates that only the inputs are signed — not the outputs. There are a few more sighash flags.
Now, a new class of sighash flags is being proposed — Noinput, Anyprevout and Anyprevoutanyscript — which we’ll refer to in this article as the “Noinput class.” This Noinput class indicates that the outputs and some other transaction data will be signed, but not the input. By not signing the input, it is possible to take a transaction, even after it is signed, and rewrite it to swap in a different but compatible input without having to generate a new signature.
Of course, more often than not, there wouldn’t be any other compatible input. The signature still corresponds to a specific public key, and this public key should be associated with a specific coin. Swapping in a random input would break this link and make the transaction invalid.
But there are some exceptions where the input can be swapped.
The Undesirable Scenario
First, an undesirable scenario.
While it is discouraged, it’s possible to accept several transactions on the same Bitcoin address, protected by the same public and private keys. If the same address is used to accept two transactions worth, say, one bitcoin each, this does result in two different outputs. These two different outputs could normally be spent only through two different inputs in follow-up transactions.
However, if one of the two coins is spent with a Noinput signature, that signature doesn’t specify which of the two outputs is actually spent and the signature corresponds with either: They are protected by the same public and private keys. This means that someone can rewrite the transaction, even after it is signed, to swap in the other input, thereby spending the other coin. In fact, the same transaction could be copied and rewritten to be broadcast twice, with the same Noinput signature, claiming both coins even when the sender meant to spend only one!
This would be undesirable indeed, and it is why the Noinput class is not intended to be used in regular wallets.
But there are also desirable applications of the Noinput class.
Eltoo
The first and most important potential application of the new sighash class is an alternative type of payment channel for the Lightning Network.
All Lightning channels are really just unbroadcasted transactions that spend funds from an address shared by two users. These users “update” the channel by signing and exchanging new transactions from this shared address every time a payment is made (or forwarded) between them. The latest “state” of the channel — an unbroadcasted transaction — is the only “real” one; broadcasting an older state would be cheating.
Participants in these channels are currently kept honest through a setup that includes “penalty transactions”: broadcasting an old state allows the channel partner to follow up with a transaction that claims all funds in the channel. This should (and usually does) suffice to keep participants honest.
The problem is that broadcasting an old channel state isn’t necessarily done intentionally. It may also be caused by a software bug. Sometimes it can happen due to an “honest” mistake, like a software backup gone wrong. In these cases, having all your funds drained from a channel is a very painful punishment, and some consider it too severe.
“Eltoo,” proposed by Blockstream’s c-lightning developers Christian Decker and Rusty Russell, and Lightning Labs’ lnd developer Olaoluwa Osuntokun, offers an alternative.
With Eltoo, both payment channel users hold on to a copy of the same unbroadcasted transaction called the “update transaction,” representing their funds in the channel. This transaction is signed by both users, so either can choose to broadcast it at any time, and it will confirm on the blockchain.
If someone broadcasts the transaction and it does confirm on the blockchain, the funds can subsequently be spent in two ways. One, both participants can spend their share after a timelock has run out; for example, after a week. Or two, the funds can immediately be spent to a newer mutually signed update transaction. Indeed, in Eltoo, update transactions are chronologically numbered. Update Transaction 3 can spend the funds from Update Transaction 2, and Update Transaction 2 can spend the funds from Update Transaction 1, but not the other way around.
This is actually already possible with the current Bitcoin protocol. But because the inputs of an update transaction need to be signed, specific update transactions can only refer to a specific output from a specific update transaction that came before it. Update Transaction 3 could claim funds from Update Transaction 2, but not from Update Transaction 1.
This isn’t very practical. If there are, say, 100 update transactions, and the very first of these is accidentally (or intentionally) broadcast, the “real” channel balance could only be restored by broadcasting all subsequent update transactions. (Update Transaction 1 spends to Update Transaction 2, which spends to Update Transaction 3, all the way to 100.) This chain of transactions would present a big burden to the Bitcoin network. It would require many fees, more or less defeating the purpose of using payment channels in the first place.
Eltoo is, therefore, really only useful if update transactions can be skipped. Update Transaction 3 must be able to spend funds not only from Update Transaction 2 but also directly from Update Transaction 1.
It’s this skipping that requires the Noinput sighash class. By swapping the input, the latest update transaction can always be rewritten to refer directly to any other update transaction. And swapping inputs is possible because, no matter which previous update transaction is picked, in a payment channel the required signatures are always from the same two users with the same two public and private keys.
An Eltoo Example
So, here’s what Eltoo would look like in practice.
Let’s say that Alice and Bob have an Eltoo Lightning channel open for a while, and the channel state has been updated 100 times. As such, they both hold on to Update Transaction 100, which spends funds from Alice and Bob’s shared address. It represents the latest state of the channel and is signed by both of them. Both Alice or Bob can choose to broadcast this update transaction at any time, in which case they can claim their share of the funds after, say, a week, when the timelock expires. (It’s actually more likely that they would opt for a regular, “cooperative” close if they do close the payment channel, as they wouldn’t have to wait a week to spend the funds — but never mind this for now.)
Now, if Alice accidentally broadcasts an old channel state, say, Update Transaction 13, and this transaction confirms on the Bitcoin blockchain, the funds are also timelocked for a week. During this week, Bob can take Update Transaction 100, rewrite it by swapping the input to refer to Update Transaction 13 instead and broadcast this.
Bitcoin nodes and miners on the network see Update Transaction 100 and conclude that it is valid. It refers to a chronologically earlier update transaction, and it includes valid signatures from both Alice and Bob, as required by the output in Update Transaction 13.
Once Update Transaction 100 is confirmed, both update transactions are included in the Bitcoin blockchain, with all the funds waiting in Update Transaction 100 for a week until both participants can claim their share. (Though Alice and Bob could, again, speed this up with a cooperative close.)
So despite Alice’s mistake, the channel was closed according to the latest channel state, attributing to both Alice and Bob what they’re owned, without any further punishment and without requiring update transactions 1–12 and 14–99 to be broadcast at all.
Lightning Watchtowers
Eltoo payment channels are useful in and of themselves, but they also benefit another Lightning Network innovation: watchtowers.
To avoid being cheated on (with or without Eltoo), Lightning users must keep track of the Bitcoin blockchain to see if an old channel state was broadcast. If that does happen, they have some time to respond and correct the situation; a week, in the examples above.
Currently, without Eltoo, this response consists of a penalty transaction, which drains all the funds from the channel and lets the “honest” user claim it. Importantly, every previous state of the channel has its own unique penalty transaction. If a payment channel was updated 100 times, both participants must hold on to 100 penalty transactions: That’s 200 penalty transactions in total. (There are some ways to reduce this data, but the difference is marginal.)
With Eltoo, this is no longer necessary. No matter which old state is broadcast, a payment channel user can correct any of it by simply broadcasting the latest channel state. Both users would only need to hold on to a copy of one and the same update transaction, and rewrite it to swap the input if needed.
Watchtowers in particular could greatly benefit from this.
Watchtowers are a special type of service provider on the Lightning Network that monitor the blockchain for other users. If they see a cheating attempt, they can broadcast the transaction that sets the record straight — presumably in return for a fee. The presence of watchtowers would make cheating practically impossible.
However, a watchtower monitors not just one channel but potentially thousands or maybe even millions of channels. All of these channels are updated frequently, and two new penalty transactions are created with each update. Thus, the number of specific penalty transactions a watchtower must hold on to could quickly balloon.
With Eltoo, watchtowers would only ever need the latest backup transaction for each channel — a much more sustainable model, making watchtower deployment more feasible.
Deploying the Noinput Class
There are currently two concrete proposals for the new sighash flag class. The first one is Noinput, initially proposed by Joseph Poon and Thaddeus Dryja in the Lightning Network white paper. It has now been drafted into a more concrete proposal by a c-lightning developer for Blockstream, Christian Decker, and formalized in Bitcoin Improvement Proposal (BIP) 118. Noinput was recently rebranded to Anyprevoutanyscript by a Bitcoin Core contributor for Xapo, Anthony Towns, who also proposed Anyprevout. There is a BIP for this set of proposals as well, but it doesn’t have a BIP number yet. Both Anyprevoutanyscript and Anyprevout are largely based on Noinput, but are specifically designed to be compatible with Taproot, another proposed Bitcoin Core protocol upgrade.
On top of that, Anyprevout signs a bit more transaction data and adds a feature designed to avoid the undesirable scenario described in the beginning of this article. To prevent an input being swapped against a user’s will (for example, after accepting several payments on the same address), this version of the sighash flag requires an additional signature, called the “chaperone signature,” that does sign the input. In Eltoo, this chaperone signature could be created by either channel partner. While this would be a bit more secure — it prevents a third party from swapping inputs — it also makes the sighash option more complex and fee expensive.
All in all, while the idea of this new type of sighash flag had already been presented several years ago, Noinput has really only been taken into serious consideration for about a year, and Anyprevout and Anyprevoutanyscript were proposed only some months ago. So far, no single specification of it has been definitely settled on. Decker, Towns and other Bitcoin and Lightning contributors are currently taking a conservative approach, favoring extensive peer review and room for discussion. As such, it is too soon to say when or if this sighash class will actually be deployed on the Bitcoin network — though it does seem likely that a version of it eventually will be.
For the sake of clarity, this article left out or simplified some implementation details. For a full specification of the proposals, see the BIPs for Noinput and Anyprevout. Thanks to Christian Decker and Anthony Towns for information and feedback.