[Lightning-dev] Escrow Over Lightning?
nadav at suredbits.com
Thu Jun 27 17:40:13 UTC 2019
I find this idea super exciting!
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
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 gained 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
On a somewhat unrelated note, I just want to throw out there that it may be
simpler to have a scheme for routing Discreet Log Contracts over the
lightning network for the kinds of simple oracle contracts like "seller S
will deliver 100 pieces of USA federal reserve commemorative decoration
paper in exchange for 1 satoshi from buyer". Using a DLC would have the
benefit of requiring no interaction with the oracle (excluding broadcast
which is fine) during dispute settlement. Just a thought :)
On Thu, Jun 20, 2019 at 12:54 AM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Good morning list,
> One thing I am attempting to think through is some implementation of
> escrow over Lightning.
> A non-custodial onchain escrow protocol simply uses a 2-of-3 multisig
> amongst the two participants and the escrow.
> Such a contract (like any onchain-enforceable contract) can be transported
> over a *single* Lightning channel, but cannot be safely hopped across
> channels: the escrow may take "one" side in one channel while taking the
> "other" side on the other channel, thus putting every hop node at risk.
> Escrow services are useful when Bitcoin needs to interact with other
> systems, such as the mythical "real world", when tr*st in a brandless
> entity is difficult to procure, while some escrow service can aggregate and
> reuse tr*st in its brand to enable trades between brandless entities.
> Thus if at all possible, we should consider how best to support escrow
> services over Lightning.
> I formulate the contract below:
> * A brandless buyer B wants to pay a brandless seller S for a service or
> * Both B and S have non-trust in one another, but can agree to tr*st a
> common branded escrow E.
> * B shall pay S if both B and S can agree that the service was rendered
> satisfactorily or product was delivered.
> * In case of dispute, E decides whether S is paid or B is refunded.
> * B and S want to provide as little information to E as possible if both B
> and S can come to an agreement (i.e. only reveal information if a dispute
> Tr*st is still needed in E.
> In particular, B and S both trust that E will not be susceptible to
> bribery from their counterparty.
> The above can trivially be implemented onchain using a 2-of-3 multisig.
> 1, The branded escrow E provides a public key as part of its brand.
> 2. B and S generate a short contract description of the service or
> product to be rendered, in a language that E understands.
> 3. B and S tweak the escrow public key (if `E` is the escrow pubkey and
> `c` is the description of the service/product, use `E + h(E | c) * G`).
> 4. B and S generate a 2-of-3 address using their own keys, plus the
> tweaked escrow public key.
> 5. If B and S can come to an agreement, then they sign using their own
> keys, and the third key (the tweaked escrow key) remains tweaked and E
> cannot determine that it could have been used as the escrow, or the details
> of the transaction, even if it monitors the blockchain (since its key is
> not used directly, instead a tweaked version is used, and the tweak is not
> revealed E if B and S are in agreement).
> But if B and S come to a dispute, either can provide E with the
> agreed-upon description `c` that is committed to onchain, and lets E judge
> where the payment should go.
> Under bip-taproot this can be optimized somewhat in favor of the "no
> dispute" case by setting the taproot internal key to `MuSig(B, S)`, and
> having separate MAST branches for `MuSig(E + h(E | c) * G, B)` and `MuSig(E
> + h(E | c) * G, S)`.
> This use-case is important: consider the case where the seller is selling
> pieces of decorated paper mass-printed by some centralized financial
> For face-to-face transactions, it is enough for all of the participants to
> appear and for the Lightning payment to be attempted and so forth.
> But for non-face-to-face transactions (such as when one participant is
> secretly an AI that is attempting to take over the world, and is currently
> unable to puppet some meatspace representative), such escrow would be best
> done online with no requirement of physical presence.
> Naively, it seems that switching to payment points / scalars from payment
> hashes / preimages (a necessity for payment decorrelation) may work.
> It may be possible to use some kind of verifiable secret sharing.
> However, I would like to make the following points possible:
> * The escrow does not learn about an escrowed trade unless a dispute
> between buyer and seller occurs.
> * The escrow is capable of returning the buyer funds immediately as soon
> as it can resolve the dispute without timing out the payment.
> * Intermediate hop nodes that are not the buyer, seller, or escrow, remain
> unaware of the escrowed trade (ideally, if they support the "normal"
> payment points / scalars system, they should not need any special support
> for escrowed trade).
> Let me sketch below something, which might not work since I have not
> actually learned verifiable secret sharing at all.
> In particular, if verifiable secret sharing requires that the participants
> including the escrow to set up the payment point interactively, this fails
> the first desired item, that the escrow only learns of the escrowed trade
> in a dispute case.
> (i.e. a real mathist should actually check this.)
> I will ignore here temporarily the issues of payment decorrelation, and
> pretend that the same point is used in the entire path.
> Before all this, E publishes its escrow key `E`.
> First, B and S generate temporary payment points and scalars, `B = b * G`
> and `S = s * G`.
> Then they agree on the contract `c` describing their agreement, in a
> language that E understands, e.g. "seller S will deliver 100 pieces of USA
> federal reserve commemorative decoration paper in exchange for 1 satoshi
> from buyer".
> Then B generates an ECDH shared secrets between escrow and buyer:
> tweak(c, P) = P + h(P | c) * G
> ecdh(a, B) = h(a * B)
> b' = ecdh(b, tweak(c, E))
> B' = b' * G
> S' = S + B'
> The payment point used in the payment route is `S'`.
> B provides `B` and `B'` to S (this can be done using TLV in the onion
> Of course, we also need to provide a proof that `B' == ecdh(b, tweak(c,
> E)) * G` where `B == b * G`.
> I have no idea how easy (or impossible) it is to make such a proof
> (without E having to attest to it).
> If S believes it has fulfilled the contract and delivered the product or
> service, it contacts B.
> If B is satisfied with the product or service, it provides `b'`, allowing
> S to compute `s + b'` needed to claim the payment point `S + B'`.
> In the non-dispute case, E never learns that it could have been the escrow.
> B receives the scalar `s + b'` from the payment, but it knows `b'` and can
> compute the scalar `s` which now serves as proof-of-payment.
> If B is unsatisfied, we have a dispute condition and S contacts the escrow
> S provides `B` and the contract `c` to the escrow.
> ECDH allows E to determine `b' = ecdh(e + h((e * G) | c), B)`.
> If E decides in favor of the seller, then it reveals `b'` to S, which can
> then compute `s + b'` and claim the payment point `S + B'`.
> However, note that if E decides in favor of the buyer, it cannot do
> anything other than let the payment timeout lapse, which automatically
> forces the seller S to fail the HTLC.
> I cannot derive a way for E to force S to fail the HTLC, without revealing
> to intermediate hop nodes that this is an escrow payment.
> Even if E is the only intermediate hop node between B and S (an
> undesirable situation since it allows E to censor and surveil the payments
> between B and S), it is not safe for E to fail its incoming PTLC until S
> has failed its incoming PTLC, as otherwise B and S could be coordinating to
> steal from escrow E.
> There are likely to be better schemes.
> Again, the ideal scheme would provide:
> * Escrow only learns of dispute cases, never learns non-dispute case.
> * Buyer can recover funds immediately as soon as escrow decides in favor
> of buyer. <- this seems difficult/impossible under LN.
> * Intermediate hop nodes are unaware of anything special with the payment.
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Lightning-dev