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
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
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
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
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
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
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
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
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
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
10 matches
Mail list logo
