Published on: 2021-02-27T11:05:14+00:00
In a recent discussion on the Lightning-dev mailing list, ZmnSCPxj proposed a new idea for smart contracts using Payment-Point Time-Locked Contracts (PTLCs). The current issue with PTLCs is that the use of '&&' is easy while '||' requires more complex operations. To address this, ZmnSCPxj suggested inverting the logic by making two payments: Seller -> Buyer claimable by BUYER && ESCROW, and Buyer -> Seller claimable by SELLER. If the buyer is satisfied, they fail the Seller->Buyer payment after the seller claims the Buyer->Seller payment. If the buyer is dissatisfied, they can involve Escrow for arbitration. This proposal effectively flips the logic by using De Morgan's theorem. It also provides proof-of-refund for the seller and proof-of-payment for the buyer.In another conversation, Pedro and Nadav discussed the concept of virtual channels and the role of the intermediary, Ingrid. Ingrid needs to hold a certain amount of coins to facilitate the virtual channel between Alice and Bob. The protocol ensures that Ingrid will be paid the fee she charges for creating the virtual channel. However, there is no guarantee that enough payments will be routed through her node to earn the same fee in a timely manner. Pedro clarified that if Ingrid charges a fee, Alice and Bob would open a virtual channel only if the total fee they would pay is higher than a certain threshold. The use cases for virtual channels include trying out a web service or utilizing micropayments for services. Pedro welcomed suggestions for other use cases.On the Lightning-dev mailing list, a proposal was made to change the Lightning Network specification to support Payment-Point Time-Locked Contracts (PTLCs) using Taproot. The proposal suggests using PTLCs instead of Hash-Time Locked Contracts (HTLCs) and introduces the concept of Stuckless Payments. The aim is to enable spontaneous payments between buyer and seller by sending a key over the Lightning Network. The proposal also discusses "Bitcoin-compatible Virtual Channels," which can be built on top of payment channels and ensure that no party loses funds when the virtual channel needs to be closed. There is also a discussion about the collateral requirements for intermediaries in virtual channels.In a separate conversation, Pedro Moreno-Sanchez introduced his work on "Bitcoin-compatible Virtual Channels," which aligns with the requirements discussed in the thread. The virtual channels are constructed using two payment channels and allow direct payments between parties without involving an intermediary for each transaction. The construction is compatible with the current Bitcoin script and the Lightning Network. Another member of the discussion raised a question about the high collateral requirement for intermediaries in virtual channels, which could result in long durations and high fees. The use cases for virtual channels were explored, suggesting that they might be preferable to routing payments in certain scenarios.A discussion thread on the Lightning-dev mailing list involves the idea of escrow over the Lightning Network. The conversation revolves around the possibility of reusing a key for both escrow and Stuckless Payments while maintaining privacy and security. One solution proposed is adding a salt to the hash function's tweak to ensure as little knowledge as possible is gained by the escrow. Although it would be ideal for the escrow not to learn that it is being used, the proposed compromise still ensures escrow privacy and sustains trustworthiness. Overall, the proposal seems feasible and acceptable to both parties involved.Another topic discussed in the thread is the implementation of escrow over Lightning. The proposal aims to enable trades between entities who do not trust each other using a common escrow. A 2-of-3 multisig contract is suggested, but it can only be transported over a single Lightning channel. The proposal emphasizes the importance of the escrow not learning about the trade unless a dispute arises. It also discusses optimization under bip-taproot and highlights the need for trust in the escrow's integrity.The author explores the implementation of escrow services over the Lightning network and proposes a non-custodial on-chain protocol using a 2-of-3 multisig contract involving the buyer, seller, and escrow. However, there is a challenge in safely hopping the escrow across channels without putting hop nodes at risk.Escrow services are particularly useful when Bitcoin needs to interact with other systems and trust in a brandless entity is difficult to establish. To address this, the author suggests a contract where a brandless buyer (B) pays a brandless seller (S) with trust in a common branded escrow (E). In case of a dispute, E decides whether B should be refunded or S should be paid. Importantly, the escrow remains unaware of the trade unless a dispute arises between the buyer and seller.
Updated on: 2023-07-31T21:42:34.777176+00:00