Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-22 📝 Original message: Ah, oops, indeed, that is ...
📅 Original date posted:2018-11-22
📝 Original message:
Ah, oops, indeed, that is much cleaner :). Still need a CSV of 1, though :(.
> On Nov 21, 2018, at 17:45, Rusty Russell <rusty at rustcorp.com.au> wrote:
>
> 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
📝 Original message:
Ah, oops, indeed, that is much cleaner :). Still need a CSV of 1, though :(.
> On Nov 21, 2018, at 17:45, Rusty Russell <rusty at rustcorp.com.au> wrote:
>
> 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