Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Escrow service #5

Open
PatrickGeyer opened this issue Apr 20, 2023 · 2 comments
Open

Escrow service #5

PatrickGeyer opened this issue Apr 20, 2023 · 2 comments

Comments

@PatrickGeyer
Copy link

Escrow will be needed for all sorts of Nostr apps.
Maybe we can work on a spec to broadcast an escrow service.
Then seller/buyer can agree on escrow and go from there?
Is there any discussion on this already?

@nobu-maeda
Copy link
Owner

In a way when I tried to split the difference between n3x and n3xB, I was thinking of n3x being a generic bonding/escrow/coordination/arbitration layer to facilitate generic trades between a maker and a taker. While n3xB makes it specific to Bitcoin/Fiat trades. Not that I think whats in the proposal right now as written is any good in doing this.

Perhaps if you have more concrete examples of what you are thinking of, it'll help better conceptualize where separation of concerns should be.

Just to be clear tho, a Bisq like trade system actually does not have escrow, just arbitration, due to the usage of Bitcoin multi-sig scripts.

Where-as RoboSats/Mostro like system do actually have a 3rd party coordinator doing escrow, which I don't like as much as there's more trust involved for every trade. And in a way the escrow is a temporary custodial service.

But ideally, the protocol layer and the global order-book should facilitate all sorts of trade/bond/arbitration mechanics. And let the most popular trade type win through free market competition. Instead of building silos of a specific trade mechanics, 3rd party clients can choose, or even choose multiple trade types to support. This is mostly int he context of Bitcoin fiat trade tho. Still want to see what concrete market demand there is for non-Bitcoin/fiat type need for escrow, etc.

@PatrickGeyer
Copy link
Author

In the case of nostr-based AirBnB:

  1. Seller posts listing of address and specifies which escrow services are available to use. So in the metadata for listing might have tag "escrow": [{"type": "hodl invoice", "node": "escrowlightningpubkey"}]
  2. Buyer finds listing of airbnb address, is happy with the provided escrow service and issues request to seller for certain dates.
  3. Seller communicates with escrow node (with nostr backend) to create hodl invoice.
  4. Buyer deposits sats into the hodl invoice.
  5. Seller issues accepted event for those dates, so that other clients know the venue is booked for those days.
  6. A week or so after the booking dates pass, the HODL invoice completes, or an issue is raised with escrow service prior.

I would have thought it would be good if escrow services could emit nostr profile pages, just like users, where they can specify

{
"id": "nostrpubkey",
"alias": "Escrow Name",
"website": "www.my-escrow-details.com",
"methods": [{"type": "hold-invoice", "nips": [what type of trades does this escrow arbitrate? AirBNB? Marketplace? Uber rides?], "node": "ln-pub-key", "fee": 0.01},...]
}

That way the seller could just post their AirBNB listing with the tag "escrow": ["npub1", "npub2"].
Can this already be done with n3x? Why do you say "Not that I think whats in the proposal right now as written is any good in doing this"?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants