bLIP-0052: Add ongoing proportional fees

[aylagreystone]

Adds support for ongoing proportional fees to the bLIP-0052 flow.

This allows the LSP to charge ongoing proportional fees taken from all subsequent payments forwarded over the channel after open. The fees are paid for by the recipient just like the opening fee is by skimming it from the HTLCs forwarded.

Ongoing fees allow the LSP to distribute the costs across the lifetime of the channel instead of charging for it all up front.

[tnull]

The concept of ongoing fees has been requested multiple times now, so we could def. consider to support it, but it would need to be a purely backwards compatible change.

[tnull]

You can't just add a field here as it would render all historical promises invalid. If we want to make such a change, it needs to be backwards compatible (read: additive), e.g., you could add a flag to the get_info result that would indicate that the agreed upon fees will be withheld on every forward, and then the service would need to reject any buy requests that have that field unset (i.e., if they don't know it).

[aylagreystone]

Makes sense. Pushed new commit that moved it to a flag outside of the params instead.

[aylagreystone]

Actually, as I went to implement this in ldk and ldk-node I realized that it's tough to avoid rendering historical promises invalid. Even if we move ongoing_proportional outside the opening_fee_params then we still would ideally want to include it in the generation of the promise.

If we do not include it in the promise then the LSP has no way to know what value it gave out as a response to a get_info request and cannot validate the value provided in the buy request.

The alternatives would be:

1. Store a mapping from promise to ongoing_proportional for each promise given out. This seems like not a great idea as the whole point of the promise is for the LSP to remain stateless when handling get_info requests.

2. Use a static ongoing_proportional value across all requests. This is less flexible but maybe acceptable (if it's the only option)? Seems like it might run into issues should the LSP ever want to change it as someone who received a get_info request with the old value will run into unexpected behavior should they issue a buy request after the new value is set by the LSP. Even if you require the client to send the value they received to the user, the LSP cannot trust it because it's not included in the promise.

Any thoughts?

[JssDWt]

I had made a PR before that allows making backward compatible changes to the calculation of the promise for the opening_fee_params. It was discussed then that if we want to add fields to the opening_fee_params, that would be a good time to revisit. This is the PR in question: BitcoinAndLightningLayerSpecs/lsp#111

Let me know if that helps your case.

[tnull]

One comment, otherwise the spec change should look good, if we agree that we want to go this way. I think we'd also want to hold off merging this until we have at least one reference implementation in-place.

[tnull]

I don't think we should repeat the computation here, but rather just refer to the other parts of the spec.

[aylagreystone]

The only potential confusion is that in the 'computing the fee' section that is for the opening fee which includes the min_fee portion. The ongoing_fee as defined only includes the proportional component of the fee.