[Lightning-dev] Fulgurite: ideas for making a more flexible Lightning Network protocol

[Trey Del Bonis]

Hi,

> > We might have to loosen the restrictions a bit how that information is validated of course.

> For the case of Burchert-Decker-Wattenhofer channel factories, a single channel announcement will be done for all channels within the factory, signed off by all of the participants in the channel factory, and we presume that the factory participants have validated that the money owned by who is actually owned by that who.  However, each channel within the factory would then need channel updates only signed off by the two direct participants in the channel.  When channels within the factory are reorganized, a new announcement will need to be done and signed off on by participants in the factory who performed the reorg.

I was more talking about situations where we *aren't* doing
Burchert-Decker-Wattenhofer and want (unannounced) subchannels.
Another idea is to have peers lie in the channel announcement which
particular channel has the funds moving when routing a payment.  So
you say "this channel has x msat capacity" and when other peers
request to route payments through it, the parties already have agreed
to send it through the unannounced subchannel.  Or just leave the
ability to route through unanounced secret subchannels to situations
where you've been given an invoice with a partial path already
provided and the sender just "assumes" that the payment will work.

It should be trivial to compose Fulgurite in
Burchert-Decker-Wattenhofer exactly as-is, and you'd still get all the
nice scalability benefits.

> Suppose we have a contract with a timelock at time N.
> And this contract is put inside an update mechanism with CSV requirement of time M.
> The contract must be cancelled by the participants at time N - M.
> However, if not cancelled, the contract will be dropped onchain, and its true expiry will still be at time N.
> In short, the contract changes between offchain (expires at time N - M) and onchain (expires at time N).

To do that generally would be to have partitions give an optional
"must be gone by" deadline where we should either get rid of the
partition by then (somehow, we don't actually care) or force the
channel on-chain if we're not using a "timeless" update mechanism like
Poon-Dryja.  Operations like ExpireHtlc should calculate an earlier
deadline at which they'd become accepted, and be the thing to actually
remove the in-channel HTLC "the right way".

Complementary to that, I have the update mechanism update a "validity
deadline" as a side effect after a state has been re-signed, which
helps us to know when to do periodic re-signings.

- Trey Del Bonis
On Sat, Dec 8, 2018 at 2:37 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> Good morning Trey,
> > 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.
>
> The validation of channel data (other than the fact that it is locked on the blockchain) is simply checking that both sides of the channel have agreed, i.e. signatures from one or both endpoints.
> That is the only validation necessary, since any details of the channel will be their inviolate demesne; we do not need global consensus for things like what fees the node wants to charge for the use of the channel.
> Only that the channel truly exists, is the only consensus validation we need.
>
> For the case of Burchert-Decker-Wattenhofer channel factories, a single channel announcement will be done for all channels within the factory, signed off by all of the participants in the channel factory, and we presume that the factory participants have validated that the money owned by who is actually owned by that who.  However, each channel within the factory would then need channel updates only signed off by the two direct participants in the channel.  When channels within the factory are reorganized, a new announcement will need to be done and signed off on by participants in the factory who performed the reorg.
>
> Burchert-Decker-Wattenhofer also allows channels to close and then reorganized with only a proper subset of the original factory participants, but this creates even more transactions and possibly greater CSV requirements.
>
>
> > > 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.
>
> Of note, is that the update mechanism can always cancel any contract if all participants in the updateable cryptocurrency system have agreed.
>
> One can consider the fulfillment of the hashlock in an HTLC to actually cancel the contract, and put its fund into whoever fulfilled it.
> Similarly, if the timelock on an HTLC is about to expire, then both sides can agree to simply cancel it back to the beneficiary of the timelock branch.
>
> From this point-of-view, then, when the timelock is about to expire, and the other side refuses to sign off on the cancellation, our only remaining remedy is to fail the system and drop to onchain for enforcement.
>
> Under Poon-Dryja there is no CSV requirement and the above point-of-view is easy to consider.
>
> Under Decker-Wattenhofer and Decker-Russell-Osuntokun, there exists this CSV requirement and this becomes complicated.
> Suppose we have a contract with a timelock at time N.
> And this contract is put inside an update mechanism with CSV requirement of time M.
> The contract must be cancelled by the participants at time N - M.
> However, if not cancelled, the contract will be dropped onchain, and its true expiry will still be at time N.
> In short, the contract changes between offchain (expires at time N - M) and onchain (expires at time N).
>
> Regards,
> ZmnSCPxj
>