Statechains: Sending Keys, Not Coins, to Scale Bitcoin Off-Chain

Block space is limited: The Bitcoin blockchain can only process some 10 transactions per second, at most. To resolve this, Bitcoin’s technical community is developing second-layer protocols that process transactions “off-chain,” such as the Lightning Network and sidechains. Using clever cryptographic tricks, these transactions are batched to periodically settle on the Bitcoin blockchain as a single transaction.

Now, a new second-layer protocol is entering the fray. Statechains, first proposed by Seoul Bitcoin Meetup organizer and Unhashed Podcast co-host Ruben Somsen, turns the concept of a Bitcoin transaction on its head. Instead of sending coins from address to address, statechain users just send the private key that can be used to spend the coins.

Here’s why that’s not as crazy as it sounds.

Why Statechains Are Secure (More or Less)

Simplified, a Bitcoin transaction is just a message that says which coins (“UTXOs”) move from which addresses (“inputs”) to which addresses (“outputs”). This message is cryptographically signed with the private keys corresponding to the sending addresses, proving that the owner of these coins created the transaction. The bundle (the transaction plus signatures) is then sent over the Bitcoin network to eventually be included in a Bitcoin block by a miner.

It is technically possible to just send private keys as payment instead: This allows the recipient of the private key to spend the associated coins. But it is not secure. If the sender — let’s be original and call her “Alice” — sends a private key to the recipient — why not call him “Bob”? — there is no way for Bob to be sure Alice didn’t keep a copy of the key. If she did keep a copy of the key, which we’ll call the “transitory key” in this context, Alice can still spend the coin on the blockchain, so the coin isn’t exclusively Bob’s at all.

Statechains’ first solution to this problem is to add a second key to the mix. By locking the coin into a two-of-two multi-signature (multisig) setup, it can only be moved on the blockchain if both keys sign in agreement.

This second key is generated by a neutral party, Victor, who becomes the facilitator of the statechain. Victor has a very important task. Victor must sign a transaction if, and only if, the last recipient of the transitory key asks him to.

So, let’s say Alice sets up a statechain, with Victor as the facilitator. Alice generates a transitory key, Victor generates Victor’s key, and they use their two keys to create a multisig address. Alice then sends one bitcoin to this address, “locking it up” between Alice and Victor. Now, if Alice wishes to send the coin to Bob, she could create a transaction, sign it with the transitory key and ask Victor to sign it as well. With both signatures, Alice can broadcast the transaction, sending the coin to Bob as a regular blockchain transaction.

But that, of course, misses the point of the statechain. Alice has a better idea. Alice instead sends the transitory key to Bob and tells Victor that she did that. This makes Bob the last recipient of the transitory key. Bob can now contact Victor and ask him for a signature to help move the coin.

Alice does still have the transitory key herself as well. However, now, if she were to ask Victor to help sign a transaction to move the coin, Victor would refuse. Alice no longer owns the coin as far as Victor is concerned. And since she only holds the transitory key, she is indeed unable to move it on her own.

Should Bob ever want to move the coins to someone else — say, Carol — he could, of course, repeat the statechain trick. When he sends the transitory key to Carol and tells Victor, Victor will only cooperate with Carol from then on, effectively making the coin Carol’s. This process can be repeated an arbitrary number of times, forwarding the transitory key to Dan, Erin, Frank and so on, without ever requiring a blockchain transaction.

Not Trusting Victor

The scenario as described above doesn’t actually remove all trust from the system. Rather, a good deal of trust is put on Victor.

For one, if Victor doesn’t sign a blockchain transaction when requested, the coin cannot be moved at all. (Maybe Victor’s computer crashed, or he got hit by a bus, or maybe Victor — aware of his power — blackmails the last recipient of the transitory key to pay him part of the coin in return for the signature.)

This problem can be solved — but this is where the statechain design does get slightly more complex.

When she initially sets up the statechain, Alice takes a precautionary step. Even before sending the coin to the multisig address, she creates a "backup transaction" that sends the coin from this multisig address to a new address.

The coin can be spent from this new address under two conditions. Either both Victor and the owner of the transitory key sign the transaction, like normal, or Alice can spend the coins on her own after, say, a week.

Alice does not broadcast this backup transaction to the Bitcoin network. Instead, she gives it to Victor, asks him to sign the transaction and has him give it back to her.

Only after Alice has received this signed (but as yet not broadcasted) backup transaction from Victor does she send her coin to the multisig address. This way, even if Victor disappears, she can broadcast the backup transaction and claim the coins back after a week.

Now, when Alice wants to send the transitory key to Bob, she first contacts Victor and asks him to sign a new backup transaction for Bob and give it to him. So, when Bob gets the transitory key from Alice, he already has an unbroadcasted but signed backup transaction from Victor, allowing him to claim the coin if Victor disappears.

As one final touch, Alice and Bob (and all subsequent owners of the transitory key) use a trick designed for the Lightning Network called Eltoo. Eltoo would allow Bob to “override” Alice’s backup transaction with his own backup transaction. So if Alice ever tries to cheat by broadcasting her old backup transaction, Bob can either use the week that Alice needs to wait to cooperate with Victor and claim the coin, or he can simply override Alice’s update transaction with his own to get the money.

First problem solved.

Trusting Victor (a Bit)

While the problem of Victor disappearing is solved, there is another problem: Victor could cheat. He could collude with a previous owner of the private key, like Alice, to steal the coin from Bob, Carol, Dan, Erin, Frank or whoever was the last recipient of the transitory key. (He could later also collude with Bob to steal from Carol, Dan, Erin, Frank … and so forth.)

This problem cannot actually be solved entirely — and this is perhaps the biggest drawback of statechains. But the risk can be minimized.

One step toward minimizing this risk is to “split up” Victor and replace him with several entities. “Victor’s key” is divided. It thus becomes a multisig setup of its own where, say, eight participants out of, say, 12 must cooperate with the transitory key holder to move the coin. Colluding with eight “Victors” should be harder than colluding with just one Victor.

Second, it can be made obvious to the outside world if these “Victors” cheat. This is done by essentially creating a new, miniature blockchain — indeed, the “statechain” — where Alice, Bob, Carol and the others sign a message confirming they’ve forwarded the coin and to whom. If the Victors collude with Alice to spend the coin after she signed it off to Bob on the statechain, everyone sees. (The details of what this miniature blockchain itself would look like exactly aren’t worked out yet, but this is not a very difficult problem to solve.)

Third, these “Victors” could be well-known entities; for example, a group of Bitcoin companies. These companies would have their reputations on the line and, therefore, have something to lose by cheating — even if they could earn a coin by doing so. While not cryptographically perfect, this makes the security assumption for statechains similar to federated sidechains, like Blockstream’s Liquid or the current implementation of RSK Labs’ RSK.

And that’s it!

Limitations of Statechains (and Potential Solutions)

On top of the required trust in “the Victors” not to collude with a previous statechain participant, statechains do have some limitations.

Limitations

The first thing to note is that, as they are explained in this article, statechains do require two protocol upgrades: Schnorr signatures and Sighash_Anyprevout (or something similar). Both of these upgrades are works in progress but seem unlikely to be contentious.

Another limitation is that statechains only allow for the transfer of whole UTXOs; Alice’s coin in the context of this article. Since Alice initially locked up exactly one bitcoin, and she sends the transitory key corresponding to this bitcoin, she must pass on the whole coin, and so must Bob, Carol and the others. This is a pretty big limitation compared to a normal Bitcoin transaction, in which any fraction of a coin can be spent, with the remainder returned to the sender as change.

Solutions

Still, this is not necessarily a showstopper. For one, statechains can be combined with another trick called “atomic swaps.” This move would allow Alice to exchange her whole coin with Zach, who has two half coins, in such a way that neither needs to trust the other not to back out of the trade halfway. All this can happen without requiring an on-chain transaction. This increases flexibility.

Second, even transferring whole UTXOs can be very useful in some contexts. Perhaps most interestingly, it would allow participants to transfer entire Lightning channels. By balancing a Lightning channel to the exact right amount (for example, by first paying herself in a different channel), Alice can still pay Bob a fraction of the coin. As a bonus, this could let Bob open Lightning channels immediately, without requiring an on-chain funding transaction (which takes time and fees).

Plus, since Lightning transactions have the opposite problem — large value transfers are harder to complete than smaller ones — statechains and the Lightning Network could complement each other quite nicely.

Privacy Questions

It’s also not yet clear how much privacy statechains could offer exactly. In a worst case scenario, the Victors and other participants in the statechain would know exactly who paid whom. (Although in reality these would still be public keys, not real names.) There are ways to improve this when it comes to the Victors. Using blind signatures (a cryptographic trick first proposed by eCash inventor David Chaum in the 1980s), for example, has the added benefit of being able to offload responsibility for transactions from the Victors to the users themselves. (The Victors would ideally not even know what they’d sign.)

Privacy from other participants could in turn be solved with atomic swaps as well, which would help obfuscate the chain of ownership. There are probably more solutions to improve privacy, like CoinJoin adaptations. (This is, for example, also what the privacy-preserving Wasabi Wallet uses.) But details have yet to be worked out.

There are also some concerns about past participants in the chain trying to cheat by trying to claim coins through the backup transaction. While this would be unlikely to succeed, it would only cost an (on-chain) transaction fee to try, so opportunist cheating behavior might limit statechains’ potential.

Finally, statechains are, of course, a relatively new concept; peer review is ongoing.

Thanks to Ruben Somsen for information and feedback. For more information on statechains, see his explainer on Medium or his presentation at Breaking Bitcoin in Amsterdam.