Scalability has been a central issue within the Bitcoin community for well over a year now.
Amongst the most promising innovations being developed are bidirectional payment channels. These can be extended to the Lightning Network, allowing users to transact securely with minimal footprint on the blockchain. Performance of these solutions would be significantly improved by Segregated Witness, the protocol upgrade proposed by the Bitcoin Core development team. However, the Segregated Witness soft fork has not activated yet.
Last week, four researchers from Imperial College London and Cornell University — Joshua Lind, Ittay Eyal, Peter Pietzuch and Emin Gün Sirer — proposed a different payment channel solution. Loosely resembling the OtherCoin concept, the researchers published a white paper detailing their implementation, dubbed “Teechan,” and successfully tested an early version of the software.
Speaking to Bitcoin Magazine, Eyal said he believes Teechan is superior to the proposed alternatives.
“Teechan is more efficient than other payment channels. It’s faster to complete a payment, and allows for more payments per second,” the Cornell University researcher said. “Plus, it doesn’t require any changes to the current Bitcoin protocol.”
The Good Ol’ Payment Channel
In essence, Bitcoin payment channels are just multisignature (“multisig”) addresses, but leveraged in clever ways.
Let’s say Alice and Bob want to open a payment channel between them. To do so, they create a 2-of-2 multisig address, for which each will generate and control one private key. Funds from this multisig address can be spent only if both Alice and Bob sign a transaction with their private keys.
Next, both Alice and Bob send funds to this address; perhaps one bitcoin each. This funding transaction is broadcast and recorded on the Bitcoin blockchain, so the bitcoins are “locked in.”
As such, the “channel state” is 1-1: they both have a balance of one bitcoin each.
Now, Alice wants to buy a pair of shoes from Bob worth 0.1 bitcoins. Instead of sending 0.1 bitcoins to Bob on the blockchain, Alice and Bob just agree that Bob should now get 1.1 bitcoins from the multisig address, and Alice 0.9 bitcoins.
As such, the channel state is 0.9-1.1. Alice has effectively paid Bob 0.1 bitcoins.
If Alice or Bob (or both) want to close the channel, they sign and broadcast a transaction from their multisig address, which pays each their share as determined by the latest channel state. In this case 0.9-1.1.
“The beauty of payment channels is that, in the meantime, Alice and Bob could have transacted thousands of times,” Eyal said. “As long as they don’t broadcast transactions to the Bitcoin network, they can keep updating the channel, effectively paying each other ‘off-chain’ as much as they want.”
Of course, there are some challenges in making all this work securely. Most important, payment channels require some kind of solution to ensure that counterparties sign off on a transaction representing the latest channel state. And payment channels require some kind of solution to ensure that counterparties sign off only on the latest channel state. (If Alice, for example, could broadcast an older channel state, it would allow her to claim the full 1 bitcoin even after she bought the shoes.)
Typical bidirectional payment channels solve this problem in novel ways that require time locks and other trickery. This works, but in some cases it requires a malleability fix (Segregated Witness) — which is still awaiting activation.
Lind, Eyal, Pietzuch and Sirer propose a different solution.
What’s in the Box?
Teechan, which stands for Trusted Execution Environment Channel, is a new payment channel protocol. Like Bitcoin itself, the solution is based on open-source software: transparent and verifiable by anyone.
But to ensure that Alice or Bob can broadcast the latest channel state and onlythe latest channel state, Teechan leverages “trusted execution environments” (TEEs). TEEs are secure hardware components included in Intel CPUs with Software Guard Extensions (SGX); many new computers have them. (See full list here.)
“With SGX TEEs, no one can ‘look inside’ to see what’s going on. Unencrypted data never leaves the chip, and so not even the owner of a computer with an SGX can observe what these chips are doing; they only see the end result,” Eyal explained.
With Teechan, both Alice and Bob first have their own TEE generate a public and private key pair. Because these keys are generated inside of the TEE, neither Alice nor Bob knows what “their” private keys are.
Then, Alice and Bob have their TEEs connect and swap public keys. As such, their TEEs can actually communicate in encrypted form, ensuring that Alice and Bob cannot decipher what their TEEs are communicating.
Additionally, Alice and Bob have both their TEEs generate a Bitcoin private key. Again, neither Alice nor Bob know what “their” own Bitcoin private key is; it’s inside the TEE.
Alice and Bob’s TEEs swap their private keys, in encrypted form over their secure channel. So, both TEEs now have both private keys — while Alice and Bob themselves know neither.
Then, with these private keys, their TEEs establish a pretty regular payment channel. They generate a multisig address, which both Alice and Bob then fund with, say, 1 bitcoin. This funding transaction is broadcast and recorded on the Bitcoin blockchain and is “locked in.”
Whenever Alice and Bob pay each other, they update the state of their payment channel, all from within their TEEs. In practice, this just means their TEEs keep track of the channel state. And both TEEs will update the channel state only if both Alice and Bob agree.
Finally, if Alice wants to close the channel, her TEE uses both Bitcoin private keys to sign a transaction reflecting the latest channel state. This transaction is broadcast to the Bitcoin network, and both Alice and Bob get their funds as determined by the latest channel state. (If Bob wants to close the channel, of course, Bob’s TEE signs this closing transaction.)
The TEEs solve both main payment channel challenges. Since both Alice’s and Bob’s TEEs control both Bitcoin private keys, they can always be sure to get their funds out. And the reason Alice and Bob cannot broadcast older channel states is simple: the Teechan software won’t allow it.
All the Trust That's Required to Make It Work ...
All this really only leaves one problem: Alice could lie to Bob about using a TEE in the first place — or Bob could lie to Alice.
Even though they would claim they created their Bitcoin private keys inside of the TEEs, and even though they’d exchange encrypted messages, they could be doing all of this from a regular CPU. Alice could hold on to all of her keys, allowing her to also decrypt Bob’s Bitcoin private key. With it, she could take all the funds from the channel.
This is where a little bit of trust comes in.
By a process called “remote attestation,” Intel — the creator of the SGX CPU that both Alice and Bob use — has a way to verify whether Alice and Bob are telling the truth. Using a special private key that only Intel should have, the technology company can use the first package Alice and Bob send across (the encrypted funding transaction), and check that it was produced both with the Teechan software and from their TEEs. However, Intel does not get to see the the content of the package; it remains encrypted.
If Alice and Bob trust Intel not to lie to them, they can be sure their counterparty really created the funding transaction from their TEEs. Alice and Bob can be sure neither of them know the Bitcoin private keys for their shared multisig address.
This works well if you trust Intel. Though of course, for this very reason, some Bitcoin purists won’t like the solution. For one, they don’t want to have to trust anyone, not even Intel. And second, the solution is not entirely permissionless: it requires a remote attestation license from Intel, which so far has been difficult to obtain.
Eyal, however, believes these concerns are overstated.
“Anyone running their Bitcoin software on an Intel machine is already placing their trust in Intel, so trusting the SGX mechanism seems natural,” he said. “And if they don’t, there are alternatives TEEs, if one prefers another TEE vendor due to trust or availability considerations. Additionally, the trust is limited to the involved parties: the participants in the payment channel, and the TEE vendor. Anyone outside the channel — all other Bitcoin users — remain oblivious to the channel construction and trust relations involved.”
The post The Teechan Solution: Scaling Bitcoin With Trusted Hardware appeared first on Bitcoin Magazine.
via Bitcoin Magazine http://ift.tt/2i8qy2K
No comments:
Post a Comment