Author: ZmnSCPxj 2018-12-08 19:13:59
Published on: 2018-12-08T19:13:59+00:00
ZmnSCPxj, a member of the Lightning-dev mailing list, mentioned that Rusty is working on a spec for reusable payment offers to request BOLT11 invoices over the LN network. Laolu and his friends are building a spontaneous-payment protocol without proof-of-payment, but the details are unclear. Lane Wagner mentioned that he is working on a protocol that allows users to host crypto public addresses using a standard DNS lookup schema. He is hopeful that it will see actual adoption and wants to enable users to post lightning invoices as well. However, he finds it difficult because typically invoices must be generated uniquely for each payment. The Lightning Network protocol is being modified with the introduction of Fulgurite, which generalizes Lightning shared-ownership update systems. A "shared-ownership update system" is a contract that is enforceable onchain and can contain other "shared-ownership update systems". The idea behind Fulgurite is to figure out some of the details surrounding how to actually implement the protocols described by formal research in the area and leave space in the design for other protocols yet to be designed without having to do a large overhaul of the protocol. Fulgurite sub-channels are expected to have only a subset of the participants of their parents. However, Fulgurite adds more complexity than necessary. Two-party shared-ownership update systems ("channels") are best, since everyone has to sign, while fewer participants mean fewer points of failure. In particular, timelocked contracts need to be published on-chain before the timeout expires, and a N-block CSV requirement then means you have to publish on-chain N+1 blocks before the absolute timelock expires. Restrictions regarding when to publish could be managed at a higher level.The Burchert-Decker-Wattenhofer channel factories have the advantage that once the channels within the factory have been 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. However, there are some important details like 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 is better to admit this earlier than later since it becomes possible as an attack point if you do not take care to pay attention to the CSV requirement. In particular, timelocked contracts need to be published on-chain before the timeout expires, and a N-block CSV requirement then means you have to publish on-chain N+1 blocks before the absolute timelock expires.ZmnSCPxj also discussed the routing gossip which is not trust-based, instead nodes check if the specified txo is unspent, and matches the purported capacity of the channel and how it could be relaxed so that the channels purported to be in the factory would sum up to less than or equal to the value of the channel factory txo instead. Additionally, he suggested that the issue of re-signing the DLC subcontracts could be avoided if you use `SIGHASH_NOINPUT`.
Updated on: 2023-06-02T15:52:00.054196+00:00