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)
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
>
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
>
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
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
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
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
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
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,
>
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
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
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
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.
>
> ##
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
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
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:
/
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
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.
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
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
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
21 matches
Mail list logo
