[Lightning-dev] Make Me An Offer: Next Level Invoicing

[Corné Plooy via Lightning-dev]

Rusty,


At the recently held Lightning Conference in Berlin you asked for people
to send you use cases / feature requests for the next-generation
Lightning invoicing. I already did some work on this back in 2018; that
work was interrupted when I started working on other ideas. I believe
CDecker is member of some W3C(?) commission on payments, so he may also
have ideas on this.


My earlier work focused on an interactive protocol for direct
communication between payer and payee. This is an old sketch / WIP:

https://github.com/bitonic-cjp/lightning-rfc/blob/payment-protocol/12-payment-protocol.md

I know some people don't like such interaction, but it does make many
things easier to accomplish, e.g. rendez-vous routing and stuckless
payments.


For now, without doing an actual technology proposal, I'd like to share
a way of thinking about payer/payee interaction.


In my view, a transaction is not a line, it's a circle. Bitcoins go from
payer to payee over the Lightning network, and whatever
assets/goods/services are paid for go from payee to payer - this closes
the circle. Transactions on all hops of the circle should be atomic.
Between Lightning hops this is realized with HTLCs. For the payer-payee
hop this is generally not possible, as non-cryptographic things
generally don't allow you to construct HTLCs on them. Invoices and
proofs of payment act as cryptographic representatives of
non-cryptographic entities.


In a generalized view, the interaction between payer and payee can be
seen as a virtual payment channel. Full refunds, partial refunds, update
of what goods are to be delivered (which may depend on an additional
payment or a partial refund), sending back delivered goods (with
refund), are all updates to this virtual channel. Desirable properties
of such a channel:

* The channel has a state, and that state can be updated.

* A state update invalidates the previous state.

* By default, a state update requires consent of both parties. We may
include a feature where, in the previous state, one party gives consent
to allow the other party to unilaterally perform certain types of state
updates.

* A state update may require a payment of a certain amount in one
direction or in the opposite direction. The state update only becomes
valid in combination with the corresponding proof of payment.

* The state specifies obligations of parties to each other (e.g. "A
shall return  back to B").

* A state can be "final" in the sense that there should be no more
updates in the future. This may not need to be enforced by software or
by protocol: it can simply be by convention. If the "final" state
requires consent of both parties for an update, any participant can make
it final by never signing an update, or even by throwing away the
private key used for the channel.


The state updating mechanism and its properties require special
attention. I think the purpose of the channel is to aid in conflict
resolution - it should provide evidence of what is agreed between both
parties. There is nothing in an old state that makes it inherently
invalid: in fact, at some point in the past it was valid. The only thing
that makes it invalid is the presence of a later version. To reveal the
truth in conflict resolution, it is necessary that

(1) the latest state is revealed

(2) it is clear that this latest state is more recent than all other
states that are revealed

I hope that (1) is likely incentive-wise: typically, incentives of the
parties are each other's opposite, so either one party has an interest
in revealing an update, or the other party has. I haven't worked out
this thought very rigorously though.

I think a bit of cryptography can help with (2). One idea is to include
sequence numbers in states, another is to include the hash of the
previous state. Either way, the possibility remains (cryptographically,
maybe not incentive-wise) to mess up the evidence by "forking" the
channel: making multiple state updates that have the same parent state.
This may be resolved semantically, with rules like "if A unilaterally
makes a fork, and both sides are revealed, B may choose which side of
the fork is to be considered valid".


Some advanced ideas

* Contracts between three or more parties.

* Merging and joining of contracts in state updates


CJP



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

Re: [Lightning-dev] Rendez-vous on a Trampoline

[Corné Plooy via Lightning-dev]

Cool: non-source rendez-vous routing. Getting closer to 2013 Amiko Pay,
with the added experience of 2019 Lightning with Sphinx routing and AMP.

https://cornwarecjp.github.io/amiko-pay/doc/amiko_draft_2.pdf

(esp. section 2.1.3)

Please forgive the use of the term "Ripple". 2013 was a different time.


CJP


On 22-10-19 14:01, Bastien TEINTURIER wrote:
> Good morning everyone,
>
> Since I'm a one-trick pony, I'd like to talk to you about...guess
> what? Trampoline!
> If you watched my talk at LNConf2019, I mentioned at the end that
> Trampoline enables high AMP very easily.
> Every Trampoline node in the route may aggregate an incoming
> multi-part payment and then decide on how
> to split the outgoing aggregated payment. It looks like this:
>
>      . 1mBTC .    .--- 2mBTC ---.
>     /                                    \ /                         
>         \
> Alice - 3mBTC --> Ted -- 4mBTC > Terry - 6mBTC
> > Bob
>    \                                     /
>     `--- 2mBTC --'
>
> In this example, Alice only has small-ish channels to Ted so she has
> to split in 3 parts. Ted has good outgoing 
> capacity to Terry so he's able to split in only two parts. And Terry
> has a big channel to Bob so he doesn't need 
> to split at all.
> This is interesting because each intermediate Trampoline node has
> knowledge of his local channels balances,
> thus can make more informed decisions than Alice on how to efficiently
> split to reach the next node.
>
> But it doesn't stop there. Trampoline also enables a better
> rendez-vous routing than normal payments.
> Christian has done most of the hard work to figure out how we could do
> rendez-vous on top of Sphinx [1]
> (thanks Christian!), so I won't detail that here (but I do plan on
> submitting a detailed spec proposal with all 
> the crypto equations and nice diagrams someday, unless Christian does
> it first).
>
> One of the issues with rendez-vous routing is that once Alice (the
> recipient) has created her part of the onion,
> she needs to communicate that to Bob (the sender). If we use a Bolt 11
> invoice for that, it means we need to
> put 1366 additional bytes to the invoice (plus some additional
> information for the ephemeral key switch).
> If the amount Alice wants to receive is big and may require
> multi-part, Alice has to decide upfront on how to split 
> and provide multiple pre-encrypted onions (so we need 1366 bytes /per
> partial payment/, which kinda sucks).
>
> But guess what? Bitcoin Trampoline fixes that*™*. Instead of doing the
> pre-encryption on a normal onion, Alice
> would do the pre-encryption on a Trampoline onion (which is much
> smaller, in my prototype it's 466 bytes).
> And that allows rendez-vous routing to benefit from
> Trampoline's ability to do multi-part at each hop.
> Obviously since the onion is smaller, that limits the number of
> trampoline hops that can be used, but don't
> forget that there are additional "normal" hops between each Trampoline
> node (and the final Trampoline spec 
> can choose the size of the Trampoline onion to enable a good enough
> rendez-vous).
>
> Here is what it would look like. Alice chooses to rendez-vous at
> Terry. Alice wants the payment to go through Terry
> and Teddy so she pre-encrypts a Trampoline onion with that route:
>
> Alice <--- Teddy <--- Terry
>
> She creates a Bolt 11 invoice containing that pre-encrypted onion. Bob
> picks up that invoice and can either reach 
> Terry directly (via a normal payment route) or via another Trampoline
> node (Toad?). Bob finalizes the encryption of 
> the Trampoline onion and sends it onward. Bob can use multi-part and
> split the payment however he wishes, 
> because every Trampoline node in the route will be free to aggregate
> and re-split differently.
> Terry is the only intermediate node to know that rendez-vous routing
> was used. Terry doesn't learn anything about 
> Alice because the payment still needs to go through Teddy. Teddy only
> learns that this is a Trampoline payment, so 
> he doesn't know his position in the Trampoline route (especially since
> he doesn't know that rendez-vous was used).
>
> I believe this makes rendez-vous routing reasonable to implement: the
> trade-offs aren't as strong as in the normal
> payment case. If I missed something (maybe other issues related to the
> current rendez-vous proposal) please let me know.
>
> Of course Trampoline itself also has trade-offs that in some cases may
> impact privacy (e.g. when paying to legacy nodes 
> that don't understand the Trampoline onion). This is why Eclair is
> currently implementing it to identify all the places where
> it falls short, so that we can then leverage the community's amazing
> brain power to converge on a spec that everyone is 
> happy with and that minimizes the trade-offs we need to make. Stay
> tuned for more information and updates to the spec PR 
> once we make progress on our Trampoline 

Re: [Lightning-dev] An Argument For Single-Asset Lightning Network

[Corné Plooy via Lightning-dev]

ZmnSCPxj,


Without reading your proposed solution, I don't understand the problem
you describe here:

> David solution effectively makes the exchange node (OM in CJP terminology) 
> also the RM in the route.
> However, with use of mere preimages and hashes, it is obvious that such a 
> "loop" where the end payee (RM) is also an intermediate node, is foolish, as 
> the end payee will simply claim the payment without letting the loop through.
> And since the payee (S in CJP terminology) is paid via the delta from its 
> incoming to its outgoing HTLC on that loop, then if the RM is the OM then it 
> is possible for the OM To simply steal the payment outright.
>
> (It is helpful to realize that payment routes pay not just the end payee, but 
> all hops in the middle; thus the "real" target of the payment (the one who 
> receives the bulk of the value) need not be at the *end* of the route)


All hops on the route are linked together the same way as hops in a
regular Lightning payment. An intermediate node who is also the end
payee, and therefore knows the preimage, can indeed shortcut the payment
by accepting the payment on the intermediate node instead of forwarding
it; this is true for all Lightning payments [*].


I think the scenario where "the bulk of the value" ends up at one or
more intermediate nodes should not typically apply here. With a
sufficiently low spread and fees, the bulk of the value should be
roughly the same on each hop. The only thing that might be stolen is in
those fees and exchange rate differences.


By design, OT will pay the fees, so its outgoing amount will be higher
than the incoming amount. RM will not want to exclude OT from its route.
If RM is OM, then RM cannot exclude OM from the route either.
Effectively, you end up with a RM-OT-RM route, which is OK if RM is OM.
Minimizing Lightning route length to minimize fees is not a bad thing.


There is a remaining issue though, that if RM is OM, then, obviously, RM
and OM can cooperate to perform a delay attack on OT. I think this is
acceptable, given that in section 4 of my paper[1] I already described
some countermeasures OT can take. I think the attack possibility is
wider: if OT and OM are anonymous / pseudonymous toward each other, then
RM can either be OM and attack OT, or it can be OT and attack OM. I
argued in section 4 that OM is more vulnerable than OT, but luckily the
assumptions to this argument do not apply anymore. OM knows the
attacker: it is RM. RM can perform a single attack on OM, and after
that, OM will refuse incoming exchange transactions that are coordinated
by RM.


So my proposal is not perfect, it does contain the trusted role RM, and
participants have to be somewhat careful which RMs they do business
with. However, it does have the benefit of de-coupling the trusted role
RM from the actual trading roles of OT and OM, so you only need to trust
a few parties and you can trade with lots of parties. Trading parties
can remain anonymous to RM, and they can hide from RM what second asset
they are trading, and to what exchange rate, so there's very little that
can be censored by RM.


CJP


[*] So it is a vulnerability for the idea where you anonymously donate
to an intermediate node by giving it a huge fee. The vulnerability does
not apply if you are the final payee, since nobody else but the final
payee can perform the attack. Other parties might control multiple nodes
on the route, but they only learn the preimage after HTLC acceptance on
all hops.


[1] https://bitonic.nl/public/slowdown_prevention.pdf



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

Re: [Lightning-dev] Reason for having HMACs in Sphinx

[Corné Plooy via Lightning-dev]

> * layer 0 (to B): decorrelation_secret = k[b]
> * layer 1 (to B): total_decorrelation_secrets = k = k[a] + k[b]


I would have less trouble understanding that if it were layer 1 (to C)
instead of (to B).


> The total_decorrelation_secrets serves as the payer-generated shared secret 
> between payer and payee.
> B cannot learn this, and thus cannot fake its own secret.
> Even if it instead offers ((I + K[A]) + k[z] * G) for a new secret k[z], it 
> cannot know how to change total_decorrelation_secrets from k[a] + k[b] to 
> k[a] + k[z] instead.
>
The way things are now, the ephemeral key generation and the payment
hash/preimage generation are completely unrelated. This is what allows
an attacker to use the same payment hash, and use his own ephemeral key
pair to create a new onion packet around it.


Primarily, path decorrelation replaces the payment hash/preimage part.
Maybe I still don't understand something, but if that's the only thing
(without changing the ephemeral key / onion shared secret generation),
attacking the direct neighbor should still work; in your case, B would
still offer ((I + K[A]) + K[B]) to C, with an onion packet B created
himself. I'm not familiar enough with the path correlation to understand
what happens after step 6, but for C it looks the same, so she should do
the same.


I do see that, if you couple the "H"TLC payment secret generation to the
onion shared secret generation, you can make the attack impossible. Do I
understand correctly that this is the idea? After all, C still needs to
receive k somehow; my crypto math isn't that good, but my intuitive
guess is that i + k is the secret that allows C to claim funds locked in
((I + K[A]) + K[B]) =? (i + (k[a] + k[b])) * G. If k is submitted from A
to C through some mechanism that replaces the current ephemeral key
system, then I understand what you're at.


Assuming this is the case, it's pretty neat. I do wonder how it
interacts with rendezvous routing. If the sender and receiver each
create the k[..] values for their own part of the route, can the
receiver-generated onion packet still use points of the form ((I + K[A])
+ K[B]), including K[..] values related to the sender side? I need to
dig deeper into this path decorrelation idea.


CJP


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

Re: [Lightning-dev] Reason for having HMACs in Sphinx

[Corné Plooy via Lightning-dev]

>> I think we could stop this type of attack by including some kind of
>> shared secret in the onion message to the final node:
> I think we get this "for free" if we switch to path decorrelation and 
> points+privkeys instead of hashes+preimages.
>
> Path decorrelation means that each hop is given a random point, to be added 
> to the next SS "HTLC".
> The final node needs to be given the total of the scalars of each hop random 
> point along the route, most likely within the last hop of the onion.
> The final node also cannot differentiate between an incorrect total for this 
> scalar, or an incorrect "invoice hash"/invoice point.
>
> Hence, some intermediate node along the way cannot guess this, and the final 
> node will give the same error, i.e. "invoice point not found".
>
>
That might indeed stop an attacker from testing 2nd-degree, 3rd-degree
etc. neighbors, making the attack much less versatile. However, for his
direct neighbor in the route, the attacker does learn the point to be
used in that hop. Therefore I think the attacker can still test whether
or not the next node is the final hop.


CJP


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

Re: [Lightning-dev] Reason for having HMACs in Sphinx

[Corné Plooy via Lightning-dev]

Thanks Christian, that makes sense. Unfortunately it's not very clear
from the BOLT, at least not for me.

Now that I think of this type of attack: *in general* the HMAC prevents
this kind of attack, but isn't the attack still possible in certain
specific cases?


For instance, the attacking intermediate node might guess that the next
node in the route is the final node; it can test this by completely
replacing the onion packet it sends to the next node with a self-written
onion packet that has the next hop as final node, with the same amount
and payment hash as instructed by the incoming payment. If that
succeeds, it has learned that the next node is indeed the final node
(and nobody gets to know about the attack); if that fails, it might
retry the payment with the original onion packet. In that case, it
learned that the next node is *not* the final node. In this case, the
attack is detectable by the next node though: it first receives an
incoming payment with a payment hash it doesn't recognize, and then it
receives a payment forwarding request with the same payment hash.


Given that the attacker has good knowledge of the shape of the Lightning
network, this type of attack can be generalized to test whether a
certain second-degree neighbor, third-degree neighbor etc. is the final
node; it scales pretty badly with increasing network distance though. An
additional advantage for the attacker is that this gives plausible
deniability: if the attack becomes visible, the attacker can always
claim it wasn't him, but some node upstream in the route. A practical
difficulty for the attacker might be that the exact amount forwarded in
further-away hops is unknown, but it's probably not that difficult to guess.


I think we could stop this type of attack by including some kind of
shared secret in the onion message to the final node:

* Payee generates shared secret and passes this to payer, as part of the
invoice

* Payer includes shared secret in the per hop data to payee

* On receiving the incoming message, payee checks whether the received
shared secret corresponds to the generated one. If this is not the case,
behave in exactly the same way as when the payment hash is unrecognized
(including timing, to prevent timing side-channel attacks).

If this shared secret is encrypted like the rest of the per hop data,
the attacker can't learn the shared secret, and can't include it in his
own replacement onion. He can't copy-paste the encrypted shared secret
from the original onion either, since he has to use his own, different
ephemeral key in his own onion. With this protocol in place, a final
node can no longer be distinguished from a non-final node with this attack.


The shared secret doesn't need to be very large: the number of attempts
per second (to guess the shared secret) is limited by network latency,
bandwidth and maybe some artificial rate limiting. If an attacker can do
100 attempts per second, then a 32-bit shared secret will take (on
average) 2^31 / (100*3600*24) = 248 days to crack, for a single guess of
which node is the final node. In the mean time, people will have noticed
the ongoing attack and will have taken countermeasures. Besides, the
transaction lock time will likely have expired in the mean time as well.


CJP


On 29-11-18 18:13, Christian Decker wrote:
> Hi Corne,
>
> the HMACs are necessary in order to make sure that a hop cannot modify
> the packet before forwarding, and the next node not detecting that
> modification.
>
> One potential attack that could facilitate is that an attacker could
> learn the path length by messing with different per-hop payloads: set
> n=0 the attacker flips bits in the nth per-hop payload, and forwards
> it. If the next node doesn't return an error it was the final recipient,
> if if returns an error, increment n and flip bits in the (n+1)th per-hop
> payload, until no error is returned. Congratulation you just learned the
> path length after you. The same can probably be done with the error
> packet, meaning you can learn the exact position in the route. Add to
> that the information you already know about the network (cltv_deltas,
> amounts, fees, ...) and you can probably detect sender and recipient.
>
> Adding HMACs solves this by ensuring that the next hop will return an
> error if anything was changed, i.e., removing the leak about which node
> would have failed the route.
>
> Cheers,
> Christian

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

[Lightning-dev] Reason for having HMACs in Sphinx

[Corné Plooy via Lightning-dev]

Hi,


Is there a reason why we have HMACs in Sphinx? What could go wrong if we
didn't?

A receiving node doesn't know anyway what the origin node is; I don't
see any attack mode where an attacker wouldn't be able to generate a
valid HMAC.

A receiving node only knows which peer sent it a Sphinx packet;
verification that this peer really sent this Sphinx packet is (I think)
already done on a lower protocol layer.


AFAICS, The only real use case of the HMAC value is the special case of
a 0-valued HMAC, indicating the end of the route. But that's just silly:
it's essentially a boolean, not any kind of cryptographic verification.


CJP


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

Re: [Lightning-dev] Approximate assignment of option names: please fix!

[Corné Plooy via Lightning-dev]

The only reasons I see for keeping the global/local distinction is that
you might not want to gossip everything, either to keep the gossip data
small, or for some privacy reasons. Apparently, that's all very
theoretical so far, as current features don't seem to need either.


Ideally you'd like to have a design that requires as little consensus as
possible, but for global feature bits it's clear there has to be
consensus about their meaning. For a moment I thought we'd have more
relaxed requirements for local feature bits (as only peers have to agree
on feature bit meanings), but if we want every peer to be able to
connect to every other peer, we still need global consensus on the
meaning of local feature bits.


I'm not even sure it makes sense to keep certain feature bits local for
privacy reasons. Interested parties can usually just figure out your
local feature bits by connecting to your node. As for the size of gossip
data: the bits themselves shouldn't be the problem. Certain features
might require extra data to be gossiped, but that should be discussed on
a case-by-case data per feature. We might end up with a gossip design
where you'd first receive the basic gossip data, and then try to get
extended data you're interested in, based on what feature bits are
enabled in the basic gossip data.


So, maybe I missed something important, but no, right now I don't see a
good reason for the global/local distinction.


CJP


On 14-11-18 00:50, Rusty Russell wrote:
> Pierre  writes:
>> Hi Rusty,
>>
>>>The feature masks are split into local features (which only
>>>affect the protocol between these two nodes) and global features
>>>(which can affect HTLCs and are thus also advertised to other
>>>nodes).
>> I don't think that definition makes a lot of sense. For example I
>> probably want to advertise the fact that my node supports
>> option_data_loss_protect, which is a local feature. OTOH why would I
>> *not* want to avertise a feature that I support? I struggle to see
>> what is the point of making the distinction between local/global
>> actually.
> The theory was that local features concern direct peers, global features
> concern others (thus *must* be advertized by gossip).
>
> I *expected* local features to become ubiquitous over time, so by the
> time an implementation decided "I don't even want to talk to nodes
> without feature X" then most nodes would support feature X, so you could
> simply connect and you're probably OK.
>
> So the question becomes:
>
> 1. Do people want to pre-filter by local features?
> 2. If so, only some local features, or all of them?
>
> If only some, then we make those ones global features.  If all, then we
> remove the local/global distinction altogether?
>
> Thanks,
> Rusty.
> ___
> 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] Including a Protocol for splicing to BOLT

[Corné Plooy via Lightning-dev]

Now that you remind me of the wiki: I remember we discussed this before,
so maybe I was just repeating myself (sorry). It is true the wiki should
be more prominent.


CJP


Op 27-08-18 om 15:19 schreef Christian Decker:
> Corné Plooy via Lightning-dev 
> writes:
>>> Aside from that, spontaneous payments is amongst the most request feature
>>> request I get from users and developers.
>> A while ago I realized that spontaneous payments (without proof of
>> payment, mostly for donations only) can be realized quite easily if the
>> payer generates the preimage and hash, and includes the preimage in the
>> sphinx message to the payee node. If the payee node recognizes the
>> sphinx message format, it can use the preimage to claim the payment.
>>
>> CJP
> You mean like we describe in the Brainstorming wiki [1]? We definitely
> need to make the Wiki more prominent :-)
>
> [1] 
> https://github.com/lightningnetwork/lightning-rfc/wiki/Brainstorming#passing-a-transfer-secret-in-the-onion

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

Re: [Lightning-dev] Including a Protocol for splicing to BOLT

[Corné Plooy via Lightning-dev]

> Aside from that, spontaneous payments is amongst the most request feature
> request I get from users and developers.

A while ago I realized that spontaneous payments (without proof of
payment, mostly for donations only) can be realized quite easily if the
payer generates the preimage and hash, and includes the preimage in the
sphinx message to the payee node. If the payee node recognizes the
sphinx message format, it can use the preimage to claim the payment.

CJP


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

Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

[Corné Plooy via Lightning-dev]

Op 10-04-18 om 20:34 schreef Tyler H:
>
> I will continue to approach the problem of securely advertising
> human-understandable node names, and I hope someday soon I will have a
> solution Lightning can use that retains the open, decentralized
> properties of the technology and the underlying blockchains.
>
Two of my favorite approaches:
* Namecoin-style: Register your name first-come-first-serve on a block
chain.
  -> Provides no protection against name squatting and attackers
registering similarly-looking names.
* Web of Trust: I tell you I believe this pubkey really corresponds to
this name; someone else might tell you something else. DNS is
essentially a special case of this, where the WoT has a centralized star
shape. TLS is another case, where there is dozens of signing parties
(CAs), and everyone typically gets their keys signed by only one of
them, so anyone verifying keys has to trust all these CAs. More
generally, a WoT can have any shape though.
  -> Provides little to no protection against trusted parties lying to you.

CJP


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

Re: [Lightning-dev] QR of node information

[Corné Plooy via Lightning-dev]

Why put everything in bech32? It hurts readability. The only possible
advantage is that data inside the bech32 blob can be digitally signed in
a convenient way. If you don't need that, I'd keep your data ourside the
bech32 blob, in a (expert-)human-readable format.


Why not follow a regular URL format when host and port are involved? I
don't see the advantage of lightning:ln1bech32nodeid/ipnumber/port over
node@ip:port. In practice, I see both C-Lightning and LND also using
node@ip:port, BTW.


Is this really only about reducing the size of QR codes? How many
percent reduction do you think you can accomplish with your approach? I
think, when it comes to reducing QR code size, it makes more sense to
think of a better way to encode the node ID. Hexadecimal isn't exactly
the most space-efficient encoding.


CJP



Op 07-04-18 om 17:17 schreef Robert Olsson:
> Hello all,
>
> I seem to not find a bolt regarding the QR code of node@ip:port
>
> It seems eclair only supports the format hex@ip:port format, and i
> haven't tried any other mobile wallets.
>
> I thought there would be support for bech32 nodeid:s to keep the QR
> small, but it doesn't seem that way.
>
> If it isn't standardized yet, i think we should do it soon so all
> wallets will support it from start and we can avoid bulky QR codes.
>
> To fully utilize QR it should work with charset in text-mode, so i
> would suggest a format like
>
> lightning:ln1bech32nodeid/ipnumber/port
>
> where /port is optional if port is 9735
>
> this is to avoid @ and confusion of : in ipv6 and :portnumber
> (skip '[' and ']' in ipv6)
>
> another approach would be to encode ip and portnumber in bech32 as
> well. my opinion is that everything coded entirely in bech32 shouldn't
> need a protocol so the 'lightning:' part could possibly be omitted as
> well.
>
> or did i just miss a bolt somewhere?
>
> best regards
> Robert Olsson
>
>
>
>
>
>
>
> ___
> 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] Lightning over NFC

[Corné Plooy via Lightning-dev]

If there are censorship concerns, you could opt for a set-up where payer
has an authenticated connection to a trusted server, through the
Internet connection provided by payee. The trusted server can, for
instance, be a full Lightning node running at the payer's home.


The payer then only has to take a very light piece of electronics with
him/her. It will still be larger than a credit card (since
authentication should be done payer-side, e.g. with a PIN code), but it
can be smaller than a smart phone. Personally, I like this kind of
set-up, because I see cell phones as a huge privacy issue (you're
continuously transmitting your rough location to the network).


Why would there need to be a direct channel between payer and payee? We
have the Lightning network to avoid needing direct channels, right?


CJP



Op 05-04-18 om 17:39 schreef ZmnSCPxj via Lightning-dev:
> Good morning Igor,
>
> This is quite an interesting use-case for Lightning.
>
> However it seems to me that the payer will need a direct channel to
> the payee, or at least the payment terminal (of the payee...?).
>
> In addition the payer will need to somehow get blockchain information
> from the payee if the payer itself has no Internet.  The payee may
> have an incentive to prevent the payer from knowing that timeouts have
> been reached, for example, and may withhold new blocks (although all
> censorship attacks I know of that could be used on LN target the payee
> and not the payer).
>
> Is my understanding correct?
>
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail  Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On April 5, 2018 5:46 PM, Igor Cota  wrote:
>
>> Hello all,
>>
>> I feel that one of the biggest promises of lightning lies in it being
>> used for everyday retail payments.
>>
>> I'd like to see a system that's:
>> 1) instantaneous like the contactless bank cards of today
>> 2) encodes a fancy HTML receipt in bolt11 for the payers future reference
>>
>> QR codes are a bit unwieldy and even more so if you want a nice HTML
>> table description of your grocery shopping with hundreds of items -
>> this relatively large amount of data makes them impractical to scan.
>>
>> To this end I've been running an instance of c-lightning on Android
>> [1][2][3] and experimenting with payments via NFC. I set up a machine
>> with an NFC USB dongle that acts as an point-of-sale terminal [4]. So
>> far so good!
>>
>> There are two basic ways you can use NFC enabled phones today - as
>> passive tag readers or in card emulation mode (not sure if the latter
>> is available on iOS).
>>
>> Passive tags are really simple and encoding bolt11 to them works as
>> expected. If you set the right MIME type Android will open whatever
>> app is registered to handle lightning and you can either pay
>> instantaneously or after user confirmation. Works great provided both
>> the phone and terminal are connected to the network and have a route
>> to each other.
>>
>> Card emulation mode is more interesting because it enables us to have
>> two way communication and therefore an ad hoc connection to the
>> lightning network. After some handshaking, phone can tell the
>> terminal that it wants to connect to lightning via NFC. All
>> communication between these two lightning nodes can be done over NFC
>> or even bluetooth [5]. This might be useful as fallback in situations
>> where mobile data is not available.
>>
>> I settled on a MIME type (application/lightning) and an NFC
>> application id (LIGHTNING). There is also a very simple protocol to
>> forward socket data. For the sake of interoperability it would be
>> great if we agreed on some standards but I'm not sure how to proceed
>> with this. Should these be part of a future BOLT or is mailing list
>> banter enough?
>>
>> I look forward to your views!
>>
>> Cheers,
>> Igor
>>
>>
>> [1]
>> https://github.com/ElementsProject/lightning/commit/bd95aba7a5f9bad8f447bf3de8f7e8cfe83751af
>> [2]
>> https://github.com/ElementsProject/lightning/commit/d4d1c4acb08efb6be4f491cdee5cb6dd4b84ddf7
>> [3]
>> https://github.com/ElementsProject/lightning/commit/bd95aba7a5f9bad8f447bf3de8f7e8cfe83751af
>> [4] https://github.com/icota/presto
>> [5] https://github.com/ElementsProject/lightning/pull/1323
>
>
>
> ___
> 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

[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

[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 
> <lightning-dev@lists.linuxfoundation.org> 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

[Lightning-dev] Proof of payment (Re: AMP: Atomic Multi-Path Payments over Lightning)

[Corné Plooy via Lightning-dev]

ty of the exchange can be done by
> providing the information encrypted, a hash of the encryption key,
> and proofs that the encrypted data is the one desired and that the
> data was encrypted with the given key; the proof-of-payment is the
> encryption key, and possession of the encryption key is sufficient
> to gain access to the information, with no need to bring in legal
> structures.
>
> (admittedly, ZKCP and ZKCSP are dependent on new cryptography...)
>
> (also, AMP currently cannot provide a proof-of-payment, unlike
> current payment routing that has proof-of-payment, but that is an
> eventual design goal that would enable use of ZKC(S)P
> on-Lightning, assuming we eventually find out that zk-SNARKs and
> so on are something we can trust)
>
> Regards,
> ZmnSCPxj
>
> ​
> Sent with ProtonMail Secure Email.
> ​
>
>  Original Message 
>  On February 13, 2018 2:05 AM, Christian Decker
> <decker.christ...@gmail.com <mailto:decker.christ...@gmail.com>>
> wrote:
>
> >Honestly I don't get why we are complicating this so much. We have a
> > system that allows atomic multipath payments using a single
> secret, and
> > future decorrelation mechanisms allow us to vary the secret in
> such a
> > way that multiple paths cannot be collated, why introduce a
> whole set of
> > problems by giving away the atomicity? The same goes for the
> overpaying
> > and trusting the recipient to only claim the owed amount, there
> is no
> > need for this. Just pay the exact amount, by deriving secrets
> from the
> > main secret and make the derivation reproducible by intermediate
> hops.
> >
> > Having proof-of-payment be presentable in a court is a nice
> feature, but
> > it doesn't mean we need to abandon all guarantees we have worked
> so hard
> > to establish in LN.
> >
> > Corné Plooy via Lightning-dev
> lightning-dev@lists.linuxfoundation.org
> <mailto:lightning-dev@lists.linuxfoundation.org>
> >writes:
> >
> >>I was thinking that, for that use case, a different signed
> invoice could
> >> be formulated, stating
> >> - several payment hashes with their corresponding amounts
> >>
> >> - the obligation of signer to deliver Z if all corresponding
> payment
> >> keys are shown
> >>
> >> - some terms to handle the case where only a part of the
> payments was
> >> successful, e.g. an obligation to refund
> >>The third item is a bit problematic: in order to distinguish
> this case
> >> from a complete success, the payee would have to prove absence of
> >> successful transactions, which is hard. Absence of successful
> >> transactions can only be declared by the payer, so in order to
> reliably
> >> settle without going to court first, the payer should sign a
> >> declaration stating that certain transactions were canceled and
> that the
> >> other ones should be refunded. This can be another invoice.
> >>So, the original invoice states:
> >> - several payment hashes with their corresponding amounts
> >>
> >> - if all corresponding payment keys are shown: the obligation
> of 
> >> to deliver Z, UNLESS stated otherwise by an invoice signed by
> 
> >>-- signed by 
> >>But if a payment partially fails, it can be refunded
> cooperatively with
> >> an invoice created by payer:
> >> - declares which of the original payments were successful (with
> payment
> >> keys) and which were not
> >>
> >> - replaces the obligation of  to deliver Z with an
> obligation to
> >> refund the successful transactions
> >>
> >> - several payment hashes with their corresponding amounts
> >>
> >> - if all corresponding payment keys are shown: cancel the
> obligation of
> >>  to refund
> >>-- signed by 
> >>Maybe this can be repeated iteratively if necessary; hopefully the
> >> not-yet-settled amount will converge to zero.
> >>Important advantage: this only requires changes to the invoice
> format,
> >> not to the network protocol.
> >>The point is: in this use case, the court is apparently the
> final point
> >> of