npub1as…wfqmx

📅 Original date posted:2019-10-26
📝 Original message:
We started to look at the `push_me` outputs again. Will refer to them as
`anchor` outputs from now on, to prevent confusion with `push_msat` on the
`open_channel` message.
The cpfp carve-out https://github.com/bitcoin/bitcoin/pull/15681 has been
merged and for reasons described earlier in this thread, we now need to add
a csv time lock to every non-anchor output on the commitment transaction.
To realize this, we are currently considering the following changes:
* Add `to_remote_delay OP_CHECKSEQUENCEVERIFY OP_DROP` to the `to_remote`
output. `to_remote_delay` is the csv delay that the remote party accepted
in the funding flow for their outputs. This not only ensures that the
carve-out works as intended, but also removes the incentive to game the
other party into force-closing. If desired, both parties can still agree to
have different `to_self_delay` values.
* Add `1 OP_CHECKSEQUENCEVERIFY OP_DROP` to the non-revocation clause of
the HTLC outputs.
For the anchor outputs we consider:
* Output type: normal P2WKH. At one point, an additional spending path was
proposed that was unconditional except for a 10 block csv lock. The
intention of this was to prevent utxo set pollution by allowing anyone to
clean up. This however also opens up the possibility for an attacker to
'use up' the cpfp carve-out after those 10 blocks. If the user A is offline
for that period of time, a malicious peer B may already have broadcasted
the commitment tx and pinned down user A's anchor output with a low fee
child. That way, the commitment tx could still remain unconfirmed while an
important htlc expires.
* For the keys to use for `to_remote_anchor` and `to_local_anchor`, we’d
like to introduce new addresses that both parties communicate in the
`open_channel` and `accept_channel` messages. We don’t want to reuse the
main commitment output addresses, because those may (at some point) be cold
storage addresses and the cpfp is likely to happen from a hot wallet.
* Within each version of the commitment transaction, both anchors always
have equal values and are paid for by the initiator. The value of the
anchors is the dust limit that was negotiated in the `open_channel` or
`accept_channel` message of the party that publishes the transaction. It
means that the definitive balance of an endpoint is dependent on which
version of the commitment transaction confirms. This however is nothing
new. In the current commitment format, there are always two or three valid
versions of the commitment transaction (local, remote and sometimes the not
yet revoked previous remote tx) which can have slightly different balances.
For the initiator, it is important to validate the other party's dust
limit. The initiator pays for it and doesn't want to give away more free
money than necessary.
Furthermore, there doesn’t seem to be a compelling reason anymore for
tweaking the keys (new insights into watchtower designs, encrypt by txid).
Therefore we think we can remove them entirely in this new commitment
format and require less channel state data to sweep the outputs.
Joost
On Wed, Nov 21, 2018 at 3:17 AM Rusty Russell <rusty at rustcorp.com.au> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191026/fe4f49f3/attachment-0001.html>