Re: [Lightning-dev] Pay payment_request with an openchannel+push_sat

[Rusty Russell]

Jonathan Underwood  writes:
> Hi all,
>
> I have mentioned this to roasbeef re: lnd implementing it... but I am
> wondering if this idea has propagated through the LN community and whether
> other wallets are going to implement it?
>
> Feature:
>
> If the recipient of a payment waiting for a specific r_hash receives
> an open_channel message with push_msat >= the value of the request where
> the temporary_channel_id contains the r_hash... that payment will be set to
> a WAITING_OPEN status.
>
> Once the channel is open, the payment moves to a PAID status.
>
> If while waiting for channel to open in the WAITING_OPEN state, a routed
> payment is received with the r_hash, accept that payment and change the
> payment status to PAID.

Hi Jonathan,

It's an interesting idea, but I think I prefer simply opening a
channel then making a payment rather than using push_msat.  Otherwise
the payer doesn't get proof of payment for this case.

> 1. Open_channel can take up to 10 minutes, but most smartphone apps kill
> background network processes for apps after 5 minutes or so.

Worse, open_channel can take *hours* if the depth requirement is high,
the fees too low, or miners unlucky.

> 2. If routing fails to pay someone. A wallet UI should ask the user:
> "You have enough on-chain funds to send. What would you like to do?
>   1. Open channel & send
>   2. Send on-chain
>   3. Give up"

Generally it's better to open a channel, though sending onchain is
possible if they provided a fallback address.

> 3. If we choose 1 in the current implementations, we would need to open a
> channel, then wait... then remember to re-open the app as soon as the
> channel is open. Then we need to paste the payment request again.

I'm sure there are ways for mobile wallets do the kind of polling needed
here, and respond accordingly.  They can certainly disconnect in the
meantime.

> 4. By allowing the person to "pay" with an open_channel, it allows people
> to signal intent to pay... allowing payment processors that generate
> payment requests with short expiration times to react to that intent
> accordingly.

It introduces trust into the system though; either you're prepared to
offer longer settlement terms, or you aren't.  I don't think you should
adjust based on such a falsifiable signal?

> I think this might be good to add into BOLT 2... what does everyone
> think?... not sure.

FWIW, this would be a 1.1 thing, since spec is frozen other than
outright bugs.

Thanks!
Rusty.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Descriptive annotations visible to intermediate nodes

[Christian Decker]

Hi Benjamin,

yes, there was a BOLT#6. It was a trivial bootstrapping mechanism I set up
using IRC (like the original bitcoin client), but we retired it in favor of
DNS seeds and gossiping.

Cheers,
Christian

On Thu, Jan 11, 2018 at 5:40 PM Benjamin Mord  wrote:

>
> Thanks Christian. I'm reading the BOLTs and reviewing source code now, so
> perhaps my question / request will be more usefully specific once I've
> finished that review. Sorry for being vague as to use case for now, let me
> just point out that the concept of source routing opens up a lot of
> potential use cases that involve collaborations with intermediaries of
> various sorts, but for which flexible communication capability would be
> desirable or required (unless you do that out-of-band, which would be so
> messy as to largely defeat the point.)
>
> I'm impressed so far by how cleanly and explicitly the BOLTs address
> extensibility. I find that reassuring, many thanks to whoever applied their
> technical creativity to this aspect.
>
> Was there a BOLT #6?
>
> On Thu, Jan 4, 2018 at 12:13 PM, Christian Decker <
> decker.christ...@gmail.com> wrote:
>
>> Hi Benjamin,
>>
>> currently the only piece of information that is kept contstant along the
>> entire route is the payment hash, and we will be removing that as well
>> in order to further decorrelate hops of a payment and make it harder for
>> forwarding nodes to collate hops into a route.
>>
>> As ZmnSCPxj has pointed out we do have the possibility of adding some
>> information in the onion packet. You can even give every single hop its
>> very specific information in the onion. Say for example you have a node
>> that does currency conversion, you may specify the desired exchange rate
>> in the onion.
>>
>> May I ask what use-case you are looking to implement using this feature?
>>
>> Cheers,
>> Christian
>>
>> Benjamin Mord  writes:
>> > Are there, or will there be, annotations one can add to a lightning
>> > transaction that can be read by all intermediate nodes along a given
>> route?
>> > Conversely, can one add annotations readable only by certain specific
>> known
>> > (to sender) intermediate nodes?
>> > ___
>> > Lightning-dev mailing list
>> > Lightning-dev@lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Invoice without amount

[Johan Torås Halseth]

Hi, Cezary,
I initially read the issue you created as a bug filing, my bad. I’ve updated it 
to reflect that it is a feature request.
Cheers! Johan

On Thu, Jan 11, 2018 at 18:16, Cezary Dziemian  
wrote:
I made issue 5 days ago: https://github.com/lightningnetwork/lnd/issues/564 
[https://github.com/lightningnetwork/lnd/issues/564]
2018-01-11 0:21 GMT+01:00 Olaoluwa Osuntokun < laol...@gmail.com 
[laol...@gmail.com] > :

Hi Cezary,
I invite you to make an issue on lnd's issue tracker: https://github.com/ 
lightningnetwork/lnd/issues [https://github.com/lightningnetwork/lnd/issues] . 
This list isn't the place for support requests/features for individual 
implementations.
On Tue, Jan 9, 2018 at 5:21 AM Cezary Dziemian < cezary.dziem...@gmail.com 
[cezary.dziem...@gmail.com] > wrote:
Good news, thanks.

Do Lightning Labs also have plan to introduce this soon? I prefer to stay with 
lnd, as we already know this implementation better, but if this option will not 
be introduced soon, we have to switch to use c-lightning.

Cheers,
Cezary
2018-01-09 5:31 GMT+01:00 Rusty Russell < ru...@rustcorp.com.au 
[ru...@rustcorp.com.au] > :
ZmnSCPxj via Lightning-dev < lightning-dev@lists. linuxfoundation.org 
[lightning-dev@lists.linuxfoundation.org] > writes:

> Good morning Cezary,
>
> Currently, c-lightning can PAY amountless invoices via the "pay" command, but 
> cannot CREATE them via the c-lightning "invoice" command.

Good point, I've filed an issue for this, so we don't lose it:

https://github.com/ ElementsProject/lightning/ issues/534 
[https://github.com/ElementsProject/lightning/issues/534]

> To pay an amountless invoice lntb... 4 satoshis in c-lightning: lightning-cli 
> pay lntb.. 4000

Note that I'd prefer the "msatoshi" field to be a magic string
(eg. "any") rather than omitting the parameter, since it's too easy for
a bug to omit the parameter.

Cheers,
Rusty.

__ _
Lightning-dev mailing list
Lightning-dev@lists. linuxfoundation.org 
[Lightning-dev@lists.linuxfoundation.org]
https://lists.linuxfoundation. org/mailman/listinfo/ lightning-dev 
[https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev]


___ Lightning-dev mailing list 
Lightning-dev@lists.linuxfoundation.org 
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

[Lightning-dev] BOLTs and meaning of "MUST" in potentially adversarial contexts

[Benjamin Mord]

One thing I find useful in RFCs is a brief discussion about the meaning of
terms like MUST, SHOULD, MAY, etc.. as used in the subsequent protocol
definition. But in the traditional approach to protocol design we first
assume cooperative nodes, and then later attempt to retrofit security when
we are surprised (yet again) to find not all nodes are operating in good
faith. Initial definition of "MUST" in RFCs thus implicitly presumes good
faith, inadvertently inviting implementers to lower their guard. But of
course, integrity despite presence of adversarial nodes is an explicit
design goal of the lightning network.

When a BOLT says that a lightning node MUST do some X, what does that mean
exactly? I'm thinking it means we should stigmatize it as "non-compliant"
with protocol consensus as documented in BOLTs, whenever we discuss the
implementation. I think violation of a MUST should be considered hostile. I
think a MUST encourages nodes to fail a channel or connection upon
observing a violation of that MUST, and even to take
implementation-specific defensive measures as deemed appropriate by
implementers (so long as they have cryptographic evidence that the
violation is not forged). But in no way does a MUST assure implementers
that they may assume this MUST will be respected by remote nodes, as it is
not the purpose of MUST to convey that cryptographic safeguards or such
elsewhere in the protocol design have arranged to force adherence..

Does that sound right? Is it worth stating explicitly somewhere, along with
definitions of SHOULD, MAY etc? Sorry if these definitions are already
stated someplace that I overlooked.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Descriptive annotations visible to intermediate nodes

[Benjamin Mord]

Thanks Christian. I'm reading the BOLTs and reviewing source code now, so
perhaps my question / request will be more usefully specific once I've
finished that review. Sorry for being vague as to use case for now, let me
just point out that the concept of source routing opens up a lot of
potential use cases that involve collaborations with intermediaries of
various sorts, but for which flexible communication capability would be
desirable or required (unless you do that out-of-band, which would be so
messy as to largely defeat the point.)

I'm impressed so far by how cleanly and explicitly the BOLTs address
extensibility. I find that reassuring, many thanks to whoever applied their
technical creativity to this aspect.

Was there a BOLT #6?

On Thu, Jan 4, 2018 at 12:13 PM, Christian Decker <
decker.christ...@gmail.com> wrote:

> Hi Benjamin,
>
> currently the only piece of information that is kept contstant along the
> entire route is the payment hash, and we will be removing that as well
> in order to further decorrelate hops of a payment and make it harder for
> forwarding nodes to collate hops into a route.
>
> As ZmnSCPxj has pointed out we do have the possibility of adding some
> information in the onion packet. You can even give every single hop its
> very specific information in the onion. Say for example you have a node
> that does currency conversion, you may specify the desired exchange rate
> in the onion.
>
> May I ask what use-case you are looking to implement using this feature?
>
> Cheers,
> Christian
>
> Benjamin Mord  writes:
> > Are there, or will there be, annotations one can add to a lightning
> > transaction that can be read by all intermediate nodes along a given
> route?
> > Conversely, can one add annotations readable only by certain specific
> known
> > (to sender) intermediate nodes?
> > ___
> > Lightning-dev mailing list
> > Lightning-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev