Good morning Nadav,
> Hi ZmnSCPxj,
>
> I find this idea super exciting!
Thank you.
I observe that this idea involves sending a key (`b'`) from buyer (who is
paying over the LN, i.e. payer) to seller (who is getting paid over the LN,
i.e. payee).
As it happens, with knowledge of the contract as well as a (possibly temporary)
pubkey of the buyer, the escrow can also provide this key if it decides in
favor of the seller.
I observe also that the Stuckless Payments proposal also involves a key being
sent from payer ("buyer") to payee ("seller").
Might it be possible to reuse the same key for both escrow and stuckless?
(we might have to separate the scalars used for decorrelation from the final
key used in stuckless / escrow).
>
> I think that the main wrinkle in what you've presented is how the Seller can
> verify that `B'` is indeed `ecdh(b, tweak(c, E))*G` since absent this
> authentication, the Escrow will be unable to provide the Seller with the
> necessary information to claim funds during a dispute.
>
> Perhaps there is some fancy ZKP that allows the Seller and Buyer to establish
> this alone but I don't know what that would look like. If it exists than that
> scheme would be better than the following but here are my thoughts:
>
> If we do need the Escrow to attest to the validity of `B'`, we want to make
> sure that the Escrow gains as little knowledge as possible. If we add a salt
> to the `tweak` function's hash (i.e `tweak(c, P, salt) = P + h(P | c |
> salt)*G`) and this salt is agreed upon by the Buyer and Seller (say for
> example, `salt = ecdh(s, B)`), then the Seller can tell the Escrow to compute
> `B'` given only `h(E | c | salt)` and `B` using `B' = ecdh(e + h(E | c |
> salt), B) * G`. In this way, the Escrow can validate for the Seller that `B'`
> is what it should be, while learning only a random hash (who's `salt` ensures
> no information about `c` is revealed), and a temporary public key, neither of
> which appear in any traceable way during a routed payment; certainly this is
> worse than no knowledge since the Escrow can compute `b'` and choose to cheat
> by giving this to the Seller, but I claim that this does not require more
> trust in the Escrow than is already being put in them. The only information ga
ined by the Escrow is that a payment is happening, and assuming that the
Seller contacts them over an onion-routed network (such as TOR), the Escrow
doesn't even learn any information about the Buyer or Seller's identities.
Although it would certainly be better to have the Escrow not even learn that
they are being used, this seems like a pretty acceptable amount of information
for them to learn, and has the potential benefit of ensuring that being a
trustworthy Escrow platform remains a sustainable (and competitive) endeavor,
even in the absence of disputes.
Indeed, this seems acceptable to me also.
Thank you for working this out, it seems feasible to me.
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
