From lf-lists at mattcorallo.com Wed Nov 21 17:55:33 2018 From: lf-lists at mattcorallo.com (Matt Corallo) Date: Wed, 21 Nov 2018 17:55:33 +0000 Subject: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment In-Reply-To: References: <87bm6jp42a.fsf@rustcorp.com.au> Message-ID: <1ea6ecfd-0f17-4aab-44c8-3c3e457cc4d6@bluematt.me> Oh, also, obviously, the HTLC transactions need a pushme output, though luckily only one for the side we expect to be broadcasting the transaction. 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 >> >> 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 >> +??????? >> + >> +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: >> + >> +??? >> + >> +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 >> +??????? OP_CHECKSIG >> +??? OP_ELSE >> +??????? 10 OP_CSV >> +??? OP_ENDIF >> + >> +The `` is `` to `to_local_pushme` and >> +`` 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 at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev