With the expansion of the nostr community, it is easy to think about an entire new household of apps being created that might work in a decentralized method (Marketplaces, AirBnB, Uber). However for these apps which require a sort of deposit, an escrow system could be wanted.
And identical to relay addresses do not need to be hardcoded into Nostr apps, it needs to be potential to not need to hard-code trusted escrow companies into apps, such that completely different implementations can uncover mutual trusted escrow nodes in a real-time style.
I might think about {that a} NIP could possibly be created describing how escrow nodes might broadcast their companies, such that two completely different market apps being utilized by purchaser/vendor might dynamically uncover out there escrow nodes to facilitate the deposit cost. If we do not wish to resort to base-chain multi-sig, or require wallets so as to add help for obscure side-chains, evidently HODL invoices on the lightning community might obtain this in a non-custodial approach, both forwarding the cost on success, or reversing the cost if the commerce is disputed by the customer.
I do know that there are technical limitations to HODL invoices, akin to the truth that they trigger funds to get caught and that every channel can solely have a sure variety of open HTLCs, however I wish to know if there’s a problem that may make it actually unattainable to realize this. The issues are as follows:
-
Max cost timeout: HODL invoices are potential for two weeks and below, however is there a motive that they can’t be held for six months, if attempting to pre-book a resort room for instance.
If there is not a technical motive for not with the ability to maintain funds for arbitrary period of time, why would it not not be potential for channels to cost themselves by how lengthy they’re keen to lock funds for a selected cost?
Plainly the community for fast funds might keep practical, the place nodes cost small charges to route funds that timeout after 1 day for instance, however different channels supply to route funds with a 1+ month timeout, however cost sizeable charges for locking up liquidity for that lengthy. Why would it not not be potential to have a part of the lightning community optimized and priced for fast funds, and different channels optimized for longer pending ‘deposits’ and the 2 working symbiotically with out impeding the opposite’s capabilities? -
Max concurrent HTLCs. Appears like escrow nodes might solely maintain 483 concurrent deposits at a time as a result of max measurement of bitcoin transactions. However does that imply that with some easy automated node administration, an escrow node might open extra channels to multiply the variety of concurrent HTLCs in complete? Would eventual transition to PTLCs up the restrict of inflight funds in any respect?
-
Lastly, and least importantly, when a purchaser is requesting the long-lasting cost bill from the vendor, there must be a option to specify an extended expiry. Present lightning-address functionality does not appear to help this, however probably the endpoints at the moment used for zaps could possibly be used with some comparatively minor? changes.
All in all, is that this a no-go? Not potential? How else can we allow non-custodial escrow on nostr with out resorting to base-chain or side-chains?