Hi, Maybe this is a stupid question, and it is late so maybe I'm overlooking something, but I don't want to lose a potentially good idea, so here it goes:
Right now, BOLT#3 imposes a certain algorithm for fee estimation. This algorithm is likely to be sub-optimal: fee estimation is a difficult subject, and may involve subjective situation-specific considerations of participants. I guess it's only there to achieve some kind of consensus between the peers. But why do we need consensus at all? There are two versions of each commitment transaction: one to be used for unilateral close by one peer (A), and one to be used by the other (B). Peer A has an interest in "commit transaction A", so I'd consider it fair to let peer A pay the transaction fee for that commit tx (subtracted from its part of the channel funds), and also to let peer A determine the amount of that fee. If A wants a different fee for whatever reason, it should simply be able to ask B for a signature on an updated "commit transaction A". B shouldn't care about that fee, as long as its own funds, HTLCs etc. are OK. I guess, when only changing the fee, you don't even need to use a new revocation secret. Your peer may have different versions which only differ in how much fees your peer pays, and you 'll never care which of them will be used by your peer. Not using a new revocation secret may or may not be a premature optimization though. If a peer doesn't have enough funds to pay a reasonably effective tx fee, normally that shouldn't be a problem, because then it doesn't have a significant financial interest in having a usable commit tx either. The only exception is if there are significant HTLCs. Is this where the idea breaks down? As far as I can see, this is an exceptional (but important) case, but during normal operation, peers should be free to choose the fee for their own commit tx. You'd have to deal with any follow-up transactions as well: changing a fee changes the txID, so you need to update follow-up transactions. regards, CJP _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
