Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2022-07-01 📝 Original message: Hi Lisa, > Adding a ...
📅 Original date posted:2022-07-01
📝 Original message:
Hi Lisa,
> Adding a noticeable on-chain signal runs counter to the goal of the move
> to taproot / gossip v2, which is to make lightning's onchain footprint
> indistinguishable from any other onchain usage
My model of gossip v2 is something like:
* there's no longer a 1:1 mapping of channels and UTXOs
* verifiers don't actually care if the advertised UTXO is actually a
channel or not
* verifiers aren't watching the chain for spends, as channel
advertisements expire after 2 weeks or w/e
* there might be a degree of "leverage" allowing someone to advertise a 1
BTC UTXO as having 10 BTC capacity (or w/e)
So in this model, splicing on the gossip network wouldn't really be an
explicit event. Since I'm free to advertise a series of channels that might
not actually exist, I can just say: ok, this set of 5 channels is now
actually 2 channels, and you can route a bit more over them. In this world,
re-organizing by a little corner of the channel graph isn't necessarily
tied to
making a series of on-chain transactions.
In the realm of the gossip network as it's defined today, the act of
splicing is already itself a noticeable chain signal: I see a channel close,
then another one advertised that uses that old channel as inputs, and the
closing and opening transactions are the same. As a result, for _public_
channels any of the chain signals I listed above don't actually give away
any additional information: splices are already identifiable (in theory).
I don't disagree that waiting N blocks is probably "good enough" for most
cases (ignoring block storms, rare long intervals between blocks, etc, etc).
Instead this is suggested in the spirit of a belt-and-suspenders approach:
if I can do something to make the signal 100% reliable, that doesn't add
extra bytes to the chain, and doesn't like additional information for public
channels (the only case where the message even matters), then why not?
-- Laolu
On Wed, Jun 29, 2022 at 5:43 PM lisa neigut <niftynei at gmail.com> wrote:
> Adding a noticeable on-chain signal runs counter to the goal of the move
> to taproot / gossip v2, which is to make lightning's onchain footprint
> indistinguishable from
> any other onchain usage.
>
> I'm admittedly a bit confused as to why onchain signals are even being
> seriously
> proposed. Aside from "infallibility", is there another reason for
> suggesting
> we add an onchain detectable signal for this? Seems heavy handed imo,
> given
> that the severity of a comms failure is pretty minimal (*potential* for
> lost routing fees).
>
> > So it appears you don't agree that the "wait N blocks before you close
> your
> channels" isn't a fool proof solution? Why 12 blocks, why not 15? Or 144?
>
> fwiw I seem to remember seeing that it takes ~an hour for gossip to
> propagate
> (no link sorry). Given that, 2x an hour or 12 blocks is a reasonable first
> estimate.
> I trust we'll have time to tune this after we've had some real-world
> experience with them.
>
> Further, we can always add more robust signaling later, if lost routing
> fees turns
> out to be a huge issue.
>
> Finally, worth noting that Alex Myer's minisketch project may well
> help/improve gossip
> reconciliation efficiency to the point where gossip reliability is less
> of an issue.
>
> ~nifty
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220701/5ce89e1b/attachment.html>;
📝 Original message:
Hi Lisa,
> Adding a noticeable on-chain signal runs counter to the goal of the move
> to taproot / gossip v2, which is to make lightning's onchain footprint
> indistinguishable from any other onchain usage
My model of gossip v2 is something like:
* there's no longer a 1:1 mapping of channels and UTXOs
* verifiers don't actually care if the advertised UTXO is actually a
channel or not
* verifiers aren't watching the chain for spends, as channel
advertisements expire after 2 weeks or w/e
* there might be a degree of "leverage" allowing someone to advertise a 1
BTC UTXO as having 10 BTC capacity (or w/e)
So in this model, splicing on the gossip network wouldn't really be an
explicit event. Since I'm free to advertise a series of channels that might
not actually exist, I can just say: ok, this set of 5 channels is now
actually 2 channels, and you can route a bit more over them. In this world,
re-organizing by a little corner of the channel graph isn't necessarily
tied to
making a series of on-chain transactions.
In the realm of the gossip network as it's defined today, the act of
splicing is already itself a noticeable chain signal: I see a channel close,
then another one advertised that uses that old channel as inputs, and the
closing and opening transactions are the same. As a result, for _public_
channels any of the chain signals I listed above don't actually give away
any additional information: splices are already identifiable (in theory).
I don't disagree that waiting N blocks is probably "good enough" for most
cases (ignoring block storms, rare long intervals between blocks, etc, etc).
Instead this is suggested in the spirit of a belt-and-suspenders approach:
if I can do something to make the signal 100% reliable, that doesn't add
extra bytes to the chain, and doesn't like additional information for public
channels (the only case where the message even matters), then why not?
-- Laolu
On Wed, Jun 29, 2022 at 5:43 PM lisa neigut <niftynei at gmail.com> wrote:
> Adding a noticeable on-chain signal runs counter to the goal of the move
> to taproot / gossip v2, which is to make lightning's onchain footprint
> indistinguishable from
> any other onchain usage.
>
> I'm admittedly a bit confused as to why onchain signals are even being
> seriously
> proposed. Aside from "infallibility", is there another reason for
> suggesting
> we add an onchain detectable signal for this? Seems heavy handed imo,
> given
> that the severity of a comms failure is pretty minimal (*potential* for
> lost routing fees).
>
> > So it appears you don't agree that the "wait N blocks before you close
> your
> channels" isn't a fool proof solution? Why 12 blocks, why not 15? Or 144?
>
> fwiw I seem to remember seeing that it takes ~an hour for gossip to
> propagate
> (no link sorry). Given that, 2x an hour or 12 blocks is a reasonable first
> estimate.
> I trust we'll have time to tune this after we've had some real-world
> experience with them.
>
> Further, we can always add more robust signaling later, if lost routing
> fees turns
> out to be a huge issue.
>
> Finally, worth noting that Alex Myer's minisketch project may well
> help/improve gossip
> reconciliation efficiency to the point where gossip reliability is less
> of an issue.
>
> ~nifty
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220701/5ce89e1b/attachment.html>;