Re: [Lightning-dev] A protocol for requesting invoices

[Andy Schroder]

Andy Schroder

On 03/19/2018 09:59 AM, Corné Plooy wrote:

It is a public key hash, yes.  But what I refer to is that the payee-determined 
route section, which starts from an introduction point, protects the payee from 
being located by the payer, but how did the payer contact the payee in the 
first place anyway?  If it was by IP or non-.onion hostname, then the payee has 
been already located and there is no point in hiding from the payer.  If it was 
by .onion hostname, then the payee security is bounded by the security of TOR, 
so it is no more secure for the payee to simply run its LN node on the same 
.onion address (which LN spec supports) and provide the public key of its LN 
node.

Note that onion routing on LN in general protects the payer and the payee from 
being known easily by intermediate hop nodes, and this is the sole intent of 
onion routing for now.  Presumably the payer knows how to contact the payee 
(else how would it form a connection to the payee in order to make an 
interactive request for invoice?).  Presumably if the payee is a merchant, it 
knows how to send its product to the payer (and thus would know details like 
the physical address of the payer).  And so on.  The payee-determined route 
that starts from the introduction point protects the payee from the payer, but 
does it indeed increase the security or is there some other way to locate the 
payee anyway?

If that payee has a LN node that is 100% a TOR hidden service, and you
don't use a (partially) payee-determined route, the payee has to reveal
its node ID to the payer. This is not the same as revealing the physical
identity of the payee, and having a hidden service may help to keep the
two identities separated, but a LN node is a relatively long-lived
entity. Over time, the risk increases that knowledge about the node ID
(e.g. what kinds of transactions are linked to this ID) leaks out and
gets combined, revealing things you don't want to be revealed.

It may, for instance, be that some of your incoming transactions are
inherently linked to your physical identity (e.g. salary), and some
other you don't want linked to yourself. If you have to reveal your node
ID to all payers, you risk those transactions being linked to you,
either now or in the future. Running a node as a TOR hidden service is
not sufficient. However, if you manage to hide your node ID from payers,
this becomes much more difficult; you really gain some privacy.

In fact, using a TOR hidden service may not always be necessary. In some
cases, you could alternatively set up payer/payee communication over a
more-or-less anonymous physical medium; maybe using a burner phone, WiFi
with a randomized MAC address, NFC, or some other kind of radio
communication.


Regarding NFC and radio communication, I think this would be important 
to bake into the original spec. I'm going to encourage bluetooth over 
wifi with a randomized MAC address. Bluetooth is likely a little better 
because you can make a lot of simultaneous bluetooth connections and 
they don't require you to do any changes to your internet connection, 
which you still need in order to interact with the bitcoin and lightning 
networks. Bluetooth also makes it simpler for the payee as far as 
limiting what the payee can use the connection for. I'm guessing you can 
randomize the bluetooth MAC address.


One thing for example that makes BIP70 complicated in that regard is 
that you need to be able to supply a few URLs in order to give the payer 
an option on how they may want to connect to fetch a payment request 
(locally via bluetooth, or over the internet using http). Some hacks 
were made to BIP70 to make it work with bluetooth, but I'm not sure if 
the design was the best.


 * Demo using my fuel pump and Bitcoin Wallet
 o http://andyschroder.com/BitcoinFluidDispenser/2.3/
 + Watch the first video on this page.
 + I don't think totally offline payments are possible with
   lightning, so that part of the workflow isn't comparable.
 * Details about how Bitcoin Wallet is designed and different ways to
   communicate with the payee.
 o https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki
 o https://github.com/bitcoin-wallet/bitcoin-wallet/wiki/Payment-Requests
 o Note, the bluetooth communication protocol used here still needs
   to be encrypted. That extension was never developed.

Obviously we aren't going to use BIP70 here for lightning, but my point 
is that there are some lessons that can be learned from the work flow.







The alternative approach to partially payee-determined routes would be
to run different nodes for different identities and to regularly shut
down nodes and set up new ones. This requires expensive on-chain actions
though (more expensive than setting up a new TOR hidden service), and I
don't think it's good for the rest of the network either if channels are
regularly shut down.

Definitely.



  I prefer if people 

Re: [Lightning-dev] A protocol for requesting invoices

[Andy Schroder]

Andy Schroder

On 03/19/2018 08:06 AM, Corné Plooy wrote:

What about enforcing a maximum payment amount that can be refunded?
Can this help make the amount not a requirement? This way the payment
amount will still be open to the payer, but it will have a constraint.

I see no use case anymore for leaving out the amount in the invoice. For
any type of transaction where the payer decides the amount, he can do so
by specifying the amount in the invoice request.


Maybe you are right.






  3.  True. Right now I'm thinking in the opposite direction:
simplifying
   BOLT 12 by removing the possibility of refunds. We can
always add it
   back later (with a proper set of features for all kinds of
refunds) as
   an optional feature.


I want my refund :-) !

I did some further thinking on refunds. Generally speaking, they are a
solution for when Transactions Get Messy, right? You agreed to a
transaction, the Lightning payment happened, but now you want to change
something. That 'something' can be, for instance, a full refund (e.g. if
goods cannot be delivered), a partial refund (e.g. if goods arrived
later than agreed, or with inferior quality), an extra payment by the
payer (e.g. cheaper model out of stock, decided to buy the more
expensive one instead), or no payment at all (e.g. payer changes mind
after the payment, and wants the black/blue model instead of the
white/gold one, which has the same price).


Did you take a look a the application in my link? It demonstrates paying 
for fuel for an automobile with bitcoin using blockchain payments. There 
is first a payment and then the pump powers on. After the person 
finishes dispensing fuel into their vehicle, it immediately places a 
refund transaction using the refund address received using the BIP70 
payment protocol. It even uses NFC and bluetooth instead of QR codes and 
http. Most automobile owners have to go through this payment process 
every 5-15 days if they buy fuel with cash. It's not really a messy 
transaction and their is no any way to know with much accuracy how much 
fuel they actually need since fuel level gauges in automobiles aren't 
very inaccurate. And, you can always be filling up some cans of unknown 
size to take back and refill your tractor, generator, boat, or whatever. 
This is a situation where you shouldn't need to divulge your identity to 
make a trivial purchase of a commodity.


Other common examples include making a deposit for a hotel. Normally you 
need to put something up far beyond the cost of the room rental in order 
to cover any damages you could make to the room. Same goes for renting 
anything really. There are many other little cases where you may need to 
place a deposit greater than the cost of the good/service you are receiving.





There is some similarity between a "BOLT 12" transaction that allows
refunds and other updates, and a microtransaction channel. Specifically,
I think you want the new state to be signed by whoever may possibly have
a legitimate interest *against* the update, and you want the old state
to be invalidated. In BOLT 12, to support this, a state should typically
contain the description field, a field that invalidates the previous
state, a field that specifies how this state can be invalidated, and
optionally a payment hash(*), which indicates that this state update is
valid only in combination with the corresponding preimage. A transaction
starts in a "null" state (no obligations between participants), and ends
specifying certain obligations that have been fulfilled. TBD: maybe
returning to null state by signing off that all obligations have been
fulfilled? E.g. payer signing off that ordered goods have been received.
Note that this must be different from canceling the transaction, since
you want the payer to keep some kind of proof of ownership. Anyway, I
think returning to null state should not be required on BOLT12 protocol
level: not everybody wants this. Some suppliers may want to require it
though.

Looking at the protocol for this (generalized) refund usage, it seems
clear that, often, you don't want to have to keep the communication line
open the entire time: it can take days, weeks or longer until the final
settlement of a transaction. You should be able to reconnect (typically
in the same direction as the initial connect) and say "hey, let's update
the state of the transaction to this-or-that". So, on re-connecting, you
also need to be able to specify *which* transaction to update.


Makes sense.



The format of the "description" field is unspecified for now; I think
it's best to keep it that way. Machine-readable formats for this are a
very complex subject, better solved at a higher level protocol. For now,
assume it to be human-readable; maybe add a MIME type field so that its
format is both unambiguous (technologically) and upgradeable.

TBD: is there a use case for transactions between more than two parties?
Or having smart contract 

Re: [Lightning-dev] A protocol for requesting invoices

[ZmnSCPxj via Lightning-dev]

Good morning Corne,



> > I suppose the use-case here is that the payee uses many TOR addresses with 
> > only one LN node.
> 
> Yes. Use different TOR addresses for things you want to keep separated.
> 
> Any TOR address you advertise for channel connections is so widely
> 
> shared through gossiping that you can in practice consider such an
> 
> address to be the same identity as your peer ID. For the payer/payee
> 
> communication (BOLT 12, and other interfaces such as a website) you
> 
> should not use the same TOR address if you want that activity to
> 
> remain unlinked from your node ID. You could use another TOR address, or
> 
> any other pseudonymous communication method.

I understand.

I want to bring up another possible privacy break.  Channels can be brought 
onchain anytime, and any HTLCs pending through that channel will also be 
brought onchain and will be visible.  This will also publish the 
`payment_hash`.  A payer observing the chain knows the `payment_hash` it was 
paying to, can see the HTLC getting claimed and exposing the `payment_hash`, 
and from the channel signatures knows which nodes were using that channel (if 
it was a public channel then it has signatures attesting who the nodes 
participating in it are, from node gossip!).  It can guess that it is likelier 
than usual that one of the nodes on that channel is the payee, and definitely 
knows that the channel was part of the payee-provided route.

(using non-public channels helps here in that the payer would have to observe 
every possible HTLC claim, not just those that it knows are from the public 
channels on the network, and would be hoping that such an event occurred during 
its payment: so it would have to devote more bandwidth and processing power 
searching through all transactions for an HTLC claim that matches its 
`payment_hash`.  But I think there is no such thing as a truly private channel: 
each channel has two participants and two can keep a secret only if one of them 
is dead)

This is not such a big concern; this is expected to be a rare case and if your 
node accepts received HTLCs very quickly and has very good uptime it is 
unlikely to occur in practice.  In addition, once we switch to Scriptless 
Script (which requires Bellare-Neven signatures to be implemented in some form 
on the base Bitcoin blockchain layer) this privacy leak disappears (I think... 
or maybe greatly reduces at least), as even onchain the equivalent to a 
hashlock is indistinguishable from an ordinary Bellare-Neven m-of-n signature.

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

Re: [Lightning-dev] A protocol for requesting invoices

[Corné Plooy via Lightning-dev]

> I suppose the use-case here is that the payee uses many TOR addresses with 
> only one LN node.
Yes. Use different TOR addresses for things you want to keep separated.
Any TOR address you advertise for channel connections is so widely
shared through gossiping that you can in practice consider such an
address to be the same identity as your peer ID. For the payer/payee
communication (BOLT 12, and other interfaces such as a website) you
should *not* use the same TOR address if you want that activity to
remain unlinked from your node ID. You could use another TOR address, or
any other pseudonymous communication method.

Depending on the transport layer you use (TOR or something else) you end
up with a different type of URL. I think for now it's good enough to
support TCP and TOR.

Another use case could be to use partial onion routes for payments in
the opposite direction. This is, for instance, to refund a payer who
wishes to remain anonymous. The original payee has an URL (can be TOR
hidden service, or even regular TCP), and the original payer connects to
this (using TOR or another anonymizing medium). The original payer can
then remain anonymous by sending an invoice for the refund that uses a
partial onion route on LN. In this use case, the purpose is to keep the
original payer anonymous (not reveal the node ID), not to keep the
original payee anonymous.

CJP

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

Re: [Lightning-dev] A protocol for requesting invoices

[Corné Plooy via Lightning-dev]

> It is a public key hash, yes.  But what I refer to is that the 
> payee-determined route section, which starts from an introduction point, 
> protects the payee from being located by the payer, but how did the payer 
> contact the payee in the first place anyway?  If it was by IP or non-.onion 
> hostname, then the payee has been already located and there is no point in 
> hiding from the payer.  If it was by .onion hostname, then the payee security 
> is bounded by the security of TOR, so it is no more secure for the payee to 
> simply run its LN node on the same .onion address (which LN spec supports) 
> and provide the public key of its LN node.
>
> Note that onion routing on LN in general protects the payer and the payee 
> from being known easily by intermediate hop nodes, and this is the sole 
> intent of onion routing for now.  Presumably the payer knows how to contact 
> the payee (else how would it form a connection to the payee in order to make 
> an interactive request for invoice?).  Presumably if the payee is a merchant, 
> it knows how to send its product to the payer (and thus would know details 
> like the physical address of the payer).  And so on.  The payee-determined 
> route that starts from the introduction point protects the payee from the 
> payer, but does it indeed increase the security or is there some other way to 
> locate the payee anyway?
If that payee has a LN node that is 100% a TOR hidden service, and you
don't use a (partially) payee-determined route, the payee has to reveal
its node ID to the payer. This is not the same as revealing the physical
identity of the payee, and having a hidden service may help to keep the
two identities separated, but a LN node is a relatively long-lived
entity. Over time, the risk increases that knowledge about the node ID
(e.g. what kinds of transactions are linked to this ID) leaks out and
gets combined, revealing things you don't want to be revealed.

It may, for instance, be that some of your incoming transactions are
inherently linked to your physical identity (e.g. salary), and some
other you don't want linked to yourself. If you have to reveal your node
ID to all payers, you risk those transactions being linked to you,
either now or in the future. Running a node as a TOR hidden service is
not sufficient. However, if you manage to hide your node ID from payers,
this becomes much more difficult; you really gain some privacy.

In fact, using a TOR hidden service may not always be necessary. In some
cases, you could alternatively set up payer/payee communication over a
more-or-less anonymous physical medium; maybe using a burner phone, WiFi
with a randomized MAC address, NFC, or some other kind of radio
communication.

The alternative approach to partially payee-determined routes would be
to run different nodes for different identities and to regularly shut
down nodes and set up new ones. This requires expensive on-chain actions
though (more expensive than setting up a new TOR hidden service), and I
don't think it's good for the rest of the network either if channels are
regularly shut down. I prefer if people can have lots of privacy, even
when running only a single node.

You could roughly say that TOR is necessary because your IP address can
often be linked to you, and partially payee-determined routes are
necessary because your node ID can often be linked to you.

CJP


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

Re: [Lightning-dev] A protocol for requesting invoices

[ZmnSCPxj via Lightning-dev]

Good morning Andy,

> > > giving new alternatives
> > > 
> > >  interactively is another option. I think using the same "introduction
> > >  
> > >  point" for all routes is best for privacy: otherwise the payer could
> > >  
> > >  determine the neighborhood of the payee.
> > > 
> > 
> > I wonder. How does the payer contact the payee in the first place, without 
> > having located the neighborhood of the payee? If it is via some TOR hidden 
> > service, and the payee considers this enough protection, why cannot the 
> > same TOR hidden service be used as the address of the LN node of the payee 
> > (LN protocol spec allows this, current implementations not so much)? 
> > Freenet or I2P, I suppose?
> 
> You're saying that a .onion address is really a public key, so their is
> 
> no reason to include both a public key and a host name?

It is a public key hash, yes.  But what I refer to is that the payee-determined 
route section, which starts from an introduction point, protects the payee from 
being located by the payer, but how did the payer contact the payee in the 
first place anyway?  If it was by IP or non-.onion hostname, then the payee has 
been already located and there is no point in hiding from the payer.  If it was 
by .onion hostname, then the payee security is bounded by the security of TOR, 
so it is no more secure for the payee to simply run its LN node on the same 
.onion address (which LN spec supports) and provide the public key of its LN 
node.

Note that onion routing on LN in general protects the payer and the payee from 
being known easily by intermediate hop nodes, and this is the sole intent of 
onion routing for now.  Presumably the payer knows how to contact the payee 
(else how would it form a connection to the payee in order to make an 
interactive request for invoice?).  Presumably if the payee is a merchant, it 
knows how to send its product to the payer (and thus would know details like 
the physical address of the payer).  And so on.  The payee-determined route 
that starts from the introduction point protects the payee from the payer, but 
does it indeed increase the security or is there some other way to locate the 
payee anyway?

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

Re: [Lightning-dev] A protocol for requesting invoices

[Andy Schroder]

Andy Schroder

On 03/15/2018 08:31 PM, ZmnSCPxj wrote:

Good morning Corne,


 routing. You could consider the start of the partial route as an
 
 "introduction point"; it is selected by the payee(**). I'm not sure if
 
 it is exactly equivalent to TOR's introduction points though.

It is almost equivalent I think.



I've been thinking, and start of the payment route has properties of 
both an introduction point and rendezvous point. The introduction point 
is chosen by the TOR hidden service, and in this case, the start point 
is chosen by the lightning payee (which is hidden if they are operating 
over TOR). The TOR rendezvous point is not known to the public (only the 
client and the hidden service), and in this case, the start point of the 
payment route is also not known by the public (only the payer and the 
payee if they are operating over TOR to communicate).





 
2.  Good thinking. I guess that, since either payer or payee will
 
 decide on the amount, there is no use case for omitting the amount in an
 
 invoice in BOLT 12; unlike BOLT 11, it should not be optional here. So
 
 that's not a problem for the partial onion route. Unknown capacity is an
 
 issue, and I guess it's worse than if the payer is completely free to
 
 choose a route, because the payer is no longer completely free to choose
 
 alternative routes. Giving a batch of alternative routes is one concept
 
 (TBD: can they have the same payment hash?);

Yes. When we retry failing routes, we reuse the payment hash until we succeed 
to pay, or, give up paying.  This is simply the same concept.


What about enforcing a maximum payment amount that can be refunded? Can 
this help make the amount not a requirement? This way the payment amount 
will still be open to the payer, but it will have a constraint.







giving new alternatives
 
 interactively is another option. I think using the same "introduction
 
 point" for all routes is best for privacy: otherwise the payer could
 
 determine the neighborhood of the payee.

I wonder.  How does the payer contact the payee in the first place, without 
having located the neighborhood of the payee?  If it is via some TOR hidden 
service, and the payee considers this enough protection, why cannot the same 
TOR hidden service be used as the address of the LN node of the payee (LN 
protocol spec allows this, current implementations not so much)?  Freenet or 
I2P, I suppose?


You're saying that a .onion address is really a public key, so their is 
no reason to include both a public key and a host name?




 
3.  True. Right now I'm thinking in the opposite direction: simplifying
 
 BOLT 12 by removing the possibility of refunds. We can always add it
 
 back later (with a proper set of features for all kinds of refunds) as
 
 an optional feature.



I want my refund :-) !

http://andyschroder.com/BitcoinVendingDevices/

Rusty already suggested that a return onion be supplied for refunds, but 
I'm not sure if he was talking about a partial onion, or a complete 
onion, because that discussion was for the case where the original 
payment was sent directly to a non-anonymous payee.


I think in this case though, were a partial onion route is supplied for 
the initial payment, the refund payment onion route would have to be a 
partial one.


All return onions still have the same problem of capacity though.




 
4.  This depends on the use case. The URL contains an optional invoice
 
 ID. A payee can request a payment for a specific, single transaction
 
 (for a single instance of delivery of goods/services) by handing over an
 
 URL, including an invoice ID, to a single payer. This provides similar
 
 functionality as BOLT 11, except that you now have a well-defined
 
 channel for transmitting larger invoice descriptions and for using
 
 partial onion routes. A payee can also hand over an URL without invoice
 
 ID; this can be used and re-used by one or more payers, whenever they
 
 want to perform payments to this payee.

How does the payer derive the payment hash? Or does the payer have to contact 
the payee again to get a fresh payment hash specifically for the payer?

Regards,
ZmnSCPxj



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

Re: [Lightning-dev] A protocol for requesting invoices

[ZmnSCPxj via Lightning-dev]

Good morning Corne,

> routing. You could consider the start of the partial route as an
> 
> "introduction point"; it is selected by the payee(**). I'm not sure if
> 
> it is exactly equivalent to TOR's introduction points though.

It is almost equivalent I think.

> 
> 2.  Good thinking. I guess that, since either payer or payee will
> 
> decide on the amount, there is no use case for omitting the amount in an
> 
> invoice in BOLT 12; unlike BOLT 11, it should not be optional here. So
> 
> that's not a problem for the partial onion route. Unknown capacity is an
> 
> issue, and I guess it's worse than if the payer is completely free to
> 
> choose a route, because the payer is no longer completely free to choose
> 
> alternative routes. Giving a batch of alternative routes is one concept
> 
> (TBD: can they have the same payment hash?);

Yes. When we retry failing routes, we reuse the payment hash until we succeed 
to pay, or, give up paying.  This is simply the same concept.

> giving new alternatives
> 
> interactively is another option. I think using the same "introduction
> 
> point" for all routes is best for privacy: otherwise the payer could
> 
> determine the neighborhood of the payee.

I wonder.  How does the payer contact the payee in the first place, without 
having located the neighborhood of the payee?  If it is via some TOR hidden 
service, and the payee considers this enough protection, why cannot the same 
TOR hidden service be used as the address of the LN node of the payee (LN 
protocol spec allows this, current implementations not so much)?  Freenet or 
I2P, I suppose?

> 
> 3.  True. Right now I'm thinking in the opposite direction: simplifying
> 
> BOLT 12 by removing the possibility of refunds. We can always add it
> 
> back later (with a proper set of features for all kinds of refunds) as
> 
> an optional feature.
> 
> 4.  This depends on the use case. The URL contains an optional invoice
> 
> ID. A payee can request a payment for a specific, single transaction
> 
> (for a single instance of delivery of goods/services) by handing over an
> 
> URL, including an invoice ID, to a single payer. This provides similar
> 
> functionality as BOLT 11, except that you now have a well-defined
> 
> channel for transmitting larger invoice descriptions and for using
> 
> partial onion routes. A payee can also hand over an URL without invoice
> 
> ID; this can be used and re-used by one or more payers, whenever they
> 
> want to perform payments to this payee.

How does the payer derive the payment hash? Or does the payer have to contact 
the payee again to get a fresh payment hash specifically for the payer?

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

Re: [Lightning-dev] A protocol for requesting invoices

[Corné Plooy via Lightning-dev]

Hi  ZmnSCPxj,


Thanks for the links. I've done a bit of reading, and this seems to be
the clearest explanation of what the Web Payments Working Group wants to
achieve:

https://www.w3.org/TR/webpayments-overview/

But maybe Christian can give better / more up-to-date info.


From what I can see, their concept is still very much focused on
non-recurring purchases, and then especially on websites. In other
words: the typical web shop use case. The site linked above does however
contain the following text:


"A concern has been raised over the structure of a payment request,
notably that there are other forms of messages that may be initiated by
a payer. There is currently a proposal to modify payment request to a
more generalized "payment instruction" that would be capable of
expressing other messages like subscriptions, preauthorizations,
refunds, and other sorts of payment-related instructions."


So it seems they're thinking about it, but there is no consensus or
standardization yet. The important question: should we wait for this?
How long is this going to take? How bad would it be to first push
forward some simple version of BOLT 12?


CJP


PS. Quote of the day:

"Some aspects of bitcoin are less useful, however. It is currently
impossible to set up recurring payments with the currency, making it
impractical for subscriptions that renew on a short term basis."



Op 09-03-18 om 05:28 schreef ZmnSCPxj:
> Good morning Corne,
>
> You mention URLs in your draft.  This made me remember about the Web Payments 
> Working Group of W3C, https://www.w3.org/Payments/WG/ , of which Decker, 
> Christian of Blockstream is a member: 
> https://www.w3.org/2000/09/dbwg/details?group=83744=1
>
> My understanding is that Christian aims to make Bitcoin payments (and 
> possibly Lightning invoice payments?) payable over Web payment protocols that 
> W3C group is working on.
>
> Possibly the Web Payments Working Group may provide better perspective on 
> various other payment use cases as well as their subtleties, which can help 
> inform your considerations in your proposed BOLT12.
>
> Regards,
> ZmnSCPxj
>
>
> ​Sent with ProtonMail Secure Email.​
>
> ‐‐‐ Original Message ‐‐‐
>
> On March 8, 2018 11:19 PM, Corné Plooy via Lightning-dev 
>  wrote:
>
>> Hi,
>>
>> I was thinking of how to use Lightning for various types of payments,
>>
>> and I think it's currently fine for customer/(web)shop type
>>
>> interactions, but it seems a bit inconvenient for other use cases, e.g.
>>
>> salary payments or direct pay-out of cryptocurrency bought on an
>>
>> exchange. I came up with an idea that addresses some of these issues and
>>
>> more (e.g. payee anonymity) by having a direct line of communication
>>
>> between payer and payee instead of BOLT11-style interaction. It's still
>>
>> a bit half-baked, with many details not worked out yet, but you can read
>>
>> it here, and see if you like where this is going:
>>
>> https://github.com/bitonic-cjp/lightning-rfc/blob/payment-protocol/12-payment-protocol.md
>>
>> In true permissionless fashion, I have been so bolD to register bolT #12
>>
>> for my idea.
>>
>> Please let me know what you think.
>>
>> kind regards,
>>
>> CJP
>>
>> 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] A protocol for requesting invoices

[ZmnSCPxj via Lightning-dev]

Good morning Corne,

You mention URLs in your draft.  This made me remember about the Web Payments 
Working Group of W3C, https://www.w3.org/Payments/WG/ , of which Decker, 
Christian of Blockstream is a member: 
https://www.w3.org/2000/09/dbwg/details?group=83744=1

My understanding is that Christian aims to make Bitcoin payments (and possibly 
Lightning invoice payments?) payable over Web payment protocols that W3C group 
is working on.

Possibly the Web Payments Working Group may provide better perspective on 
various other payment use cases as well as their subtleties, which can help 
inform your considerations in your proposed BOLT12.

Regards,
ZmnSCPxj


​Sent with ProtonMail Secure Email.​

‐‐‐ Original Message ‐‐‐

On March 8, 2018 11:19 PM, Corné Plooy via Lightning-dev 
 wrote:

> Hi,
> 
> I was thinking of how to use Lightning for various types of payments,
> 
> and I think it's currently fine for customer/(web)shop type
> 
> interactions, but it seems a bit inconvenient for other use cases, e.g.
> 
> salary payments or direct pay-out of cryptocurrency bought on an
> 
> exchange. I came up with an idea that addresses some of these issues and
> 
> more (e.g. payee anonymity) by having a direct line of communication
> 
> between payer and payee instead of BOLT11-style interaction. It's still
> 
> a bit half-baked, with many details not worked out yet, but you can read
> 
> it here, and see if you like where this is going:
> 
> https://github.com/bitonic-cjp/lightning-rfc/blob/payment-protocol/12-payment-protocol.md
> 
> In true permissionless fashion, I have been so bolD to register bolT #12
> 
> for my idea.
> 
> Please let me know what you think.
> 
> kind regards,
> 
> CJP
> 
> 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