[Lightning-dev] Base AMP

ZmnSCPxj ZmnSCPxj at protonmail.com
Fri Nov 30 05:53:26 UTC 2018


Good morning Rusty,


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, November 30, 2018 7:46 AM, Rusty Russell <rusty at rustcorp.com.au> wrote:

> ZmnSCPxj ZmnSCPxj at 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 takesmax 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".


Consider a network where there are 4 paths between payer and payee.

3 paths have low capacity but negligible feerate, while the 4th has high capacity but ridiculously high feerates measurable in whole microbitcoins.

The rational thing to try, when paying a somewhat large amount but trying to minimize fees, would be to split among the three lowcost paths.

But what if 2 of those paths fail?
It would be better to merge them into a single payment along the expensive 4th path.
However, the remaining succeeding path has already given `numpaths`=3.

Using `numpaths` overcommits to what you will do in the future, and is unnecessary anyway.
The payee is interested in the total value, not the details of the split.


Regards,
ZmnSCPxj

>
> But it's bad for the separate-payer case anyway, so...
>
> Thanks,
> Rusty.




More information about the Lightning-dev mailing list