For what it’s worth, I think the model I described in the last post may be functionally equivalent to tracking a net balance and keeping a separate count of prepaid funds. It’s possible that tracking the net balance and prepaid funds would more clearly model the behavior we want (assuming we don’t want prepaid funds to be sent back as a settlement).
That sounds like what I described as netting, no? If both the Receivables and Payables are greater than zero, you can net instead of settle the Payables.
Yes. I didn’t originally implement it that way but then found it strange that if you forward Prepares to me that are then fulfilled, I can’t send an equal value of Prepares back to you even though you owe me that money.
Fair point. This may be an argument for thinking of it as a net balance with a separate tracker for prepaid funds.
Good question. I originally had it as
+ Payable Balance OR - Receivable Balance, because the original Prepare might have come from either one (and you don’t want to have to remember which one). If you put it back into the Receivable Balance, it could have come from Payable, and the Receivable won’t be “settled back” so there’s no way to get that money aside from sending ILP packets.
Also good question. The settling back and forth forever problem is a non-issue if the peers communicate about what their limits and thresholds will be beforehand. For example, if my
settleTo is -500, we won’t have a problem if you set your
settleThreshold > 500. I think it’s better to reduce the amount of communication and coordination the peers need in order to set themselves up properly, and we want to build the system such that misconfigurations still don’t cause problems like the settling back and forth forever.
Just to be clear,
Net if Payable > 0 and Receivable > 0 is a separate check from
Settle if Payable >= Settle Threshold. So in your first example, settlement would occur if the Settle Threshold is <= 100.
The settlement amount would be Payable Balance -
Agreed, though I don’t think that has to do with the limit but rather how the “Effect” of the packet is applied
Not currently supported. If the prefund amounts stay small, I’m not sure we need to support refunds. You can always send an ILP packet to another account (or maybe even to the same account, if the connector lets you do that).
If that’s the case, then she wouldn’t have fulfilled the packet. From Alice’s perspective, let’s say the Max Receivable is 300. When Bob sends the first packets through for 200, that brings the Receivable up to 200. When he tries to Prepare another 200 it should fail. (The way the limit is described above, you could argue that it would succeed if the Prefunding caused Alice’s Prepared Balance to go negative. Maybe that check is wrong or Prefunding shouldn’t be tracked on Alice’s side?)
If you don’t want to settle for every fulfilled packet, don’t set the
settlementThreshold to 0. If you do, you should know that that’ll be the effect.
I think we should try to make it work such that they don’t need to agree. I admit that it may be difficult or impossible (for example, if your Settle Threshold is higher than the peer’s Max Receivable they’ll start rejecting packets before you initiate settlement).