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…

Article Source…