Author: Lane Wagner 2018-12-07 13:14:20
Published on: 2018-12-07T13:14:20+00:00
The author is working on a protocol that allows users to host crypto public addresses, using a standard DNS lookup schema. The protocol aims to offer some advantages over OpenAlias and the author is hopeful for its adoption. Additionally, the author is considering allowing users to post lightning invoices, but acknowledges the difficulty in generating unique invoices for each payment. Seeking thoughts on this matter, they have provided links to the protocol, implementation, and open source implementation. On the Lightning-dev mailing list, discussions are focused on path decorrelation and rendezvous routing. Participants are discussing making a more flexible Lightning Network protocol and avoiding re-signing DLC subcontracts by using `SIGHASH_NOINPUT`. The Lightning Network protocol, Fulgurite, aims to make the information exchange in channels more flexible. Multiparty channels require more coordination than two-party channels and have more points of failure. It is better to admit the effect of CSV requirements earlier than later. Timelocked contracts need to be published on-chain before the timeout expires, and a N-block CSV requirement means that you must publish N+1 blocks before the absolute timelock expires. Fulgurite subchannels are expected to have only a subset of the participants of their parents. Therefore, it is better to move time-sensitivity to Fulgurite than to higher layers. Fulgurite generalizes Lightning shared-ownership update systems ('channels') and can contain 'shared-ownership update systems' of interest to its participants. There is a discussion on the Lightning-dev mailing list focused on the use of "shared-ownership update system" and subsystems within it. Participants raised concerns about the safety of non-custodial use of such a system as they have no power to refuse to sign off an invalid state transition. The idea of 2-party shared-ownership update systems ("channels") was proposed as it requires everyone's signature, reducing the points of failure. Burchert-Decker-Wattenhofer channel factories were suggested as they provide the advantage that once channels are set up, participants can be absent, and only their channels are affected. Existing update protocols can carry almost any Bitcoin-enforceable contract, including the same contracts used to enforce them. This allows update protocols to nest, as in Burchert-Decker-Wattenhofer or parent and child channels. However, some important details were highlighted, such as the fact that Decker-Wattenhofer and Decker-Russell-Osuntokun impose an extra CSV on their transported contracts, and most contracts cannot be transported across systems. It was emphasized that it is essential to pay attention to the CSV requirement as it affects the behavior of absolute timelocks used by HTLCs. Any absolute timelocked contract implies a timeout for the lifetime of the Fulgurite system/channel it is in. The discussion on the Lightning-dev mailing list revolved around the safety and practicality of different approaches to shared-ownership update systems.
Updated on: 2023-06-02T15:54:54.213717+00:00