An update on PTLCs

Summary:

The Lightning Network is a payment protocol that operates on top of Bitcoin and is designed to facilitate fast and cheap transactions. One of the challenges in developing the Lightning Network is ensuring security and privacy while maintaining speed and efficiency. The use of Point-TimeLock Contracts (PTLCs) instead of Hash-TimeLock Contracts (HTLCs) in Lightning Network payments is seen as an improvement, as it allows for payment de-correlation along routes, which improves privacy and protects against wormhole attacks.Furthermore, PTLCs enable a variety of interesting applications, such as stuckless payments, escrow contracts over Lightning, high/DLOG AMP, pay-for-signature, and atomic multi-payment setup, among others. While some believe that bootstrapping the oracles has been the real impediment to Discreet Log Contracts (DLC) deployment, the original protocol requiring three on-chain transactions, asymmetric state and punishment transactions, and the potential for errors have also slowed progress. In contrast, the PTLC-based DLC only requires two transactions and symmetric state, making it more attractive for users and developers.Nadav Kohen provides an update on replacing HTLCs with PTLCs and lists various benefits of using PTLCs for Lightning Network payments. Nadav intends to implement a PoC sandbox to test out theoretical proposals surrounding PTLCs before Schnorr is implemented. However, he underestimates the degree of synchronization required to pull off the necessary changes to existing nodes, including the core channel state machine, HTLC scripts, on-chain HTLC handling and resolution, path finding algorithms, invoice changes, and onion blob processing.Implementing PTLC-based lightning channels requires significant changes to the core channel state machine, HTLC scripts, on-chain HTLC handling and resolution, path finding algorithms, invoice changes, and onion blob processing, which may take longer than expected. Moreover, while ECDSA-based techniques are simpler than prior ones, they still use OP_CMS and are not compatible with modifying the funding output, so dual deployment is currently the best approach.The Lightning Network is set to utilize 2p-Schnorr adaptor signatures once Taproot is established. Until then, a 1p-ECDSA adaptor signature method has been developed by Lloyd, which allows for PTLCs on Bitcoin today when paired with OP_CHECKMULTISIG. Nickler has implemented this in a branch of secp256k1, and it has also been implemented in Bouncy Castle in Bitcoin-S. The crypto itself has been described in a write-up by waxwing. A demo of an on-chain PTLC executed using nickler's implementation on the backend with bitcoin-s can be seen in a video. The hope is to create a PTLC-based Lightning Network that is safe and stable as soon as possible, and further development and experimentation with PTLCs is encouraged ahead of Taproot's establishment. Some changes will need to be made to existing nodes to support PTLCs, such as updating add_ptlc and commitment_signed functions. Dual deployment may be necessary as there is a risk that Schnorr will become available mid-development.

Updated on: 2023-06-03T01:01:53.409073+00:00