Good morning list,
For extra bikeshedding opportunities, I present below, a proposal for explicit
management of commitment transaction and mutual close transaction fees.
By this thought, "explicit management", I want to convey, that the parties have
more control over fees.
### Additional Variables
Nodes will now additionally track for each channel:
* `from_local_fee_msat` - 64-bit unsigned integer. The amount of fees
contributed by this node.
* `from_remote_fee_msat` - 64-bit unsigned integer. The amount of fees
contributed by this node
If the node is the initiator of the channel, its `from_local_fee_msat` contains
the fee decided during channel opening, and its `from_remote_fee_msat` is 0.
If it is not the initiator, then the reverse is true.
#### Rationale
Although onchain fees are measured in satoshi, the above variables are in
millisatoshi in order to allow finer proportional deductions when reducing fees.
### Additional channel state updates
These update messages behave similarly to `offer_htlc`. Multiple of these
messages may be sent, and then `commitment_signed` puts them into effect for
the commitment transaction.
#### The `add_fees` message
1. type - TBD
2. data:
* [`8`: `short_channel_id`]
* [`8` : `additional_donated_fee_sat`]
`additional_donated_fee_sat` is the amount of fees that the sending node
proposes to donate as fees, in order for the commitment transaction to be
confirmed in a timely manner.
The donated fee is deducted from the sender funds of the channel.
Multiple `add_fees` message add up their effects.
The sender:
* MUST NOT offer a fee donation that would put their balance below the channel
reserve.
* MAY donate their entire balance, minus the channel reserve.
Both nodes:
* MUST convert the satoshi units in this message to millisatoshis before
updating the `from_local_fee_msat` and `from_remote_fee_msat` when a commitment
is signed.
#### The `propose_deduct_fees` message
1. type - TBD
2. data:
* [`8`: `short_channel_id`]
* [`8` : `proposed_deducted_fee_sat`]
`proposed_deducted_fee_sat` is the amount by which the total fees will be
deducted.
This message starts a sub-protocol, where other channel state update messages
for the channel are disallowed and will trigger an `error` message with code
`TBD`.
The sub-protocol involves `propose_deduct_fees` messages, and is ended once
both sides send `accept_deduct_fees`.
The lowest `proposed_deducted_fee_sat` before the `accept_deduct_fees` is
selected.
Thus each node has the ability to veto a deduction by simply sending a 0
`proposed_deducted_fee_sat`.
#### The `accept_deduct_fees` message
1. type - TBD
2. data:
* [`8`: `short_channel_id`]
* [`8` : `min_proposed_deducted_fee_sat`]
Once both nodes have sent this `accept_deduct_fees` for a channel with the same
`min_proposed_deducted_fee_sat`, then both nodes have come to an agreement on
how much to deduct as fees.
The deduction is split between the two nodes in proportion to how much each one
donated to the fees.
Thus, to compute how much will be deducted from `from_local_fee_msat`, the
division below is rounded down:
deduct_from_local_fee_msat = 1000 * min_proposed_deducted_fee_sat *
from_local_fee_msat / (from_local_fee_msat + from_remote_fee_msat)
The receiver:
* SHOULD send `propose_deduct_fees` with the lowest deducted fee, if the
`min_proposed_deducted_fee_sat` does not match what it believes to have seen as
the lowest.
* this may occur if messages get sent at about the same time.
* MAY fail the channel if this occurs too often.
* MAY fail the channel if it considers the fee deduction to be too low to be
reasonable.
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev