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

Reply via email to