{"id":19950,"date":"2019-06-14T23:01:25","date_gmt":"2019-06-14T23:01:25","guid":{"rendered":"http:\/\/ci027cfe6c501026c3"},"modified":"2025-01-27T21:50:40","modified_gmt":"2025-01-27T21:50:40","slug":"statechains-sending-keys-not-coins-to-scale-bitcoin-off-chain","status":"publish","type":"post","link":"https:\/\/bitcoinmagazine.com\/technical\/statechains-sending-keys-not-coins-to-scale-bitcoin-off-chain","title":{"rendered":"Statechains: Sending Keys, Not Coins, to Scale Bitcoin Off-Chain"},"content":{"rendered":"
<\/div>
<\/figure>\n

Block space is limited: The Bitcoin blockchain can only process some 10 transactions per second, at most. To resolve this, Bitcoin\u2019s technical community is developing second-layer protocols that process transactions \u201coff-chain,\u201d such as the Lightning Network<\/a> and sidechains<\/a>. Using clever cryptographic tricks, these transactions are batched to periodically settle on the Bitcoin blockchain as a single transaction.<\/p>\n

Now, a new second-layer protocol is entering the fray. Statechains<\/a>, first proposed by Seoul Bitcoin Meetup<\/a> organizer and Unhashed Podcast<\/a> 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.<\/p>\n

Here\u2019s why that\u2019s not as crazy as it sounds.<\/p>\n

Why Statechains Are Secure (More or Less)<\/h3>\n

Simplified, a Bitcoin transaction is just a message that says which coins (\u201cUTXOs\u201d) move from which addresses (\u201cinputs\u201d) to which addresses (\u201coutputs\u201d). 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.<\/p>\n

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 \u2014 let\u2019s be original and call her \u201cAlice\u201d \u2014 sends a private key to the recipient \u2014 why not call him \u201cBob\u201d? \u2014 there is no way for Bob to be sure Alice didn\u2019t keep a copy of the key. If she did keep a copy of the key, which we\u2019ll call the \u201ctransitory key\u201d in this context, Alice can still spend the coin on the blockchain, so the coin isn\u2019t exclusively Bob\u2019s at all.<\/p>\n

Statechains\u2019 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.<\/p>\n

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 <\/em>if, the last recipient of the transitory key asks him to.<\/p>\n

So, let\u2019s say Alice sets up a statechain, with Victor as the facilitator. Alice generates a transitory key, Victor generates Victor\u2019s key, and they use their two keys to create a multisig address. Alice then sends one bitcoin to this address, \u201clocking it up\u201d 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.<\/p>\n

But that, of course, misses the point of the statechain. Alice has a better idea. Alice instead sends the transitory key<\/em> 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.<\/p>\n

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.<\/p>\n

Should Bob ever want to move the coins to someone else \u2014 say, Carol \u2014 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\u2019s. 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.<\/p>\n

Not Trusting Victor<\/h3>\n

The scenario as described above doesn\u2019t actually remove all trust from the system. Rather, a good deal of trust is put on Victor.<\/p>\n

For one, if Victor doesn\u2019t sign a blockchain transaction when requested, the coin cannot be moved at all. (Maybe Victor\u2019s computer crashed, or he got hit by a bus, or maybe Victor \u2014 aware of his power \u2014 blackmails the last recipient of the transitory key to pay him part of the coin in return for the signature.) <\/p>\n

This problem can be solved \u2014 but this is where the statechain design does get slightly more complex.<\/p>\n

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<\/em> this multisig address to a new address. <\/p>\n

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.<\/p>\n

Alice does not <\/em>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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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<\/a>. Eltoo would allow Bob to \u201coverride\u201d Alice\u2019s 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\u2019s update transaction with his own to get the money.<\/p>\n

First problem solved.<\/p>\n

Trusting Victor (a Bit)<\/h3>\n

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 \u2026 and so forth.)<\/p>\n

This problem cannot actually be solved entirely \u2014 and this is perhaps the biggest drawback of statechains. But the risk can be minimized.<\/p>\n

One step toward minimizing this risk is to \u201csplit up\u201d Victor and replace him with several entities. \u201cVictor\u2019s key\u201d 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 \u201cVictors\u201d should be harder than colluding with just one Victor.<\/p>\n

Second, it can be made obvious to the outside world if these \u201cVictors\u201d cheat. This is done by essentially creating a new, miniature blockchain \u2014 indeed, the \u201cstatechain\u201d \u2014 where Alice, Bob, Carol and the others sign a message confirming they\u2019ve 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\u2019t worked out yet, but this is not a very difficult problem to solve.)<\/p>\n

Third, these \u201cVictors\u201d 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 \u2014 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\u2019s Liquid or the current implementation of RSK Labs\u2019 RSK.<\/p>\n

And that\u2019s it!<\/p>\n

<\/figure>\n

Limitations of Statechains (and Potential Solutions) <\/h3>\n

On top of the required trust in \u201cthe Victors\u201d not to collude with a previous statechain participant, statechains do have some limitations.<\/p>\n

Limitations<\/h3>\n

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.<\/p>\n

Another limitation is that statechains only allow for the transfer of whole UTXOs; Alice\u2019s 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.<\/p>\n

Solutions<\/h3>\n

Still, this is not necessarily a showstopper. For one, statechains can be combined with another trick called \u201catomic swaps.\u201d 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. <\/p>\n

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). <\/p>\n

Plus, since Lightning transactions have the opposite problem \u2014 large value transfers are harder to complete than smaller ones \u2014 statechains and the Lightning Network could complement each other quite nicely.<\/p>\n

Privacy Questions<\/h3>\n

It\u2019s 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\u2019d sign.) <\/p>\n

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.<\/p>\n

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\u2019 potential.<\/p>\n

Finally, statechains are, of course, a relatively new concept; peer review is ongoing.<\/p>\n

Thanks to Ruben Somsen for information and feedback. For more information on statechains, see his <\/em>explainer<\/em><\/a> on Medium or his presentation at <\/em>Breaking Bitcoin<\/em><\/a> in Amsterdam.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

Statechains, a new second-layer protocol, turns the concept of a Bitcoin transaction on its head.<\/p>\n","protected":false},"author":2509,"featured_media":13182,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[35],"tags":[3359,460,396,708,989],"class_list":{"0":"post-19950","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-technical","8":"tag-breaking-bitcoin","9":"tag-lightning-network","10":"tag-sidechains","11":"tag-transactions","12":"tag-utxos"},"author_data":{"id":2509,"name":"Aaron van Wirdum","nicename":"aaron-van-wirdum","avatar_url":"https:\/\/bitcoinmagazine.com\/wp-content\/uploads\/2024\/12\/aaron-van-wirdum-96x96.jpg"},"featured_image_url":"https:\/\/bitcoinmagazine.com\/wp-content\/uploads\/2024\/11\/statechains.jpg","_links":{"self":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/19950","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/users\/2509"}],"replies":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/comments?post=19950"}],"version-history":[{"count":0,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/19950\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media\/13182"}],"wp:attachment":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media?parent=19950"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/categories?post=19950"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/tags?post=19950"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}