Implement full trustless escrow approach as in "hodlcontracts" for maker-buyers

[Reckless-Satoshi]

In order to understand this feature request you must first understand well the work done by @supertestnet in https://github.com/supertestnet/hodlcontracts

Background

It's becoming apparent that the current approach for fidelity bond / escrow with hodl invoices works very nicely in practice. Yet, one can argue the balance of power in this tri-partite relation is heavier in the service provider side: it is the recipient of the HTLC while also the generator of the preimage .

Oportunities

It will be, no doubt, difficult to improve this fact, specially without degrading the user experience. Yet, there is a specific case " a maker that is a buyer and is running LND " where the buyer could be directly the recipient of the HTLC but not hold the preimage (the preimage is given to him by RoboSats once the seller confirms he received the Fiat).

Why would a maker-buyer need to have LND? As of now, it is the only "wallet" that allows for hodl invoice generation in this specific setup. To understand the setup better check this video by SuperTestnet of the functioning of LightningEscrow.io.
https://www.youtube.com/watch?v=vvlOzEIPRws

Discussion

I do not exactly see how this feature could be used in the case of a seller-maker or a taker (any kind), as these are probably not going to be willing to spend the extra time to run a command line tool to interact with RoboSats.

If LightningEscrow.io releases a good API that could be easily be integrated into RoboSats backend, that would be fantastic. It would be up to users if they want to pay the extra cost for this feature to LNescrow.io . If integration of an existing API is difficult, the right way to proceed would be to fully implement the feature into RoboSats' backend.

This feature will be... hard to implement and maybe won't see much use (unless big liquidity providers join RoboSats and have devs available).So at the moment I am ranking it low in the list of priorities for implementation (just a personal opinion, totally open to change my mid) . However, I truly want to encourage anyone who want to jump into implementing it: it's one of the most exciting ideas around.

Thanks

Thank you very much to SuperTestnet & Tristan for the awesome contribution to the Lightning Network and the exciting discussions around the trust models in LN.

[supertestnet]

Thanks and congratulations on your launch!

Regarding the lightning escrow api, currently I am revising the api so that our server expects json encoded key/value pairs. Right now it expects html form encoding on most pages.

This revision is also an occasion for me to document the code and add support for long-duration api keys rather than 2 week long session keys, which is what I've been using up to now.

During our beta we don't charge a fee for makers or takers but later we will charge a 1% fee; the person creating the contract has to pick who will pay the fee, we don't currently offer an option to split it 50/50 but I will probably add that feature later.

Lastly there's the ux of using the terminal as a maker... Yes, that has been a huge turnoff for our beta testers and I want to get to a point where it's not needed.

To get there I think we need to make a wallet that automatically interacts with our api and knows how to create and settle hodl invoices. I am not sure I have the skills to make such a wallet so one option here is to wait for Tristan to acquire funding so that we can hire a developer to make the wallet.

Until then, using the terminal may be the only thing available, though I am currently trying to make a way to use browser-based submarine swaps as an alternative option, so maybe that will work sooner than we can hire a dev.

[supertestnet]

The api for lightning escrow is now documented:

https://github.com/supertestnet/lightningescrow.io/blob/main/README.md

I am happy to help you implement support for the api if you want help in that regard. Please reach out if you have any questions. I will just note here a few things to be aware of:

• We use different terminology regarding who is "buyer" and who is "seller." I always assume the person "selling" something is the one getting the bitcoin and thus the "seller" is the one who creates an invoice. But in your terminology most users are "buying" bitcoin and so the "buyer" is the one who creates an invoice.
• Also, the parts where the "seller" (in my terminology) creates an invoice, checks its status, and settles it can be tricky for users who don't know how to use the terminal. I'd love to work on some way to eliminate the need for that.
• Suggestions on how to improve the api and its documentation are welcome.

[Reckless-Satoshi]

Thanks a lot @supertestnet !

Indeed, I noticed our buyer/seller terminology is inverted. It would be amazing to have some support to implement the API on the backend of RoboSats. I could add it as a simple option in the "Advanced options for makers" #52

I am still hesitant over that one case where the buyer (RoboSat's BTC seller) opens a dispute exactly a block or two before CLTV expiry: I did not receive the goods (or fiat)" and how to deal with it.

[supertestnet]

Thanks a lot @supertestnet !

You're welcome :)

It would be amazing to have some support to implement the API on the backend of RoboSats. I could add it as a simple option in the "Advanced options for makers" #52

That sounds good, what do you think is the best way to work together on this? I am open to doing a zoom call to go over the best place to start. I think it would be best if the frontend checked whether something like "use lightning escrow" was checked in settings. If so, it should call the various endpoints of the lightning escrow api and then store state updates on your backend. MakerPage.js and TradeBox.js look like the best places to go to town on this, but unfortunately my react-foo is weak. I would appreciate some hands-on help with modifying those files (if they are even the places to start).

I am still hesitant over that one case where the buyer (RoboSat's BTC seller) opens a dispute exactly a block or two before CLTV expiry: I did not receive the goods (or fiat)" and how to deal with it.

Instruct the seller (RoboSat's BTC buyer) to set a long minimum cltv_expiry such as 10 days (1440 blocks). Then instruct the buyer (your BTC seller) to open a dispute within the first 8 days. That way you have 2 days to investigate the dispute. If there is no dispute opened in the first 8 days then automatically settle the invoice of the seller (your BTC buyer).

[supertestnet]

After considering it over the weekend I think your site should query the lightning escrow api on the backend rather than making users do it on the frontend. Users can do it on the frontend but then each user will need their own lightning escrow account, which increases the number of queries they will need to make in order to create a contract. Instead of that, perhaps your entire site should use one unique "robosats" account on lightning escrow. Then buyers (in your meaning of the term) only need to give you an invoice and later tell you their invoice's status. Your site can do all other queries for them and limit the number of queries required by not making a new account for each user (since you will use the same "robosats" account for everyone). Let me know what you think of that.

[Reckless-Satoshi]

Hey @supertestnet ,

Sorry for the delay to reply. I have been thinking deeply about this and the more I think the more I realize how much of a big undertaking this feature is :)

Indeed, the way to implement it is to have a single lnescrow account for 'robosats' that makes all of the requests. Users interact with it trough Robosats frontend. It will require some radical changes to the existing trade pipeline. It's a complete fork of how trades happen. The kind of escrow-type the order is, should be chosen at the step of order making.

MakerPage.js and TradeBox.js look like the best places to go to town on this

Yes! MakerPage.js and TradeBox.js are the two frontend element that will need to accommodate the new user facing pieces. I would take 100% care of them. However, the most work will be needed in the backend to accomodate the full trade-pipeline where all the usual checks for bonds locked, etc have to be replaced for calls to LNescrow. As of now I do not think I have any available time to work on the backend side, it actually sounds like an almost total rebuild of /api/logics.py and api/models.py's Order class. If you are brave enough to fork the backend to add a new trade pipeline that makes use of LNescrow tech would be amazing (warning: it really is a lot of work! two folds of work: first understand how it works now, then make it work with lnescrow api calls). I would deem this as highly experimental though. But then I would put the work on creating the user facing react components to interact with the new lnescrow enabled backend pipeline!

Instruct the seller (RoboSat's BTC buyer) to set a long minimum cltv_expiry such as 10 days (1440 blocks). Then instruct the buyer (your BTC seller) to open a dispute within the first 8 days. That way you have 2 days to investigate the dispute. If there is no dispute opened in the first 8 days then automatically settle the invoice of the seller (your BTC buyer).

Yeah, this makes sense. I am a bit troubled though with the time constrain to resolve disputes. Will be a problem without a doubt. In my short experience solving RoboSats disputes this is the most common case: 2 legit users who are totally right ( user A did send the fiat, user B never received it). First, it takes a few days of back and forth to discover they both are right. Then, the problem: a payment rail that does not do the job right. Can be solved by the users calling support of the payment platform and waiting long periods (over 1 week already for some disputes), but it is unclear to which direction the payment provider will resolve. I think some disputes might not be solvable at all in less than 1 month. To start, the very first step to discover if users are not lying, might even require a videoconf with the users and some scheduling (there it goes +2 days).

I am also seeing a lot of unavailable routes and overall high difficulty to route HTLCs with a total locktime over ~4-6 days. In fact many wallets won't even allow it (e.g., Phoenix). So increasing the CLTV does not sound like an option; in fact, I would like to decrease it as much as possible in a safe way. Have you crawled the LN graph to see what is an acceptable CLTV upper value? Would be super useful (and a piece of critical information for both models robosats and lnescrow).

[Czino]

We are facing the exact same challenge at peach. Just drafting out different mechanisms we could apply. Having the buyer generate the hold invoice while the escrow generates the pre-image and only shares the hash is preferable for us.

UX

Since peach aims to be easy to use and already has a bitcoin wallet (which greatly helps automising escrow and address generation) we also want to include lightning capabilities.

The solution to the UX problem (users don't want to do terminal stuff) seems to be very close if we implement breez-sdk on the frontend. Only feature still missing are generating and settling of hold invoices.

Expiry

The CLTV delta question is indeed a tough one and one of our main concerns as well. Even if we get an expiry of 14 days, not all disputes, as you already mentioned @Reckless-Satoshi, can be solved quickly.

Have you found an answer towards what an acceptable CLTV is? I suppose it might also be subject to change over time as the network matures.

I received note from BitEscrow (formerly Lightning Escrow) that they will go with 10 days. I am assuming tests have been made and payments successfully routed.

[Reckless-Satoshi]

Have you found an answer towards what an acceptable CLTV is? I suppose it might also be subject to change over time as the network matures.

I find that wallets using trampoline nodes (e.g. Phoenix) have a CLTV limited to ~300-500 blocks. All in all, you start finding issues at ~3 days (wallet side, will not even attempt paying the invoice) or general network routing issues starting at ~5 days (you can pay the invoice, but gets harder to find routes). Over 6 days is doable, but you will find some routes are already not possible.