Escrow Over Lightning?



Summary:

In a Lightning-dev mailing list, a proposal was made to change the spec and add a new BOLT so all lightning implementations could support a feature. The proposal suggested using PTLCs instead of HTLCs which would be possible with Taproot. This change is not specific to this protocol and only the end nodes (buyer and seller) would need any special code to execute these contracts if the underlying Lightning Network was using PTLCs. An interactive shared secret generation between buyer and escrow could allow spontaneous payment to the seller. The scheme requires special code for the end nodes and relies on the existence of a Zero Knowledge Proof of Knowledge of a hash. Another construction called “Bitcoin-compatible Virtual Channels” was discussed in the same thread. It highly resembles the use case and requirements put forward in the thread. A virtual channel is built on top of two payment channels and uses them to construct its funding transaction. The construction is compatible with the current Bitcoin script and the Lightning Network. The construction makes sure that no party loses funds when the virtual channel needs to be closed.A question was raised regarding virtual channels where it was pointed out that the intermediary has to lock up a lot of collateral (in total, the size of the channel). The channel could stay open for a long time and the intermediary will charge a high fee for both setup and duration of the channel. The use cases for this were discussed and it was suggested that its use might be preferable to just routing payments the normal way other than if the in-between node is not reliable and there are no other cheap routes.


Updated on: 2023-06-02T18:54:32.772334+00:00