A 3rd party pre image for an invoice tx between 2 parties, Application idea. \ stacker news ~bitcoin

A 3rd party pre image for an invoice tx between 2 parties, Application idea.

1522 sats \ 8 comments \ @AyCaramba 22 Jul 2023 bitcoin

Hi, I was reading the explanation of the HODL invoice (https://guide.bolt.fun/guide/invoices/hodl-invoice), where it says:

"With a hodl invoice there is also an additonal option where the recipient does not have to be the same person creating the payment hash for a given invoice they will generate (as is usually the case). They can also receive a payment hash from another party to create an invoice again where that other party would be the one that will hold the secret (preimage) for the hash until some condition is met and the secret is revealed which allows the invoice to be successfully settled."

I was thinking of an application that will create that pre image and that will settle a business transaction between two parties.

Example:

A wants to hire B for a parcel service. 2, B asks for $X in sats.
A agrees the price.
B requests the application to generate a payment hash. The application gives the payment hash to B. The application stores in a safe place the preimage and does not reveal it to anyone yet.
B creates an invoice for $X using that payment hash, and sends it to A.
A pays that invoice and the payment remains frozen until B reveals the preimage to A.
When the parcel service is made, A confirms the application that the service is completed.
The application reveals the pre image to everyone.
The payment is confirmed.

question 1: Is this possible to do this with any current lightning implementation (CLN, LND, Eclair)? question 2 : Does it require custom made or specific lightning wallets or it can work for people using like say Wallet of Satoshi? question 3: Is there a service today that acts as the described application?

I think this application can work ok since it will have no custody of funds at anytime. Also I explicitly avoided involving any third party decide disputes. The application will only hold profiles and reputations, no money, no personal info.

If my model is failing on something, please let me know, I am only a noob.

Thanks!!

view all related items

200 sats \ 3 replies \ @TonyGiorgio 22 Jul 2023

@super_testnet

0 sats \ 2 replies \ @AyCaramba OP 23 Jul 2023

Hey thanks, yeah I have seen @super_testnet work, it's awesome!. I hope he gives me some feedback. I am actually in a dilemma between these Hodl contracts/invoices stuff and just yielding to a 3rd party custodial (but legit) stuff, because I really do not want to bloat the routes with htlc's.

100 sats \ 1 reply \ @TonyGiorgio 23 Jul 2023

Yeah he'll probably have a ton to say if he sees this.

But yeah HTLC bloat is definitely a thing. Best if you have a direct channel with the sender for this.

0 sats \ 0 replies \ @super_testnet 23 Jul 2023

Thanks Tony! My reply is here: #212784

100 sats \ 3 replies \ @VzxPLnHqr 23 Jul 2023

What you are describing is, for the most part, doable on the lightning network as it exists today. In fact there have been some explorations and mailing list posts regarding using hodl invoices for a physical/parcel delivery protocol¹.

However, one thing that makes such a protocol difficult to utilize at scale in lightning today is that physical deliveries are often on the order of days or even weeks, whereas lightning invoices usually have shorter expiration times.

If long duration hodl invoices became a popular thing on lightning, intermediate routing nodes may be hesitant to forward payments unless/until they are adequately compensated. This is due to the limited number of unsettled htlcs a channel can have at any given time, so they are foregoing fee revenue in the interim. Maybe there are some ways to address these issues.

Now, to try to briefly answer your questions:

question 1: Is this possible to do this with any current lightning implementation (CLN, LND, Eclair)?

I have only tested hodl invoices with LND, but I think the other implementations now support generating such invoices.

question 2 : Does it require custom made or specific lightning wallets or it can work for people using like say Wallet of Satoshi?

For people paying the hodl invoices, it should work with pretty much any lightning wallet which follows the lightning specs. Some wallets might not have the UI setup to handle long expiration invoices though, so it might be clunky.

question 3: Is there a service today that acts as the described application?

Not that I am aware of, but I think it is a good idea and should be explored further!

https://github.com/VzxPLnHqr/discreet-physical-delivery-protocol ↩

0 sats \ 2 replies \ @AyCaramba OP 23 Jul 2023

Thanks for the reply!! Yeah the htlc bloating is an issue I have read a lot about in my research. Regarding the existing wallets, I would really need both parties' wallets to be regular ones (eg wallet of satoshi) so that means Hodl Invoices are really not an option for my concept (seller will be just a regular person, not a lightning node operator). Also onchain txs (using multisig 3-2 schemes) are not really a solution due to long confirmation times. For me a fast user experience is the key. Considering these restrictions, I believe my idea is not possible at this time. I will just explore the custodial solution (handling the money) using my infrastructure. I will collect no data anyway (use LNURL auth). I will make sure of setting it up as secure as possible. Anyway I do not expect large amounts .

240 sats \ 1 reply \ @super_testnet 23 Jul 2023

Your idea is possible without needing the seller to run a lightning node. Instead of having the seller create the hodl invoice, you can run a lightning node and create a hodl invoice. This doesn't mean the payment will come to you. Before creating your invoice, get a regular lightning invoice from the seller's ordinary lightning wallet, extract its payment hash, and use that payment hash in your lightning invoice -- which is a hodl invoice. Once that is done, the buyer can safely attempt to pay your hodl invoice, knowing that you can't settle it except by forwarding the payment to the seller -- i.e. by paying the seller's invoice. That action will get you the preimage you need in order to settle the buyer's payment, thus completing the circuit.

My hodlcontracts software is designed to automate some parts of this and make it easy.

Regarding htlc bloating, it is true that lightning node operators sometimes get mad when a payment has a really long htlc because such payments can lock up their liquidity for a long time. However, there are pretty good solutions out there for managing that. It is easy to configure your lightning node not to forward long htlcs, and you can even price them differently by setting up a low-fee node that won't forward long htlcs and a high-fee node that will. Each node's htlc duration limits are part of gossip, so wallets can easily detect if they need to create a long htlc and then seek routes that will forward it.

There are also ways to limit htlc bloating by introducing more messages. For example, a custom routing node can easily delay forwarding long htlcs until it gets a message from the seller saying they are ready to receive the payment. Once they get that message, they can forward the payment and expect instant settlement by the seller, thus avoiding imposing a lengthy lockup period on other routing nodes. People who want such a service could then send long htlcs with low bloat by opening a channel with that custom routing node and sending their payment through that channel. In that case, the only htlc slots that get locked up belong to the custom routing node, who explicitly permits this as a service and therefore (probably) charges a high enough routing fee to compensate for the time value their money loses while locked up.

Everything in the last paragraph is easy to do today with wallets that let users choose their channel counterparties, such as blixt wallet, electrum wallet, and zeus. Most popular LN wallets do not let you to manage your own channels, and thus they cannot take advantage of the above-described technique, but perhaps if such services became popular, the popular wallets would add support for it. In the mean time, you could just recommend better wallets for an optimal experience, but still -- even using a basic wallet with no channel management features -- such payments should work just fine, and if routing nodes get mad that their htlc slots get locked up as a result, they can increase their fees for long htlcs using the tools that are already available.

So don't give up on your idea! It is very possible to do today.

10 sats \ 0 replies \ @AyCaramba OP 23 Jul 2023

Hey! Thanks for the reply I agree the bloating problem is a node problem (I as a node operator can manage that). I did not know I can reuse a payment hash so that the payment will just bounce from me, that is neat! I was checking the hodlcontract repo, looks nice. I hope I will use it to setup a server. My idea would be to replicate your setup (LND + flask server in my private machine) plus a public web app in another exposed one so the idea would be to connect via rest API to the server. or another way I would like instead of the web app is just an Android app that will interact with the flask server itself. Thanks, I have enough here to start working.

BTW I only want this as a delivery service, since a guy who started a burger place (accepting btc) asked me to do a lightning solution for the delivery of food.

Footnotes