Update md links and replace Justice by Penalty in KeyDerivation.md

This commit is contained in:
Tibo-lg
2020-01-27 17:34:57 +09:00
parent f0bbdc389f
commit 9d6c3e05e1
2 changed files with 4 additions and 4 deletions

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/bitcoin-s/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](https://github.com/discreetlogcontracts/dlcspecs/blob/master/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/bitcoin-s/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](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`).
Define `k_cet = k_par / 1 / event_index / key_index`.
### Closing Key (Optional)
Closing keys are used as outputs in [Unilateral](https://github.com/bitcoin-s/dlcspecs/blob/master/Transactions.md#closing-transaction-unilateral) and [Justice](https://github.com/bitcoin-s/dlcspecs/blob/master/Transactions.md#closing-transaction-justice) transactions. Since these 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).
Closing keys are used as outputs in [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) transactions. Since these 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).
Define `k_closing` to be `k_par / 2`.

View File

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