diff --git a/.aspell.en.pws b/.aspell.en.pws index 6744cc297..1675ec813 100644 --- a/.aspell.en.pws +++ b/.aspell.en.pws @@ -425,3 +425,4 @@ ints replaceability disincentivize UTXOs +blockheight diff --git a/02-peer-protocol.md b/02-peer-protocol.md index 38e2b72ac..47a5d78d4 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -1171,6 +1171,10 @@ This message initiates the v2 channel establishment workflow. 2. data: * [`...*byte`:`type`] 1. type: 2 (`require_confirmed_inputs`) + 1. type: 3 (`request_funds`) + 2. data: + * [`u64`:`requested_sats`] + * [`u32`:`blockheight`] Rationale and Requirements are the same as for [`open_channel`](#the-open_channel-message), with the following additions. @@ -1185,11 +1189,19 @@ The sending node: - MUST set `funding_feerate_perkw` to the feerate for this transaction - If it requires the receiving node to only use confirmed inputs: - MUST set `require_confirmed_inputs` + - if is accepting a `option_will_fund` offer from the peer's + `node_announcement`: + - MUST set `requested_sats` to the amount of sats they are requesting + the peer contribute to the channel in their `funding_satoshi` + - MUST set `blockheight` to the blockheight to be used + to calculate the commitment transaction accepter's CLTV encumbrance The receiving node: - MAY fail the negotiation if: - the `locktime` is unacceptable - the `funding_feerate_perkw` is unacceptable + - if the `option_will_fund` tlv is present and: + - the `blockheight` is considered too far in the past or future - MUST fail the negotiation if: - `require_confirmed_inputs` is set but it cannot provide confirmed inputs @@ -1223,7 +1235,11 @@ as a convenience for implementations. The sending node may require the other participant to only use confirmed inputs. This ensures that the sending node doesn't end up paying the fees of a low -feerate unconfirmed ancestor of one of the other participant's inputs. + +If the receiving node has advertised `option_will_fund`, opener +may `request_funds` from the peer. They provide an amount requested +and a `blockheight` which is the starting point for the funding lease +of 4032 blocks. ### The `accept_channel2` Message @@ -1258,6 +1274,18 @@ acceptance of the new channel. 2. data: * [`...*byte`:`type`] 1. type: 2 (`require_confirmed_inputs`) + 1. type: 3 (`will_fund`) + 2. data: + * [`signature`:`signature`] + * [`lease_rates`:`lease_rates`] + +1. subtype: `lease_rates` +2. data: + * [`u16`:`funding_weight`] + * [`u16`:`lease_fee_basis`] + * [`u16`:`channel_fee_max_basis`] + * [`u32`:`lease_fee_base_sat`] + * [`tu32`:`channel_fee_max_base_msat`] Rationale and Requirements are the same as listed above, for [`accept_channel`](#the-accept_channel-message) with the following @@ -1270,10 +1298,47 @@ The accepting node: - MAY respond with a `funding_satoshis` value of zero. - If it requires the opening node to only use confirmed inputs: - MUST set `require_confirmed_inputs` + - if the `option_will_fund` tlv was sent in `open_channel2`: + - if they decline to contribute funds or to be paid for their + contributions: + - SHOULD omit the `will_fund` tlv + - if they decide to accept the offer: + - MUST include a `will_fund` tlv + - MUST set `funding_satoshis` to a value greater than 0msat + - MAY send `funding_satoshis` less than `requested_sats` + - MUST set `lease_fee_base_sat` to the base fee + (in satoshi) it will charge for the `funding_satoshis` + - MUST set `lease_fee_basis` to the amount + (in thousandths of satoshi) it will charge per `funding_satoshi` + - MUST set `funding_weight` to the weight they will charge + the peer for. + + - MUST set `channel_fee_base_max_msat` to the max base fee + (in millisatoshi) it will charge for any HTLC on this channel + during the funding period. + - MUST set `channel_fee_max_basis` to the max amount + (in thousandths of a satoshi) it will charge per transferred + satoshi during the funding period. + - MUST set `signature` to the ECDSA signature of + SHA256("option_will_fund" || `funding_pubkey`|| `blockheight` || + `channel_fee_base_max_msat` || `channel_fee_max_basis`) + using the node_id key. The receiving node: + - SHOULD fail the negotiation if: + - they sent `request_funds` tlv and: + - the `funding_satoshi` is less than required + - the `lease_fee_basis` is too high + - the `lease_fee_base_sat` is too high + - the `funding_weight` is too high + - the `channel_fee_max_basis` is too high + - the `channel_fee_max_base_msat` is too high + - the `signature` is invalid + - SHOULD accept the negotiation if: + - the `funding_satoshi` is excess of `requested_sats` - MUST fail the negotiation if: - `require_confirmed_inputs` is set but it cannot provide confirmed inputs + - `will_fund` tlv was recieved and they DID NOT send a `request_funds` tlv #### Rationale @@ -1286,6 +1351,44 @@ Instead, the channel reserve is fixed at 1% of the total channel balance rounded down to the nearest whole satoshi or the `dust_limit_satoshis`, whichever is greater. +If the opener requested a `option_will_fund` peer to contribute funds to +this channel, via the inclusion of a `will_fund` tlv in their +`open_channel2`, the peer may or may not choose to accept the offer. + +If the accepter node has run out of available funds, they should +either fail the negotiation or reply with a `funding_satoshi` set +to 0msat and no `will_fund` TLV, allowing the peer to fail the negotiation. + +`funding_weight` is the weight it will cost the node to +contribute the offered funds to the channel. This is added to the +total lease fee at a rate of `funding_weight` times the +`funding_feerate_perkw` established in `open_channel2`. + +The total lease fee is added to the accepter node's output in the +commitment transaction. It is equal to the `lease_fee_base_sat` + +min(`accept_channel2`.`funding_satoshis`,`open_channel2`.`requested_sats`) +* `lease_fee_basis` / 10_000 + `funding_feerate_perkw` * +`funding_weight` / 1000, rounded down to the nearest satoshi. See [Appendix A: The lease fee](#appendix-a-the-lease-fee). + +`signature` signs the leasing node's `funding_pubkey`, the +lease expiration block (opener's `blockheight` + 4032), and the returned +`channel_fee` parameters. This provides the opener +with proof in the case the accepter does not maintain the stated +`channel_fee` rates during the channel's funding lease. + +The lessor is the `accepter`, who contributes funds to the channel for a fee. +The lessee is the `opener`, who requests for funds and pays the lessor a fee +for the funds they contribute to the channel. A lease is defined as being for +4032 blocks; a `lease_end` is defined as the `open_channel2`.`blockheight` ++ 4032. If the initiating node sent `request_funds` and the +accepting node replied with `will_fund` this channel is considered 'leased'. + +During the duration of the lease, the lessee may limit +the rate funds are routed through the channel as this provides the lessor +the opportunity to move the funds elsewhere (and renders the +lease lock fairly useless). A sensible policy here depends on the +motivation of the lessee in acquiring the lease. + ### Funding Composition Funding composition for channel establishment v2 makes use of the @@ -2312,6 +2415,12 @@ be trimmed at the updated feerate, this could overflow the configured `max_dust_htlc_exposure_msat`. Whether to close the channel preemptively or not is left as a matter of node policy. +The lessor's lease is only shortened when a new `blockheight` is committed, +otherwise it's always 4032 blocks in the future. If the peer doesn't +update the blockheight, at some point it has to start the closing process +to retrieve its funds. 1008 blocks seems a reasonable (but not compulsory!) +answer here. + ## Message Retransmission Because communication transports are unreliable, and may need to be @@ -2578,6 +2687,59 @@ interactive transaction construction, or safely abort that transaction if it was not signed by one of the peers, who has thus already removed it from its state. +## Appendix A: The lease fee (`option_will_fund`) + +The lease fee is added to the accepter's balance in a channel, in addition +to the `funding_satoshi` that they are contributing. The channel initiator +must contribute enough funds to cover `open_channel2`.`funding_satoshis`, +the lease fee, and their tx weight * `funding_feerate_perkw` / 1000. + +The lease fee is calculated as: + + `lease_fee_base_sat` + + min(`accept_channel2`.`funding_satoshis`, `open_channel2`.`requested_sats`) * `lease_fee_basis` / 10_000 + + `funding_weight` * `funding_feerate_perkw` / 1000 + +E.g. +An node requests 1_000_000sats at a feerate of 2500perkw. They +are contributing 500_000sats. Their weight contribution to the +funding transaction will be 720. + +The accepter adds 1,100,000sats and charges a base funding fee of +233sats with a lease fee basis of 22. Their funding weight is 444. +The lease fee is as follows: + + 233 + min(1_000_000,1_100_000) * 22 / 10_000 + 444 * 2500 / 1000 + +The total lease fee for this open is 3543sats. + +The outputs to the peers in the commitment transaction will be + + to-opener: 500_000sats + to-accepter: 1_103_543sats + +The miner fee for the opener will be 720 * 2500 / 1000 or 1800sats. + +Minimum funds that the opener must contribute to the channel open +transaction: + + open_channel2.funding_satoshis: 500_000sats + lease fee: 3_543sats + miner fee: 1_800sats + + total required contribution: 505_343sats + +Minimum funds that the accepter must contribute to the channel open +transaction: + + accept_channel2.funding_satoshis: 1_100_000sats + miner fee[1]: 1_110sats + + total required contribution: 1_101_110sats + + +[1] assumes `444` is their total weight for this transaction. + # Authors [ FIXME: Insert Author List ] diff --git a/03-transactions.md b/03-transactions.md index 1437f8e3f..c73cdb6f8 100644 --- a/03-transactions.md +++ b/03-transactions.md @@ -11,13 +11,18 @@ This details the exact format of on-chain transactions, which both sides need to * [Commitment Transaction](#commitment-transaction) * [Commitment Transaction Outputs](#commitment-transaction-outputs) * [`to_local` Output](#to_local-output) + * [`to_local` Leased channel (`option_will_fund`)](#to-local-leased-channel-option_will_fund) * [`to_remote` Output](#to_remote-output) + * [`to_remote` Leased channel (`option_will_fund`)](#to-remote-leased-channel-option_will_fund) * [`to_local_anchor` and `to_remote_anchor`](#to_local_anchor-and-to_remote_anchor-output-option_anchor_outputs) * [Offered HTLC Outputs](#offered-htlc-outputs) + * [Leasee Offered HTLC Outputs (`option_will_fund`)](#leasee-offered-htlc-outputs-option_will_fund) * [Received HTLC Outputs](#received-htlc-outputs) + * [Leasee Received HTLC Outputs (`option_will_fund`)](#leasee-received-htlc-outputs-option_will_fund) * [Trimmed Outputs](#trimmed-outputs) * [HTLC-timeout and HTLC-success Transactions](#htlc-timeout-and-htlc-success-transactions) - * [Closing Transaction](#closing-transaction) + * [Lease Locked Success and Timeout Transactions (`option-will-fund`)](#lease-locked-success-and-timeout-transactions-option_will_fund) + * [Closing Transaction](#closing-transaction) * [Fees](#fees) * [Fee Calculation](#fee-calculation) * [Fee Payment](#fee-payment) @@ -128,6 +133,30 @@ If a revoked commitment transaction is published, the other party can spend this 1 +##### `to_local` Leased channel (`option_will_fund`) + +If a `lease` applies to the channel, the `to_local` output of the +`leasor`'s commitment transaction is encumbered with a CLTV set to +the `lease_end`. + + OP_IF + # Penalty transaction + + OP_ELSE + OP_CHECKLOCKTIMEVERIFY OP_DROP + `to_self_delay` + OP_CHECKSEQUENCEVERIFY + OP_DROP + + OP_ENDIF + OP_CHECKSIG + +The output is spent by a transaction with `nLocktime` field set to +`lease_end`, containing an input with `nSequence` set to `to_self_delay` +and witness: + + <> + #### `to_remote` Output If `option_anchors` applies to the commitment transaction, the `to_remote` output is encumbered by a one block csv lock. @@ -141,6 +170,25 @@ The output is spent by an input with `nSequence` field set to `1` and witness: Otherwise, this output is a simple P2WPKH to `remotepubkey`. Note: the remote's commitment transaction uses your `localpubkey` for their `to_remote` output to yourself. +##### `to_remote` Leased channel (`option_will_fund`) + +If a `lease` applies to the channel, the `to_remote` output +of the `lessor`'s commitment transaction is +encumbered with a CLTV set to the `lease_end`. This ensures +the `leasor`'s funds are not spendable until the lease expires. + + OP_CHECKLOCKTIMEVERIFY OP_DROP + + # NOTE: if `option_anchors` applies, the following line is included + OP_CHECKSIGVERIFY 1 OP_CHECKSEQUENCEVERIFY + +The output is spent by a transaction with `nLocktime` field set to +`lease_end` and witness: + + + +If `option_anchors`, the input's `nSequence` field is set to `1`. + #### `to_local_anchor` and `to_remote_anchor` Output (option_anchors) This output can be spent by the local and remote nodes respectively to provide incentive to mine the transaction, using child-pays-for-parent. Both @@ -223,6 +271,45 @@ If a revoked commitment transaction is published, the remote node can spend this The sending node can use the HTLC-timeout transaction to timeout the HTLC once the HTLC is expired, as shown below. This is the only way that the local node can timeout the HTLC, and this branch requires ``, which ensures that the local node cannot prematurely timeout the HTLC since the HTLC-timeout transaction has `cltv_expiry` as its specified `locktime`. The local node must also wait `to_self_delay` before accessing these funds, allowing for the remote node to claim these funds if the transaction has been revoked. +### Leasee Offered HTLC Outputs (`option_will_fund`) + +If a `lease` applies to the channel, the leasee's `to_remote` clause of a +commitment transaction now spends to a second transaction, termed the +lease-timeout transaction. The funds are sent into this second stage +transaction, identical to how the lessor's funds are in an offered +HTLC output. This ensures the `lessor`'s funds are not +accessible until `lease_end`. + + # To remote node with revocation key + OP_DUP OP_HASH160 OP_EQUAL + OP_IF + OP_CHECKSIG + OP_ELSE + OP_SWAP OP_SIZE 32 OP_EQUAL + OP_NOTIF + # To local node via HTLC-timeout transaction (timelocked). + OP_DROP 2 OP_SWAP 2 OP_CHECKMULTISIG + OP_ELSE + # To remote node via lease-locked success transaction (timelocked). + OP_HASH160 OP_EQUALVERIFY + 2 OP_SWAP 2 OP_CHECKMULTISIG + OP_CHECKSIG + OP_ENDIF + # NOTE: if `option_anchors` applies, the following line is included + 1 OP_CHECKSEQUENCEVERIFY OP_DROP + OP_ENDIF + + +Note that if `option_anchors` applies, the nSequence field of +the spending input must be `1`. + +To redeem the remote funds, the lease-locked transaction is used as detailed below. +This is the only way that the remote node can spend funds, since this branch requires + ``, which ensures that the remote node must wait until `lease_end` +before accessing these funds. The remote node cannot access their channel funds +until the lease has ended. + + #### Received HTLC Outputs This output sends funds to either the remote node after the HTLC-timeout or using the revocation key, or to an HTLC-success transaction with a successful payment preimage. The output is a P2WSH, with a witness script (no `option_anchors`): @@ -256,12 +343,12 @@ Or, with `option_anchors`: # To local node via HTLC-success transaction. OP_HASH160 OP_EQUALVERIFY 2 OP_SWAP 2 OP_CHECKMULTISIG + 1 OP_CHECKSEQUENCEVERIFY OP_DROP OP_ELSE # To remote node after timeout. OP_DROP OP_CHECKLOCKTIMEVERIFY OP_DROP OP_CHECKSIG OP_ENDIF - 1 OP_CHECKSEQUENCEVERIFY OP_DROP OP_ENDIF To timeout the HTLC, the remote node spends it with the witness: @@ -277,6 +364,44 @@ If a revoked commitment transaction is published, the remote node can spend this To redeem the HTLC, the HTLC-success transaction is used as detailed below. This is the only way that the local node can spend the HTLC, since this branch requires ``, which ensures that the local node must wait `to_self_delay` before accessing these funds allowing for the remote node to claim these funds if the transaction has been revoked. + +### Leasee Received HTLC Outputs (`option_will_fund`) + +If a `lease` applies to the channel, the leasee's `to_remote` clause of a +commitment transaction now spends to a second transaction, termed the +lease-locked timeout transaction. The funds are sent into this second stage +transaction, identical to how the lessor's funds are in an offered +HTLC output. This ensures the `lessor`'s funds are not +accessible until `lease_end`. + + # To remote node with revocation key + OP_DUP OP_HASH160 OP_EQUAL + OP_IF + OP_CHECKSIG + OP_ELSE + OP_SWAP OP_SIZE 32 OP_EQUAL + OP_IF + # To local node via HTLC-success transaction. + OP_HASH160 OP_EQUALVERIFY + 2 OP_SWAP 2 OP_CHECKMULTISIG + # NOTE: if `option_anchors` applies, the following line is included + 1 OP_CHECKSEQUENCEVERIFY OP_DROP + OP_ELSE + # To remote node via lease locked-timeout transaction (timelocked). + OP_DROP 2 OP_SWAP 2 OP_CHECKMULTISIG + OP_ENDIF + OP_ENDIF + + +Note that if `option_anchors` applies, the nSequence field of +the spending input must be `1`. + +To redeem the remote funds, the lease-locked transaction is used as detailed below. +This is the only way that the remote node can spend funds, since this branch requires + ``, which ensures that the remote node must wait until `lease_end` +before accessing these funds. + + ### Trimmed Outputs Each peer specifies a `dust_limit_satoshis` below which outputs should @@ -350,6 +475,35 @@ The witness script for the output is: To spend this via penalty, the remote node uses a witness stack ` 1`, and to collect the output, the local node uses an input with nSequence `to_self_delay` and a witness stack ` 0`. +### Lease Locked Success and Timeout Transactions (`option_will_fund`) + +The lease locked transactions are almost identical, the only difference is the +witness stack elements: lease locked success contains the preimage of the HTLC. + +Note: lease locked transactions are not spendable by a penalty transaction, as +they hold funds that belong to the non-closing peer. + +* version: 2 +* locktime: `lease_end` +* txin count: 1 + * `txin[0]` outpoint: `txid` of the commitment transaction and `output_index` of the matching HTLC output for the lease locked transaction + * `txin[0]` sequence: `0` (set to `1` for `option_anchors`) + * `txin[0]` script bytes: `0` + * `txin[0]` witness stack: `0 ` for lease locked-success, `0 <>` for lease locked-timeout +* txout count: 1 + * `txout[0]` amount: the HTLC `amount_msat` divided by 1000 (rounding down) minus fees in satoshis (see [Fee Calculation](#fee-calculation)) + * `txout[0]` script: version-0 P2WSH with witness script as shown below +* if `option_anchors` applies to this commitment transaction, `SIGHASH_SINGLE|SIGHASH_ANYONECANPAY` is used as described in [BOLT #5](05-onchain.md#generation-of-htlc-transactions). + +The witness script for the output is: + + `lease_end` + OP_CHECKSEQUENCEVERIFY + OP_DROP + + OP_CHECKSIG + + ## Closing Transaction Note that there are two possible variants for each node. diff --git a/07-routing-gossip.md b/07-routing-gossip.md index 4b67a381e..f0d5f42d2 100644 --- a/07-routing-gossip.md +++ b/07-routing-gossip.md @@ -270,6 +270,14 @@ nodes not associated with an already known channel are ignored. * [`32*byte`:`alias`] * [`u16`:`addrlen`] * [`addrlen*byte`:`addresses`] + * [`node_ann_tlvs`:`tlvs`] + +1. `tlv_stream`: `node_ann_tlvs` +2. types: + 1. type: 1 (`option_will_fund`) + 2. data: + * [`lease_rates`:`lease_rates`] + `timestamp` allows for the ordering of messages, in the case of multiple announcements. `rgb_color` and `alias` allow intelligence services to assign @@ -323,6 +331,19 @@ The origin node: bits it sets. - SHOULD not announce a Tor v2 onion service. - MUST NOT announce more than one `type 5` DNS hostname. + - if supports `option_will_fund`: + - MUST include `option_will_fund` tlv type + - MUST set `funding_fee_base_sat` to the base fee (in satoshi) it will charge + for any reciprocated funding. + - MUST set `funding_fee_proportional_basis` to the amount (in + thousandths of a satoshi) it will charge per contributed satoshi. + - MUST set `funding_weight_max` to the maximum weight that will be charged + for any lease. + - MUST set `channel_fee_base_max_msat` to the maximum base fee + (in millisatoshi) it will charge for any HTLC during the funding period. + - MUST set `channel_fee_proportional_basis_max` to the max amount (in + thousandths of a satoshi) it will charge per transferred satoshi during + the funding period. The receiving node: - if `node_id` is NOT a valid compressed public key: @@ -377,6 +398,12 @@ to be ordered in ascending order, unknown ones can be safely ignored. Additional fields beyond `addresses` may also be added in the future—with optional padding within `addresses`, if they require certain alignment. +If a node signals `option_will_fund`, they are signaling that they +will provide funding to a node at the stated terms. They also commit +to a maximum feerate they will charge for transmitting funds over the channel +for the duration of the funding lease. + + ### Security Considerations for Node Aliases Node aliases are user-defined and provide a potential avenue for injection @@ -498,6 +525,13 @@ The origin node: - SHOULD NOT create redundant `channel_update`s - If it creates a new `channel_update` with updated channel parameters: - SHOULD keep accepting the previous channel parameters for 10 minutes + - if they are the `leasor` for a currently active lease on this channel + (`option_will_fund`): + - MUST NOT set `fee_base_msat` greater than `channel_fee_max_base_msat` + (as committed to in the `accept_channel2`.`will_fund`.`signature`) + - MUST NOT set `fee_proportional_millionths` greater than + `channel_fee_max_proportional_thousands` * 1000 + (as committed to in the `accept_channel2`.`will_fund`.`signature`) The receiving node: - if the `short_channel_id` does NOT match a previous `channel_announcement`, diff --git a/proposals/010-will-fund-for-food.md b/proposals/010-will-fund-for-food.md new file mode 100644 index 000000000..7a98b3881 --- /dev/null +++ b/proposals/010-will-fund-for-food.md @@ -0,0 +1,89 @@ +# Will Fund For Food Proposal +## Liquidity Advertisements + +## Problem Description + +Sourcing liquidity on the lightning network is a common problem +for any node looking to accept inbound payments. + +## Overview + +This proposal adds a TLV to the `node_announcement`, +which permits a node to advertise a rate for which they will contribute +funds to an open channel request. Due to the nature of the protocol, these +opens are only possible on the v2 channel protocol. + +Any advertised liquidity lease is for a duration of 4032 blocks, or +approximately 28 days. + +Any node wishing to take advantage of the offered funding contribution +may send an `open_channel2` request to the `node_announcement` node, +and include a `request_funds` tlv. + +The accepter responds to the `open_channel2` by including a `will_fund` +TLV in their `accept_channel2` response, which includes the +fees they're charging for funding an open, the weight of the bytes they'll +add to the funding transaction, the maximum channel-fees +they will charge for moving HTLCs over the channel, and a signature. The +signature can be used by the opener to prove the accepter did not +abide by their channel-fee commitment. + +An accepter may refuse to fund (but allow the open to succeed without +their contribution of funds) or decline to participate in a +channel open (fail the negotiation). + +In the case that the accepter does not or can not supply the +requested funding amount, they may contribute less than the total +requested amount. They may also offer to contribute more. The lease fee +is calculated using the total amount contributed by the accepter. + +Any contributed funds are subject to a funding lease of 4032 blocks. To enforce +this lease, the CSV of the accepter's output on the commitment transaction +is modified to reflect the remaining time left in the lease. + +The opener updates the lease expiry by communicating their current blockheight +to the accepter via `update_blockheight` messages. If the opener fails +to update the blockheight (and thus the CSV lock) in a timely manner, the +accepter should fail the channel. + +When the funding lease expires, the CSV locks on the accepter's +commitment transaction output reverts to the normal value, and the +fund lease is considered concluded. + +## Implementation + +This proposal is only applicable to dual-funded channels, as +single-funded channels do not have the capability to permit +the accepter to contribute funds to a channel. + +A new TLV is added to both the `open_channel2` and `accept_channel2`. +These allow for the negotiation of the terms and funds for the +contribution. + +A new message, `update_blockheight` is added to the Normal Operation of +a channel's lifetime. As with `update_feerate`, only the channel opener +may send this message. + +The CSV value for the commitment transaction outputs to the accepter +are modified. They now incorporate the funding lease and time since +the channel has been opened. As blocks are published, the CSV +for the accepter's outputs is decremented. Once the funding lease +has passed, the CSV value outputs return to the 'normal', non-leased values. + +The lease fee, which is owed to the accepter from the opener's funding +transaction inputs, is found as: + + - the `funding_fee_base_sat`, plus + - the accepter's `funding_satoshis` times the + `funding_fee_proportional_basis` / 1000, plus + - the weight charge times the `funding_feerate_perkw` / 1000 + +The lease fee is added to the accepter's output in the commitment transaction. + +## Security +The opener should consider implementing a rate limit or routing policy +that curtails the export of the leased funds during the duration of +the lease. This depends on the goals of the opener node. + +## Open Questions +TODO