[ ] We're gonna start off by building a central payment processor. Something like Paypal. Show a new large node appear called "Paypal".
[ ] Paypal will keep track of how much money everyone has. Show a state table show up with Alice's name and 0 dollars. Paypal's feeling nice today, so here's $100. See Alice's balance increase up to 100
[ ] Sounds good. But, names don't seem like a very good way to keep track of everyone's money. What if someone else joins Paypal named Alice?? We represent every person as a different long string of letters and numbers called an address. (maybe for simplicity sake, we just use public keys)
[ ] Let's try to send some money to Alice's gerbil friend, Bob. Alice will make a message. show message appear above alice that says "From: 0xabc (Alice), To: 0xdef (Bob), Amount: 10". Paypal receives the message and shows a green checkmark. Alice's balance decreases to 90 and Bob appears with a balance of 10.
[ ] Awesome! Now let's see if we can be sneaky and trick paypal into sending money we don't have. Show new message sending $100 from Alice to Bob, Alice sends to Paypal. All Paypal has to do is check to make sure Alice has the money she's trying to send. Show "90 -100 < 0" in red. Error message appears "Insufficient funds".
[ ] Let user create transactions as Alice and send them to Bob. Now, let's try something sneaky.... Switch From and To, so now messsage reads: "From: Bob, To: Alice". User sends the transaction, and Bob's balance decreases and Alice's increases.
[ ] Uh Oh!! We have no way to check that the person sending the transaction is who they are. Enter: DIGITAL SIGNATURES!! Each user has a public key and a private key. Think of the public key as similar to a bank account number or on something like venmo, your username, and the private key is similar to your card and PIN number or your venmo password. You can use your safely kept private key to "digitally sign" your transaction, and everyone can verify using your public key that the transaction was signed by your private key. The signature is just a long number that Paypal can do some math on with your message to verify that you signed it.
[ ] Reset paypal state to Alice: 100, Bob: 0. Now, show transactions sending from Alice with "From: 0xabc (Alice), To: 0xdef (Bob), Amount: 10, Signature: 0xa29309f".
[ ] Let's try to send money from Bob again: "From:0xdef (Bob), To 0xabc (Alice), Amount: 10, Signature: 0xa29309f". Transaction sends to Paypal - flashes red. "Invalid signature" error appears.
[ ] Show transactions going back and forth between Bob and Alice. Let user send $10 from Bob to Alice and sign, or send $10 from Alice to Bob and sign. But wait! There's one last attack that we didn't handle :(
[ ] On the Internet, it's fairly easy for someone to listen in on your network activity and see the messages you send out. So if you're trying to be bad... You can listen in on the messages Bob is sending out to Paypal. Show Alice move over to the link between Bob and Paypal with an ear up to the link. Bob sends "$10 to Alice" message to Paypal. Now you have Bob's signature and his transaction information!
[ ] Show Alice sending 5 of those transactions to Paypal one after another, and Paypal accepting them, depleting Bob's balance and adding to Alice's. The digital signature is correct, but Bob only meant to send that transaction once. Bad Alice!
[ ] This is called a replay attack. We prevent replay attacks by adding a number called a nonce to each transaction we send out. Our nonce is just saying "This is my Xth transaction". So, if Alice tries to replay Bob's "2nd transaction", Paypal will reject it: "I already got Bob's 2nd transaction, I'm waiting on his 3rd transaction now."
[ ] Let the user play around with 5 nodes, with transactions being sent to paypal, allowing users to attempt replay attacks, spending money they don't have, and invalid singatures.
[ ] First, you are this node, enter your name.
[ ] We're gonna start off by building a central payment processor. Something like Paypal. Show a new large node appear called "Paypal".
[ ] Paypal will keep track of how much money everyone has. Show a state table show up with Alice's name and 0 dollars. Paypal's feeling nice today, so here's $100. See Alice's balance increase up to 100
[ ] Sounds good. But, names don't seem like a very good way to keep track of everyone's money. What if someone else joins Paypal named Alice?? We represent every person as a different long string of letters and numbers called an address. (maybe for simplicity sake, we just use public keys)
[ ] Let's try to send some money to Alice's gerbil friend, Bob. Alice will make a message. show message appear above alice that says "From: 0xabc (Alice), To: 0xdef (Bob), Amount: 10". Paypal receives the message and shows a green checkmark. Alice's balance decreases to 90 and Bob appears with a balance of 10.
[ ] Awesome! Now let's see if we can be sneaky and trick paypal into sending money we don't have. Show new message sending $100 from Alice to Bob, Alice sends to Paypal. All Paypal has to do is check to make sure Alice has the money she's trying to send. Show "90 -100 < 0" in red. Error message appears "Insufficient funds".
[ ] Let user create transactions as Alice and send them to Bob. Now, let's try something sneaky.... Switch From and To, so now messsage reads: "From: Bob, To: Alice". User sends the transaction, and Bob's balance decreases and Alice's increases.
[ ] Uh Oh!! We have no way to check that the person sending the transaction is who they are. Enter: DIGITAL SIGNATURES!! Each user has a public key and a private key. Think of the public key as similar to a bank account number or on something like venmo, your username, and the private key is similar to your card and PIN number or your venmo password. You can use your safely kept private key to "digitally sign" your transaction, and everyone can verify using your public key that the transaction was signed by your private key. The signature is just a long number that Paypal can do some math on with your message to verify that you signed it.
[ ] Reset paypal state to Alice: 100, Bob: 0. Now, show transactions sending from Alice with "From: 0xabc (Alice), To: 0xdef (Bob), Amount: 10, Signature: 0xa29309f".
[ ] Let's try to send money from Bob again: "From:0xdef (Bob), To 0xabc (Alice), Amount: 10, Signature: 0xa29309f". Transaction sends to Paypal - flashes red. "Invalid signature" error appears.
[ ] Show transactions going back and forth between Bob and Alice. Let user send $10 from Bob to Alice and sign, or send $10 from Alice to Bob and sign. But wait! There's one last attack that we didn't handle :(
[ ] On the Internet, it's fairly easy for someone to listen in on your network activity and see the messages you send out. So if you're trying to be bad... You can listen in on the messages Bob is sending out to Paypal. Show Alice move over to the link between Bob and Paypal with an ear up to the link. Bob sends "$10 to Alice" message to Paypal. Now you have Bob's signature and his transaction information!
[ ] Show Alice sending 5 of those transactions to Paypal one after another, and Paypal accepting them, depleting Bob's balance and adding to Alice's. The digital signature is correct, but Bob only meant to send that transaction once. Bad Alice!
[ ] This is called a replay attack. We prevent replay attacks by adding a number called a nonce to each transaction we send out. Our nonce is just saying "This is my Xth transaction". So, if Alice tries to replay Bob's "2nd transaction", Paypal will reject it: "I already got Bob's 2nd transaction, I'm waiting on his 3rd transaction now."
[ ] Let the user play around with 5 nodes, with transactions being sent to paypal, allowing users to attempt replay attacks, spending money they don't have, and invalid singatures.