Timelocks and Atomic Swaps: April 7, 2019 Snippets
As always, thanks for reading. Want Snippets delivered to your inbox, a whole day earlier? Subscribe here.
This week’s theme: how we can use cryptography to write post-dated cheques, and why that’s useful. Plus news from Clearbanc and Relativity.
In our ongoing Snippets series about the Lightning Network, so far we’ve covered some basics around what it is: a network of user-established payment channels that sits on top of Bitcoin or another cryptocurrency. We’ve also talked last week about “Watchtowers”, an interesting idea on how to police a distributed network of Lightning channels in order to make sure no one is gaming the system to their advantage. (As a reminder, if you’re just arriving now to this series and want to catch up on the basis of how Bitcoin and proof of work cryptocurrencies function, here’s a primer for you.)
You may recall that over the past two weeks, we glossed over one particular design feature of the Lightning Network that’s crucial for preventing misbehaviour within channels — the ability to specify time-locked transactions who only mature after a certain delay, kind of like a post-dated cheque. We didn’t spend any time talking about how this works; we simply took for granted that such a thing could be done. This week, we’re going to pay this feature its due respect, first by outlining how these time-locked transactions work, and second by going further into an important new behaviour they allow: a kind of trust-less, two-party swap of one crypto asset for another in a way that requires no trusted third party, escrow, or other intermediary whatsoever.
First of all, let’s talk about time-locking. Some of you may recall that the actual, fungible unit that’s being traded from person to person, which we interchangeably call Bitcoins and has value we exchange with one another, is something funky called an “Unspent Transaction Output” or UTXO. This sounds intimidating, but it’s not hard to understand: if I send one Bitcoin to Ben, then what I’m really doing is giving Ben the right to sent it next. I’m telling the Bitcoin network: “I have specified that Ben is the new owner of the ‘unspent output’ of this transaction. The outcome of this transaction is that Ben, by signing with his private key, can now write a new transaction and specify a subsequent recipient.” Phrased another way, possession of a Bitcoin basically just means “the right to specify who it will go to next.” That’s it.
Now, here’s a thing. Remember when I told you that that what’s being broadcast by users and written into the blockchain by miners are these subsequent sequences of “I have the coin and have proved it’s me by signing with this private key; I now spend the key by specifying that Ben is the new owner. If you want to spend the coin by specifying a new subsequent owner, then sign with Ben’s private key in order to show you’re Ben”? Well, that’s generally what’s happening. But Bitcoin is a little bit more flexible than that. If I wanted to, I could skip the private key step (although this would be ill-advised, as then anyone would be able to spend the coin and it would be effectively stolen immediately), or I could specify multiple private keys that have to be signed in order for the coins to be spent; this is usually called multisig. Bitcoin is a programming language, albeit a very restricted one.
Now suppose I wanted to program a transaction that said, “I, Alex, am sending this UTXO to Ben. But I only want Ben to be able to spend the UTXO starting 48 hours from now”. Is there any way to do this cryptographically? Well, there sure is — and a public proof-of-work blockchain like Bitcoin comes pre-built with a robust way to handle this. Rather than specify a specific time and day as a condition which must be met for the transaction to be recognized as legitimate (which could potentially be gamed in creative ways), I can specify “in order for this transaction to be valid, we must be at least 200 blocks in the future from where we are now”. That’s quite secure — the only way for us to add 200 blocks is for a proof-of-work puzzle to be solved 200 times by the mining pool, and for our intents and purposes, there’s no way to speed that up.
The original Bitcoin protocol allowed us to do something similar to this, but there were a few issues to iron out; the biggest of which was that we only had a way to specify whether an entire transaction was legal or not legal. Ideally, what we’d want is to be able to write a transaction that says, “This transaction is legal and good to go as of right now. However, I want its unspent transaction output to itself be only spendable after 48 hours”, or however many blocks that corresponds to approximately. Recent upgrades to the Bitcoin network, known as Check Lock Time Verify (CLTV) and Check Sequence Verify (CSV) allow Bitcoin users to do this pretty easily.
Congratulations! We now have the ability to create cryptographically secured post-dated cheques. So what’s the big deal? First of all, you’ll remember from previous weeks that this is an important part of the Lightning Network’s security: if a user ever tries to close out a channel by broadcasting an invalid previous state, their redemption transaction on the main blockchain gets locked for a period of time, during which the other participant (or a watchtower) gets the opportunity to challenge by posting a more recent state. This deters any attempt to cheat, because you’ll be sure to be caught. However, that’s not all we can do with time locks. It turns out there’s another major application for cryptographically secured post-dated cheques sitting right in front of us, and that’s something called Atomic Swaps.
Atomic Swaps are a cryptographically secure way of accomplishing something pretty remarkable: a way for two strangers who don’t trust each other to exchange crypto assets with one another, even if they’re on different blockchains, and without a trusted intermediary. This is a classic coordination problem: if neither of you trusts the other, who hands over the gold first? Well, you can pay a third party to act as an intermediary; our financial system does this all the time. But is there any way where we can use cryptography to ensure that, for any swap that two parties engage in, either both transactions happen, or neither? (“Atomic” here simply means “either all or nothing”.)
Let’s approach this first with an analogy. Suppose we meet on Twitter, and we find out that I have a watch I’m looking to sell, and you’ve got a guitar you’re looking to sell, and lo and behold we come to an agreement to swap one for the other. Being cyberpunks, we’d like to do this in a way that requires no trusted intermediaries. So we agree to use a special pair of safety deposit boxes with clear transparent doors, and whose locks are magically and irreversibly linked together (by quantum mechanics or something), to conduct our transaction. The way it works is: I put my watch in one safe, and you put the guitar in the other safe, and then we mail them to each other. We each look into the safe through the clear window, and validate that we’re both happy with what’s inside. If we’re both good, then we each put our key into the lock, which then opens both doors simultaneously and we both get our proceeds. Sounds good? Well, we have a question to address: there needs to be a way to undo the transaction if for any reason it fails: surely, readers will be thinking, there must be some way we can use these cryptographically secure post-dated cheques to make this work? And yes; so long as both assets are represented on a cryptographically secured public blockchain, there is. It’s actually quite cool to walk through, so that’s what we’re going to do. It goes as following:
First, Ben and Julia reach a preliminary agreement to swap 1 BTC for 20 ETH. Ben picks a random number x known only to him, and then hashes it to create the hash product H(x). (If you’re unclear on how hashing works, read the primer! It’s important.) Then Ben creates two transactions:
TX1: “I, Ben, pay 1 BTC to Julia if either: a) Julia can provide the number x that successfully hashes to H(x), or b) Both Ben and Julia sign with our private keys.”
TX2: “I, the unspent transaction output from TX1, send 1 BTC to Ben’s public key, locked 48 hours in the future. Signed, Ben and _____”
Then Ben sends TX2 over to Julia; she looks it over, signs it in that blank space, and then sends TX2 back to Ben. Then Ben posts TX1 to the Bitcoin network. Julia can now look and verify that Ben’s offer for 1 BTC is genuine.
Recap: So far, what have we built? We’ve created a pair of transactions, TX1 and TX2, that is either a) going to pay out to Julia (if she can successfully provide this secret number x that Ben knows), or else b) return the coins to Ben after 48 hours (which it’s now fully permissioned to do, having been signed by both Ben and Julia).
Now for step two. Julia is now going to create a pair of very similar looking transactions on her end:
TX3: “I, Julia, pay 20 ETH to Ben if either: a) Ben reveals the number x that successfully hashes to H(x) (which, remember, Ben knows!), or b) both of us sign the transaction.”
TX4: “I, the unspent transaction output from TX3, send 20 ETH to Julia’s public key, locked 24 hours in the future. Signed, Julia and ______.”
Just as before, Julia then sends TX4 over to Ben, who looks it over, signs in that blank space, and sends it back to Julia. Now the fun begins:
Julia posts both TX3 to the network, which validates to Ben that her 20 ETH is genuine, and invites Ben to claim those 20 ETH by revealing the number x. Once he does, then Julia can now claim the 1 BTC in TX1, by using the now-known number x. We’ve just accomplished something cool: essentially a digital safe where opening one door opens the other door as well, even if those safes hold two different kinds of crypto assets. The key to the safe is simply knowing the number x. If for some reason Ben declines to open the first door (by not providing the number x), then after some period of time, both of them will be able to get their coins back by posting TX2 and TX4 respectively; no harm, no foul. Instead of trusting a third party intermediary, we can trust cryptography. Pretty cool!
One more thing: you may have noticed something odd, which is that the time delays on TX2 and TX4 aren’t the same — Julia’s is 24 hours, whereas Ben’s is 48 hours. Why? This isn’t just to pick on Ben — it’s an extra security feature meant to prevent against one way that Ben could theoretically abuse his position as being the X knower prior to the mutual transaction going down. Suppose the time lock for both TX2 and 4 were 24 hours. Ben could wait 23 hours, 59 minutes and 30 seconds, then execute his transaction really fast and then hope Julia doesn’t get the chance to complete her transaction in time before the 24 hour time lock expires (which would allow Ben to make off with both set of coins). Sneaky! Fortunately, there’s a really easy way to guard against this which is simply to give Julia more time than Ben. Hence, the asymmetric time lock, which sufficiently counterbalances the asymmetric prior knowledge of x.
Speaking of crypto, the SEC continues to have things to say, and people continue to draw pretty much whatever conclusion they already believed:
On crypto-legal frameworks and no-action letters | Stephen Palley, The Block
Podcast episodes for your listening enjoyment:
Casey Newton on Facebook and The Interface | Longform Podcast
What Grinds My Gears, Episode 13: You’ve been Liquidated | Jill Carlson & Meltem Demirors
Rob Delaney on wrapping up Catastrophe and working through grief | San Briger, NPR
Plus, I recorded a podcast along with Kim-Mai Cutler of Initialized Capital where we talked all about one of the subjects that fascinates me most: housing. Kim knows a lot more about housing than I do, particularly in the Bay Area, so it was a lot of fun to get to learn some things with her in real time. Erik Torenberg generously hosted. Give it a listen!
A deep dive on housing with Kim-Mai Cutler and Alex Danco | Venture Stories with Erik Torenberg
Capital concerns:
On startup capital efficiency | Steve Cheney
How to make startup stock options a better deal for employees | Steve Blank, HBR
Other reading from around the Internet:
Robert A Caro on the means and ends of power | David Marchese, NYT
YouTube executives ignored warnings, letting toxic videos run rampant | Mark Bergen, Bloomberg
Genetic paradox explained by nonsense | Miles F Wilkinson, Nature
Shopify’s latest moves are a sign of what’s to come in Ecommerce | Ann-Marie Alcántara, Adweek
And just for fun; first of all, the LA Times had this year’s only good April Fool’s joke:
For cramped New York, an expanding dining scene | Lucas Kwan Peterson, LA Times
And second, if you haven’t seen any of these already — well, you’ve heard of video game streaming; get ready for competitive Excel streaming:
In this week’s news and notes from the Social Capital family, first up we have a major announcement to share from our friends at Clearbanc:
Clearbanc plans to disrupt Venture Capital with the 20-Minute Term Sheet | Kate Clark, TechCrunch
Clearbanc has been working towards this goal for quite a while, and it’s great to see it get realized: a new, quick and powerful way for founders to raise capital for growth and marketing in a way that aims for the best of both worlds of equity and debt. For certain types of fast-growing companies, particularly e-commerce companies who are selling units at predictable COGS and CAC, being cash-constrained isn’t a good place to be: you know you can move more units, if only you had more cash to put into your growth and marketing machine. The problem, though, is that neither equity nor debt is quite the right fit for this. Sure, you could raise equity from VCs who’ll happily fund your growth, but this’ll be really expensive for you in the long run. Once you sell that equity, it’s never coming back. On the other hand, you could raise debt, knowing you’ll be able to pay it off quickly as your sales and marketing turns into orders and revenue. Unfortunately, most banks aren’t really happy lending to newer online companies with little collateral: unless you’re willing to sign over your house or make some other personal guarantee, you’ll be out of luck. So what’s in the middle?
In the middle, there’s Clearbanc’s 20 minute term sheet. Clearbanc plugs directly into your payment processor, like Stripe or Paypal, as well as into your growth and marketing channels like Google and Facebook, in order to get a crystal clear look at how their money will get put to work. Clearbanc then gives you a cash advance on future sales — not debt, exactly, but something like it — which they recoup directly from your payment processor, as an agreed-upon cut out from your revenue. Depending on how you plan to put that money to work, you’re able to put this cash advance to work at a very reasonable rate: a six percent flat fee for use cases that Clearbanc understands well (like buying Adwords) and slightly higher if you want to go put that money to work in more bespoke ways. In the old days, getting a cheap rate as a startup was a function of how much collateral you could put up; now, getting a cheap rate is more like it should be — a function of how clearly, transparently and reliably you can put your data to work.
Interestingly, Clearbanc’s announcement prompted a fair amount of armchair criticism and finger-pointing among exactly the type of people you’d hope would hate this — VCs themselves. “This isn’t serious!” “This already exists, it’s called credit cards!” “No one will seriously pick this over VC money!” Well, guess what? That’s exactly what you’d hope to hear if you were launching a truly disruptive product. And its actual customers, the entrepreneurs putting Clearbanc’s capital to work, love it. If you think this is right for your business or someone you know, head over to 20minutetermsheet.com and get started.
And finally, Relativity Space passed a major milestone the other day, with the announcement of their first launch client: Telesat.
Rocket startup Relativity Space announces first major launch client | Aaron Pressman, Fortune
Telesat, a Canadian satellite company who took over Google’s Project Loon IP earlier this year, is ramping up on their plan to launch hundreds of small telecommunications satellites into orbit over the next several years. Their deal with Relativity Space will see them launch multiple satellites from Relativity’s launch pad at Cape Canaveral, starting in 2021.
Have a great week,
Alex & the team from Social Capital
