mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2025-01-18 21:32:31 +01:00
Code Issues Projects Releases Wiki Activity

htlckey: new basepoint avoid holding the payment secret.

Browse Source 
This is stolen from @sstone's #243 "reduce attack surface".

This breaks compatibility, as agreed at the 2017-11-13 meeting.
Note also that it does not update the test vectors.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell 2017-10-31 11:32:32 +10:30
parent 046f5acb16
commit 4f91f0bb2a
3 changed files with 23 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
.aspell.en.pws
View File

@ -292,3 +292,8 @@ SRV
TTL
URI
cli
paymentkey
htlckey
remotehtlcsig
localhtlcsig
basepoints

12
02-peer-protocol.md
View File

@ -98,6 +98,7 @@ desire to set up a new channel.
* [`33`:`revocation_basepoint`]
* [`33`:`payment_basepoint`]
* [`33`:`delayed_payment_basepoint`]
* [`33`:`htlc_basepoint`]
* [`33`:`first_per_commitment_point`]
* [`1`:`channel_flags`]
@ -120,7 +121,7 @@ funding flow wishes to advertise this channel publicly to the network
as detailed within
[BOLT #7](https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#bolt-7-p2p-node-and-channel-discovery).
The `funding_pubkey` is the public key in the 2-of-2 multisig script of the funding transaction output. The `revocation_basepoint` is combined with the revocation preimage for this commitment transaction to generate a unique revocation key for this commitment transaction. The `payment_basepoint` and `delayed_payment_basepoint` are similarly used to generate a series of keys for any payments to this node: `delayed_payment_basepoint` is used to for payments encumbered by a delay. Varying these keys ensures that the transaction ID of each commitment transaction is unpredictable by an external observer, even if one commitment transaction is seen: this property is very useful for preserving privacy when outsourcing penalty transactions to third parties.
The `funding_pubkey` is the public key in the 2-of-2 multisig script of the funding transaction output. The `revocation_basepoint` is combined with the revocation preimage for this commitment transaction to generate a unique revocation key for this commitment transaction. The `payment_basepoint`, `htlc_basepoint` and `delayed_payment_basepoint` are similarly used to generate a series of keys for any payments to this node: `delayed_payment_basepoint` is used to for payments encumbered by a delay. Varying these keys ensures that the transaction ID of each commitment transaction is unpredictable by an external observer, even if one commitment transaction is seen: this property is very useful for preserving privacy when outsourcing penalty transactions to third parties.
FIXME: Describe Dangerous feature bit for larger channel amounts.
@ -136,12 +137,11 @@ to less than 2^24 satoshi. The sender MUST set `push_msat` to
equal or less than to 1000 * `funding_satoshis`. The sender SHOULD set `to_self_delay` sufficient to ensure the sender
can irreversibly spend a commitment transaction output in case of
misbehavior by the receiver.
`funding_pubkey`, `revocation_basepoint`, `payment_basepoint` and `delayed_payment_basepoint` MUST be valid DER-encoded
`funding_pubkey`, `revocation_basepoint`, `htlc_basepoint`, `payment_basepoint` and `delayed_payment_basepoint` MUST be valid DER-encoded
compressed secp256k1 pubkeys. The sender SHOULD set `feerate_per_kw`
to at least the rate it estimates would cause the transaction to be
immediately included in a block.
The sender SHOULD set `dust_limit_satoshis` to a sufficient value to
allow commitment transactions to propagate through the Bitcoin
network. It SHOULD set `htlc_minimum_msat` to the minimum
@ -166,10 +166,9 @@ The receiving node MAY fail the channel if it considers
The receiver MUST fail the channel if it
considers `feerate_per_kw` too small for timely processing, or unreasonably large. The
receiver MUST fail the channel if `funding_pubkey`, `revocation_basepoint`, `payment_basepoint` or `delayed_payment_basepoint`
receiver MUST fail the channel if `funding_pubkey`, `revocation_basepoint`, `htlc_basepoint`, `payment_basepoint` or `delayed_payment_basepoint`
are not valid DER-encoded compressed secp256k1 pubkeys.
The receiver MUST NOT consider funds received using `push_msat` to be received until the funding transaction has reached sufficient depth.
@ -183,6 +182,8 @@ The sender can unconditionally give initial funds to the receiver using a non-ze
The `feerate_per_kw` is generally only a concern to the sender (who pays the fees), but that is also the feerate paid by HTLC transactions; thus unreasonably large fee rates can also penalize the recipient.
Separating the `htlc_basepoint` from the `payment_basepoint` improves security: a node needs the secret associated with the `htlc_basepoint` to produce HTLC signatures for the protocol, but the secret for the `payment_basepoint` can be in cold storage.
#### Future
@ -212,6 +213,7 @@ acceptance of the new channel.
* [`33`:`revocation_basepoint`]
* [`33`:`payment_basepoint`]
* [`33`:`delayed_payment_basepoint`]
* [`33`:`htlc_basepoint`]
* [`33`:`first_per_commitment_point`]
#### Requirements

22
03-transactions.md
View File

@ -21,7 +21,7 @@ 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_delayedkey` and `remote_delayedkey` Derivation](#localkey-remotekey-local_delayedkey-and-remote_delayedkey-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)
* [Per-commitment Secret Requirements](#per-commitment-secret-requirements)
* [Efficient Per-commitment Secret Storage](#efficient-per-commitment-secret-storage)
@ -116,10 +116,10 @@ This output sends funds to a HTLC-timeout transaction after the HTLC timeout, or
OP_IF
OP_CHECKSIG
OP_ELSE
<remotekey> OP_SWAP OP_SIZE 32 OP_EQUAL
<remote_htlckey> OP_SWAP OP_SIZE 32 OP_EQUAL
OP_NOTIF
# To me via HTLC-timeout transaction (timelocked).
OP_DROP 2 OP_SWAP <localkey> 2 OP_CHECKMULTISIG
OP_DROP 2 OP_SWAP <local_htlckey> 2 OP_CHECKMULTISIG
OP_ELSE
# To you with preimage.
OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
@ -129,7 +129,7 @@ This output sends funds to a HTLC-timeout transaction after the HTLC timeout, or
The remote node can redeem the HTLC with the witness:
<remotesig> <payment_preimage>
<remotehtlcsig> <payment_preimage>
If a revoked commitment transaction is published, the remote node can spend this output immediately with the following witness:
@ -146,12 +146,12 @@ This output sends funds to the remote peer after the HTLC timeout or using the r
OP_IF
OP_CHECKSIG
OP_ELSE
<remotekey> OP_SWAP
<remote_htlckey> OP_SWAP
OP_SIZE 32 OP_EQUAL
OP_IF
# To me via HTLC-success transaction.
OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
2 OP_SWAP <localkey> 2 OP_CHECKMULTISIG
2 OP_SWAP <local_htlckey> 2 OP_CHECKMULTISIG
OP_ELSE
# To you after timeout.
OP_DROP <cltv_expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP
@ -161,7 +161,7 @@ This output sends funds to the remote peer after the HTLC timeout or using the r
To timeout the HTLC, the remote node spends it with the witness:
<remotesig> 0
<remotehtlcsig> 0
If a revoked commitment transaction is published, the remote node can spend this output immediately with the following witness:
@ -216,7 +216,7 @@ These HTLC transactions are almost identical, except the HTLC-Timeout transactio
* `txin[0]` outpoint: `txid` of the commitment transaction and `output_index` of the matching HTLC output for the HTLC transaction.
* `txin[0]` sequence: `0`
* `txin[0]` script bytes: `0`
* `txin[0]` witness stack: `0 <remotesig> <localsig> <payment_preimage>` for HTLC-Success, `0 <remotesig> <localsig> 0` for HTLC-Timeout.
* `txin[0]` witness stack: `0 <remotehtlcsig> <localhtlcsig> <payment_preimage>` for HTLC-Success, `0 <remotehtlcsig> <localhtlcsig> 0` for HTLC-Timeout.
* txout count: 1
* `txout[0]` amount: the HTLC amount minus fees (see [Fee Calculation](#fee-calculation)).
* `txout[0]` script: version 0 P2WSH with witness script as shown below.
@ -416,7 +416,7 @@ their bases.
For efficiency, keys are generated from a series of per-commitment secrets which are generated from a single seed, allowing the receiver to compactly store them (see [below](#efficient-per-commitment-secret-storage)).
### `localkey`, `remotekey`, `local_delayedkey` and `remote_delayedkey` Derivation
### `localkey`, `remotekey`, `local_htlckey`, `remote_htlckey`, `local_delayedkey` and `remote_delayedkey` Derivation
These keys are simply generated by addition from their base points:
@ -424,12 +424,12 @@ These keys are simply generated by addition from their base points:
The `localkey` uses the local node's `payment_basepoint`, `remotekey`
uses the remote node's `payment_basepoint`, the `local_delayedkey`
uses the local node's `delayed_payment_basepoint`, and the
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 node's
`delayed_payment_basepoint`.
The corresponding private keys can be derived similarly if the basepoint
secrets are known (i.e., `localkey` and `local_delayedkey` only):
secrets are known (i.e., `localkey`, `local_htlckey` and `local_delayedkey` only):
secretkey = basepoint_secret + SHA256(per_commitment_point || basepoint)