Dynamic Commitment Fees

[Roasbeef]

Currently there's a hard-coded fee of 5k satoshis on the commitment transaction. This sufficed for initial tests but needs to be made dynamic for real-world use in order to maintain the invariant that the current commitment transaction is able to be included in the next block.

In the Lighting Summit, we agreed that for now the initiator pays all fees on the commitment transaction. Therefore any additional fees due to added HTLC's should be subtracted from the initiator's balance if necessary. Additionally messages need to be added to the wire protocol to allow the initiator to signal that they wish to change their desired fee rate on the commitment transaction.

This section within the v1 specification is still being fleshed out. As the specification becomes more concrete, this issue will be updated to detail the requirements as laid out by the spec.

A related issue if the lack of any dynamic fee estimation in lnd currently. In order to robustly implement dynamic commitment fees, we'll also need an internal model which predicts the fee required to make it into the Nth block.

type FeeEstimator interface {
    // EstimateFee takes in a target for the number of blocks 
    // until an initial confirmation and returns the estimated fee 
    // expressed in satoshis/byte. 
    EstimateFee(numBlocks uint32) uint64

    EstimateConfirmation(satPerByte int64) uint32
}

As a placeholder, the above interface can be created with a concrete implementation which simply returns our current hard-coded fee "5000 satoshis". This will allow for a two-step migration, with the first step being simply a move-only refactoring.

See these relevant areas within the spec:

• https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#fees
• https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#updating-fees-update_fee

Relevant btcd PR:

• rpc method estimatefee btcsuite/btcd#735

[Roasbeef]

Closed by #199!!!

Still a few more edge cases to be handled (incorporation of fee_update messages, and corner cases related to zero valued outputs, but can handled later).