History of Atomic Routing
History of Atomic Routing
Gabriel Comte
Ordered by topics rather than time
Some details are sacrificed to remove complexity
The goal is to understand the core concepts
Do we need to open a payment channel with everyone we want to transact with?
That's very inefficient!
The payment processors are businesses and have incentives to behave ethically
This results in a network of trust relations
Your boss wants to buy something from John for $50 (on credit)
John could now send $200 into the opposite direction
... on a centralized platform. (Ripplepay website)
Return a secret when payment arrived;
I will pay you as long as you know p such that sha256(p) == h
Funds can only be spent after a given time or block number
Funds can only be spent if you know the secret s, such that:
hash(s) == x
x is written to the unlocking script, s needs to be provided by the spender such that x can be reproduced
signature + hash lock + time lock
Funds can be spent by you, at block 800,000 (or later), if you know a secret
signature, hash lock, time lock
Funds can be spent by Alice at block 800,000 (or later)
ORby Bob if he knows a secret
Alice wants to send Eric 1 BTC
1) Eric creates a secret R and communicates its hash to Alice
2) Alice creates a commitment TX: I will pay Bob 1.003 BTC if he presents the secret (R) that leads to hash H, during the next 10 blocks
Bob now also knows H, so he can craft a similar TX
3) Bob creates a commitment TX: I will pay Carol 1.002 BTC if she presents the secret (R) that leads to hash H, during the next 9 blocks
Remember, the commitment TX spends the 2-of-2 multiSig (funding TX) and is not being published to the Bitcoin network!
4) Carol now also knows H, she crafts a similar TX for Diana
5) Same story for Diana
Diminishing BTC amount --> a fee for the routing is being paid
Diminishing time lock --> Security measure to ensure atomicity of the transaction
Eric is the only one who knows actually knows R! Diana constructed an HTLC in which she promised 1 BTC to Eric if he reveals R!
Eric is happy! But what about Diana? Will she ever receive her "refund" from Carol?
Eric publishes the HTLC on-chain (closes the channel)
Now he has 7 blocks to spend the commitment TX, or else Diana can take the money back.
He spends that commitment TX and sends it to himself to ensure the money belongs to him forever. This means, he needs to reveal R on-chain!
Bob, Carol and Diana are watching the blockchain and learn R from there! They can now also claim their funds.
Happy end!
Well, not really.
Even though the payment went through, channels have also been closed, which is unfortunate.
So let's go back to the moment Diana sent Eric her HTLC
As we have just witnessed, Eric could claim his funds now, and Diana knows that as well.
So Eric asks Diana to move to a new channel state, where Eric owns +1 BTC, and Diana -1 BTC
Diana tells Eric that she is only willing to do that if he tells her R
HTLC consolidation
They collaboratively move to a new channel state and remove the HTLC
Diana has given 1 BTC to Bob. She is now in the same situation as Bob before.
The scheme repeats through 7, 8, 9 until the transaction went through.
What if step 1 does not happen?
Payment cannot be constructed.
What if step 2 does not happen?
Alice searches for a new payment route
What if one of steps 2, 3, 4, 5, 6 does not happen?
Funds are locked in HTLC until time lock runs out
What if one of steps 7, 8, 9 does not happen?
Bob, Carol or Diana may lose 1 BTC
They are protected by the time-lock to have enough time to react. But if they leave the system, they can only harm themselves, not anyone else.
The transaction is atomic! (as long as you run your system responsibly)
Bitcoin fixed the ripple-problem :-)
Any questions so far?
The more hops involved, the more ...
Extract from HTLC output script in (Bolt 3)
# To remote node with preimage.
OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
OP_CHECKSIG
Extract from HTLC output script in (Bolt 3)
# To remote node after timeout.
OP_DROP <cltv_expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP
OP_CHECKSIG
Any questions regarding HTLCs?
The better you're connected, the fewer hops you're gonna have
History
Current implementation