ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-01-08 📝 Original message: Good morning CJP, Sent ...
📅 Original date posted:2019-01-08
📝 Original message:
Good morning CJP,
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, January 8, 2019 10:26 PM, Corné Plooy <corne at bitonic.nl> wrote:
> 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)
This is the problem with David solution.
David solution requires that OM be the one that knows the preimage, and releases the preimage.
Thus, it serves as the equivalent to RM.
However...
>
> 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 [].
Indeed.
This is the problem with David solution.
> 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.
What I mean is that the transaction-payee S is paid, not by being the final payee in the route, but via the difference between its incoming and outgoing HTLCs.
So semantically S is the transaction payee, but in terms of route, RM is the final payee.
> 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.
There is another issue here.
By creating the role of RM, we enforce that American Call Options pay a premium.
F can route via OM to S, and S needs to forward to RM in order to acquire the preimage.
Once S has acquired the preimage, however, it can stall, and the HTLCs formed are still an American Call Option equivalent.
A price has been paid to acquire the preimage --- S had to forward value to RM to get the preimage.
This is equivalent to paying a premium.
This at least fixes the problem that OT no longer is capable of getting premium-free American Call Options.
But notice who the premium is paid *to*.
It is paid to RM.
It is not paid to OM, who is the one who loses if the American Call Option is exercised.
This is a rent paid by OM to RM.
This can lead to rent-seeking behavior from RM if RM != OM.
For instance, RM may acquire 8 random letters from /dev/random and start writing long articles about American Call Options on Lightning, as well as waxing lyrical about black swans and bleeder funds and cryptocurrency volatility, under those 8 random letters.
This encourages people to create American Call Options that pay a premium to RM while bleeding OM when the option is exercised.
What is pernicious here is that, even if we somehow derive some way of verification of RM behavior, on Lightning RM can behave perfectly correctly and release the preimage immediately.
But S can still stall once it has paid the premium and acquired the preimage.
Thus, RM != OM cannot be safe due to rent-seeking by RM.
Regards,
ZmnSCPxj
📝 Original message:
Good morning CJP,
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, January 8, 2019 10:26 PM, Corné Plooy <corne at bitonic.nl> wrote:
> 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)
This is the problem with David solution.
David solution requires that OM be the one that knows the preimage, and releases the preimage.
Thus, it serves as the equivalent to RM.
However...
>
> 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 [].
Indeed.
This is the problem with David solution.
> 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.
What I mean is that the transaction-payee S is paid, not by being the final payee in the route, but via the difference between its incoming and outgoing HTLCs.
So semantically S is the transaction payee, but in terms of route, RM is the final payee.
> 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.
There is another issue here.
By creating the role of RM, we enforce that American Call Options pay a premium.
F can route via OM to S, and S needs to forward to RM in order to acquire the preimage.
Once S has acquired the preimage, however, it can stall, and the HTLCs formed are still an American Call Option equivalent.
A price has been paid to acquire the preimage --- S had to forward value to RM to get the preimage.
This is equivalent to paying a premium.
This at least fixes the problem that OT no longer is capable of getting premium-free American Call Options.
But notice who the premium is paid *to*.
It is paid to RM.
It is not paid to OM, who is the one who loses if the American Call Option is exercised.
This is a rent paid by OM to RM.
This can lead to rent-seeking behavior from RM if RM != OM.
For instance, RM may acquire 8 random letters from /dev/random and start writing long articles about American Call Options on Lightning, as well as waxing lyrical about black swans and bleeder funds and cryptocurrency volatility, under those 8 random letters.
This encourages people to create American Call Options that pay a premium to RM while bleeding OM when the option is exercised.
What is pernicious here is that, even if we somehow derive some way of verification of RM behavior, on Lightning RM can behave perfectly correctly and release the preimage immediately.
But S can still stall once it has paid the premium and acquired the preimage.
Thus, RM != OM cannot be safe due to rent-seeking by RM.
Regards,
ZmnSCPxj