mirror of
https://github.com/lightning/bolts.git
synced 2025-01-18 13:22:35 +01:00
BOLT 2,3,5: always refer to shared/pubkey/private key.
Make it clear what kind of key we're talking about. We use the abbreviation pubkey for public key (as it's quite common to use in field names), but generally spell out 'private'. (I generally prefer 'secret' to 'private' but we use private far more often already, and we use 'secret' for things which don't directly derive keys). Fixes: #368 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell
parent
3e2d275471
commit
4c8cb512d0
@ -885,7 +885,7 @@ A node that sends `update_fulfill_htlc`, before the sender, is also
|
||||
committed to the HTLC and risks losing funds.
|
||||
|
||||
If the onion is malformed, the upstream node won't be able to extract
|
||||
a key to generate a response — hence the special failure message, which
|
||||
the shared key to generate a response — hence the special failure message, which
|
||||
makes this node do it.
|
||||
|
||||
The node can check that the SHA256 that the upstream is complaining about
|
||||
|
||||
@ -22,8 +22,8 @@ This details the exact format of on-chain transactions, which both sides need to
|
||||
* [Fee Payment](#fee-payment)
|
||||
* [Keys](#keys)
|
||||
* [Key Derivation](#key-derivation)
|
||||
* [`localkey`, `remotekey`, `local_htlckey`, `remote_htlckey`, `local_delayedkey`, and `remote_delayedkey` Derivation](#localkey-remotekey-local_delayedkey-and-remote_delayedkey-derivation)
|
||||
* [`revocationkey` Derivation](#revocationkey-derivation)
|
||||
* [`localpubkey`, `remotepubkey`, `local_htlcpubkey`, `remote_htlcpubkey`, `local_delayedpubkey`, and `remote_delayedpubkey` Derivation](#localpubkey-remotepubkey-local_delayedpubkey-and-remote_delayedpubkey-derivation)
|
||||
* [`revocationpubkey` Derivation](#revocationpubkey-derivation)
|
||||
* [Per-commitment Secret Requirements](#per-commitment-secret-requirements)
|
||||
* [Efficient Per-commitment Secret Storage](#efficient-per-commitment-secret-storage)
|
||||
* [Appendix A: Expected Weights](#appendix-a-expected-weights)
|
||||
@ -51,8 +51,8 @@ Most transaction outputs used here are P2WSH outputs: the Segwit version of P2SH
|
||||
## Funding Transaction Output
|
||||
|
||||
* The funding output script is a pay-to-witness-script-hash<sup>[BIP141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#witness-program)</sup> to:
|
||||
* `2 <key1> <key2> 2 OP_CHECKMULTISIG`
|
||||
* Where `key1` is the numerically lesser of the two DER-encoded `funding_pubkey` and where `key2` is the numerically greater of the two.
|
||||
* `2 <pubkey1> <pubkey2> 2 OP_CHECKMULTISIG`
|
||||
* Where `pubkey1` is the numerically lesser of the two DER-encoded `funding_pubkey` and where `pubkey2` is the numerically greater of the two.
|
||||
|
||||
## Commitment Transaction
|
||||
|
||||
@ -62,7 +62,7 @@ Most transaction outputs used here are P2WSH outputs: the Segwit version of P2SH
|
||||
* `txin[0]` outpoint: `txid` and `output_index` from `funding_created` message
|
||||
* `txin[0]` sequence: upper 8 bits are 0x80, lower 24 bits are upper 24 bits of the obscured commitment transaction number
|
||||
* `txin[0]` script bytes: 0
|
||||
* `txin[0]` witness: `0 <signature_for_key1> <signature_for_key2>`
|
||||
* `txin[0]` witness: `0 <signature_for_pubkey1> <signature_for_pubkey2>`
|
||||
|
||||
The 48-bit commitment transaction number is obscured by `XOR` with the lower 48 bits of:
|
||||
|
||||
@ -84,16 +84,16 @@ The amounts for each output MUST be rounded down to whole satoshis. If this amou
|
||||
|
||||
#### `to_local` Output
|
||||
|
||||
This output sends funds back to the owner of this commitment transaction and thus must be timelocked using `OP_CSV`. It can be claimed, without delay, by the other party if they know the revocation key. The output is a version-0 P2WSH, with a witness script:
|
||||
This output sends funds back to the owner of this commitment transaction and thus must be timelocked using `OP_CSV`. It can be claimed, without delay, by the other party if they know the revocation private key. The output is a version-0 P2WSH, with a witness script:
|
||||
|
||||
OP_IF
|
||||
# Penalty transaction
|
||||
<revocationkey>
|
||||
<revocationpubkey>
|
||||
OP_ELSE
|
||||
`to_self_delay`
|
||||
OP_CSV
|
||||
OP_DROP
|
||||
<local_delayedkey>
|
||||
<local_delayedpubkey>
|
||||
OP_ENDIF
|
||||
OP_CHECKSIG
|
||||
|
||||
@ -107,21 +107,21 @@ If a revoked commitment transaction is published, the other party can spend this
|
||||
|
||||
#### `to_remote` Output
|
||||
|
||||
This output sends funds to the other peer and thus is a simple P2WPKH to `remotekey`.
|
||||
This output sends funds to the other peer and thus is a simple P2WPKH to `remotepubkey`.
|
||||
|
||||
#### Offered HTLC Outputs
|
||||
|
||||
This output sends funds to either a HTLC-timeout transaction after the HTLC-timeout or to the remote node using the payment preimage or the revocation key. The output is a P2WSH, with a witness script:
|
||||
|
||||
# To remote node with revocation key
|
||||
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationkey))> OP_EQUAL
|
||||
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
|
||||
OP_IF
|
||||
OP_CHECKSIG
|
||||
OP_ELSE
|
||||
<remote_htlckey> OP_SWAP OP_SIZE 32 OP_EQUAL
|
||||
<remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
|
||||
OP_NOTIF
|
||||
# To local node via HTLC-timeout transaction (timelocked).
|
||||
OP_DROP 2 OP_SWAP <local_htlckey> 2 OP_CHECKMULTISIG
|
||||
OP_DROP 2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
|
||||
OP_ELSE
|
||||
# To remote node with preimage.
|
||||
OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
|
||||
@ -135,7 +135,7 @@ The remote node can redeem the HTLC with the witness:
|
||||
|
||||
If a revoked commitment transaction is published, the remote node can spend this output immediately with the following witness:
|
||||
|
||||
<revocation_sig> <revocationkey>
|
||||
<revocation_sig> <revocationpubkey>
|
||||
|
||||
The sending node can use the HTLC-timeout transaction to timeout the HTLC once the HTLC is expired, as shown below.
|
||||
|
||||
@ -144,16 +144,16 @@ The sending node can use the HTLC-timeout transaction to timeout the HTLC once t
|
||||
This output sends funds to either the remote node after the HTLC-timeout or using the revocation key, or to an HTLC-success transaction with a successful payment preimage. The output is a P2WSH, with a witness script:
|
||||
|
||||
# To remote node with revocation key
|
||||
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationkey))> OP_EQUAL
|
||||
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
|
||||
OP_IF
|
||||
OP_CHECKSIG
|
||||
OP_ELSE
|
||||
<remote_htlckey> OP_SWAP
|
||||
<remote_htlcpubkey> OP_SWAP
|
||||
OP_SIZE 32 OP_EQUAL
|
||||
OP_IF
|
||||
# To local node via HTLC-success transaction.
|
||||
OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
|
||||
2 OP_SWAP <local_htlckey> 2 OP_CHECKMULTISIG
|
||||
2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
|
||||
OP_ELSE
|
||||
# To remote node after timeout.
|
||||
OP_DROP <cltv_expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP
|
||||
@ -167,7 +167,7 @@ To timeout the HTLC, the remote node spends it with the witness:
|
||||
|
||||
If a revoked commitment transaction is published, the remote node can spend this output immediately with the following witness:
|
||||
|
||||
<revocation_sig> <revocationkey>
|
||||
<revocation_sig> <revocationpubkey>
|
||||
|
||||
To redeem the HTLC, the HTLC-success transaction is used as detailed below.
|
||||
|
||||
@ -232,12 +232,12 @@ The witness script for the output is:
|
||||
|
||||
OP_IF
|
||||
# Penalty transaction
|
||||
<revocationkey>
|
||||
<revocationpubkey>
|
||||
OP_ELSE
|
||||
`to_self_delay`
|
||||
OP_CSV
|
||||
OP_DROP
|
||||
<local_delayedkey>
|
||||
<local_delayedpubkey>
|
||||
OP_ENDIF
|
||||
OP_CHECKSIG
|
||||
|
||||
@ -253,7 +253,7 @@ Note that there are two possible variants for each node.
|
||||
* `txin[0]` outpoint: `txid` and `output_index` from `funding_created` message
|
||||
* `txin[0]` sequence: 0xFFFFFFFF
|
||||
* `txin[0]` script bytes: 0
|
||||
* `txin[0]` witness: `0 <signature_for_key1> <signature_for_key2>`
|
||||
* `txin[0]` witness: `0 <signature_for_pubkey1> <signature_for_pubkey2>`
|
||||
* txout count: 0, 1 or 2
|
||||
* `txout` amount: final balance to be paid to one node (minus `fee_satoshis` from `closing_signed`, if this peer funded the channel)
|
||||
* `txout` script: as specified in that node's `scriptpubkey` in its `shutdown` message
|
||||
@ -402,8 +402,8 @@ committed HTLCs:
|
||||
|
||||
## Key Derivation
|
||||
|
||||
Each commitment transaction uses a unique set of keys: `localkey` and `remotekey`.
|
||||
The HTLC-success and HTLC-timeout transactions use `local_delayedkey` and `revocationkey`.
|
||||
Each commitment transaction uses a unique set of keys: `localpubkey` and `remotepubkey`.
|
||||
The HTLC-success and HTLC-timeout transactions use `local_delayedpubkey` and `revocationpubkey`.
|
||||
These are changed for every transaction based on the `per_commitment_point`.
|
||||
|
||||
The reason for key change is so that trustless watching for revoked
|
||||
@ -417,46 +417,46 @@ avoid storage of every commitment transaction, a _watcher_ can be given the
|
||||
the scripts required for the penalty transaction; thus, a _watcher_ need only be
|
||||
given (and store) the signatures for each penalty input.
|
||||
|
||||
Changing the `localkey` and `remotekey` every time ensures that commitment
|
||||
Changing the `localpubkey` and `remotepubkey` every time ensures that commitment
|
||||
transaction ID cannot be guessed; every commitment transaction uses an ID
|
||||
in its output script. Splitting the `local_delayedkey`, which is required for
|
||||
in its output script. Splitting the `local_delayedpubkey`, which is required for
|
||||
the penalty transaction, allows it to be shared with the _watcher_ without
|
||||
revealing `localkey`; even if both peers use the same _watcher_, nothing is revealed.
|
||||
revealing `localpubkey`; even if both peers use the same _watcher_, nothing is revealed.
|
||||
|
||||
Finally, even in the case of normal unilateral close, the HTLC-success
|
||||
and/or HTLC-timeout transactions do not reveal anything to the
|
||||
_watcher_, as it does not know the corresponding `per_commitment_secret` and
|
||||
cannot relate the `local_delayedkey` or `revocationkey` with their bases.
|
||||
cannot relate the `local_delayedpubkey` or `revocationpubkey` with their bases.
|
||||
|
||||
For efficiency, keys are generated from a series of per-commitment secrets
|
||||
that are generated from a single seed, which allows the receiver to compactly
|
||||
store them (see [below](#efficient-per-commitment-secret-storage)).
|
||||
|
||||
### `localkey`, `remotekey`, `local_htlckey`, `remote_htlckey`, `local_delayedkey`, and `remote_delayedkey` Derivation
|
||||
### `localpubkey`, `remotepubkey`, `local_htlcpubkey`, `remote_htlcpubkey`, `local_delayedpubkey`, and `remote_delayedpubkey` Derivation
|
||||
|
||||
These keys are simply generated by addition from their base points:
|
||||
These pubkeys are simply generated by addition from their base points:
|
||||
|
||||
pubkey = basepoint + SHA256(per_commitment_point || basepoint) * G
|
||||
|
||||
The `localkey` uses the local node's `payment_basepoint`; the `remotekey`
|
||||
uses the remote node's `payment_basepoint`; the `local_delayedkey`
|
||||
uses the local node's `delayed_payment_basepoint`; the `local_htlckey` uses the
|
||||
local node's `htlc_basepoint`; and the `remote_delayedkey` uses the remote
|
||||
The `localpubkey` uses the local node's `payment_basepoint`; the `remotepubkey`
|
||||
uses the remote node's `payment_basepoint`; the `local_delayedpubkey`
|
||||
uses the local node's `delayed_payment_basepoint`; the `local_htlcpubkey` uses the
|
||||
local node's `htlc_basepoint`; and the `remote_delayedpubkey` uses the remote
|
||||
node's `delayed_payment_basepoint`.
|
||||
|
||||
The corresponding private keys can be similarly derived, if the basepoint
|
||||
secrets are known (i.e. `localkey`, `local_htlckey`, and `local_delayedkey` only):
|
||||
secrets are known (i.e. the private keys corresponding to `localpubkey`, `local_htlcpubkey`, and `local_delayedpubkey` only):
|
||||
|
||||
secretkey = basepoint_secret + SHA256(per_commitment_point || basepoint)
|
||||
privkey = basepoint_secret + SHA256(per_commitment_point || basepoint)
|
||||
|
||||
### `revocationkey` Derivation
|
||||
### `revocationpubkey` Derivation
|
||||
|
||||
The `revocationkey` is a blinded key: when the local node wishes to create a new
|
||||
The `revocationpubkey` is a blinded key: when the local node wishes to create a new
|
||||
commitment for the remote node, it uses its own `revocation_basepoint` and the remote
|
||||
node's `per_commitment_point` to derive a new `revocationkey` for the
|
||||
node's `per_commitment_point` to derive a new `revocationpubkey` for the
|
||||
commitment. After the remote node reveals the
|
||||
`per_commitment_secret` used (thereby revoking that commitment), the local node
|
||||
can then derive the `revocationsecretkey`, as it now knows the two secrets
|
||||
can then derive the `revocationprivkey`, as it now knows the two secrets
|
||||
necessary to derive the key (`revocation_basepoint_secret` and
|
||||
`per_commitment_secret`).
|
||||
|
||||
@ -464,10 +464,10 @@ The `per_commitment_point` is generated using elliptic-curve multiplication:
|
||||
|
||||
per_commitment_point = per_commitment_secret * G
|
||||
|
||||
And this is used to derive the revocation key from the remote node's
|
||||
And this is used to derive the revocation pubkey from the remote node's
|
||||
`revocation_basepoint`:
|
||||
|
||||
revocationkey = revocation_basepoint * SHA256(revocation_basepoint || per_commitment_point) + per_commitment_point * SHA256(per_commitment_point || revocation_basepoint)
|
||||
revocationpubkey = revocation_basepoint * SHA256(revocation_basepoint || per_commitment_point) + per_commitment_point * SHA256(per_commitment_point || revocation_basepoint)
|
||||
|
||||
This construction ensures that neither the node providing the
|
||||
basepoint nor the node providing the `per_commitment_point` can know the
|
||||
@ -476,7 +476,7 @@ private key without the other node's secret.
|
||||
The corresponding private key can be derived once the `per_commitment_secret`
|
||||
is known:
|
||||
|
||||
revocationsecretkey = revocation_basepoint_secret * SHA256(revocation_basepoint || per_commitment_point) + per_commitment_secret * SHA256(per_commitment_point || revocation_basepoint)
|
||||
revocationprivkey = revocation_basepoint_secret * SHA256(revocation_basepoint || per_commitment_point) + per_commitment_secret * SHA256(per_commitment_point || revocation_basepoint)
|
||||
|
||||
### Per-commitment Secret Requirements
|
||||
|
||||
@ -678,14 +678,14 @@ The *expected weight* of an HTLC transaction is calculated as follows:
|
||||
accepted_htlc_script: 139 bytes
|
||||
- OP_DUP: 1 byte
|
||||
- OP_HASH160: 1 byte
|
||||
- OP_DATA: 1 byte (RIPEMD160(SHA256(revocationkey)) length)
|
||||
- RIPEMD160(SHA256(revocationkey)): 20 bytes
|
||||
- OP_DATA: 1 byte (RIPEMD160(SHA256(revocationpubkey)) length)
|
||||
- RIPEMD160(SHA256(revocationpubkey)): 20 bytes
|
||||
- OP_EQUAL: 1 byte
|
||||
- OP_IF: 1 byte
|
||||
- OP_CHECKSIG: 1 byte
|
||||
- OP_ELSE: 1 byte
|
||||
- OP_DATA: 1 byte (remotekey length)
|
||||
- remotekey: 33 bytes
|
||||
- OP_DATA: 1 byte (remotepubkey length)
|
||||
- remotepubkey: 33 bytes
|
||||
- OP_SWAP: 1 byte
|
||||
- OP_SIZE: 1 byte
|
||||
- 32: 2 bytes
|
||||
@ -697,8 +697,8 @@ The *expected weight* of an HTLC transaction is calculated as follows:
|
||||
- OP_EQUALVERIFY: 1 byte
|
||||
- 2: 1 byte
|
||||
- OP_SWAP: 1 byte
|
||||
- OP_DATA: 1 byte (localkey length)
|
||||
- localkey: 33 bytes
|
||||
- OP_DATA: 1 byte (localpubkey length)
|
||||
- localpubkey: 33 bytes
|
||||
- 2: 1 byte
|
||||
- OP_CHECKMULTISIG: 1 byte
|
||||
- OP_ELSE: 1 byte
|
||||
@ -714,14 +714,14 @@ The *expected weight* of an HTLC transaction is calculated as follows:
|
||||
offered_htlc_script: 133 bytes
|
||||
- OP_DUP: 1 byte
|
||||
- OP_HASH160: 1 byte
|
||||
- OP_DATA: 1 byte (RIPEMD160(SHA256(revocationkey)) length)
|
||||
- RIPEMD160(SHA256(revocationkey)): 20 bytes
|
||||
- OP_DATA: 1 byte (RIPEMD160(SHA256(revocationpubkey)) length)
|
||||
- RIPEMD160(SHA256(revocationpubkey)): 20 bytes
|
||||
- OP_EQUAL: 1 byte
|
||||
- OP_IF: 1 byte
|
||||
- OP_CHECKSIG: 1 byte
|
||||
- OP_ELSE: 1 byte
|
||||
- OP_DATA: 1 byte (remotekey length)
|
||||
- remotekey: 33 bytes
|
||||
- OP_DATA: 1 byte (remotepubkey length)
|
||||
- remotepubkey: 33 bytes
|
||||
- OP_SWAP: 1 byte
|
||||
- OP_SIZE: 1 byte
|
||||
- OP_DATA: 1 byte (32 length)
|
||||
@ -731,8 +731,8 @@ The *expected weight* of an HTLC transaction is calculated as follows:
|
||||
- OP_DROP: 1 byte
|
||||
- 2: 1 byte
|
||||
- OP_SWAP: 1 byte
|
||||
- OP_DATA: 1 byte (localkey length)
|
||||
- localkey: 33 bytes
|
||||
- OP_DATA: 1 byte (localpubkey length)
|
||||
- localpubkey: 33 bytes
|
||||
- 2: 1 byte
|
||||
- OP_CHECKMULTISIG: 1 byte
|
||||
- OP_ELSE: 1 byte
|
||||
@ -817,7 +817,7 @@ coinbase (note that such a P2PKH input is inadvisable, as detailed in [BOLT #2](
|
||||
# privkey in base58: cRCH7YNcarfvaiY1GWUKQrRGmoezvfAiqHtdRvxe16shzbd7LDMz
|
||||
# pubkey in base68: mm3aPLSv9fBrbS68JzurAMp4xGoddJ6pSf
|
||||
|
||||
The funding transaction is paid to the following keys:
|
||||
The funding transaction is paid to the following pubkeys:
|
||||
|
||||
local_funding_pubkey: 023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb
|
||||
remote_funding_pubkey: 030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c1
|
||||
@ -893,9 +893,9 @@ INTERNAL: remote_revocation_basepoint: 02466d7fcae563e5cb09a0d1870bb580344804617
|
||||
# From local_delayed_payment_basepoint_secret
|
||||
INTERNAL: local_delayed_payment_basepoint: 023c72addb4fdf09af94f0c94d7fe92a386a7e70cf8a1d85916386bb2535c7b1b1
|
||||
INTERNAL: local_per_commitment_point: 025f7117a78150fe2ef97db7cfc83bd57b2e2c0d0dd25eaf467a4a1c2a45ce1486
|
||||
INTERNAL: remote_secretkey: 8deba327a7cc6d638ab0eb025770400a6184afcba6713c210d8d10e199ff2fda01
|
||||
INTERNAL: remote_privkey: 8deba327a7cc6d638ab0eb025770400a6184afcba6713c210d8d10e199ff2fda01
|
||||
# From local_delayed_payment_basepoint_secret, local_per_commitment_point and local_delayed_payment_basepoint
|
||||
INTERNAL: local_delayed_secretkey: adf3464ce9c2f230fd2582fda4c6965e4993ca5524e8c9580e3df0cf226981ad01
|
||||
INTERNAL: local_delayed_privkey: adf3464ce9c2f230fd2582fda4c6965e4993ca5524e8c9580e3df0cf226981ad01
|
||||
-->
|
||||
|
||||
Here are the points used to derive the obscuring factor for the commitment number:
|
||||
@ -909,11 +909,11 @@ And, here are the keys needed to create the transactions:
|
||||
local_funding_privkey: 30ff4956bbdd3222d44cc5e8a1261dab1e07957bdac5ae88fe3261ef321f374901
|
||||
local_funding_pubkey: 023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb
|
||||
remote_funding_pubkey: 030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c1
|
||||
local_secretkey: bb13b121cdc357cd2e608b0aea294afca36e2b34cf958e2e6451a2f27469449101
|
||||
localkey: 030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e7
|
||||
remotekey: 0394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b
|
||||
local_delayedkey: 03fd5960528dc152014952efdb702a88f71e3c1653b2314431701ec77e57fde83c
|
||||
local_revocation_key: 0212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b19
|
||||
local_privkey: bb13b121cdc357cd2e608b0aea294afca36e2b34cf958e2e6451a2f27469449101
|
||||
localpubkey: 030d417a46946384f88d5f3337267c5e579765875dc4daca813e21734b140639e7
|
||||
remotepubkey: 0394854aa6eab5b2a8122cc726e9dded053a2184d88256816826d6231c068d4a5b
|
||||
local_delayedpubkey: 03fd5960528dc152014952efdb702a88f71e3c1653b2314431701ec77e57fde83c
|
||||
local_revocation_pubkey: 0212a140cd0c6539d07cd08dfe09984dec3251ea808b892efeac3ede9402bf2b19
|
||||
# funding wscript = 5221023da092f6980e58d2c037173180e9a465476026ee50f96695963e8efe436f54eb21030e9f7b623d2ccc7c9bd44d66d5ce21ce504c0acf6385a132cec6d3c39fa711c152ae
|
||||
|
||||
And, here are the test vectors themselves:
|
||||
@ -1490,8 +1490,8 @@ seeded with `0x000...00`.
|
||||
|
||||
# Appendix E: Key Derivation Test Vectors
|
||||
|
||||
These test the derivation for `localkey`, `remotekey`, `local_htlckey`, `remote_htlckey`, `local_delayedkey`, and
|
||||
`remote_delayedkey` (which use the same formula), as well as the `revocationkey`.
|
||||
These test the derivation for `localpubkey`, `remotepubkey`, `local_htlcpubkey`, `remote_htlcpubkey`, `local_delayedpubkey`, and
|
||||
`remote_delayedpubkey` (which use the same formula), as well as the `revocationpubkey`.
|
||||
|
||||
All of them use the following secrets (and thus the derived points):
|
||||
|
||||
@ -1500,15 +1500,15 @@ All of them use the following secrets (and thus the derived points):
|
||||
base_point: 0x036d6caac248af96f6afa7f904f550253a0f3ef3f5aa2fe6838a95b216691468e2
|
||||
per_commitment_point: 0x025f7117a78150fe2ef97db7cfc83bd57b2e2c0d0dd25eaf467a4a1c2a45ce1486
|
||||
|
||||
name: derivation of key from basepoint and per_commitment_point
|
||||
name: derivation of pubkey from basepoint and per_commitment_point
|
||||
# SHA256(per_commitment_point || basepoint)
|
||||
# => SHA256(0x025f7117a78150fe2ef97db7cfc83bd57b2e2c0d0dd25eaf467a4a1c2a45ce1486 || 0x036d6caac248af96f6afa7f904f550253a0f3ef3f5aa2fe6838a95b216691468e2)
|
||||
# = 0xcbcdd70fcfad15ea8e9e5c5a12365cf00912504f08ce01593689dd426bca9ff0
|
||||
# + basepoint (0x036d6caac248af96f6afa7f904f550253a0f3ef3f5aa2fe6838a95b216691468e2)
|
||||
# = 0x0235f2dbfaa89b57ec7b055afe29849ef7ddfeb1cefdb9ebdc43f5494984db29e5
|
||||
localkey: 0x0235f2dbfaa89b57ec7b055afe29849ef7ddfeb1cefdb9ebdc43f5494984db29e5
|
||||
localpubkey: 0x0235f2dbfaa89b57ec7b055afe29849ef7ddfeb1cefdb9ebdc43f5494984db29e5
|
||||
|
||||
name: derivation of secret key from basepoint secret and per_commitment_secret
|
||||
name: derivation of private key from basepoint secret and per_commitment_secret
|
||||
# SHA256(per_commitment_point || basepoint)
|
||||
# => SHA256(0x025f7117a78150fe2ef97db7cfc83bd57b2e2c0d0dd25eaf467a4a1c2a45ce1486 || 0x036d6caac248af96f6afa7f904f550253a0f3ef3f5aa2fe6838a95b216691468e2)
|
||||
# = 0xcbcdd70fcfad15ea8e9e5c5a12365cf00912504f08ce01593689dd426bca9ff0
|
||||
@ -1516,7 +1516,7 @@ All of them use the following secrets (and thus the derived points):
|
||||
# = 0xcbced912d3b21bf196a766651e436aff192362621ce317704ea2f75d87e7be0f
|
||||
localprivkey: 0xcbced912d3b21bf196a766651e436aff192362621ce317704ea2f75d87e7be0f
|
||||
|
||||
name: derivation of revocation key from basepoint and per_commitment_point
|
||||
name: derivation of revocation pubkey from basepoint and per_commitment_point
|
||||
# SHA256(revocation_basepoint || per_commitment_point)
|
||||
# => SHA256(0x036d6caac248af96f6afa7f904f550253a0f3ef3f5aa2fe6838a95b216691468e2 || 0x025f7117a78150fe2ef97db7cfc83bd57b2e2c0d0dd25eaf467a4a1c2a45ce1486)
|
||||
# = 0xefbf7ba5a074276701798376950a64a90f698997cce0dff4d24a6d2785d20963
|
||||
@ -1526,7 +1526,7 @@ All of them use the following secrets (and thus the derived points):
|
||||
# = 0xcbcdd70fcfad15ea8e9e5c5a12365cf00912504f08ce01593689dd426bca9ff0
|
||||
# x per_commitment_point = 0x0325ee7d3323ce52c4b33d4e0a73ab637711057dd8866e3b51202a04112f054c43
|
||||
# 0x02c00c4aadc536290422a807250824a8d87f19d18da9d610d45621df22510db8ce + 0x0325ee7d3323ce52c4b33d4e0a73ab637711057dd8866e3b51202a04112f054c43 => 0x02916e326636d19c33f13e8c0c3a03dd157f332f3e99c317c141dd865eb01f8ff0
|
||||
revocationkey: 0x02916e326636d19c33f13e8c0c3a03dd157f332f3e99c317c141dd865eb01f8ff0
|
||||
revocationpubkey: 0x02916e326636d19c33f13e8c0c3a03dd157f332f3e99c317c141dd865eb01f8ff0
|
||||
|
||||
name: derivation of revocation secret from basepoint_secret and per_commitment_secret
|
||||
# SHA256(revocation_basepoint || per_commitment_point)
|
||||
|
||||
@ -92,9 +92,9 @@ The local and remote nodes each hold a *commitment transaction*. Each of these
|
||||
commitment transactions has four types of outputs:
|
||||
|
||||
1. _local node's main output_: Zero or one output, to pay to the *local node's*
|
||||
commitment key.
|
||||
commitment pubkey.
|
||||
2. _remote node's main output_: Zero or one output, to pay to the *remote node's*
|
||||
commitment key.
|
||||
commitment pubkey.
|
||||
3. _local node's offered HTLCs_: Zero or more pending payments (*HTLCs*), to pay
|
||||
the *remote node* in return for a payment preimage.
|
||||
4. _remote node's offered HTLCs_: Zero or more pending payments (*HTLCs*), to
|
||||
@ -364,7 +364,7 @@ recognize all of the *remote node's* commitment transaction HTLC outputs. It can
|
||||
detect the data loss state, because it has signed the transaction, and the
|
||||
commitment number is greater than expected. If both nodes support
|
||||
`option-data-loss-protect`, the local node will possess the remote's
|
||||
`per_commitment_point`, and thus can derive its own `remotekey` for the
|
||||
`per_commitment_point`, and thus can derive its own `remotepubkey` for the
|
||||
transaction, in order to salvage its own funds. Note: in this scenario, the node
|
||||
will be unable to salvage the HTLCs.
|
||||
|
||||
@ -476,34 +476,34 @@ If not otherwise resolved, once the HTLC output has expired, it is considered
|
||||
|
||||
If any node tries to cheat by broadcasting an outdated commitment transaction
|
||||
(any previous commitment transaction besides the most current one), the other
|
||||
node in the channel can use its revocation key to claim all the funds from the
|
||||
node in the channel can use its revocation private key to claim all the funds from the
|
||||
channel's original funding transaction.
|
||||
|
||||
## Requirements
|
||||
|
||||
Once a node discovers a commitment transaction for which *it* has a
|
||||
revocation key, the funding transaction output is *resolved*.
|
||||
revocation private key, the funding transaction output is *resolved*.
|
||||
|
||||
A local node:
|
||||
- MUST NOT broadcast a commitment transaction for which *it* has exposed the
|
||||
revocation key.
|
||||
`per_commitment_secret`.
|
||||
- MAY take no action regarding the _local node's main output_, as this is a
|
||||
simple P2WPKH output to itself.
|
||||
- Note: this output is considered *resolved* by the commitment transaction
|
||||
itself.
|
||||
- MUST *resolve* the _remote node's main output_ by spending it using the
|
||||
revocation key.
|
||||
revocation private key.
|
||||
- MUST *resolve* the _local node's offered HTLCs_ in one of three ways:
|
||||
* spend the *commitment tx* using the payment revocation key.
|
||||
* spend the *commitment tx* using the payment revocation private key.
|
||||
* spend the *commitment tx* using the payment preimage (if known).
|
||||
* spend the *HTLC-timeout tx*, if the remote node has published it.
|
||||
- MUST *resolve* the _remote node's offered HTLCs_ in one of two ways:
|
||||
* spend the *commitment tx* using the payment revocation key.
|
||||
* spend the *commitment tx* once the HTLC timeout has passed.
|
||||
- MUST *resolve* the _remote node's HTLC-timeout transaction_ by spending it
|
||||
using the revocation key.
|
||||
using the revocation private key.
|
||||
- MUST *resolve* the _remote node's HTLC-success transaction_ by spending it
|
||||
using the revocation key.
|
||||
using the revocation private key.
|
||||
- SHOULD extract the payment preimage from the transaction input witness, if
|
||||
it's not already known.
|
||||
- MAY use a single transaction to *resolve* all the outputs.
|
||||
@ -583,22 +583,22 @@ A node:
|
||||
As described in [BOLT #3](03-transactions.md), the witness for this transaction
|
||||
is:
|
||||
|
||||
<sig> 1 { OP_IF <key> OP_ELSE to_self_delay OP_CSV OP_DROP <key> OP_ENDIF OP_CHECKSIG }
|
||||
<sig> 1 { OP_IF <revocationpubkey> OP_ELSE to_self_delay OP_CSV OP_DROP <local_delayedpubkey> OP_ENDIF OP_CHECKSIG }
|
||||
|
||||
The *expected weight* of the `to_local` penalty transaction witness is
|
||||
calculated as follows:
|
||||
|
||||
to_local_script: 83 bytes
|
||||
- OP_IF: 1 byte
|
||||
- OP_DATA: 1 byte (revocationkey length)
|
||||
- revocationkey: 33 bytes
|
||||
- OP_DATA: 1 byte (revocationpubkey length)
|
||||
- revocationpubkey: 33 bytes
|
||||
- OP_ELSE: 1 byte
|
||||
- OP_DATA: 1 byte (delay length)
|
||||
- delay: 8 bytes
|
||||
- OP_CHECKSEQUENCEVERIFY: 1 byte
|
||||
- OP_DROP: 1 byte
|
||||
- OP_DATA: 1 byte (localkey length)
|
||||
- localkey: 33 bytes
|
||||
- OP_DATA: 1 byte (local_delayedpubkey length)
|
||||
- local_delayedpubkey: 33 bytes
|
||||
- OP_ENDIF: 1 byte
|
||||
- OP_CHECKSIG: 1 byte
|
||||
|
||||
@ -639,8 +639,8 @@ calculated as follows (some calculations have already been made in
|
||||
- number_of_witness_elements: 1 byte
|
||||
- revocation_sig_length: 1 byte
|
||||
- revocation_sig: 73 bytes
|
||||
- revocation_key_length: 1 byte
|
||||
- revocation_key: 33 bytes
|
||||
- revocationpubkey_length: 1 byte
|
||||
- revocationpubkey: 33 bytes
|
||||
- witness_script_length: 1 byte
|
||||
- witness_script (accepted_htlc_script)
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user