Ah, oops, indeed, that is much cleaner :). Still need a CSV of 1, though :(.
> On Nov 21, 2018, at 17:45, Rusty Russell <ru...@rustcorp.com.au> wrote: > > 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
