Nostr notes by

📅 Original date posted:2019-01-08 📝 Original message: ...

2023-06-09T12:53:47Z

In reply to nevent1q…8564
_________________________

📅 Original date posted:2019-01-08
📝 Original message:
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

📅 Original date posted:2018-12-06 📝 Original message: > ...

2023-06-09T12:53:20Z

In reply to nevent1q…va87
_________________________

📅 Original date posted:2018-12-06
📝 Original message:
> * 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

📅 Original date posted:2018-12-04 📝 Original message: ...

2023-06-09T12:53:20Z

In reply to nevent1q…z2rk
_________________________

📅 Original date posted:2018-12-04
📝 Original message:
>> 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

📅 Original date posted:2018-12-04 📝 Original message: ...

2023-06-09T12:53:19Z

In reply to nevent1q…7y8q
_________________________

📅 Original date posted:2018-12-04
📝 Original message:
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

📅 Original date posted:2018-05-22 📝 Original message: > ...

2023-06-09T12:50:30Z

In reply to nevent1q…8ekh
_________________________

📅 Original date posted:2018-05-22
📝 Original message:
> You missed the vital detail: that you must prove channel closure if you
> can't unpeel the onion further. That *will* hit an unresponsive party
> with a penalty.[1]
Is this specified in a BOLT somewhere? I tried to find it several times,
without success.

CJP

📅 Original date posted:2018-04-16 📝 Original message: Op ...

2023-06-09T12:49:52Z

In reply to nevent1q…2ggl
_________________________

📅 Original date posted:2018-04-16
📝 Original message:
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

📅 Original date posted:2018-03-15 📝 Original message: Hi ...

2023-06-09T12:49:25Z

In reply to nevent1q…a9mh
_________________________

📅 Original date posted:2018-03-15
📝 Original message:
Hi Andy,

1. Don't confuse TOR onion routing (used for anonymous/pseudonymous
communication) with Lightning onion routing (used for anonymous
payments). TOR's design is outside the scope of the discussion; as far
as I can see, TOR is only relevant because it exists, it works(*) and it
is useful to us. The "partial onion route" is about Lightning's onion
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.

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?); 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.

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.

Thanks for the questions; I think I can improve my proposal based on
your feedback.

What should I do with BOLT 12? Have it pulled in
lightningnetwork/lightning-rfc; maybe in a separate branch? Or first
work it out in more detail? How does lightningnetwork/lightning-rfc
distinguish between drafts, finished agreed-on specs and things we
decided we don't want? Is there even a consensus forming mechanism?

CJP

(*) to some degree; there are limits to the privacy provided by TOR.

(**) when extending the current BOLT 12 draft a bit, it might also
optionally be selected by the payer.

Op 10-03-18 om 06:16 schreef Andy Schroder:
> Hello Corné,
>
> I'm glad to see that someone getting this kind of idea started.
>
> I'm still new to some of these topics, but I have a few comments.
> Hopefully I'm not wasting your time if they are too rudimentary!
>
> 1. You mention that the payee gives a URL where the payer can then
> connect to to request invoices. You mention that this can be a tor
> hidden service if the payee needs to remain private. You also
> suggest that the payee can remain private by "payee can send an
> invoice to payer which has a partial onion route as destination
> instead of a node ID". I was reading about tor hidden services
> (https://www.torproject.org/docs/onion-services.html.en), and they
> require an introduction point, and a rendezvous point. Do we not
> need this two step process for the payment route, because we
> already have communication initiated over the anonymous
> communication channel, and the beginning of the partial onion
> route is not publicly available information, and can change with
> every invoice?
> 2. What happens if the capacity of the partial onion route is no
> longer sufficient when the payer is ready to pay? Is there a way
> to provide a few routes just in case? Or, in the case where no
> amount is specified, how is the partial onion route possible if we
> don't even know how much capacity may be needed?
> 3. You say the refund should invalidate the proof of payment of the
> initial transaction. What about partial refunds? I think there are
> a lot of applications where there would be a partial refund.
> 4. You say "this BOLT specifies a protocol where payee gives a URL to
> one or more potential payers". How does the payer identify itself
> to the payee so that the payee knows what goods or services that
> they want an invoice for? Do they send this after making the
> connection, or is it part of the URL?
>
>
>
>
> Andy Schroder
> On 03/08/2018 10:19 AM, 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>

📅 Original date posted:2018-02-12 📝 Original message: I was ...

2023-06-09T12:49:04Z

In reply to nevent1q…q2jl
_________________________

📅 Original date posted:2018-02-12
📝 Original message:
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 <payee>
to deliver Z, UNLESS stated otherwise by an invoice signed by <payer>

-- signed by <payee>

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 <payee> 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
<payee> to refund

-- signed by <payer>

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 settlement for invoices, just like the blockchain is for the other
channels in the route. IANAL, but I think the "scripting language"
accepted by courts is quite flexible, and you can use that to enforce
atomicity. With the construction described above, you can either refund
cooperatively (and collect evidence that refund has happened), or, if
that fails, go to court to enforce settlement there.

CJP

Op 12-02-18 om 10:23 schreef Christian Decker:
> CJP <cjp at ultimatestunts.nl> writes:
>> Can you give a use case for this?
>>
>> Usually, especially in the common case that a payment is done in
>> exchange for some non-cryptographic asset (e.g. physical goods), there
>> already is some kind of trust between payer and payee. So, if a payment
>> is split non-atomically into smaller transactions, and only a part
>> succeeds, presumably they can cooperatively figure out some way to
>> settle the situation.
> The scenario that is commonly used in these cases is a merchant that
> provides a signed invoice "if you pay me X with payment_hash Y I will
> deliver Z". Now the user performs the payment, learns the payment_key
> matching the payment_hash, but the merchant refuses to deliver, claiming
> it didn't get the payment. Now the user can go to a court, present the
> invoice signed by the merchant, and the proof-of-payment, and force the
> merchant to honor its commitment.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev