Escrow services

[PatrickGeyer]

What's the best way to integrate escrow services into Nostr apps?
They're going to be needed for a variety of apps (Marketplace, Uber deposits, AirBnB bookings...), it would be good if there was a standard for using escrows. Nostr apps shouldn't hard-code a specific escrow service, but probably should discover available escrows on the network. The escrow should broadcast what types of transactions it brokers, and what kind of fee it takes, and any additional information.
Then buyer/seller can agree on escrow and proceed with transaction.

In most cases we probably don't want the escrow to actually have custody of any funds, so are there multiple mechanisms for achieving that? HODL invoices for example? Could we then have Nostr events broadcast for when the escrow service has received the payment, but hasn't forwarded it, so that the seller can be sure that the buyer's money is safely in escrow?

Apologies if there has already been discussion on this, am new to the space.
If this isn't the right place for this convo, where should I go to find out more?

[ekzyis]

Escrow services on nostr are a very good idea!

I was also thinking about this lately.
Imo, the main disadvantage of p2p trading vs. trading using centralized services is that the third party can act as an arbiter during dispute.

However, using nostr, a reputation-based market for arbiters could evolve. Funds can be hold in a 2of3 multisig where each party holds one key.

The trading parties would be incentivized to act honestly or the arbiter will be able to choose who will receive the funds.

This assumes that the arbiter is neutral and was not chosen by any party in advance.
The best case would be if the arbiter is chosen randomly where arbiter with more "reputation" are preferred and doesn't know anything about the trading parties (anonymous trading).

However, I don't know how an arbiter can gain reputation. Since an arbiter only takes action during a dispute, there will most likely always be one side which will most likely "upvote" and one side which will most likely "downvote" the arbiter.

Just writing my thoughts down in here with the hope that someone else can chime in here :)

2of3 multisig however assumes onchain transactions.

I don't know a lot about HODL invoices but on first view, they don't seem suitable for escrow. However, I know that robosats uses them as bonds. Maybe we can copy something from there since robosats also acts as escrow.

[weex]

A few years ago (pre-lightning) I created an escrow system that utilized two multisigs.

One was a standard 2-of-3 where each party held a key. This was for the main payment to the seller/worker.

The other was of the form ((A or B) and C) which held the escrow agent's fee. This construction made sure the agent gets paid if at least one party cooperates. It also ensures the buyer and seller don't take that fee for themselves.

This was all accompanied by a ratings system. I shelved the whole thing when fees got too big and can see now with lightning and Nostr this kind of thing could work. The main question is what's available in terms of lightning escrow construction.

[PatrickGeyer]

I think in theory HODL invoices work fine for escrow. In practice, there's a few issues:

1. The amount of capital locked for each escrow transaction is transaction size * number of hops between seller/buyer/escrow node, as each HTLC locks up the transaction amount in that channel, and can't use that liquidity for other transactions.

2. HTLC timeout not checked by lightning node implementations. Since most nodes on lightning assume preimages are sent back instantly, they don't price their channels by HTLC time lock. I don't see why we couldn't add a parameter to say that you won't accept HTLCs with timeouts more than 1 day, but if you do, you price that in and establish a market for HELD transactions as well.

3. Out-of-band payments for reversed transactions. If the trade between seller/buyer is disputed and the payment is reversed (i.e. never completed) then the escrow doesn't collect the transaction fee. Therefore there needs to be an out-of-band payment to the escrow so that they get paid regardless of transaction success or reversal.

4. Max in-flight HTLCs. If a wallet has 100,000 users and 10% of them have a deposit inflight to a marketplace or AirBnB type app using HODL invoices, then 10,000 HTLCs will be 'in-flight'. Currently there is a max HTLC limit of 480ish due to the max transactions size that can be published on-chain. I suppose this would mean that a wallet that wants to allow users to do escrow transactions would need to open multiple channels, such that each can fill up with 480ish HTLCs.
   I don't know how this changes if PTLCs are adopted? Anyone know?

So it seems there are a few major hurdles to realizing this idea, but it's still more realistic than every wallet adding Liquid support (which would mean we could just do easy and cheap-ish 'on-chain' escrow).
So I'm still optimistic we can make a rudimentary version of lightning escrows and build resiliency from there, but not 100% confident on that.

[weex]

Good points. Thanks for raising them for discussion.

1. The amount of capital locked for each escrow transaction is transaction size * number of hops between seller/buyer/escrow node, as each HTLC locks up the transaction amount in that channel, and can't use that liquidity for other transactions.

That can be a big cost. Do you have a sense of how many hops most HODL invoices involve? Was introduced with the general LN in mind or more like an Upwork where you'd be required to open a channel with them to do business.

2. HTLC timeout not checked by lightning node implementations. Since most nodes on lightning assume preimages are sent back instantly, they don't price their channels by HTLC time lock. I don't see why we couldn't add a parameter to say that you won't accept HTLCs with timeouts more than 1 day, but if you do, you price that in and establish a market for HELD transactions as well.

Also a valid concern, has this been raised in BOLTS or in lnd/clightning?

3. Out-of-band payments for reversed transactions. If the trade between seller/buyer is disputed and the payment is reversed (i.e. never completed) then the escrow doesn't collect the transaction fee. Therefore there needs to be an out-of-band payment to the escrow so that they get paid regardless of transaction success or reversal.

Again, an issue that grows with number of hops.

4. ...

That'd be a great problem to have, probably best to worry if we ever got there.

[earonesty]

you might want to check out https://celebrityescrow.org/ for an example of using nostr for escrow. code is here: https://github.com/ArcadeLabsInc/celebrity-escrow. also, it works.

[PatrickGeyer]

@earonesty looks like that's onchain? We're looking for a lightning solution.

[earonesty]

oh, yes, then you're limited to a 2 week escrow, hodl invoice, and smaller amounts.