Re: [Lightning-dev] Impact of eltoo loss of state

[Jeremy]

Just my 2 cents:

I think worrying about the size of a resolution during a contested close
scenario (too much) is not worth it. Encoding the state needed (e.g., in
op_return or whatever) is the safest option because then you guarantee the
availability of the closing transaction data in the protocol with no
external dependencies.

If you want to make it cheaper, then allow for Alice to choose to cooperate
with a contesting Bob to replace the transaction with something smaller
(quibble: we should get rid of mempool absolute fee increase rule for RBF
perhaps... otherwise, this should be done as pre-broadcast negotiation)
after observing the state published by Bob, but make it mandatory to at
least reveal it if Bob wants to use the transaction unilaterally.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Impact of eltoo loss of state

[ZmnSCPxj via Lightning-dev]

Good morning aj, and list,


> > I don't think you can reliably hide that you forgot some state?

Thinking a little more --- *why* do we need to hide that we forgot some state?

The reason is that if your peer learns you forgot state, the peer can pass off 
obsolete state onchain, thereby stealing funds from you before you can recover 
your data.

But if some completely random node that is ***not*** your peer and has ***no*** 
channels with you is holding your memento, then there is no need to worry --- 
even if you tell them "actually I forgot my state" they have no obsolete state 
to hurt you with.

Suppose that nodes provide a "will remember for you" flag in the feature bits.

Now, your node can then use a secret distance measurement --- for example, it 
could take the keyed hash (with your node privkey as key) of every "will 
remember for you"-advertising node, then look for the hash that is numerically 
lowest.

Locating the "nearest" node, your node then contacts that node and asks them to 
remember our memento.
Now, your node should not be using its "normal" pubkey for this, instead, it 
should generate a "throwaway" keypair derived from its privkey plus the pubkey 
of the selected node.

--

After your node hits its head and becomes amnesiac, you provide it with the 
privkey (which can be represented as some words).

The node then re-downloads gossip map, and uses the same secret distance 
measurement to find, say, the 100 "nearest" nodes with the "will remember for 
you" feature.
Assuming the gossip map has not changed too much since before the amnesia 
event, then it is likely that the previously selected node is still in the 
nearest 100 nodes.

Your node will then iterate over the nearest 100 nodes, starting with the 
nearest, and re-derive the "throwaway" keypair and ask each node if it holds a 
memento for that pubkey.

Since your node contacts them using a throwaway keypair that is not 
correlatable with your normal node pubkey, even if they are conspiring with 
your channel peers, the "will remember for you" node cannot identify that your 
node has suffered amnesia, it only knows that *some* node *somewhere* suffered 
amnesia.

This implies as well that the selected node can even be your peer, and it will 
still not be sure that the amnesiac node is you or might be somebody else 
completely.

--

Of course, the anonymous nature of the client requesting data storage is a 
problem, as this feature is now vulnerable to abuse and DDoS.
As a spam prevention, such a "will remember for you" node can use any number of 
techniques developed for anonymously paying to watchtowers, which have a 
similar "need to pay for anonymous storage to prevent DoS" problem.


Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Impact of eltoo loss of state

[ZmnSCPxj via Lightning-dev]

Good morning cdecker, aj, and list,

> . In addition we can store the same data with multiple peers, ensuring that 
> as long as one node is behaving we're good.


Depending on size limits of the stored data, it may be possible to use some 
kind of erasure coding so that at least k of n peers need to be honest so we 
are good.
I suspect peers would prefer to limit the amount of data they have to store, if 
they offer this feature, so use of erausre coding seems to be a good idea.

However, since the peer does not know the data you are storing, this detail can 
be known only by the node saving its data with the peer, so not need to put in 
specifications.

> I don't think you can reliably hide that you forgot some state? If you
> _did_ forget your state, you'll have forgotten their latest bundle too,
> and it seems like there's at least a 50/50 chance you'd have to send
> them their bundle before they sent you yours?

This objection seems quite correct.

Perhaps it is possible to (mis)use Barrier Escrow: 
https://suredbits.com/payment-points-implementing-barrier-escrows/
After all, what is needed is a simultaneous way for both sides to provide the 
data (or admit they lost it) before the other can withhold the data.

1.  Both agree on some Barrier Escrow and generate some temporary points.
2.  Both sides invoke `barrier-commit` on the Barrier Escrow, receiving E.
3.  Both sides *additionally* encrypt the bundle using an asymmetric 
encryption, which can be decrypted only by anyone who knows `e` such that `E = 
e * G`.
4.  Both sides exchange the asymmetrically-encrypted bundles.
5.  Once a side receives the asymmetrically-encrypted bundle from the other 
side, they invoke `barrier-reveal` using their temporary scalar from #1.
6.  When they get `e` from `barrier-reveal` they can decrypt the asymmetric 
encryption layer from the bundle they receive, then proceed to validate and 
decrypt the actual encrypted bundle.

If Alice is amnesiac, it just provides a random vector for the "asymmetric 
encrypted bundle of Bob".

Suppose Bob wants to check if Alice is amnesiac.
Bob cannot delay its send of the Alice-bundle, due to the Barrier Escrow 
ensuring that both parties have sent *some* bundle.
Thus, even if Bob knows later than Alice has gone amnesiac, by the time Bob 
knows that, it has handed over the memento of Alice by which Alice can recover.

Bob can send a bogus bundle to Alice, and then if it also receives a bogus 
bundle, it knows Alice is amnesiac (and it might be a good time to steal from 
Alice).
ALTERNATELY Alice is *also* trying to probe Bob, so Alice sent a bogus bundle 
itself.
In that case, Bob could attempt to steal, but runs the risk that Alice was 
*also* another prober who is not actually amnesiac.
(Not sure if that is valid game theory, though)


On the other hand, Barrier Escrow services have to be paid for their service 
(else why would they run), and if you have not connected to your peer then you 
cannot pay for barrier escrow services over Lightning.

Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Impact of eltoo loss of state

[Anthony Towns]

On Wed, Jul 14, 2021 at 04:44:24PM +0200, Christian Decker wrote:
> Not quite sure if this issue is unique to eltoo tbh. While in LN-penalty
> loss-of-state equates to loss-of-funds, in eltoo this is reduced to
> impact only funds that are in a PTLC at the time of the loss-of-state.

Well, the idea (in my head at least) is it should be "safe" to restore
an eltoo channel from a backup even if it's out of date, so the question
is what "safe" can actually mean. LN-penalty definitely isn't safe in
that scenario.

>  2) Use the peer-storage idea, where we deposit an encrypted bundle with
>  our peers, and which we expect the peers to return. by hiding the fact
>  that we forgot some state, until the data has been exchanged we can
>  ensure that peers always return the latest snapshot of whatever we gave
>  them.

I don't think you can reliably hide that you forgot some state? If you
_did_ forget your state, you'll have forgotten their latest bundle too,
and it seems like there's at least a 50/50 chance you'd have to send
them their bundle before they sent you yours?

Sharing with other peers has costs too -- if you can't commit to an
updated state with peer A until you've sent the updated data to peers
B and C as backup, then you've got a lot more latency on each channel,
for example. And if you commit first, then you've got the problem of
what happens if you crash before the update has made it to either B or C?

But I guess what I'm saying is sure -- those are great ideas, but they
only reduce the chance that you'll not have the latest state, they don't
eliminate it.

But it seems like it can probably be reduced enough that it's fine that
you're risking the balances in live HTLCs (or perhaps HTLCs that have
been initiated since your last state backup), as long as you're at least
able to claim your channel balance from whatever more recent state your
peers may have.

Cheers,
aj

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Impact of eltoo loss of state

[Christian Decker]

We'd likely be using an HMAC to ensure the integrity of the data returned
by peers, so we'd only have to guard against them returning an older
version, which in eltoo. Furthermore by retrieving the blobs on reconnect
regardless of whether we need them or not we can verify that peers are
behaving correctly, since they shouldn't be able to distinguish whether
we're just checking or actually need the data. In addition we can store the
same data with multiple peers, ensuring that as long as one node is
behaving we're good.

Cheers,
Christian

On Thu, 15 Jul 2021, 12:28 Martin Habovštiak 
wrote:

> What would happen in 2) if the node has data but the peer returned an
> incorrect state?
>
> On Wed, Jul 14, 2021, 20:13 Christian Decker 
> wrote:
>
>> Not quite sure if this issue is unique to eltoo tbh. While in LN-penalty
>> loss-of-state equates to loss-of-funds, in eltoo this is reduced to
>> impact only funds that are in a PTLC at the time of the loss-of-state.
>>
>> We have a couple of options here, that don't touch the blockchain, and
>> are therefore rather lightweight:
>>
>>  1) Do nothing and keep the incentive to keep up to date backups. It
>>  still is a reduction in risk w.r.t. LN-penalty, since this is just an
>>  append only log of secrets, and old secrets don't harm you like
>>  attempting to close with an old commitment would.
>>  2) Use the peer-storage idea, where we deposit an encrypted bundle with
>>  our peers, and which we expect the peers to return. by hiding the fact
>>  that we forgot some state, until the data has been exchanged we can
>>  ensure that peers always return the latest snapshot of whatever we gave
>>  them.
>>
>> The latter is the encrypted-blob idea that Rusty has been proposing for
>> a while now.
>>
>> Cheers,
>> Christian
>>
>> Anthony Towns  writes:
>> > Hello world,
>> >
>> > Suppose you have some payments going from Alice to Bob to Carol with
>> > eltoo channels. Bob's lightning node crashes, and he recovers from an
>> > old backup, and Alice and Carol end up dropping newer channel states
>> > onto the blockchain.
>> >
>> > Suppose the timeout for the payments is a few hours away, while the
>> > channels have specified a week long CSV delay to rectify any problems
>> > on-chain.
>> >
>> > Then I think that that means that:
>> >
>> >  1) Carol will reveal the point preimages on-chain via adaptor
>> > signatures, but Bob won't be able to decode those adaptor signatures
>> > because those signatures will need to change for each state
>> >
>> >  2) Even if Bob knows the point preimages, he won't be able to
>> > claim the PTLC payments on-chain, for the same reason: he needs
>> > newer adaptor signatures that he'll have lost with the state update
>> >
>> >  3) For any payments that timeout, Carol doesn't have any particular
>> > incentive to make it easy for Bob to claim the refund, and Bob won't
>> > have the adaptor signatures for the latest state to do so
>> >
>> >  4) But Alice will be able to claim refunds easily. This is working how
>> > it's meant to, at least!
>> >
>> > I think you could fix (3) by giving Carol (who does have all the adaptor
>> > signatures for the latest state) the ability to steal funds that are
>> > meant to have been refunded, provided she gives Bob the option of
>> claiming
>> > them first.
>> >
>> > However fixing (1) and (2) aren't really going against Alice or Carol's
>> > interests, so maybe you can just ask: Carol loses nothing by allowing
>> > Bob to claim funds from Alice; and Alice has already indicated that
>> > knowing P is worth more to her than the PTLC's funds -- otherwise she
>> > wouldn't have forwarded the PTLC to Bob in the first place.
>> >
>> > Likewise, everyone's probably incentivised to negotiate cooperative
>> > closes instead of going on-chain -- better privacy, less fees, and less
>> > delay before the funds can be used elsewhere.
>> >
>> > FWIW, I think a similar flaw exists even in the original eltoo spec --
>> > Alice could simply decline to publish the settlement transaction until
>> > the timeout has been reached, preventing Bob from revealing the HTLC
>> > preimage before Alice can claim the refund.
>> >
>> > So I think that adds up to:
>> >
>> >  a) Nodes should share state on reconnection; if you find a node that
>> > doesn't do this, close the channel and put the node on your enemies
>> > list. If you disagree on what the current state is, share your most
>> > recent state, and if the other guy's state is more recent, and all
>> > the signatures verify, update your state to match theirs.
>> >
>> >  b) Always negotiate a mutual/cooperative close if possible, to avoid
>> > actually using the eltoo protocol on-chain.
>> >
>> >  c) If you want to allow continuing the channel after restoring an old
>> > state from backup, set the channel state index based on the real
>> time,
>> > eg (real_time-start_time)*(max_updates_per_second). That way your
>> > first 

Re: [Lightning-dev] Impact of eltoo loss of state

[Martin Habovštiak]

What would happen in 2) if the node has data but the peer returned an
incorrect state?

On Wed, Jul 14, 2021, 20:13 Christian Decker 
wrote:

> Not quite sure if this issue is unique to eltoo tbh. While in LN-penalty
> loss-of-state equates to loss-of-funds, in eltoo this is reduced to
> impact only funds that are in a PTLC at the time of the loss-of-state.
>
> We have a couple of options here, that don't touch the blockchain, and
> are therefore rather lightweight:
>
>  1) Do nothing and keep the incentive to keep up to date backups. It
>  still is a reduction in risk w.r.t. LN-penalty, since this is just an
>  append only log of secrets, and old secrets don't harm you like
>  attempting to close with an old commitment would.
>  2) Use the peer-storage idea, where we deposit an encrypted bundle with
>  our peers, and which we expect the peers to return. by hiding the fact
>  that we forgot some state, until the data has been exchanged we can
>  ensure that peers always return the latest snapshot of whatever we gave
>  them.
>
> The latter is the encrypted-blob idea that Rusty has been proposing for
> a while now.
>
> Cheers,
> Christian
>
> Anthony Towns  writes:
> > Hello world,
> >
> > Suppose you have some payments going from Alice to Bob to Carol with
> > eltoo channels. Bob's lightning node crashes, and he recovers from an
> > old backup, and Alice and Carol end up dropping newer channel states
> > onto the blockchain.
> >
> > Suppose the timeout for the payments is a few hours away, while the
> > channels have specified a week long CSV delay to rectify any problems
> > on-chain.
> >
> > Then I think that that means that:
> >
> >  1) Carol will reveal the point preimages on-chain via adaptor
> > signatures, but Bob won't be able to decode those adaptor signatures
> > because those signatures will need to change for each state
> >
> >  2) Even if Bob knows the point preimages, he won't be able to
> > claim the PTLC payments on-chain, for the same reason: he needs
> > newer adaptor signatures that he'll have lost with the state update
> >
> >  3) For any payments that timeout, Carol doesn't have any particular
> > incentive to make it easy for Bob to claim the refund, and Bob won't
> > have the adaptor signatures for the latest state to do so
> >
> >  4) But Alice will be able to claim refunds easily. This is working how
> > it's meant to, at least!
> >
> > I think you could fix (3) by giving Carol (who does have all the adaptor
> > signatures for the latest state) the ability to steal funds that are
> > meant to have been refunded, provided she gives Bob the option of
> claiming
> > them first.
> >
> > However fixing (1) and (2) aren't really going against Alice or Carol's
> > interests, so maybe you can just ask: Carol loses nothing by allowing
> > Bob to claim funds from Alice; and Alice has already indicated that
> > knowing P is worth more to her than the PTLC's funds -- otherwise she
> > wouldn't have forwarded the PTLC to Bob in the first place.
> >
> > Likewise, everyone's probably incentivised to negotiate cooperative
> > closes instead of going on-chain -- better privacy, less fees, and less
> > delay before the funds can be used elsewhere.
> >
> > FWIW, I think a similar flaw exists even in the original eltoo spec --
> > Alice could simply decline to publish the settlement transaction until
> > the timeout has been reached, preventing Bob from revealing the HTLC
> > preimage before Alice can claim the refund.
> >
> > So I think that adds up to:
> >
> >  a) Nodes should share state on reconnection; if you find a node that
> > doesn't do this, close the channel and put the node on your enemies
> > list. If you disagree on what the current state is, share your most
> > recent state, and if the other guy's state is more recent, and all
> > the signatures verify, update your state to match theirs.
> >
> >  b) Always negotiate a mutual/cooperative close if possible, to avoid
> > actually using the eltoo protocol on-chain.
> >
> >  c) If you want to allow continuing the channel after restoring an old
> > state from backup, set the channel state index based on the real
> time,
> > eg (real_time-start_time)*(max_updates_per_second). That way your
> > first update after a restore from backup will ensure that any old
> > states that your channel partner may not have told you about are
> > invalidated.
> >
> >  d) Accept that if you lose connectivity to a channel partner, you will
> > have to pay any PTLCs that were going to them, and won't be able
> > to claim the PTLCs that were funding them. Perhaps limit the total
> > value of inbound PTLCs for forwarding that you're willing to accept
> > at any one itme?
> >
> > Also, layered commitments seem like they make channel factories
> > complicated too. Nobody came up with a way to avoid layered commitments
> > while I wasn't watching did they?
> >
> > Cheers,
> > aj
> > 

Re: [Lightning-dev] Impact of eltoo loss of state

[Christian Decker]

Not quite sure if this issue is unique to eltoo tbh. While in LN-penalty
loss-of-state equates to loss-of-funds, in eltoo this is reduced to
impact only funds that are in a PTLC at the time of the loss-of-state.

We have a couple of options here, that don't touch the blockchain, and
are therefore rather lightweight:

 1) Do nothing and keep the incentive to keep up to date backups. It
 still is a reduction in risk w.r.t. LN-penalty, since this is just an
 append only log of secrets, and old secrets don't harm you like
 attempting to close with an old commitment would.
 2) Use the peer-storage idea, where we deposit an encrypted bundle with
 our peers, and which we expect the peers to return. by hiding the fact
 that we forgot some state, until the data has been exchanged we can
 ensure that peers always return the latest snapshot of whatever we gave
 them.

The latter is the encrypted-blob idea that Rusty has been proposing for
a while now.

Cheers,
Christian

Anthony Towns  writes:
> Hello world,
>
> Suppose you have some payments going from Alice to Bob to Carol with
> eltoo channels. Bob's lightning node crashes, and he recovers from an
> old backup, and Alice and Carol end up dropping newer channel states
> onto the blockchain.
>
> Suppose the timeout for the payments is a few hours away, while the
> channels have specified a week long CSV delay to rectify any problems
> on-chain.
>
> Then I think that that means that:
>
>  1) Carol will reveal the point preimages on-chain via adaptor
> signatures, but Bob won't be able to decode those adaptor signatures
> because those signatures will need to change for each state
>
>  2) Even if Bob knows the point preimages, he won't be able to
> claim the PTLC payments on-chain, for the same reason: he needs
> newer adaptor signatures that he'll have lost with the state update
>
>  3) For any payments that timeout, Carol doesn't have any particular
> incentive to make it easy for Bob to claim the refund, and Bob won't
> have the adaptor signatures for the latest state to do so
>
>  4) But Alice will be able to claim refunds easily. This is working how
> it's meant to, at least!
>
> I think you could fix (3) by giving Carol (who does have all the adaptor
> signatures for the latest state) the ability to steal funds that are
> meant to have been refunded, provided she gives Bob the option of claiming
> them first.
>
> However fixing (1) and (2) aren't really going against Alice or Carol's
> interests, so maybe you can just ask: Carol loses nothing by allowing
> Bob to claim funds from Alice; and Alice has already indicated that
> knowing P is worth more to her than the PTLC's funds -- otherwise she
> wouldn't have forwarded the PTLC to Bob in the first place.
>
> Likewise, everyone's probably incentivised to negotiate cooperative
> closes instead of going on-chain -- better privacy, less fees, and less
> delay before the funds can be used elsewhere.
>
> FWIW, I think a similar flaw exists even in the original eltoo spec --
> Alice could simply decline to publish the settlement transaction until
> the timeout has been reached, preventing Bob from revealing the HTLC
> preimage before Alice can claim the refund.
>
> So I think that adds up to:
>
>  a) Nodes should share state on reconnection; if you find a node that
> doesn't do this, close the channel and put the node on your enemies
> list. If you disagree on what the current state is, share your most
> recent state, and if the other guy's state is more recent, and all
> the signatures verify, update your state to match theirs.
>
>  b) Always negotiate a mutual/cooperative close if possible, to avoid
> actually using the eltoo protocol on-chain.
>
>  c) If you want to allow continuing the channel after restoring an old
> state from backup, set the channel state index based on the real time,
> eg (real_time-start_time)*(max_updates_per_second). That way your
> first update after a restore from backup will ensure that any old
> states that your channel partner may not have told you about are
> invalidated.
>
>  d) Accept that if you lose connectivity to a channel partner, you will
> have to pay any PTLCs that were going to them, and won't be able
> to claim the PTLCs that were funding them. Perhaps limit the total
> value of inbound PTLCs for forwarding that you're willing to accept
> at any one itme?
>
> Also, layered commitments seem like they make channel factories
> complicated too. Nobody came up with a way to avoid layered commitments
> while I wasn't watching did they?
>
> Cheers,
> aj
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org

Re: [Lightning-dev] Impact of eltoo loss of state

[Jeremy]

Another option would be to somehow encrypt this data in, say, an OP_RETURN
for any update transaction for each participant (perhaps worth breaking
update symmetry for efficiency on this...) that way if an update ever
happens on a state you don't have you can use your static key to decrypt
the relevant data for what PK_si signed off on.


--
@JeremyRubin 



On Mon, Jul 12, 2021 at 3:16 PM Jeremy  wrote:

> Without an exact implementation, one thing you could do to fix the lost
> state issue would be to make the scripts something like:
>
> [` CLTV DROP PKu CHECKSIGVERIFY GETLOCKTIME 
> BIP32DERIVE CHECKTRANSACTIONSIGNEDFROMSTACK`, `2016 CSV DROP PK_si
> CHECKSIG`]
>
> In order to upgrade to state M>= N+1 you'd have to publish a transaction
> signed with the BIP32 derived key for that update in the future.
>
> The downside is that you end up double publishing the txdata on the chain,
> but it at least ensure data availability.
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Impact of eltoo loss of state

[Jeremy]

Without an exact implementation, one thing you could do to fix the lost
state issue would be to make the scripts something like:

[` CLTV DROP PKu CHECKSIGVERIFY GETLOCKTIME 
BIP32DERIVE CHECKTRANSACTIONSIGNEDFROMSTACK`, `2016 CSV DROP PK_si
CHECKSIG`]

In order to upgrade to state M>= N+1 you'd have to publish a transaction
signed with the BIP32 derived key for that update in the future.

The downside is that you end up double publishing the txdata on the chain,
but it at least ensure data availability.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

[Lightning-dev] Impact of eltoo loss of state

[Anthony Towns]

Hello world,

Suppose you have some payments going from Alice to Bob to Carol with
eltoo channels. Bob's lightning node crashes, and he recovers from an
old backup, and Alice and Carol end up dropping newer channel states
onto the blockchain.

Suppose the timeout for the payments is a few hours away, while the
channels have specified a week long CSV delay to rectify any problems
on-chain.

Then I think that that means that:

 1) Carol will reveal the point preimages on-chain via adaptor
signatures, but Bob won't be able to decode those adaptor signatures
because those signatures will need to change for each state

 2) Even if Bob knows the point preimages, he won't be able to
claim the PTLC payments on-chain, for the same reason: he needs
newer adaptor signatures that he'll have lost with the state update

 3) For any payments that timeout, Carol doesn't have any particular
incentive to make it easy for Bob to claim the refund, and Bob won't
have the adaptor signatures for the latest state to do so

 4) But Alice will be able to claim refunds easily. This is working how
it's meant to, at least!

I think you could fix (3) by giving Carol (who does have all the adaptor
signatures for the latest state) the ability to steal funds that are
meant to have been refunded, provided she gives Bob the option of claiming
them first.

However fixing (1) and (2) aren't really going against Alice or Carol's
interests, so maybe you can just ask: Carol loses nothing by allowing
Bob to claim funds from Alice; and Alice has already indicated that
knowing P is worth more to her than the PTLC's funds -- otherwise she
wouldn't have forwarded the PTLC to Bob in the first place.

Likewise, everyone's probably incentivised to negotiate cooperative
closes instead of going on-chain -- better privacy, less fees, and less
delay before the funds can be used elsewhere.

FWIW, I think a similar flaw exists even in the original eltoo spec --
Alice could simply decline to publish the settlement transaction until
the timeout has been reached, preventing Bob from revealing the HTLC
preimage before Alice can claim the refund.

So I think that adds up to:

 a) Nodes should share state on reconnection; if you find a node that
doesn't do this, close the channel and put the node on your enemies
list. If you disagree on what the current state is, share your most
recent state, and if the other guy's state is more recent, and all
the signatures verify, update your state to match theirs.

 b) Always negotiate a mutual/cooperative close if possible, to avoid
actually using the eltoo protocol on-chain.

 c) If you want to allow continuing the channel after restoring an old
state from backup, set the channel state index based on the real time,
eg (real_time-start_time)*(max_updates_per_second). That way your
first update after a restore from backup will ensure that any old
states that your channel partner may not have told you about are
invalidated.

 d) Accept that if you lose connectivity to a channel partner, you will
have to pay any PTLCs that were going to them, and won't be able
to claim the PTLCs that were funding them. Perhaps limit the total
value of inbound PTLCs for forwarding that you're willing to accept
at any one itme?

Also, layered commitments seem like they make channel factories
complicated too. Nobody came up with a way to avoid layered commitments
while I wasn't watching did they?

Cheers,
aj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev