ZmnSCPxj <zmnsc...@protonmail.com> writes: > Good morning all, > >> I initially suggested we could just have a 2-byte "number of total >> pieces", but it turns out there's a use-case where that doesn't work >> well: splitting the bill. There each payer is unrelated, so doesn't >> know how the others are paying. > > This would also not work well in case of a dynamic algorithm that greedily > tries to pay the whole amount at once, then splits it if it does not fit, > with each split also being liable to splitting. > Such a dynamic algorithm would not know in the first place how many splits it > will take, but it *will* know the total amount it intends to deliver.
Well, that would have worked because received takes *max* of the values received, ie, sender starts with A and B, both with "numpieces=2", then splits B into BA and BB, both with "numpieces=3". But it's bad for the separate-payer case anyway, so... Thanks, Rusty. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
