github.com/mit-dci/lit@v0.0.0-20221102210550-8c3d3b49f2ce/docs/execute-dlc-litaf.md (about) 1 # Executing a Discreet Log Contract using LIT-AF 2 This tutorial explains how you can execute a Discreet Log Contract using the LIT command line client (LIT-AF). There's a separate tutorial on setting up two LIT nodes, you can find that [here](test-setup.md) 3 4 We'll be providing oracle keys and signatures you can use for testing, but if you want to use your own oracle, you can create one using our tutorial in either [Go](https://github.com/mit-dci/dlc-oracle-go/blob/master/TUTORIAL.md), [.NET Core](https://github.com/mit-dci/dlc-oracle-dotnet/blob/master/TUTORIAL.md) or [NodeJS](https://github.com/mit-dci/dlc-oracle-nodejs/blob/master/TUTORIAL.md) 5 6 ## Step 1: Opening LIT-AF 7 8 In the tutorial for setting up nodes, you learnt how to connect to LIT using it's command line utility `lit-af`. Open two consoles and connect `lit-af` to both of the LIT nodes running on your machine. 9 10 ## Step 2: Adding the oracle 11 12 Next, in both consoles execute the following command to add the Oracle to the nodes: 13 14 ``` 15 dlc oracle add <pubkey> <name> 16 ``` 17 18 The pubkey parameter is the public key of the oracle you'd like to use. If you're using your own oracle, from the tutorial linked above, it will print this out to the console. Otherwise, you can use the public key `03c0d496ef6656fe102a689abc162ceeae166832d826f8750c94d797c92eedd465`, like so: 19 20 ``` 21 dlc oracle add 03c0d496ef6656fe102a689abc162ceeae166832d826f8750c94d797c92eedd465 Tutorial 22 ``` 23 24 When successful, you'll see an output something like this: 25 26 ``` 27 Oracle successfully registered under ID 1 28 ``` 29 30 If the ID is different, because you've experimented with oracles before, make sure you substitute with the correct ID in the commands we use hereafter. 31 32 ## Step 3: Creating the contract 33 34 Now that we have the oracle imported, we can create the contract. The contract is based on an expected publication in the future. For this purpose, the oracle publishes an R-point. This is a public key to the one-time signing key used by the oracle to sign this and only this publication. We need this when forming the contract. 35 36 If you're using your own oracle from the tutorial, it will print the R-point to the console as well. Otherwise, you can use the R-point `027168bba1aaecce0500509df2ff5e35a4f55a26a8af7ceacd346045eceb1786ad`. 37 38 If you want to learn more about the commands and their parameters, you can issue it with a `-h` parameter. For instance, in stead of `dlc contract setoracle 1 1` you can issue `dlc contract setoracle -h` and it will print out the usage and parameters for the command: 39 40 ``` 41 dlc contract setoracle <cid> <oid> 42 Configures a contract for using a specific oracle 43 cid The ID of the contract 44 oid The ID of the oracle 45 ``` 46 47 In order to create the contract we issue the following commands to `lit-af`. You only need to to this for one node, since we'll be sending the contract over to the other one. If this is not the first time creating a contract in LIT, the contract will get a new index. You would need to correct the first parameter to all the `dlc contract set...` commands in that case. 48 49 First, we create a new draft contract 50 51 ``` 52 dlc contract new 53 ``` 54 55 Then, we configure the contract to use the oracle we added in step 2. Remember, if this oracle got a different ID, you have to adjust the second parameter to this call. 56 57 ``` 58 dlc contract setoracle 1 1 59 ``` 60 61 Next, we configure the timestamp at which the contract will settle. This is a time in the past, since we already know the value and signature. It's just a hint to the system at this time. 62 63 ``` 64 dlc contract settime 1 1528848000 65 ``` 66 67 Then, we configure the R-point for the contract, as mentioned earlier this is the public key to the one-time signing key used by the oracle to sign the value it will publish. 68 69 ``` 70 dlc contract setrpoint 1 027168bba1aaecce0500509df2ff5e35a4f55a26a8af7ceacd346045eceb1786ad 71 ``` 72 73 We configure the coin type to be Bitcoin Regtest: 74 75 ``` 76 dlc contract setcointype 1 257 77 ``` 78 79 We set the funding of the contract. Both peers will fund 1 BTC (100,000,000 satoshi) 80 81 ``` 82 dlc contract setfunding 1 100000000 100000000 83 ``` 84 85 Next, we determine the division in the contract. The oracle from the tutorial mentioned above publishes a value between 10000 and 20000. So, we can use that in the contract to determine that we get all the value in the contract when the published value is 20000, and our counter party will get all the value if it's 10000 86 87 ``` 88 dlc contract setdivision 1 20000 10000 89 ``` 90 91 Now the contract is fully configured. You can check this by issuing the `dlc contract view 1` command, which will print out something like this: 92 93 ``` 94 entered command: dlc contract view 1 95 Index : 1 96 Oracle public key : [03c0...ee...d465] 97 Oracle R-point : [0271...35...86ad] 98 Settlement time : Wed Jun 13 00:00:00 UTC 2018 99 Funded by us : 100000000 100 Funded by peer : 100000000 101 Coin type : 257 102 Peer : None 103 Status : Draft 104 105 Payout division: 106 107 Oracle value | Our payout | Their payout 108 ------------------------------------------------------------------ 109 0 | 0 | 200000000 110 3000 | 0 | 200000000 111 6000 | 0 | 200000000 112 9000 | 0 | 200000000 113 12000 | 40000000 | 160000000 114 15000 | 100000000 | 100000000 115 18000 | 160000000 | 40000000 116 21000 | 200000000 | 0 117 24000 | 200000000 | 0 118 27000 | 200000000 | 0 119 30000 | 200000000 | 0 120 ``` 121 122 ## Step 4: Sending the contract to the other peer 123 124 Now that the contract is ready, we can send it to the other peer. We do this by issuing the `dlc contract offer` command, followed by the contract ID and the index of the peer we want to send it to. 125 126 ``` 127 dlc contract offer 1 1 128 ``` 129 130 When you go to the other LIT node, and issue `dlc contract ls` you will see a new contract appeared with index 1. You can view it by issuing `dlc contract view 1` 131 132 ``` 133 Index : 1 134 Oracle public key : [03c0...ee...d465] 135 Oracle R-point : [0271...35...86ad] 136 Settlement time : Wed Jun 13 00:00:00 UTC 2018 137 Funded by us : 100000000 138 Funded by peer : 100000000 139 Coin type : 257 140 Peer : Peer 1 141 Status : Received offer, awaiting reply 142 143 Payout division: 144 145 Oracle value | Our payout | Their payout 146 ------------------------------------------------------------------ 147 0 | 200000000 | 0 148 3000 | 200000000 | 0 149 6000 | 200000000 | 0 150 9000 | 200000000 | 0 151 12000 | 160000000 | 40000000 152 15000 | 100000000 | 100000000 153 18000 | 40000000 | 160000000 154 21000 | 0 | 200000000 155 24000 | 0 | 200000000 156 27000 | 0 | 200000000 157 30000 | 0 | 200000000 158 ``` 159 160 You might notice that the payout table is reversed to the one we saw on the first LIT node, which makes sense. 161 162 ## Step 5: Accepting the contract 163 164 Now we can accept the contract from the other peer by issuing: 165 166 ``` 167 dlc contract accept 1 168 ``` 169 170 What will happen now in sequence, is: 171 172 * The nodes will exchange their funding inputs 173 * The nodes will exchange signatures for spending from the contract output 174 * The nodes will exchange signatures for the funding transaction 175 * Node 1 will publish the funding transaction 176 177 You should now generate one more block in the Bitcoin Core Debug console, so that the transaction is mined. Once you did that, issue the `dlc contract view 1`, and the status of the contract should show `Active` (on both peers) 178 179 ``` 180 entered command: dlc contract view 1 181 Index : 1 182 Oracle public key : [03c0...ee...d465] 183 Oracle R-point : [0271...35...86ad] 184 Settlement time : Wed Jun 13 00:00:00 UTC 2018 185 Funded by us : 100000000 186 Funded by peer : 100000000 187 Coin type : 257 188 Peer : Peer 1 189 Status : Active 190 ``` 191 192 ## Step 6: Settling the contract 193 194 Once the oracle publishes a value, we can settle the contract using the value and the oracle's signature. If you used your own oracle, the value and signature are printed to the console - if you didn't you can use the value `15161` and signature `9e349c50db6d07d5d8b12b7ada7f91d13af742653ff57ffb0b554170536faeac` 195 196 You can do the settlement on either of the two peers, but in this case we'll run it on the first peer (the one that offered the contract): 197 198 ``` 199 dlc contract settle 1 15161 9e349c50db6d07d5d8b12b7ada7f91d13af742653ff57ffb0b554170536faeac 200 ``` 201 202 What this does in order, is: 203 * The node you issued the command to will publish the settlement transaction corresponding to the value 15161 to the blockchain 204 * That node will also send a transaction claiming the output due him using the oracle signature and his own private key (combined) back to his wallet 205 * The other node will observe the transaction being published, and claim the output due him back to his wallet using just his private key 206 207 In order to trigger the other node to claim back his funds, you should generate two more blocks in the Bitcoin Core debug window. 208 209 ## Step 7: Check balances 210 211 After mining the blocks, you will see that the balances and UTXOs on both peers have changed, if you issue the `ls` command: 212 213 Peer 1: 214 ``` 215 entered command: ls 216 [...] 217 Txos: 218 0 2adb78b78ef287ec775acef77398040551a7ba362f708df3b8b200b40518b7ae;0 h:203 amt:103219000 /44'/257'/0'/0'/3' regtest 219 1 2fe0c7ec6fcb90911ba4f946421a6c73f660bd69ed2298018afa3b0ae3c200d0;1 h:203 amt:899999500 /44'/257'/0'/0'/2' regtest 220 [...] 221 Type: 257 Sync Height: 204 FeeRate: 80 Utxo: 1003218500 WitConf: 1003218500 Channel: 0 222 ``` 223 224 Peer 2: 225 ``` 226 entered command: ls 227 [...] 228 Txos: 229 0 7295f550fae9bb71689565251ee78dd22896decb490cdefa0ff5c6983563f6c8;0 h:203 amt:96779000 /44'/257'/0'/0'/2' regtest 230 1 2fe0c7ec6fcb90911ba4f946421a6c73f660bd69ed2298018afa3b0ae3c200d0;2 h:203 amt:899999500 /44'/257'/0'/0'/1' regtest 231 [...] 232 Type: 257 Sync Height: 204 FeeRate: 80 Utxo: 996778500 WitConf: 996778500 Channel: 0 233 ``` 234 235 You can see that Peer 1 has 10.032185 BTC and peer 2 has 9.96778500 BTC. Both have an output of 8.999995 BTC, which is the change they got when funding the contract with 1 BTC (and paying 500 satoshi fees). The other output came from the contract based on the division. Since the published value was close to the middle of the contract (15000 would have equally divided the contract), the difference is not too big. 236 237 ## Conclusion 238 239 We executed a discreet log contract using LIT's command line client. If you want to integrate this technology into your own application, or you have a use case that you think could leverage this technology - we also have an RPC client for LIT in [Go](https://github.com/mit-dci/lit-rpc-client-go), [.NET Core](https://github.com/mit-dci/lit-rpc-client-dotnet) and [NodeJS](https://github.com/mit-dci/lit-rpc-client-nodejs) that you can use to issue these commands programmatically. A tutorial on how to do that will follow.