aljaz/dlcspecs
1
0
Fork 0
mirror of https://github.com/aljazceru/dlcspecs.git synced 2026-01-16 12:34:20 +01:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #9 from benthecarman/fix-links

Browse Source 
Fix links to be references to the files rather than the github
This commit is contained in:
Nadav Kohen
2020-02-27 12:51:26 -07:00
committed by GitHub
parent 123a55cc41 8c168add59
commit 407231df06
3 changed files with 19 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
KeyDerivation.md
View File

@@ -10,7 +10,7 @@ Where an apostrophe in the path indicates that BIP32 hardened derivation is used
All keys in this scheme will be derived in the form `key = k_par / phase / path`, where `phase = 0` is for the funding transaction, `phase = 1` is for the contract execution/refund transactions and `phase = 2` is for closing transactions. Note that `path` can be empty.
### Funding Key
The funding key pair is used to create and later sign the [Funding Transaction](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions.md#funding-transaction)'s 2-of-2 multisignature output.
The funding key pair is used to create and later sign the [Funding Transaction](Transactions.md#funding-transaction)'s 2-of-2 multisignature output.
Define `k_funding` to be `k_par / 0`.
@@ -22,11 +22,11 @@ Define `k_refund` to be `k_par / 1 / 0`.
### Contract Execution Transaction (CET) Key
Every possible DLC outcome must be known in advance and must have a CET constructed for it. Given some deterministic indexing of these events, we can deterministically derive CET keys. This indexing must start at `1` (as opposed to `0`) since we reserve the `0` index for the [refund/timeout outcome](#refund-key)
There are three different keys each party has for each event: The key in one's own [ToLocalOutput](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions.md#CetOutputs), the key in one's counter-party's ToLocalOutput, and the key in one's counter-party's ToRemoteOutput. In order, let these three keys be indexed with `0, 1 and 2` (this will be referenced to as the `key_index`).
There are three different keys each party has for each event: The key in one's own [ToLocalOutput](Transactions.md#CetOutputs), the key in one's counter-party's ToLocalOutput, and the key in one's counter-party's ToRemoteOutput. In order, let these three keys be indexed with `0, 1 and 2` (this will be referenced to as the `key_index`).
Define `k_cet = k_par / 1 / event_index / key_index`.
### Closing Key
Closing keys are used as outputs in [Mutual](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions.md#mutual-closing-transaction), [Unilateral](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions.md#closing-transaction-unilateral) and [Penalty](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions.md#ClosingPenalty) closing transactions. Since Unilateral and Penalty transactions are only constructed by one party and require no signatures from their counter-party, there is no strict requirement that these keys be deterministically derived. However, there are many instances in which it is nice to do so anyway, such as for testing purposes (TODO: Link to test vectors). Let `key_index` be `0`, `1`, and `2` for Mutual, Unilateral, and Penalty closing transactions respectively.
Closing keys are used as outputs in [Mutual](Transactions.md#mutual-closing-transaction), [Unilateral](Transactions.md#closing-transaction-unilateral) and [Penalty](Transactions.md#ClosingPenalty) closing transactions. Since Unilateral and Penalty transactions are only constructed by one party and require no signatures from their counter-party, there is no strict requirement that these keys be deterministically derived. However, there are many instances in which it is nice to do so anyway, such as for testing purposes (TODO: Link to test vectors). Let `key_index` be `0`, `1`, and `2` for Mutual, Unilateral, and Penalty closing transactions respectively.
Define `k_closing` to be `k_par / 2 / key_index`.

30
Protocol.md
View File

@@ -31,13 +31,13 @@ This message includes the following information:
1. Contract information (an array of triples defined below)
1. Oracle information (optional)
1. A's fund amount (satoshi)
1. A's [extended public key](https://github.com/discreetlogcontracts/dlcspecs/blob/master/KeyDerivation.md)
1. A's inputs
1. A's change address
1. Estimatesmartfee (satoshi/vbyte)
1. CET CSV delay
1. CET locktime (corresponding to the contract maturity date)
1. Refund locktime
2. A's [extended public key](KeyDerivation.md)
3. A's inputs
4. A's change address
5. Estimatesmartfee (satoshi/vbyte)
6. CET CSV delay
7. CET locktime (corresponding to the contract maturity date)
8. Refund locktime
#### Contract information
Contract information consists of a total value (sum of both outputs) and a map to be used to create CETs.
@@ -57,7 +57,7 @@ If both parties already have this information, transmission is unnecessary.
How much A inputs into the contract.
#### A's extended public key
The extended public key to be used to [derive](https://github.com/discreetlogcontracts/dlcspecs/blob/master/KeyDerivation.md) public keys for the Fund transaction, refund transaction and CETs.
The extended public key to be used to [derive](KeyDerivation.md) public keys for the Fund transaction, refund transaction and CETs.
#### A's inputs
The set of UTXOs to be used as input to the fund transaction.
@@ -69,7 +69,7 @@ The address to use to send the change if the sum of A's inputs is greater than t
The fee rate to be used when computing fees for the different transactions.
#### CET CSV Delay
The number to use as input to the CSV in the [CETs](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions.md#outputs-1).
The number to use as input to the CSV in the [CETs](Transactions.md#outputs-1).
#### CET lock time
The number to use as `nLockTime` for the CET transactions.
@@ -84,17 +84,17 @@ It should be set at a later date than the maturity date of the contract.
### Accept
After receiving the `offer` message from A, and after [validating](#offer-validation) the provided information, B creates and sends back an `accept` message containing:
1. B's fund amount (satoshi)
1. B's [extended public key](https://github.com/discreetlogcontracts/dlcspecs/blob/master/KeyDerivation.md)
1. B's inputs
1. B's change output
1. CET signatures
1. Refund signature
2. B's [extended public key](KeyDerivation.md)
3. B's inputs
4. B's change output
5. CET signatures
6. Refund signature
#### B's fund amount (satoshi)
How much B inputs into the contract.
#### B's extended public key
The extended public key to be used to [derive](https://github.com/discreetlogcontracts/dlcspecs/blob/master/KeyDerivation.md) public keys for the Fund transaction, refund transaction and CETs.
The extended public key to be used to [derive](KeyDerivation.md) public keys for the Fund transaction, refund transaction and CETs.
#### B's inputs
The set of UTXOs to be used as input to the fund transaction.

2
Transactions.md
View File

@@ -1,6 +1,6 @@
# DLC Transactions
It is recommended that all keys be generated/derived as specified [here](https://github.com/discreetlogcontracts/dlcspecs/blob/master/KeyDerivation.md#dlc-key-derivation).
It is recommended that all keys be generated/derived as specified [here](KeyDerivation.md#dlc-key-derivation).
## Funding Transaction
### <a name="FundingKnownValues">Known Values</a>