From rusty at rustcorp.com.au  Wed Nov 21 22:45:23 2018
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Thu, 22 Nov 2018 09:15:23 +1030
Subject: [Lightning-dev] [PATCH] First draft of
	option_simplfied_commitment
In-Reply-To: <1ea6ecfd-0f17-4aab-44c8-3c3e457cc4d6@bluematt.me>
References: <87bm6jp42a.fsf@rustcorp.com.au>
	<e0c177b5-99ab-4ca9-81e3-3bb53d92d262@bluematt.me>
	<1ea6ecfd-0f17-4aab-44c8-3c3e457cc4d6@bluematt.me>
Message-ID: <87va4qnj7g.fsf@rustcorp.com.au>

Matt Corallo <lf-lists at 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 <rusty at 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 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
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev