Bitcoin & Blockchain (parte 2) - Università degli Studi Roma Tre (10/04/18)

Talk presso il Dipartimento di Ingegneria dell'Università degli Studi di Roma Tre
---------------------------------------------------------------------------
Segui il Blockchain Education Network Italia su:

➡ Facebook: https://www.facebook.com/BlockchainEduIT
➡ Twitter: https://twitter.com/BlockchainEduIT
➡ Forum Bitcoin Talk: http://goo.gl/zqDdte

http://blockchainedu.net

Transcript

1. Simone Bronzini CTO @ Chainside simone.bronzini@chainside.net Leveraging the power of Bitcoin scripting to scale
2. Roadmap 1. Scalability limits of Bitcoin 2. What is a Bitcoin transaction a. Spending conditions b. Scripts in Bitcoin transactions 3. Using scripts to create payment channels a. General idea b. Protocol 4. Network of payments
3. Scalability limits of BITCOIN Limited block size: 1 MB Block time: 10 minutes Average tx in a block: 2000
4. Scalability limits of BITCOIN Transactions throughput: only 7-9 transactions per second 20000 transactions per second
5. Under the hood: Transactions What is a BITCOIN transaction? Output indicating conditions to be spent Checks whether who’s spending actually has the right to do so.
6. Transactions validation process Properties we want to guarantee: 1. The money spent by the transaction has not been already spent (double spending) 2. Check whether who’s spending actually has the right to spend 3. Money spent in the tx actually exist
7. Transactions validation process How we guarantee them: 1. Check the blockchain (keep an updated UTXO) 2. Run the scriptSig providing the spending conditions and run the scriptPubkey that should enforce them 3. Recursively check backwards which outputs are spent by the tx until you get to a coinbase tx (actually, keeping an updated UXTO solves this as well)
8. Transactions validation process How we guarantee them: 1. Check the blockchain (keep an updated UTXO) 2. Run the scriptSig providing the spending conditions and run the scriptPubkey that should enforce them 3. Recursively check backwards which outputs are spent by the tx until you get to a coinbase tx (actually, keeping an updated UXTO solves this as well)
9. Transaction chains TX K TX L Alice to Bob: 3 BTC Bob to Carol: 2 BTC TX M Carol to Eve: 4 BTC
10. Validation – Scripts TX Validation is done through BITCOIN scripting language: Not turing-complete (luckily!) Stack based: stacks used to manipulate data Both inputs and outputs include a script
11. Validation Process 1. 1. Run scriptSig 2. 2. With the same stack, run scriptPubKey This pretty much means: scriptSig pushes some data onto the stack, scriptPubKey uses those data to check if the spending conditions are met
12. Transactions - Validation Outputs: specify the spending conditions (scriptPubKey) 1. “Only the owner of private key matching public key K 1 can redeem” 2. “Only the owner of the private key whose public key’s hash is f2ceacda3dc98cab00091d8d6422aeb57bb7db77 can redeem” 3. “Only the owners of private keys matching public keys K 1 and K 2 can redeem” 4. “Either the owners of private keys matching public keys K 1 and K 2 can redeem right away, or the owner of the private key matching public key K 3 can redeem after 3 months have passed”
13. Transactions - Validation Inputs: provide data that matches conditions in the output (scriptSig) 1. “Signature of a hash of the transaction with private key k 1 ” 2. “Public key K 2 and a signature of the hash of the transaction with private key k 2 ” 3. “Two signatures of a hash of the transaction with private keys k 1 and k 2 ” 4. “Signature of a hash of the transaction with private key k 3 after the expiration of 3 months”
14. SOLUTION: Off-chain Transactions Reducing use of main chain Off-chain solution: LIGHTNING NETWORK
15. Lightning payment channels block n Tx 1 From: Alice To: Bob
16. Lightning payment channels block n Tx 1 From: Alice To: Bob Tx 2 From: Bob To: Chuck OFF-CHAIN
17. Lightning payment channels block n block n+1 Tx 1 From: Alice To: Bob Tx 2 From: Bob To: Chuck Tx 3 From: Chuck To: Dave OFF-CHAIN
18. Lightning payment channels block n block n+1 block n+2 Tx 1 From: Alice To: Bob Tx 2 From: Bob To: Chuck Tx 3 From: Chuck To: Dave Tx 20 From: Ken To: Eve Tx (…) From: (…) To: (…) OFF-CHAIN
19. Lightning payment channels block n block n+1 block n+2 Tx 1 From: Alice To: Bob Tx 2 From: Bob To: Chuck Tx 3 From: Chuck To: Dave Tx 20 From: Ken To: Eve Tx 21 From: Eve To: Bob Tx (…) From: (…) To: (…) OFF-CHAIN
20. Lightning payment channels block n block n+1 block n+2 block n+3 Tx 1 From: Alice To: Bob Tx 2 From: Bob To: Chuck Tx 3 From: Chuck To: Dave Tx 20 From: Ken To: Eve Tx 21 From: Eve To: Bob Tx 22 From: Bob To: Ted Tx (…) From: (…) To: (…) OFF-CHAIN OPENING CHANNEL CLOSING CHANNEL
21. Payment channels in depth ALICE BOB
22. Payment channels in depth MULTISIG 2-2 ALICE BOB
23. Payment channels in depth MULTISIG 2-2 ALICE BOB FUNDING TX (NOT ON BLOCKCHAIN YET)
24. Payment channels in depth MULTISIG 2-2 FUNDING TX (NOT ON BLOCKCHAIN YET) ALICE BOB BOB CREATES SEC B ALICE CREATES SEC A COMMITMENT TXs
25. Payment channels in depth MULTISIG 2-2 FUNDING TX BROADCASTED! ALICE BOB BOB CREATES SEC B ALICE CREATES SEC A They exchange txs COMMITMENT TXs
26. Updating state of channels OLD STATE When exchanging new state, they share previous state’ secret ALICE CREATES SEC A’ BOB CREATES SEC B’ They exchange txs NEW STATE
27. Closing channels FUNDING TX (already on chain) CLOSING TX (to be broadcast)
28. Payment networks Establishment of network between all channels Possible to route payments through other channels: A wants to send money to C, but no channel between them HOWEVER: A has a channel with B, so payment can pass through their channel, NO NEED for a channel with C A
29. Payment networks Establishment of network between all channels Possible to route payments through other channels: A wants to send money to C, but no channel between them HOWEVER: A has a channel with B, so payment can pass through their channel, NO NEED for a channel with C A B
30. Payment networks Establishment of network between all channels Possible to route payments through other channels: A wants to send money to C, but no channel between them HOWEVER: A has a channel with B, so payment can pass through their channel, NO NEED for a channel with C A B C
31. Payment networks Nodes 1362 Channels 4196
32. Summary • The blockchain is useful but highly inefficient • Scalability must be achieved by avoiding the blockchain • Bitcoin’s powerful scripting language can be used to scale off-chain
33. If you feel like experimenting We recently released an open source Python3 library to create complex Bitcoin scripts: https://github.com/chainside/btcpy OR pip3 install chainside-btcpy
34. QUESTIONS?