Escrow module

[dpc]

Status: Just an initial draft, starting point for discussion and design.

An escrow system is very useful for facilitating online exchange of goods over Internet.

The most basic overview is:

Buyer wants to buy something from Seller online and pay with Bitcoin/ecash. Since B and S can't trust each other, it's impossible to prevent fraud without introducing an intermediary of some kind, that should also be trust minimized as much as possible.

That's where the Escrow comes into place. The role of E is to handle disputes between B and S. They intentionally should not have any power or even knowledge of the transaction until dispute is triggered, and can't act on the funds in ways that were not pre-agreed by B and S beforehand.

A and B would need to agree on E beforehand. Possibly E could consist of multiple entities, or just one person.

Instead of paying directly B would deposit funds in an "escrow contract" involving B, S, E. Note that all parties are determined and locked in the contract upfront, thought possibly the identity of E, all even everyone could be blinded by using a preimage or some other crypto like that.

On a happy path (goods delivered), B will just release the funds to S, and E is not involved, and possibly not even aware of the transaction. In case of a dispute, after certain time period passed B or S would be able to trigger an arbitration: E would get involved, contact the parties, examine evidence, etc. and trigger one of: revert the funds to B (S fault, e.g. goods not delivered) , or send the funds to S (Bs fault). For their effort they would substract a fee that they keep.

Escrow's identity should typically be persistent over time, to allow building reputation. However this can happen outside of Fedimint's consensus: advertising escrow services, building review system, etc.

The escrow service should optionally support multiple Es with a threshold. Unclear how needed it is, but could be useful when dealing with low-trust environment. B could pick own preferred E_b, S its own preferred E_s and then some very_expensive and reputable neutral E could be added to the mix to break the ties between Es, etc. Or possibly 2 Es with a threshold 1 are used for redundancy and to speed up the process, etc. Again - unclear if needed or good idea. Typically 1 E would be good enough.

On a happy path instead of one Fedimint tx (like re-minting notes from B by S), there would be deposit tx mint notes -> contract by B and then contract + release-funds-hash + sig -> mint notes by S, where release-funds-hash can be passed from B to S out-of-band. So the overhead would be quite minimal. Though the exact design needs to be thought through end to end (end-user-app to end-user-app).

[BitcoinBrief]

@m1sterc001guy has a detailed escrow proposal, and Open Source Justice Foundation would love to see running code implementing it! Is there anyone else who would be willing to work on a project like this?

[dpc]

Looking at it, it seems to me that the goals and details might be slightly different there. But there is a lot of overlap for sure.