accounting: round to nearest whole satoshi for balances, not down

[niftynei]

This is really more of a suggestion/draft than an entirely serious proposal.

The update mechanism is missing from this PR and while it has merits in a very 'gross' sense, there's not really a rush or reason to change the way that outputs are calculated for close/commitment txs any time soon.

Rather this might be a change that's useful to wrap up into a broader protocol change (such as a move to PTLCs) which also impacts the commitment tx protocol; or a move to an 'interactive close' which impacts the close tx.

Also, this is probably much more important for the close tx than the unilateral case, as 1) unilaterals are usually ridiculously expensive in fees anyway, relatively speaking, and 2) are expected to be less frequent than mutual closes.

---

Over the lifetime of a node, rounding every msat balance down (adding to
fees) is a net loss of funds from the network to the miners.

To make things a bit more even, instead we can round to the nearest
satoshi for every peer balance output (on close txs and the
to_local/to_remote balances).

It gets a bit more complicated with HTLC output balances as there is no
'inherent yin/yang' relationship btw the htlc outputs; in other words
you may round up multiple times instead of one rounding up, the other
rounding down, which ends up with bad math.

Consider the following.

You have a 5000msats starting balance.

You add 2 htlcs of 750msats.

Here's what the balances would be if maintained in msats:

5000 - 1500 = 3500 to_local
750 htlc_1
750 htlc_2

With the applied rounding rule (round up if over 499), here's what
the following outputs would be:

4sat to_local
1sat htlc_1
1sat htlc_2

4 + 1 + 1 = 6, which is greater than the 5 sats we started with.

So to make this ok, the HTLCs are always rounded down, which means
that if the unilateral close they're in ever goes to chain,
there's a good chance you're down a fraction of a satoshi but those
won't be the only satoshis you're out if you go to chain with HTLCs
because recovering those funds onchain has a fee cost of generally
greater than a satoshi etc.

[lightning-developer]

I am sorry to say that I am not convinced about this proposal.

While your already mentioned that it is most likely not worth to implement this on the the current channel state machine I think there are more issues to it with respect to the 500msat case. While you already addressed the case with HTLCs in flight I think a similar situation might emerge without HTLCs in flight.

Let's say you have a channel with to_local = 999500msat and to_remote = 1000500msat then the total capacity would be 2000 sats but according to your rule you round up this implies that to_local = 1000 sat and to_remote = 1001 sat. Meaning we would have a total capacity of 2001 sat. Thus the fix of always rounding HTLCs down will not work in this particular - admidetly rare - case.

In order to fix this it seems that we would have to make an additional rule how to handle the situation where both to_local and to_remote have 500msat which seems to make everything even more complicated.

I guess since the funder of the channel pays the fees for the close transaction anyway which should be far more than 1 satoshi this might not yield a fundamental problem if both outputs are rounded up and then fees are applied as negotiated. However it still seems a bit weired to change this now. In a similar way we could say that the on chain fees are so high that we could always round up and apply fees. What I try to say all the rounding choices that we could think of seem a bit arbitrary anyway. Thus I am wondering why would we need to touch a system which is working already and needs to be the same for both peers to not trigger force closes.

By the end of the day I think that the on chain fees are much larger than the single satoshi which we start to discuss about here. Which lets me think that we should neglect this satoshi. The situation changes of course if at some point in time lightning node operators are also mining their own transactions and don't need to pay fees but I guess that is a totally different story. However in that situation where we don't apply a fee rounding up for both 500msat outputs will definately not work.

[niftynei]

Ah good point, there's a case I didn't cover here. It's been patched. Since the opener is responsible for paying fees in the general case, they round up in the case of a tie.

It's true that if you want a quick review to leave an obvious flaw in your proposal :P

The logic behind this proposal is remains unchanged however -- over a long enough operation, rounding should approximately result in a node's balance equaling the net amount owed them from channel operations.

[t-bast]

Is this something we want to follow up on? Or should we close this for now @niftynei?