Published on: 2019-10-24T06:39:27+00:00
The article discusses various ideas and proposals to improve the Lightning Network and enhance the functionality and security of lightning contracts. One of the main concepts explored is the use of lightning contracts with Payment Points (PP) and ECDHing. These contracts can be used for different purposes, such as Multisig, Escrow, and DLCs.The Escrow Contract idea is based on the point S + ECDH(B,E), where S represents the seller's point, B represents the buyer's point, and E represents the escrow's point. This allows for scalar discovery by the seller in collaboration with the buyer or the escrow, creating a condition of S AND (B OR E). Under certain circumstances, this can be extended to include payments conditioned on arbitrary AND/OR circuits. The implementation of AND circuits is straightforward, while OR circuits require multi-party key exchanges.Contracts following this scheme appear indistinguishable from normal payments on the network and are fully compatible with High AMPs. The author proposes two specific contract ideas: "MultiSignature" Lightning Contracts and DLCs Routed over Lightning.In "MultiSignature" Lightning Contracts, m-of-n parties must agree to the payment, and no actual signatures are used. For example, a 2-of-3 multisig between parties A, B, and C can be represented as (A AND B) OR (B AND C) OR (C AND A). The payment point used for the payment would be S + KE(A+B, B+C, C+A).DLCs Routed over Lightning involve Alice and Bob entering into a contract where Alice wins some amount if s_A is broadcasted and Bob wins if s_B is broadcasted. Alice sends a payment with the payment point A + S_A to Bob, and Bob sends a payment with B + S_B to Alice. If s_A is broadcasted, Alice gets paid (with Bob receiving proof of payment a), and if s_B is broadcasted, Bob gets paid (with Alice receiving b as proof of payment). The setup for DLC Routed over Lightning requires trust in an escrow entity who generates a point E for the payment, shifting trust from the counter-party to the escrow.The article also mentions the use of other features such as Payment De-correlation, "Stuckless" Payments, High AMP, Selling Signatures, Selling Pedersen De-commitment, and Escrow Contracts. These features are categorized into Proof of Payment (PoP) and Commitment Applications.Moreover, the participants in the discussion suggest contributing their ideas to the scriptless scripts repository to standardize terminology and notation in the scriptless space. They discuss various schemes and proposals, including barrier escrows, pointlocked branches, and premium-free American Call Option mitigation. The possibility of using the High AMP protocol in conjunction with Stuckless payments to enable atomic payments with known paths is also explored.Additionally, there is mention of a new language called Improv, similar to miniscript, that allows for the specification of spending rules in transactions. This language could be used to compile protocols for secure key and signature exchange. The participants plan to write up their ideas and add them to the scriptless scripts repository.Overall, the discussions revolve around improving the Lightning Network by exploring new ideas and proposals related to payment points, barrier escrows, complex access structures, and the use of scripting languages like Improv. The goal is to enhance the functionality and security of lightning contracts and enable atomic payments with known paths.
Updated on: 2023-07-31T22:10:55.062159+00:00