ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-12-06 📝 Original message: Good morning Trey, > One ...
📅 Original date posted:2018-12-06
📝 Original message:
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
📝 Original message:
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