Good afternoon, >Of note, the routing gossip is not trust-based. >Instead, part of the routing gossip is the block and transaction and output on >which the channel is anchored onchain. >Nodes check if the specified txo is unspent, and matches the purported >capacity of the channel. >Once a channel outpoint is spent, nodes automatically remove it from their >maps.
>I suppose that 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. >This would allow a Fulgurite system to allocate only part of its funds to >Lightning-visible routing nodes. I haven't really thought much about what the consequences for routing discovery would be. There's already some amount of trust in the information you're getting about channels, so I think we have a bit of flexibility with regard to what we announce to the rest of the network. We might have to loosen the restrictions a bit how that information is validated of course. Someone smarter than me should comment on that in case it's a horrible idea though. >It strikes me that the issue of re-signing the DLC subcontracts could be >avoided if you use `SIGHASH_NOINPUT`. Oh yes. SIGHASH_NOINPUT makes a lot of things nicer and cleaner. And while I'm confident everyone is going to reach an agreement about it on Bitcoin eventually, I'm not exactly holding my breath. Plus there's other coins that might *never* support it, so I'd like to make sure designs can not require it if we can. >At minimum the lower-level system would have to alert the higher-level system >that a time-sensitive contract needs to collapse the Fulgrite system or else >it would not be possible to enforce the timelock. >But the upper layer needs to be informed of the latest time that the contract >can be enforced onchain. >Your alternative is that the upper layer needs to know whether the lower layer >is using Poon-Dryja (no CSV requirement) or Decker-Wattenhofer (CSV >requirement) or Decker-Russell-Osuntokun (CSV requirement), which you can >argue is a layering violation. >Further the exact specs (how many blocks do all participants agree is >reasonable for the CSV requirement?) would vary. I think I actually just devised an elegant way to make that work using deadline timing flags being passed out of the update state machine, it'll be in the repo later. As long as the update mechanism impl is smart enough to know when to emit that the upper layer shouldn't care. Of course still have checks underneath where necessary. There'd have to be negotiation beforehand about the CSV requirements, like during channel setup. It could be adjusted later though I figure out a good way to make that work. >So it seems to me better to move time-sensitivity to Fulgurite than to higher >layers. >Higher layers can simply be concerned about what contracts it wants to enter >into. >The higher layer informs the Fulgurite layer of the shortest absolute timelock >in each contract it enters into. >The Fulgurite layer then returns to the higher layer the latest blockheight at >which it can still safely collapse the Fulgurite system, or an error that the >absolute timelock is too near and is already not enforceable at the Fulgurite >layer. That's a good way to do it. I'll try something like that. - Trey Del Bonis On Thu, Dec 6, 2018 at 6:23 PM ZmnSCPxj <zmnsc...@protonmail.com> wrote: > > Good morning Trey, > > One thing > > we've talked about is if you and your counterparty want to route > > payments through each other but also want to enter into discreet log > > contracts, it might make sense to set up a subchannel for each purpose > > so you don't have to re-sign for all the potential outcomes for the > > DLCs (slow!) every time you add/remove an HTLC. Only the routing > > (sub)channel would be announced to the routing network. > > Of note, the routing gossip is not trust-based. > Instead, part of the routing gossip is the block and transaction and output > on which the channel is anchored onchain. > Nodes check if the specified txo is unspent, and matches the purported > capacity of the channel. > Once a channel outpoint is spent, nodes automatically remove it from their > maps. > > In a world with Burchert-Decker-Wattenhofer factories, the factory would have > an onchain txo. > Gossip would contain all the channels in the factory, and would be signed by > the same signatories as the onchain txo. > Nodes would check that the channels purported to be contained in the factory > sum up to the value of this txo. > > I suppose that 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. > This would allow a Fulgurite system to allocate only part of its funds to > Lightning-visible routing nodes. > > It strikes me that the issue of re-signing the DLC subcontracts could be > avoided if you use `SIGHASH_NOINPUT`. > The same signatories could be used for the DLCs, and even if the update > transaction changes, you can reanchor the DLC subcontracts with > `SIGHASH_NOINPUT`. > > > > Code speaks louder than words. > > > > Of course. :) > > Yes, so feel free to ignore whatever I say, since I have not coded for a > while. > > > > CSV requirements are a time-based requirement that affect the behavior of > > > absolute timelocks used by HTLCs. > > > 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 onchain before > > > the timeout expires, and a N-block CSV requirement then means you have to > > > publish onchain N+1 blocks before the absolute timelock expires. > > > > Restrictions regarding when to publish could be managed at a higher > > level. What Fulgurite is trying to solve is how to manage the state > > negotiation rather than the high-level logic about when exactly to > > publish commitment txs. Maybe we should slightly alter the mechanics > > for how HTLC expiry works in-channel vs on-chain for this problem? > > At minimum the lower-level system would have to alert the higher-level system > that a time-sensitive contract needs to collapse the Fulgrite system or else > it would not be possible to enforce the timelock. > > Since contracts inside a multiparticipant updatable system can be cancelled > by the agreement of all participants, I suppose the higher layer can decide > to demand an update that the timelock be followed within the multiparticipant > updatable system. > But the upper layer needs to be informed of the latest time that the contract > can be enforced onchain. > Your alternative is that the upper layer needs to know whether the lower > layer is using Poon-Dryja (no CSV requirement) or Decker-Wattenhofer (CSV > requirement) or Decker-Russell-Osuntokun (CSV requirement), which you can > argue is a layering violation. > Further the exact specs (how many blocks do all participants agree is > reasonable for the CSV requirement?) would vary. > > So it seems to me better to move time-sensitivity to Fulgurite than to higher > layers. > Higher layers can simply be concerned about what contracts it wants to enter > into. > The higher layer informs the Fulgurite layer of the shortest absolute > timelock in each contract it enters into. > The Fulgurite layer then returns to the higher layer the latest blockheight > at which it can still safely collapse the Fulgurite system, or an error that > the absolute timelock is too near and is already not enforceable at the > Fulgurite layer. > > Regards, > ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
