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

```Good morning David and CJP,

Although we have determined that the David solution and all classes of that
solution are insufficient, it also triggered me to mentally compare the CJP
solution to the David solution.```
```
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)

But there is a way to safely loop through the end payee, and that is if the
final payee has insufficient knowledge to perform the claim unless it lets the
payment through via the loop.
Suppose we can somehow make a route that requires two secrets: a secret known
by the final payee (RM == OM) and a separate secret known by the "actual" payee
(S).

One way is to use points and scalars, another is to require two hashes from F
to OM to S, then a single hash from OM to RM (RM == OM).
Points and scalars are probably better since it obscures to intermediate hop
nodes whether they are before S in a cross-asset payment or not.

Below I describe the solution using points and scalars, and also including
decorrelation.
It should be trivial to convert it to two-hash form.

1.  First, F contacts the OM (i.e. the exchange, who is also the RM) to acquire
an exchange rate quotation.
The OM provides
1.  An exchange rate between BTC and WJT.
2.  An exchange fee.
3.  A one-time-use "exchange rate point".
4.  A signature of the exchange rate and fee, signed using the scalar of
the exchange rate point.
This proves that the OM knows the scalar of the exchange rate point.
2.  F creates a route from F to S via OM, and a route from S to OM.
The route from F to S should pay the desired amount to S, plus the routing
fees and exchange fee for the S to OM route.
3.  As is typical for decorrelation, for every hop (including itself as a hop),
F generates a random scalar.
F sums up the decorrelation scalars of various parts of the total route:
1.  F to OM: `f_to_om_scalar`
2.  OM to S: `om_to_s_scalar`
3.  S to OM: `s_to_om_scalar`
4.  F offers a payment to the first hop node (can be OM, can be an independent
hop node on BTC side) for the point:

f_to_om_scalar * G + om_to_s_scalar * G + s_to_om_scalar * G +
payment_point + exchange_rate_point

5.  When the payment reaches OM from F, it gets paid if it is able to acquire
the scalar corresponding to:

om_to_s_scalar * G + s_to_om_scalar * G + payment_point +
exchange_rate_point

6.  In addition, F adds to the OM onion hop packet the below information:
1.  `payment_point`
2.  `exchange_rate_point`
3.  The point sum of `(om_to_s_scalar + s_to_om_scalar) * G`
4.  A signature using the point `(om_to_s_scalar + s_to_om_scalar) * G` of
the serialization of the `payment_point` and `exchange_rate_point`.
7.  The OM verifies:
1.  That `exchange_rate_point` is a point corresponding to some exchange
rate quotation it issued before.
2.  That the exchange rate is still economically viable for it.
3.  That the sum of the `payment_point`, `exchange_rate_point`, and
`(om_to_s_scalar + s_to_om_scalar) * G` correspond to the point that OM will
need to learn the scalar of.
8.  The OM forwards the route (which is still opaque to it, thus cannot know S
or F) subtracting its decorrelation scalar.
9.  When the payment reaches S from OM, it gets paid if it is able to acquire
the scalar corresponding to:

s_to_om_scalar * G + payment_point + exchange_rate_point

10.  S then subtracts `payment_scalar` (which it should know, with
`payment_point = payment_scalar * G`) and its decorrelation scalar, and
forwards it to the next hop.
Note that S does not learn the identity of OM, and does not learn the
exact `exchange_rate_point`.
Only F knows who both OM and S are.
This is appropriate is it is the one that sets up all the routes.
11.  When the payment reaches OM from S, it gets paid if it is able to acquire
the scalar corresponding to:

exchange_rate_point

When a payment terminates at OM, OM checks if it is also one of its
exchange rate quotations.
If the exchange rate is still economically viable for it, then it claims
the payment.
If not, it fails the payment, probably with an error for F that the
exchange rate has gone out of synch and it should reacquire a new exchange rate.

Note that the OM cannot be fooled.
Suppose F == S.

1.  Suppose S does not forward, until a time when it is economically viable for
F == S to perform the American Call Option.
If it is economically viable for F == S to do so, it is economically
non-viable for OM to release its exchange rate point and it will simply fail
with "exchange rate deviated too far from quotation".
2.  Suppose S forwards immediately and learns the exchange rate scalar, then
waits for the American Call Option.
The payment S forwarded to learn the exchange rate scalar is the premium on
the American Call Option it has set up.
Thus the American Call Option is no longer premium-free and this attack
vector disappears.
The OM would willingly take the premium which it can now use immediately.

Now what are the advantages of this approach?

1.  The OM never learns exactly who F or S are, and thus is not able to censor
their transaction.
2.  There is no RM who is a trusted third party.
There is only an OM who F hires for exchange, and S who F wants to pay in
order to acquire some scalar proof-of-payment.
Thus, we can ignore all arguments for trusted third parties.
3.  Routing failures due to dead channels or insufficient capacity do not cost
anything to F, if F != S or are acting as separate entities.
4.  It's still possible to set up American Call Options, but they now have an
Indeed, the "exchange rate fee" can be a formula based on the value of one
of the assets, and the CLTV the exchange will incur, rather than some fixed
value.
In short, the exchange offers American Call Options by default, which can
be abused in order to make them into a payment from one entity to another,
rather than the reverse (the exchange offers a payment route, which can be
abused in order to make it into an American Call Option).

Thus, we should really move to points and scalars "soon", because decorrelation
and better proofs-of-payment.
We must be brave and face the three `OP_CODESEPARATOR`s needed for this.

Regards,
ZmnSCPxj

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, January 6, 2019 12:31 AM, David A. Harding <d...@dtrt.org> wrote:

> On Sat, Jan 05, 2019 at 07:01:18AM +0000, ZmnSCPxj wrote:
>
> > Good morning David,
> > What happens if the exchange node only sends its preimage towards the
> > payer and not towards the payee?
> > If the payer and payee do not coordinate, then it becomes possible for
> > the exchange node to take the funds without the payee gaining the
> > ability to claim the payment.
>
> Indeed, you are correct. I had not taken that into account. Thinking
> about it from that perspective, there's no way to depend on proof that
> the someone received something (e.g. a payment) without also allowing
> the receiver to block payment by refusing to provide that proof. That
> invalidates this class of solutions.
>
> Thanks,
>
> -Dave

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