Re: [Lightning-dev] Base AMP

2018-12-04 Thread ZmnSCPxj via Lightning-dev
Except we have invoices with no specified amount (payer dictates how much to pay). Which is why we need to send the total amount to the payee as part of the onion final hop, for the case the invoice has no specified amount. Regards, ZmnSCPxj Sent with [ProtonMail](https://protonmail.com)

Re: [Lightning-dev] Base AMP

2018-12-04 Thread Christian Decker
Which brings us back to the initial proposal that just signals the awareness of a temporary underpayment with the single "more is coming"-bit. On Sun, Dec 2, 2018 at 11:49 PM Rusty Russell wrote: > ZmnSCPxj writes: > > But what if 2 of those paths fail? > > It would be better to merge them

Re: [Lightning-dev] Base AMP

2018-12-02 Thread Rusty Russell
ZmnSCPxj writes: > 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 >

Re: [Lightning-dev] Base AMP

2018-11-29 Thread ZmnSCPxj via Lightning-dev
Good morning Rusty, Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, November 30, 2018 7:46 AM, Rusty Russell wrote: > ZmnSCPxj zmnsc...@protonmail.com writes: > > > Good morning all, > > > > > I initially suggested we could just have a 2-byte "number of total >

Re: [Lightning-dev] Base AMP

2018-11-29 Thread Rusty Russell
ZmnSCPxj 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

Re: [Lightning-dev] Base AMP

2018-11-27 Thread ZmnSCPxj via Lightning-dev
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

Re: [Lightning-dev] Base AMP

2018-11-27 Thread Rusty Russell
Johan Torås Halseth writes: > (excuse me for not yet understanding what this extra complexity gives us) > > To summarize: My suggestion was to only add an optional field to the > invoice, and let the recepient wait until all funds have received before > pulling the payment. No changes to the

Re: [Lightning-dev] Base AMP

2018-11-27 Thread Johan Torås Halseth
(excuse me for not yet understanding what this extra complexity gives us) To summarize: My suggestion was to only add an optional field to the invoice, and let the recepient wait until all funds have received before pulling the payment. No changes to the onion. We briefly discussed this during

Re: [Lightning-dev] Base AMP

2018-11-26 Thread ZmnSCPxj via Lightning-dev
Good morning Johan, I believe what Rusty refers to here is a probe by an intermediate node, rather than a probe by the source node (who, as we know, already knows whether the payee supports AMP or not, by the invoice). Regards, ZmnSCPxj Sent with [ProtonMail](https://protonmail.com) Secure

Re: [Lightning-dev] Base AMP

2018-11-25 Thread Johan Torås Halseth
This shouldn't be problem, as the invoice will already indicate that the node supports BaseAMP. If you have a reason to not reveal that you support BAMP for certain invoices, you'll just not specify it in the invoice, and act non-BAMPy when receiving payments to this payment hash. Of course, this

Re: [Lightning-dev] Base AMP

2018-11-22 Thread Rusty Russell
Conner Fromknecht writes: > Hi all, > >> But it's unnecessary for the recipient to know the total amount I meant >> to pay; they just need to return the receipt once it exceeds the amount >> they want. > > I think it’s true that the recipient doesn’t need to know necessarily, but > sending the

Re: [Lightning-dev] Base AMP

2018-11-22 Thread ZmnSCPxj via Lightning-dev
Good morning Rusty, Okay, I shall modify pull request as you suggested. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday, November 22, 2018 6:50 AM, Rusty Russell wrote: > ZmnSCPxj zmnsc...@protonmail.com writes: > > > Good morning Rusty, >

Re: [Lightning-dev] Base AMP

2018-11-22 Thread Conner Fromknecht
Hi all, > But it's unnecessary for the recipient to know the total amount I meant > to pay; they just need to return the receipt once it exceeds the amount > they want. I think it’s true that the recipient doesn’t need to know necessarily, but sending the intended amount is more robust IMO,

Re: [Lightning-dev] Base AMP

2018-11-21 Thread Rusty Russell
Johan Torås Halseth writes: > Seems like we can restrict the changes to BOLT11 by having the receiver > assume NAMP for incoming payments < invoice_amount. (with some timeout of > course, but that would need to be the case even when the sender is > signalling NAMP). This would effectively become

Re: [Lightning-dev] Base AMP

2018-11-21 Thread Rusty Russell
ZmnSCPxj writes: > Good morning Rusty, > >> And do not play with `amount_to_forward`, as it's an important >> signal to the final node that the previous node did not offer less value >> for the HTLC than it was supposed to. (You could steal the top bit to >> signal partial payment if you really

Re: [Lightning-dev] Base AMP

2018-11-21 Thread Johan Torås Halseth
Seems like we can restrict the changes to BOLT11 by having the receiver assume NAMP for incoming payments < invoice_amount. (with some timeout of course, but that would need to be the case even when the sender is signalling NAMP). Cheers, Johan On Wed, Nov 21, 2018 at 3:55 AM ZmnSCPxj via

Re: [Lightning-dev] Base AMP

2018-11-20 Thread ZmnSCPxj via Lightning-dev
Good morning Rusty, > And do not play with `amount_to_forward`, as it's an important > signal to the final node that the previous node did not offer less value > for the HTLC than it was supposed to. (You could steal the top bit to > signal partial payment if you really want to). I do not view

Re: [Lightning-dev] Base AMP

2018-11-20 Thread Rusty Russell
René Pickhardt via Lightning-dev writes: > Hey List, > > as this base AMP proposal seems pretty small I just started to write this > up to make a PR for BOLT04 and BOLT11. While doing my write up I realize > that there are smaller things that I would want to verify / double check > and propose

Re: [Lightning-dev] Base AMP

2018-11-20 Thread ZmnSCPxj via Lightning-dev
Good morning Rene, > Hey List, > > as this base AMP proposal seems pretty small I just started to write this up > to make a PR for BOLT04 and BOLT11. While doing my write up I realize that > there are smaller things that I would want to verify / double check and > propose with you. > > ##

Re: [Lightning-dev] Base AMP

2018-11-20 Thread René Pickhardt via Lightning-dev
Hey List, as this base AMP proposal seems pretty small I just started to write this up to make a PR for BOLT04 and BOLT11. While doing my write up I realize that there are smaller things that I would want to verify / double check and propose with you. ## Verifying: 1.) I understand the receiving

Re: [Lightning-dev] Base AMP

2018-11-16 Thread Anthony Towns
On Thu, Nov 15, 2018 at 11:54:22PM +, ZmnSCPxj via Lightning-dev wrote: > The improvement is in a reduction in `fee_base_msat` in the C->D path. I think reliability (and simplicity!) are the biggest things to improve in lightning atm. Having the flag just be incuded in invoices and not need

Re: [Lightning-dev] Base AMP

2018-11-15 Thread Christian Decker
I'm not sure this is an improvement at all over just allowing a single merge-point, i.e., the destination. You see as long as we don't attempt intermediate merges the routes are independent and failures of one HTLC do not impact any other parts. Take for example the network below: /

Re: [Lightning-dev] Base AMP

2018-11-15 Thread ZmnSCPxj via Lightning-dev
Good morning Christian, The improvement is in a reduction in `fee_base_msat` in the C->D path. If C is the merge point, then the C->D `fee_base_msat` is only paid once, not twice. In effect, A is rationally choosing between a lower fee and better payment reliability. Granted, current

Re: [Lightning-dev] Base AMP

2018-11-14 Thread ZmnSCPxj via Lightning-dev
Good morning list, In case it was not noticed, I made a pull request for Base AMP: https://github.com/lightningnetwork/lightning-rfc/pull/511 This is primarily based on what Rusty suggested on-list, with sufficient MUST and SHOULD. Regards, ZmnSCPxj Sent with ProtonMail Secure Email.

Re: [Lightning-dev] Base AMP

2018-11-13 Thread ZmnSCPxj via Lightning-dev
Good morning Conner, > > MUST NOT forward (if an intermediate node) or claim (if the final node) > > unless > > it has received a total greater or equal to `intended_total_payment` in all > > incoming HTLCs for the same `payment_hash`. > > I was under the impression that this would not require

Re: [Lightning-dev] Base AMP

2018-11-13 Thread ZmnSCPxj via Lightning-dev
Good morning Johan, Merge nodes will prefer to wait until the entire payment is available and committed to as HTLCs, before doing any claims. I believe it was mentioned that one of us figured it out (prior to the summit) that such a thing was what a merge point would rationally want. We assume

Re: [Lightning-dev] Base AMP

2018-11-13 Thread Conner Fromknecht
Good morning all, > MUST NOT forward (if an intermediate node) or claim (if the final node) unless > it has received a total greater or equal to `intended_total_payment` in all > incoming HTLCs for the same `payment_hash`. I was under the impression that this would not require changes on behalf

Re: [Lightning-dev] Base AMP

2018-11-13 Thread Johan Torås Halseth
Good evening Z and list, I'm wondering, since these payments are no longer atomic, should we name it accordingly? Cheers, Johan On Tue, Nov 13, 2018 at 1:28 PM ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Good morning list, > > I propose the below to support

[Lightning-dev] Base AMP

2018-11-13 Thread ZmnSCPxj via Lightning-dev
Good morning list, I propose the below to support Base AMP. The below would allow arbitrary merges of paths, but not arbitrary splits. I am uncertain about the safety of arbitrary splits. ### The `multipath_merge_per_hop` type (`option_base_amp`) This indicates that payment has been split by