OpenCAP alias integrations with invoices/destination [combined summary]



Individual post summaries: Click here to read the original discussion on the lightning-dev mailing list

Published on: 2018-12-08T19:13:59+00:00


Summary:

Laolu and his friends are working on a protocol that allows users to host crypto public addresses using a standard DNS lookup schema. They hope for the adoption of this protocol, which offers advantages over OpenAlias. They are also considering enabling users to post lightning invoices but acknowledge the challenge of generating unique invoices for each payment. The author seeks thoughts on this matter and provides links to the protocol, implementation, and open source implementation.On the Lightning-dev mailing list, discussions are centered around path decorrelation and rendezvous routing. Participants aim to make the Lightning Network protocol more flexible and avoid re-signing DLC subcontracts by utilizing `SIGHASH_NOINPUT`. The introduction of Fulgurite in the Lightning Network protocol is aimed at enhancing the flexibility of information exchange in channels. However, it adds complexity, particularly in the case of multiparty channels. It is better to address CSV requirements early on as they affect timelocked contracts. Timelocked contracts must be published on-chain before the timeout expires, and an N-block CSV requirement means publishing N+1 blocks before the absolute timelock expires. Fulgurite subchannels are expected to have fewer participants than their parent channels. Moving time-sensitivity to Fulgurite rather than higher levels is recommended.Fulgurite generalizes Lightning shared-ownership update systems known as "channels" and allows for the inclusion of other "shared-ownership update systems". Discussions on the Lightning-dev mailing list focus on the use of these systems and their subsystems. Concerns are raised regarding the safety of non-custodial use of such systems, as participants may not have the power to refuse signing off on an invalid state transition. The idea of two-party shared-ownership update systems ("channels") is proposed as it requires everyone's signature, reducing points of failure. Burchert-Decker-Wattenhofer channel factories are suggested as they allow for absent participants without affecting their channels. Existing update protocols can carry various Bitcoin-enforceable contracts, including those used to enforce them. This nesting capability is demonstrated in Burchert-Decker-Wattenhofer or parent and child channels. However, it is important to note that certain details, such as the additional CSV imposed by Decker-Wattenhofer and Decker-Russell-Osuntokun on transported contracts, and the limited transportability of contracts across systems, should be considered. Paying attention to the CSV requirement is crucial as it affects the behavior of absolute timelocks used by HTLCs.The discussion on the Lightning-dev mailing list revolves around the safety and practicality of different approaches to shared-ownership update systems.


Updated on: 2023-07-31T21:09:09.247781+00:00