![Strange transactions:
T2 = (User P1 sends 1 BTC from T1 to P2 signature of P1 on [T2])
T3 = (User P2 sends 1 BTC from T2 to P3 signature of P2 on [T3])
P2
P3
T2 = a condition C2 to spend T2 a “witness W2”
T3 = a “witness W3”
P2
P3
T1
1
BTC
T2
1
BTC a condition C3 to spend T3
a Boolean function
Standard transactions:](https://image.slidesharecdn.com/3-160609173659/85/Smart-contracts-and-applications-part-I-3-320.jpg)
![Redeeming condition
T3 redeems T2 if
C2 evaluates to true on input ([T3],W3).
Note: in the the standard transactions:
C2([T3],W3) = Vrfy(pk2,[T3],W3)
[T3]
T2 = a condition C2 to spend T2 a “witness W2”
T3 = a “witness W3”
P2
P3
T1
1
BTC
T2
1
BTC a condition C3 to spend T2](https://image.slidesharecdn.com/3-160609173659/85/Smart-contracts-and-applications-part-I-4-320.jpg)
![Example: “Alice gives 1 BTC to the Bob if
he factors 2501.”
T2 =
can be spent using Bob’s
signature and p and q
such that p,q > 1
and pq = 2501
Alice’s
signature
T1
1
BTC
T3 =
can be spent using
Bob’s signature
p=41
q=61
Bob’s
signature
on [T3]
T2
1
BTC
Alice posts:
T1 --- earlier transaction that can be spent by Alice
Bob claims the
money by
posting:
formally:
C([T],(p,q,𝝈)) = true iff
p,q>1 & pq=2501
and 𝝈 is Bob’s signature on [T]](https://image.slidesharecdn.com/3-160609173659/85/Smart-contracts-and-applications-part-I-5-320.jpg)
![Bitcoin contracts
The “strange transactions” can be used to create the “Bitcoin
contracts”.
Simple examples:
• Payment channels
• Pay money to anyone who knows some password.
• Assurance contracts.
• Put a “deposit” to prove you are not a spammer.
• Pay money only if some event happens (may require an oracle).
More advanced examples:
• ‘’decentralized organizations”
• secure multiparty computation protocols [Andrychowicz, D.,
Malinowski, Mazurek, 2014, Bentov and Kumaresan 2014].](https://image.slidesharecdn.com/3-160609173659/85/Smart-contracts-and-applications-part-I-7-320.jpg)
![Solution: Alice asks Bob to sign a “refund”
transaction T’ with a timelock.
Please sign the following:
[T’] =
can be spent by Alice
if 30 days passed
T0
1
BTC
ok, here is my signature
Good news: technically this can be done without showing T’ to Bob.
Bad news: this solution has problems with transaction malleability
(but let’s ignore them here).
signature of Bob](https://image.slidesharecdn.com/3-160609173659/85/Smart-contracts-and-applications-part-I-21-320.jpg)
Smart contracts and applications part I
- 1. Smart Contracts and Applications (part I) Stefan Dziembowski University of Warsaw Workshop on Bitcoin, Introduction to Cryptocurrencies, Kfar Maccabiah, Ramat Gan, Israel, June 6-7, 2016
- 2. This lecture We give a short introduction to the smart contracts and the scripting features of Bitcoin
- 3. Strange transactions: T2 = (User P1 sends 1 BTC from T1 to P2 signature of P1 on [T2]) T3 = (User P2 sends 1 BTC from T2 to P3 signature of P2 on [T3]) P2 P3 T2 = a condition C2 to spend T2 a “witness W2” T3 = a “witness W3” P2 P3 T1 1 BTC T2 1 BTC a condition C3 to spend T3 a Boolean function Standard transactions:
- 4. Redeeming condition T3 redeems T2 if C2 evaluates to true on input ([T3],W3). Note: in the the standard transactions: C2([T3],W3) = Vrfy(pk2,[T3],W3) [T3] T2 = a condition C2 to spend T2 a “witness W2” T3 = a “witness W3” P2 P3 T1 1 BTC T2 1 BTC a condition C3 to spend T2
- 5. Example: “Alice gives 1 BTC to the Bob if he factors 2501.” T2 = can be spent using Bob’s signature and p and q such that p,q > 1 and pq = 2501 Alice’s signature T1 1 BTC T3 = can be spent using Bob’s signature p=41 q=61 Bob’s signature on [T3] T2 1 BTC Alice posts: T1 --- earlier transaction that can be spent by Alice Bob claims the money by posting: formally: C([T],(p,q,𝝈)) = true iff p,q>1 & pq=2501 and 𝝈 is Bob’s signature on [T]
- 6. How are the conditions written? In Bitcoin scripting language (non-Turing complete stack-based) Example: OP_DUP OP_HASH160 02192cfd7508be5c2e6ce9f1b6312b7f268476d2 OP_EQUALVERIFY OP_CHECKSIG
- 7. Bitcoin contracts The “strange transactions” can be used to create the “Bitcoin contracts”. Simple examples: • Payment channels • Pay money to anyone who knows some password. • Assurance contracts. • Put a “deposit” to prove you are not a spammer. • Pay money only if some event happens (may require an oracle). More advanced examples: • ‘’decentralized organizations” • secure multiparty computation protocols [Andrychowicz, D., Malinowski, Mazurek, 2014, Bentov and Kumaresan 2014].
- 9. A problem with Bitcoin It’s hard to do micropaments in Bitcoin. Reasons: • non-negligible transactions fees • long transaction confirmation times Inherent limitation of Bitcoin: 7 transactions/second. paymements worth a fraction of a cent
- 10. A way to deal with this problem Payment channels (e.g. the Lightning Network). Alice and Bob establish a channel that allows them to do transactions without posting them on the blockchain. Alice Bob payment channel
- 11. How shall it look? Alice Bob payment channel 1 BTC 1 BTC 1. Initially they put some money into the channel, 2. and they decide how much money goes to each party.
- 12. For example, initially the “state” of the channel is as follows: payment channel 1 BTC1 BTC Important: this is just a “virtual” payment (it is not “formalized” on the blockchain).
- 13. Channel adjustment Suppose Alice wants to pay to Bob 0.01 BTC. Then they can “adjust” the channel as follows: payment channel Alice Bob 1 BTC1 BTC 1.01 BTC0.99 BTC
- 14. In general Given a “state” (with non-negative x and y such that 𝐱 + 𝐲 = 𝟐): payment channel y BTCx BTC Alice Bob Alice can pay to Bob any amount 𝐱′ ≤ 𝐱 by adjusting the channel to: payment channel y+x’ BTCx-x’ BTC Alice Bob
- 15. Symmetrically: payment channel y BTCx BTC Alice Bob Bob can pay to Alice any amount 𝐲′ ≤ 𝐲 by adjusting the channel to: payment channel y-y’ BTCx+y’ BTC Alice Bob
- 16. Closing the channel At the end Alice and Bob can close the channel, and get the “real money”. General picture: founding the channel adjustments closing the channel only these phases require blockchain operations this can be done “offline” (hence: for free and very efficiently)
- 17. How to construct such a channel? Let’s start with “unidirectional” channels, where only Alice can pay to Bob. The initial state is as follows: Alice Bob payment channel 1 BTC 0 BTC1 BTC
- 18. Tool: mulisignature transactions The Bitcoin scripts permit to create k-out-of-n mulisignature transactions. These are transactions that can be claimed only by providing signatures from k users (from some set of n users). Example: a 2-out-of-2 multisignature transaction T2 = can be spent by any transaction that has signatures of Alice and Bob signature of CarolT1 1 BTC some unspent transaction of Carol Then T2 can be redeemed by can be spent by Dave signature of Alice T2 1 BTC signature of Bob
- 19. Convention T2 = can be spent by any transaction that has signatures of Alice and Bob signature of CarolT1 1 BTC we will write Carol sends 1 BTC from T1 to Alice&Bob signature of Carol𝐓𝟐 = Instead of
- 20. Founding a channel Alice sends 1 BTC from T to Alice&Bob signature of Alice𝐓𝟎 = Alice creates a founding transaction 𝐓𝟎 as follows: some unspent transaction of Alice Can Alice post 𝐓𝟎 on the blockchain or show it to Bob? No! Then her money from T could be locked forever.
- 21. Solution: Alice asks Bob to sign a “refund” transaction T’ with a timelock. Please sign the following: [T’] = can be spent by Alice if 30 days passed T0 1 BTC ok, here is my signature Good news: technically this can be done without showing T’ to Bob. Bad news: this solution has problems with transaction malleability (but let’s ignore them here). signature of Bob
- 22. Situation Now Alice can be sure that she will get her money back in 30 days by • adding her own signature to T’ • and posting T’on the blockchain. transaction T’ can be spent by Alice if 30 days passed signature of Bob T0 1 BTC signature of Alice
- 23. First blockchain transaction Since Alice is sure that she will get her money back, she can now post T0 on the blockchain. transaction T0
- 24. How to make a micropayment Alice sends 0.99 BTC from T0 to Alice, Alice sends 0.01 BTC from T0 to Bob if 29 days have passed signature of Alice𝐓𝟏 = In order to send 0.01 BTC to Bob, Alice sends to Bob a transaction 𝐓𝟏 constructed as: 𝐓𝟏 How can Bob get the real money from 𝐓𝟏? He can just add his own signature and post 𝐓𝟏 on the blockchain. Important: he has to do it before day 30 (as otherwise Alice can steal all the money) signature of Bob
- 25. And so on… Alice sends 0.98 BTC from T0 to Alice, Alice sends 0.02 BTC from T0 to Bob if 29 days have passed signature of Alice 𝐓𝟐 = In order to further send 0.01 BTC to Bob, Alice sends to Bob a transaction 𝐓𝟐 constructed as: Alice Bob 𝐓𝟏
- 26. In general to send y BTC: if the last transaction sent by Alice to Bob was: then Alice can sends to Bob the following transaction: 𝐓𝐢+𝟏 = Alice sends x BTC from T0 to Alice, Alice sends 1-x BTC from T0 to Bob if 29 days have passed signature of Alice 𝐓𝐢 = Alice sends x-y BTC from T0 to Alice, Alice sends 1-(x-y) BTC from T0 to Bob if 29 days have passed signature of Alice
- 27. How to close the channel? If Bob wants to close the channel then he simply adds his signature and posts the last 𝐓𝐢 on the blockchain (at day 29). Observe: the 𝐓𝐢’s only get better and better for him. Therefore he will always post the last 𝐓𝐢. To close the channel Alice has to wait (or ask Bob).
- 28. Suppose Bob wants to send money back to Alice. How to “invert the channel”? The situation with the unidirectional channels: Bob’s payout time 1 BTC
- 29. We want: Bob’s payout time 1 BTC Observe: in these periods it’s Alice who is “gaining money with time”
- 30. Let’s concentrate on single inversion: Suppose the state of the channel is (1-y BTC to Alice, y BTC to Bob) Bob’s payout 1 BTC y BTC
- 31. Solution Invert the situation: let now Bob send “signed transactions” to Alice. To send y BTC from Bob to Alice: Alice sends 1-(y-y’) BTC from T0 to Alice, Alice sends y-y’ BTC from T0 to Bob if 28 days have passed signature of Bob 𝐓𝐢 = Alice Bob 𝐓𝐢 why 28?
- 32. Why the timelock is “28 days” now? Remember: Bob is now “loosing money”. At day 29 he could post the transaction that gives him y BTC… Bob’s payout 1 BTC y BTC Alice needs to be able to “react” earlier (in day 28).
- 33. Payment networks Problem: every pair of parties requires a separate channel… Can we do better? Yes! We can let the parties “route” the payments. channel channel channel Alice Bob Carol Dave Alice pays to Dave using Bob and Carol as intermediaries (possibly at a fee).
- 34. What if Alice and Dave do not trust the intermediaries? There is a solution that uses hash-locked transactions H – hash function Let Y := H(X) A Y-hash-locked transaction from A to B can be redeemed only by publishing X: T2 = can be spent using B’s signature and X such that Y = H(X) A’s signature T1 1 BTC
- 35. How can it be used? Sketch of the solution: channel channel channel Alice Bob Carol Dave generates random X and computes Y = H(X) Y I pay you a 0.01 if you show me X such that Y = H(X) I pay you a 0.01 if you show me X such that Y = H(X) I pay you a 0.01 if you show me X such that Y = H(X) XXX
- 36. Improvements Assuming some improvements in Bitcoin, the Lightning network achieves the following: • channels can be open “forever” (no need to have specified timelocks) • but can be reasonably quickly closed at a request of any party.
- 37. ©2016 by Stefan Dziembowski. Permission to make digital or hard copies of part or all of this material is currently granted without fee provided that copies are made only for personal or classroom use, are not distributed for profit or commercial advantage, and that new copies bear this notice and the full citation.