diff --git a/11_3_Empowering_Bitcoin_with_Scripts.md b/11_3_Empowering_Bitcoin_with_Scripts.md index 14b14cb..6dc5f49 100644 --- a/11_3_Empowering_Bitcoin_with_Scripts.md +++ b/11_3_Empowering_Bitcoin_with_Scripts.md @@ -14,7 +14,7 @@ The [Lightning Network](https://rusty.ozlabs.org/?p=450) is a payment channel th The trick with Lightning is that it's off-chain. The participants jointly lock funds on Bitcoin with an n-of-n multisignature, then they engage in a number of transactions between themselves. Each new "commitment transaction" splits those joint funds in a different way; it's partially signed but _it isn't put on the blockchain_. -So how do you keep one of the participants from reverting back to an old transaction that's more beneficial to them? That's where revocation comes in. You give the participant who would be harmed by reversion to a revoked transaction the ability to reclaim the funds himself if the another participant illegitamately tried to use the revoked transaction. +So how do you keep one of the participants from reverting back to an old transaction that's more beneficial to them? That's where revocation comes in, as is demonstrated in the following example from BIP 112, which was intended as a stepping stone toward Lightning. You give the participant who would be harmed by reversion to a revoked transaction the ability to reclaim the funds himself if the another participant illegitamately tried to use the revoked transaction. For example, presume that Alice updated the commitment transaction to give more of the funds to Bob (effectively: she sent funds to Bob via the Lightning network). As part of this new transaction, she gives Bob a `revokeHash` which can be used to claim the funds from the previous transaction, before Alice gave Bob the new funds. @@ -81,7 +81,7 @@ Stack: [ False ] #### Run the Lock Script for Cheating Alice, without Revocation Code So what if Alice instead tries to use her own signature, without the revocation code? -``` + ``` Script: 0 OP_HASH160 OP_EQUAL IF ELSE <+24Hours> OP_CHECKSEQUENCEVERIFY OP_DROP ENDIF OP_CHECKSIG Stack: [ ] @@ -118,7 +118,7 @@ Stack: [ <+24Hours> ] — Script EXITS #### Run the Lock Script for Virtuous Bob What this means is that Bob has 24 hours to reclaim his funds if Alice ever tries to cheat, using the `` and his signature: -``` + ``` Script: OP_HASH160 OP_EQUAL IF ELSE <+24Hours> OP_CHECKSEQUENCEVERIFY OP_DROP ENDIF OP_CHECKSIG Stack: [ ] @@ -141,7 +141,6 @@ Script: OP_CHECKSIG Running: True IF Stack: [ ] - Script: OP_CHECKSIG Stack: [ ] @@ -155,6 +154,138 @@ All of the commitment scripts are locked with this same transaction, whether the ### Lock with Hashed Time-Lock Contracts +BIP 112 also offers a slightly more complex mechanism for protecting Lightning-like transactions: a [hashed timelock contract](https://en.bitcoin.it/wiki/Hashed_Timelock_Contracts), or HTLCs. This is what allows singular transactions to actually become a network and is what's actually used as the basis of the Lightning network. -Noet that the transaction requires - * Peg-in Chains? +#### Lock the Recipient's Transaction + +Take as an example the following commitment transaction created for new funds that Alice has received: +``` +OP_HASH160 +OP_DUP + +OP_EQUAL + +IF + + <+24Hours> + OP_CHECKSEQUENCEVERIFY + OP_2DROP + + +ELSE + + + OP_EQUAL + + OP_NOTIF + + + OP_CHECKLOCKTIMEVERIFY + OP_DROP + + ENDIF + + + +ENDIF + +OP_CHECKSIG +``` +The key to this is the `secretHash`, which is what allows a transaction to span the network. Each of several transactions is locked with the `secretHash`. When the transaction has spanned from its originator to its intended recipient, the `secretCode` is revealed, which allows all the participants to create a `secretHash` and unlock the whole network of payments: after the `secretCode` has been revealed, Alice can claim the funds 24 hours after the transaction is put on the Bitcoin network. + +However, the hash could alternatively be a `revokeHash`, which was supplied after the transaction was supplanted by a new one. Bob can relcaim the funds in that situation _or if_ an absolute timeout has occurred. + +#### Lock the Sender's Transaction + +Due to the additional complexity of HTLCs, an additional commitment transaction is required for the sender of every HTLC transaction: +``` +OP_HASH160 +OP_DUP + +OP_EQUAL +OP_SWAP + +OP_EQUAL +OP_ADD + +IF + + + +ELSE + + + OP_CHECKLOCKTIMEVERIFY + <+24Hours> + OP_CHECKSEQUENCEVERIFY + OP_2DROP + + +ENDIF +OP_CHECKSIG +``` +The initial part of their Script is quite clever and so worth running: +``` +Initial Script: OP_HASH160 OP_DUP OP_EQUAL OP_SWAP OP_EQUAL OP_ADD +Stack: [ ] + +Initial Script: OP_HASH160 OP_DUP OP_EQUAL OP_SWAP OP_EQUAL OP_ADD +Stack: [ ] + +Initial Script: OP_DUP OP_EQUAL OP_SWAP OP_EQUAL OP_ADD +Running: OP_HASH160 +Stack: [ ] + +Initial Script: OP_EQUAL OP_SWAP OP_EQUAL OP_ADD +Running: OP_DUP +Stack: [ ] + +Initial Script: OP_EQUAL OP_SWAP OP_EQUAL OP_ADD +Running: OP_DUP +Stack: [ ] + +Initial Script: OP_EQUAL OP_SWAP OP_EQUAL OP_ADD +Running: OP_DUP +Stack: [ ] + +Initial Script: OP_SWAP OP_EQUAL OP_ADD +Running: OP_EQUAL +Stack: [ ] + +Initial Script: OP_EQUAL OP_ADD +Running: OP_SWAP +Stack: [ ] + +Initial Script: OP_EQUAL OP_ADD +Stack: [ ] + +Initial Script: OP_ADD +Running: OP_EQUAL +Stack: [ ] + +Initial Script: OP_ADD +Running: OP_EQUAL +Stack: [ ] + +Initial Script: +Running: OP_ADD +Stack: [ ] +``` +Running through the script, it becomes obvious that the initial checks determine if the hash was either the `secretCode` or the `revokeCode`. If so, Alice can take the funds in the first block. If not, Bob can take the funds, but only after Alice has had her chance, and both the 24 hour timeout and the absolute timeout have passed. + +#### Understand HTLCs + +HTLCs are quite complex, and you may not entirely understand them from just this overview. Rusty Russell's [overview](https://rusty.ozlabs.org/?p=462) of them has more and there's even more in his [Deployable Lightning](https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf) paper. + +For the purposes of this tutorial, two things are important for HTLCs: + + * Understand that a very complex structure like an HTLC can be created with Bitcoin Script. + * Analyze how to run each of the HTLC scripts. + +It's worth your time running each of the HTLC scripts through each of its permutations, one stack item at a time. + +### Summary: Empowering Bitcoin with Scripts + +We're closing our examination of Bitcoin Scripts with a look at how truly powerful they can be. In 20 opcodes or less, a Bitcoin Script can form the basis of an entire off-chain payment channel. Similarly, two-way pegged sidechains are the product of less than twenty opcodes, as briefly noted in [BIP 112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki). + +If you've ever seen complex Bitcoin functionality or Bitcoin-adjacent systems, they were problem built on Bitcoin Scripts. And now you have all the tools to do the same yourself.