Matt Corallo <lf-li...@mattcorallo.com> writes: > Oh, also, obviously, the HTLC transactions need a pushme output, though > luckily only one for the side we expect to be broadcasting the transaction.
The intent was that HTLC transactions are now SIGHASH_SINGLE|SIGHASH_ANYONECANPAY (since we don't need the txid), so you Bring Your Own Fees. I missed this in the draft, patch coming... Cheers, Rusty. > On 11/21/18 2:54 AM, Matt Corallo wrote: >> Not sure if others already realized this, but in thinking about our RBF >> policy hack from Adelaide a bit more, to allow the carve-out exception >> of "last tx in a package, which has only one unconfirmed ancestor" to >> always be available for the "honest party" when broadcasting a >> commitment transaction, we also need at least a CSV delay of 1 block on >> the HTLC transaction outputs (as otherwise those transactions could >> count as the carve-out tx). >> >> Matt >> >> On 11/21/18 2:17 AM, Rusty Russell wrote: >>> I'm also starting to implement this, to see what I missed! >>> >>> Original at https://github.com/lightningnetwork/lightning-rfc/pull/513 >>> >>> Pasted here for your reading convenience: >>> >>> - Option is sticky; it set at open time, it stays with channel >>> - I didn't want to have to handle penalty txs on channels which switch >>> - We could, however, upgrade on splice. >>> - Feerate is fixed at 253 >>> - `feerate_per_kw` is still in open /accept (just ignored): >>> multifund may want it. >>> - closing tx negotiates *upwards* not *downwards* >>> - Starting from base fee of commitment tx = 282 satoshi. >>> - to_remote output is always CSV delayed. >>> - pushme outputs are paid for by funder, but only exist if the matching >>> to_local/remote output exists. >>> - After 10 blocks, they become anyone-can-spend (they need to see the >>> to-local/remote witness script though). >>> - remotepubkey is not rotated. >>> - You must spend your pushme output; you may sweep for others. >>> >>> Signed-off-by: Rusty Russell <ru...@rustcorp.com.au> >>> >>> diff --git a/02-peer-protocol.md b/02-peer-protocol.md >>> index 7cf9ebf..6ec1155 100644 >>> --- a/02-peer-protocol.md >>> +++ b/02-peer-protocol.md >>> @@ -133,7 +133,9 @@ node can offer. >>> (i.e. 1/4 the more normally-used 'satoshi per 1000 vbytes') that this >>> side will pay for commitment and HTLC transactions, as described in >>> [BOLT #3](03-transactions.md#fee-calculation) (this can be adjusted >>> -later with an `update_fee` message). >>> +later with an `update_fee` message). Note that if >>> +`option_simplified_commitment` is negotiated, this `feerate_per_kw` >>> +is treated as 253 for all transactions. >>> `to_self_delay` is the number of blocks that the other node's to-self >>> outputs must be delayed, using `OP_CHECKSEQUENCEVERIFY` delays; this >>> @@ -208,7 +210,8 @@ The receiving node MUST fail the channel if: >>> - `push_msat` is greater than `funding_satoshis` * 1000. >>> - `to_self_delay` is unreasonably large. >>> - `max_accepted_htlcs` is greater than 483. >>> - - it considers `feerate_per_kw` too small for timely processing or >>> unreasonably large. >>> + - if `option_simplified_commitment` is not negotiated: >>> + - it considers `feerate_per_kw` too small for timely processing >>> or unreasonably large. >>> - `funding_pubkey`, `revocation_basepoint`, `htlc_basepoint`, >>> `payment_basepoint`, or `delayed_payment_basepoint` >>> are not valid DER-encoded compressed secp256k1 pubkeys. >>> - `dust_limit_satoshis` is greater than `channel_reserve_satoshis`. >>> @@ -228,7 +231,7 @@ The *channel reserve* is specified by the peer's >>> `channel_reserve_satoshis`: 1% >>> The sender can unconditionally give initial funds to the receiver >>> using a non-zero `push_msat`, but even in this case we ensure that the >>> funder has sufficient remaining funds to pay fees and that one side >>> has some amount it can spend (which also implies there is at least one >>> non-dust output). Note that, like any other on-chain transaction, this >>> payment is not certain until the funding transaction has been >>> confirmed sufficiently (with a danger of double-spend until this >>> occurs) and may require a separate method to prove payment via >>> on-chain confirmation. >>> -The `feerate_per_kw` is generally only of concern to the sender (who >>> pays the fees), but there is also the fee rate paid by HTLC >>> transactions; thus, unreasonably large fee rates can also penalize the >>> recipient. >>> +The `feerate_per_kw` is generally only of concern to the sender (who >>> pays the fees), but there is also the fee rate paid by HTLC >>> transactions; thus, unreasonably large fee rates can also penalize the >>> recipient. It is ignored for `option_simplified_commitment`. >>> 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. >>> @@ -340,6 +343,12 @@ This message introduces the `channel_id` to >>> identify the channel. It's derived f >>> #### Requirements >>> +Both peers: >>> + - if `option_simplified_commitment` was negotiated: >>> + - `option_simplified_commitment` applies to all commitment and >>> HTLC transactions >>> + - otherwise: >>> + - `option_simplified_commitment` does not apply to any commitment >>> or HTLC transactions >>> + >>> The sender MUST set: >>> - `channel_id` by exclusive-OR of the `funding_txid` and the >>> `funding_output_index` from the `funding_created` message. >>> - `signature` to the valid signature, using its `funding_pubkey` >>> for the initial commitment transaction, as defined in [BOLT >>> #3](03-transactions.md#commitment-transaction). >>> @@ -351,6 +360,12 @@ The recipient: >>> - on receipt of a valid `funding_signed`: >>> - SHOULD broadcast the funding transaction. >>> +#### Rationale >>> + >>> +We decide on `option_simplified_commitment` at this point when we >>> first have to generate the commitment >>> +transaction. Even if a later reconnection does not negotiate this >>> parameter, this channel will honor it. >>> +This simplifies channel state, particularly penalty transaction >>> handling. >>> + >>> ### The `funding_locked` Message >>> This message indicates that the funding transaction has reached the >>> `minimum_depth` asked for in `accept_channel`. Once both nodes have >>> sent this, the channel enters normal operating mode. >>> @@ -508,8 +523,11 @@ The funding node: >>> - SHOULD send a `closing_signed` message. >>> The sending node: >>> - - MUST set `fee_satoshis` less than or equal to the >>> - base fee of the final commitment transaction, as calculated in [BOLT >>> #3](03-transactions.md#fee-calculation). >>> + - if `option_upfront_shutdown_script` applies to the final >>> commitment transaction: >>> + - MUST set `fee_satoshis` greater than or equal to 282. >>> + - otherwise: >>> + - MUST set `fee_satoshis` less than or equal to the >>> + base fee of the final commitment transaction, as calculated in >>> [BOLT #3](03-transactions.md#fee-calculation). >>> - SHOULD set the initial `fee_satoshis` according to its >>> estimate of cost of inclusion in a block. >>> - MUST set `signature` to the Bitcoin signature of the close >>> @@ -543,9 +561,18 @@ progress is made, even if only by a single >>> satoshi at a time. To avoid >>> keeping state and to handle the corner case, where fees have shifted >>> between disconnection and reconnection, negotiation restarts on >>> reconnection. >>> -Note there is limited risk if the closing transaction is >>> -delayed, but it will be broadcast very soon; so there is usually no >>> -reason to pay a premium for rapid processing. >>> +In the `option_simplified_commitment` case, the fees on the commitment >>> +transaction itself are minimal (it is assumed that a child >>> transaction will >>> +supply additional fee incentive), so that forms a floor for negotiation. >>> +[BOLT #3](03-transactions.md#fee-calculation), gives 282 satoshis (1116 >>> +weight, 254 `feerate_per_kw`). >>> + >>> +Otherwise, the commitment transaction usually pays a premium fee, so >>> that >>> +forms a ceiling. >>> + >>> +Note there is limited risk if the closing transaction is delayed, but >>> it will >>> +be broadcast very soon; so there is usually no reason to pay a >>> premium for >>> +rapid processing. >>> ## Normal Operation >>> @@ -763,7 +790,10 @@ is destined, is described in [BOLT >>> #4](04-onion-routing.md). >>> A sending node: >>> - MUST NOT offer `amount_msat` it cannot pay for in the >>> remote commitment transaction at the current `feerate_per_kw` (see >>> "Updating >>> -Fees") while maintaining its channel reserve. >>> +Fees") while maintaining its channel reserve >>> + - if `option_simplified_commitment` applies to this commitment >>> transaction and the sending >>> + node is the funder: >>> + - MUST be able to additionally pay for `to_local_pushme` and >>> `to_remote_pushme` above its reserve. >>> - MUST offer `amount_msat` greater than 0. >>> - MUST NOT offer `amount_msat` below the receiving node's >>> `htlc_minimum_msat` >>> - MUST set `cltv_expiry` less than 500000000. >>> @@ -782,7 +812,7 @@ Fees") while maintaining its channel reserve. >>> A receiving node: >>> - receiving an `amount_msat` equal to 0, OR less than its own >>> `htlc_minimum_msat`: >>> - SHOULD fail the channel. >>> - - receiving an `amount_msat` that the sending node cannot afford at >>> the current `feerate_per_kw` (while maintaining its channel reserve): >>> + - receiving an `amount_msat` that the sending node cannot afford at >>> the current `feerate_per_kw` (while maintaining its channel reserve >>> and any `to_local_pushme` and `to_remote_pushme` fees): >>> - SHOULD fail the channel. >>> - if a sending node adds more than its `max_accepted_htlcs` HTLCs to >>> its local commitment transaction, OR adds more than its >>> `max_htlc_value_in_flight_msat` worth of offered HTLCs to its local >>> commitment transaction: >>> @@ -997,6 +1027,11 @@ A node: >>> ### Updating Fees: `update_fee` >>> +If `option_simplified_commitment` applies to the commitment transaction, >>> +`update_fee` is never used: the `feerate_per_kw` is always considered >>> 253, but >>> +the funder also pays 2000 satoshi for the `to_local_pushme` and >>> +`to_remote_pushme` outputs. >>> + >>> An `update_fee` message is sent by the node which is paying the >>> Bitcoin fee. Like any update, it's first committed to the receiver's >>> commitment transaction and then (once acknowledged) committed to the >>> @@ -1020,13 +1055,19 @@ given in [BOLT >>> #3](03-transactions.md#fee-calculation). >>> #### Requirements >>> The node _responsible_ for paying the Bitcoin fee: >>> - - SHOULD send `update_fee` to ensure the current fee rate is >>> sufficient (by a >>> + - if `option_simplified_commitment` applies to the commitment >>> transaction: >>> + - MUST NOT send `update_fee`. >>> + - otherwise: >>> + - SHOULD send `update_fee` to ensure the current fee rate is >>> sufficient (by a >>> significant margin) for timely processing of the commitment >>> transaction. >>> The node _not responsible_ for paying the Bitcoin fee: >>> - MUST NOT send `update_fee`. >>> A receiving node: >>> + - if `option_simplified_commitment` applies to the commitment >>> transaction: >>> + - SHOULD fail the channel. >>> + - MUST NOT update the `feerate_per_kw`. >>> - if the `update_fee` is too low for timely processing, OR is >>> unreasonably large: >>> - SHOULD fail the channel. >>> - if the sender is not responsible for paying the Bitcoin fee: >>> @@ -1038,7 +1079,12 @@ A receiving node: >>> #### Rationale >>> -Bitcoin fees are required for unilateral closes to be effective — >>> +Fee adjustments are unnecessary for `option_simplified_commitment` which >>> +relies on "pushme" outputs and a child transaction which will provide >>> +additional fee incentive which can be calculated at the time it is >>> spent, and >>> +replaced by higher-fee children if required. >>> + >>> +Without this option, bitcoin fees are required for unilateral closes >>> to be effective — >>> particularly since there is no general method for the broadcasting >>> node to use >>> child-pays-for-parent to increase its effective fee. >>> diff --git a/03-transactions.md b/03-transactions.md >>> index e769961..440bd0d 100644 >>> --- a/03-transactions.md >>> +++ b/03-transactions.md >>> @@ -82,6 +82,8 @@ To allow an opportunity for penalty transactions, in >>> case of a revoked commitmen >>> The reason for the separate transaction stage for HTLC outputs is so >>> that HTLCs can timeout or be fulfilled even though they are within the >>> `to_self_delay` delay. >>> Otherwise, the required minimum timeout on HTLCs is lengthened by >>> this delay, causing longer timeouts for HTLCs traversing the network. >>> +If `option_simplified_commitment` applies to the commitment >>> transaction, then the `to_self_delay` used for all transactions is the >>> greater of the `to_self_delay` sent by each peer. Otherwise, each >>> peer sends the `to_self_delay` to be used for the other peer's >>> commitment amd HTLC transactions. >>> + >>> The amounts for each output MUST be rounded down to whole satoshis. >>> If this amount, minus the fees for the HTLC transaction, is less than >>> the `dust_limit_satoshis` set by the owner of the commitment >>> transaction, the output MUST NOT be produced (thus the funds add to >>> fees). >>> #### `to_local` Output >>> @@ -109,7 +111,40 @@ 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 `remotepubkey`. >>> +This output sends funds to the other peer, thus is not encumbered by a >>> +revocation private key. >>> + >>> +If `option_simplified_commitment` applies to the commitment >>> transaction, the `to_remote` output is delayed similarly to the >>> `to_local` output, and is to a fixed key: >>> + >>> + `to_self_delay` >>> + OP_CSV >>> + OP_DROP >>> + <remote_pubkey> >>> + >>> +The output is spent by a transaction with `nSequence` field set to >>> `to_self_delay` (which can only be valid after that duration has >>> passed) and witness: >>> + >>> + <remote_sig> >>> + >>> +Otherwise, this output is a simple P2WPKH to `remotepubkey`. >>> + >>> + >>> +#### `to_local_pushme` and `to_remote_pushme` Output >>> (option_simplified_commitment) >>> + >>> +This output can be spent by the local and remote nodes respectivey to >>> provide incentive to mine the transaction, using >>> child-pays-for-parent. They are only added if the `to_local` and >>> `to_remote` outputs exist, respectively. >>> + >>> + OP_DEPTH >>> + OP_IF >>> + <pubkey> OP_CHECKSIG >>> + OP_ELSE >>> + 10 OP_CSV >>> + OP_ENDIF >>> + >>> +The `<pubkey>` is `<local_delayedpubkey>` to `to_local_pushme` and >>> +`<remote_delayedpubkey>` for `to_remote_pushme`. The output amount is >>> +1000 satoshi, to encourage spending of the output. Once the >>> +`remote_pubkey` is revealed (by spending the `to_local` output) and >>> +the commitment transaction is 10 blocks deep, anyone can spend it. >>> + >>> #### Offered HTLC Outputs >>> @@ -294,6 +329,9 @@ The fee calculation for both commitment >>> transactions and HTLC >>> transactions is based on the current `feerate_per_kw` and the >>> *expected weight* of the transaction. >>> +Note that if `option_simplified_commitment` applies to the commitment >>> +transaction then `feerate_per_kw` is 253. >>> + >>> The actual and expected weights vary for several reasons: >>> * Bitcoin uses DER-encoded signatures, which vary in size. >>> @@ -306,10 +344,12 @@ Thus, a simplified formula for *expected weight* >>> is used, which assumes: >>> * Signatures are 73 bytes long (the maximum length). >>> * There are a small number of outputs (thus 1 byte to count them). >>> * There are always both a `to_local` output and a `to_remote` output. >>> +* (if `option_simplified_commitment`) there are always both a >>> `to_local_pushme` and `to_remote_pushme` output. >>> This yields the following *expected weights* (details of the >>> computation in [Appendix A](#appendix-a-expected-weights)): >>> - Commitment weight: 724 + 172 * num-untrimmed-htlc-outputs >>> + Commitment weight (no option_simplified_commitment): 724 + 172 >>> * num-untrimmed-htlc-outputs >>> + Commitment weight (option_simplified_commitment: 1116 + 172 * >>> num-untrimmed-htlc-outputs >>> HTLC-timeout weight: 663 >>> HTLC-success weight: 703 >>> @@ -366,7 +406,7 @@ outputs) is 7140 satoshi. The final fee may be >>> even higher if the >>> ### Fee Payment >>> -Base commitment transaction fees are extracted from the funder's >>> amount; if that amount is insufficient, the entire amount of the >>> funder's output is used. >>> +Base commitment transaction fees and amounts for `to_local_pushme` >>> and `to_remote_pushme` outputs are extracted from the funder's amount; >>> if that amount is insufficient, the entire amount of the funder's >>> output is used. >>> Note that after the fee amount is subtracted from the to-funder output, >>> that output may be below `dust_limit_satoshis`, and thus will also >>> @@ -390,23 +430,29 @@ committed HTLCs: >>> 2. Calculate the base [commitment transaction fee](#fee-calculation). >>> 3. Subtract this base fee from the funder (either `to_local` or >>> `to_remote`), >>> with a floor of 0 (see [Fee Payment](#fee-payment)). >>> +4. If `option_simplified_commitment` applies to the commitment >>> transaction, >>> + subtract 2000 satoshis from the funder (either `to_local` or >>> `to_remote`). >>> 3. For every offered HTLC, if it is not trimmed, add an >>> [offered HTLC output](#offered-htlc-outputs). >>> 4. For every received HTLC, if it is not trimmed, add an >>> [received HTLC output](#received-htlc-outputs). >>> 5. If the `to_local` amount is greater or equal to >>> `dust_limit_satoshis`, >>> add a [`to_local` output](#to_local-output). >>> +6. If `option_simplified_commitment` applies to the commitment >>> transaction, >>> + and `to_local` was added, add `to_local_pushme`. >>> 6. If the `to_remote` amount is greater or equal to >>> `dust_limit_satoshis`, >>> add a [`to_remote` output](#to_remote-output). >>> +6. If `option_simplified_commitment` applies to the commitment >>> transaction, >>> + and `to_remote` was added, add `to_remote_pushme`. >>> 7. Sort the outputs into [BIP 69 >>> order](#transaction-input-and-output-ordering). >>> # Keys >>> ## Key Derivation >>> -Each commitment transaction uses a unique set of keys: `localpubkey` >>> and `remotepubkey`. >>> +Each commitment transaction uses a unique `localpubkey`, and a >>> `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`. >>> +These are changed for every transaction based on the >>> `per_commitment_point`, with the exception of `remotepubkey` if >>> `option_simplified_commitment` is negotiated. >>> The reason for key change is so that trustless watching for revoked >>> transactions can be outsourced. Such a _watcher_ should not be able to >>> @@ -419,8 +465,9 @@ 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 `localpubkey` and `remotepubkey` every time ensures that >>> commitment >>> -transaction ID cannot be guessed; every commitment transaction uses >>> an ID >>> +Changing the `localpubkey` every time ensures that commitment >>> +transaction ID cannot be guessed except in the trivial case where >>> there is no >>> +`to_local` output, as every commitment transaction uses an ID >>> 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 `localpubkey`; even if both peers use the same _watcher_, >>> nothing is revealed. >>> @@ -434,14 +481,13 @@ 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)). >>> -### `localpubkey`, `remotepubkey`, `local_htlcpubkey`, >>> `remote_htlcpubkey`, `local_delayedpubkey`, and `remote_delayedpubkey` >>> Derivation >>> +### `localpubkey``local_htlcpubkey`, `remote_htlcpubkey`, >>> `local_delayedpubkey`, and `remote_delayedpubkey` Derivation >>> These pubkeys are simply generated by addition from their base points: >>> pubkey = basepoint + SHA256(per_commitment_point || basepoint) * G >>> -The `localpubkey` uses the local node's `payment_basepoint`; the >>> `remotepubkey` >>> -uses the remote node's `payment_basepoint`; the `local_delayedpubkey` >>> +The `localpubkey` uses the local 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`. >>> @@ -451,6 +497,17 @@ secrets are known (i.e. the private keys >>> corresponding to `localpubkey`, `local_ >>> privkey = basepoint_secret + SHA256(per_commitment_point || >>> basepoint) >>> +### `remotepubkey` Derivation >>> + >>> +If `option_simplified_commitment` is negotiated the `remotepubkey` is >>> simply the remote node's `payment_basepoint`, otherwise it is >>> calculated as above using the remote node's `payment_basepoint`. >>> + >>> +The simplified derivation means that a node can spend a commitment >>> +transaction even if it has lost data and doesn't know the >>> +corresponding `payment_basepoint`. A watchtower could correlate >>> +transactions given to it which only have a `to_remote` output if it >>> +sees one of them onchain, but such transactions do not need any >>> +enforcement and should not be handed to a watchtower. >>> + >>> ### `revocationpubkey` Derivation >>> The `revocationpubkey` is a blinded key: when the local node wishes >>> to create a new >>> @@ -636,12 +693,22 @@ The *expected weight* of a commitment >>> transaction is calculated as follows: >>> - var_int: 1 byte (pk_script length) >>> - pk_script (p2wsh): 34 bytes >>> - output_paying_to_remote: 31 bytes >>> + output_paying_to_remote (no option_simplified_commitment): 31 bytes >>> - value: 8 bytes >>> - var_int: 1 byte (pk_script length) >>> - pk_script (p2wpkh): 22 bytes >>> - htlc_output: 43 bytes >>> + output_paying_to_remote (option_simplified_commitment): 43 bytes >>> + - value: 8 bytes >>> + - var_int: 1 byte (pk_script length) >>> + - pk_script (p2wsh): 34 bytes >>> + >>> + output_pushme (option_simplified_commitment): 43 bytes >>> + - value: 8 bytes >>> + - var_int: 1 byte (pk_script length) >>> + - pk_script (p2wsh): 34 bytes >>> + >>> + htlc_output: 43 bytes >>> - value: 8 bytes >>> - var_int: 1 byte (pk_script length) >>> - pk_script (p2wsh): 34 bytes >>> @@ -650,7 +717,7 @@ The *expected weight* of a commitment transaction >>> is calculated as follows: >>> - flag: 1 byte >>> - marker: 1 byte >>> - commitment_transaction: 125 + 43 * num-htlc-outputs bytes >>> + commitment_transaction (no option_simplified_commitment): 125 + >>> 43 * num-htlc-outputs bytes >>> - version: 4 bytes >>> - witness_header <---- part of the witness data >>> - count_tx_in: 1 byte >>> @@ -663,15 +730,32 @@ The *expected weight* of a commitment >>> transaction is calculated as follows: >>> ....htlc_output's... >>> - lock_time: 4 bytes >>> + commitment_transaction (option_simplified_commitment): 223 + 43 >>> * num-htlc-outputs bytes >>> + - version: 4 bytes >>> + - witness_header <---- part of the witness data >>> + - count_tx_in: 1 byte >>> + - tx_in: 41 bytes >>> + funding_input >>> + - count_tx_out: 1 byte >>> + - tx_out: 172 + 43 * num-htlc-outputs bytes >>> + output_paying_to_remote, >>> + output_paying_to_local, >>> + output_pushme, >>> + output_pushme, >>> + ....htlc_output's... >>> + - lock_time: 4 bytes >>> + >>> Multiplying non-witness data by 4 results in a weight of: >>> - // 500 + 172 * num-htlc-outputs weight >>> + // 500 + 172 * num-htlc-outputs weight (no >>> option_simplified_commitment) >>> + // 892 + 172 * num-htlc-outputs weight >>> (option_simplified_commitment) >>> commitment_transaction_weight = 4 * commitment_transaction >>> // 224 weight >>> witness_weight = witness_header + witness >>> - overall_weight = 500 + 172 * num-htlc-outputs + 224 weight >>> + overall_weight (no option_simplified_commitment) = 500 + 172 * >>> num-htlc-outputs + 224 weight >>> + overall_weight (option_simplified_commitment) = 892 + 172 * >>> num-htlc-outputs + 224 weight >>> ## Expected Weight of HTLC-timeout and HTLC-success Transactions >>> diff --git a/05-onchain.md b/05-onchain.md >>> index 231c209..c5fb5e1 100644 >>> --- a/05-onchain.md >>> +++ b/05-onchain.md >>> @@ -89,21 +89,29 @@ trigger any action. >>> # Commitment Transaction >>> The local and remote nodes each hold a *commitment transaction*. >>> Each of these >>> -commitment transactions has four types of outputs: >>> +commitment transactions has six types of outputs: >>> 1. _local node's main output_: Zero or one output, to pay to the >>> *local node's* >>> -commitment pubkey. >>> +delayed pubkey. >>> 2. _remote node's main output_: Zero or one output, to pay to the >>> *remote node's* >>> -commitment pubkey. >>> +pubkey. >>> +1. _local node's push output_: Zero or one output, to pay to the >>> *local node's* >>> +delayed pubkey. >>> +2. _remote node's push output_: Zero or one output, to pay to the >>> *remote node's* >>> +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 >>> pay the *local node* in return for a payment preimage. >>> To incentivize the local and remote nodes to cooperate, an >>> `OP_CHECKSEQUENCEVERIFY` >>> -relative timeout encumbers the *local node's outputs* (in the *local >>> node's >>> +relative timeout encumbers some outputs: the *local node's outputs* >>> (in the *local node's >>> commitment transaction*) and the *remote node's outputs* (in the >>> *remote node's >>> -commitment transaction*). So for example, if the local node publishes >>> its >>> +commitment transaction*). If `option_simplified_commitment` applies >>> +to the commitment transaction, then the *to_remote* output of each >>> commitment is >>> +identically encumbered, for fairness. >>> + >>> +Without `option_simplified_commitment`, if the local node publishes its >>> commitment transaction, it will have to wait to claim its own funds, >>> whereas the remote node will have immediate access to its own funds. >>> As a >>> consequence, the two commitment transactions are not identical, but >>> they are >>> @@ -140,6 +148,11 @@ A node: >>> - otherwise: >>> - MUST use the *last commitment transaction*, for which it >>> has a >>> signature, to perform a *unilateral close*. >>> + - MUST spend any `to_local_pushme` output, providing sufficient >>> fees as incentive to include the commitment transaction in a block >>> + - SHOULD use >>> [replace-by-fee](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki) >>> >>> or other mechanism on the spending transaction if it proves >>> insufficient for timely inclusion in a block. >>> + >>> +A node: >>> + - MAY monitor the blockchain for unspent `to_local_pushme` and >>> `to_remote_pushme` outputs and try to spend them after 10 confirmations. >>> ## Rationale >>> @@ -154,7 +167,8 @@ need not consume resources monitoring the channel >>> state. >>> There exists a bias towards preferring mutual closes over unilateral >>> closes, >>> because outputs of the former are unencumbered by a delay and are >>> directly >>> spendable by wallets. In addition, mutual close fees tend to be less >>> exaggerated >>> -than those of commitment transactions. So, the only reason not to use >>> the >>> +than those of commitment transactions (or in the case of >>> `option_simplified_commitment`, >>> +the commitment transaction may require a child transaction to cause >>> it to be mined). So, the only reason not to use the >>> signature from `closing_signed` would be if the fee offered was too >>> small for >>> it to be processed. >>> diff --git a/09-features.md b/09-features.md >>> index d06fcff..caea38b 100644 >>> --- a/09-features.md >>> +++ b/09-features.md >>> @@ -26,6 +26,7 @@ These flags may only be used in the `init` message: >>> | 3 | `initial_routing_sync` | Indicates that the sending node >>> needs a complete routing information dump | [BOLT >>> #7](07-routing-gossip.md#initial-sync) | >>> | 4/5 | `option_upfront_shutdown_script` | Commits to a shutdown >>> scriptpubkey when opening channel | [BOLT >>> #2](02-peer-protocol.md#the-open_channel-message) | >>> | 6/7 | `gossip_queries` | More sophisticated gossip >>> control | [BOLT #7](07-routing-gossip.md#query-messages) | >>> +| 8/9 | `option_simplified_commitment` | Simplified >>> commitment transactions | [BOLT #3](03-transactions.md) | >>> ## Assigned `globalfeatures` flags >>> _______________________________________________ >>> Lightning-dev mailing list >>> Lightning-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >>> >> _______________________________________________ >> Lightning-dev mailing list >> Lightning-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
