Author: Olaoluwa Osuntokun 2020-04-24 02:41:53
Published on: 2020-04-24T02:41:53+00:00
The deployment of Discreet Log Contracts (DLCs) has been hindered due to the difficulty in bootstrapping oracles, which are essential for the functioning of DLCs. The need for trust in centralized entities to prevent equivocation has made it challenging to deploy new oracles. Coinbase's recent announcement of a new price oracle for Ethereum could solve this issue as a trusted entity with a good reputation.Laolu suggests using base DLC-specific channels instead of complex barrier escrow scriptless scripts. This approach would simplify the design and implementation of DLCs. The Lightning Network community is encouraged to explore Payment Point Lightning Networks (PTLCs), which offer advantages over Hash-TimeLock Contracts (HTLCs).PTLCs allow for payment de-correlation along routes and enable a wide range of applications not possible with HTLCs. These include stuckless payments with proof of payment, escrow contracts over Lightning, and discrete log contracts on Lightning Network. The community is called upon to experiment with PTLCs before the availability of Taproot, which will enable the use of 2p-Schnorr adaptor signatures in Lightning channels.In the meantime, 1p-ECDSA adaptor signatures can be used by pairing them with OP_CHECKMULTISIG. Nickler has implemented this in a branch of secp256k1, and Lloyd has written about a way to do 1p-ECDSA adaptor sigs. A fork of one lightning implementation or Rust Lightning is proposed to be a proof of concept ECDSA-PTLC node that enables testing and playing with PTLC-based proposals. The required changes would include an update_add_ptlc with a 32-byte x-coordinate, commitment_signed with 162-byte adaptor ptlc_signatures, and simplified in-flight outputs on the commitment transaction itself.
Updated on: 2023-05-23T03:50:13.977530+00:00