Hi list,
tl;dr: I think can use two round MuSig safely in the context of lightning.
As a recap, Zeeman did a good evaluation of "purely scriptless" lightning
channels after taproot/schnorr.[1]
Z concluded that even in the most optimized case the 3 round MuSig protocol
leads to an extra round of c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi all,
We are writing to let the Lightning community know about the existence of
vulnerabilities that affect lnd versions 0.10.x and below. The full details of
these vulnerabilities will be disclosed on October 20, 2020. The circumstances
surroundi
Good morning t-bast,
> Please forget about channel jamming, upfront fees et al and simply consider
> the parameters I'm
> mentioning. It feels to me that these are by nature dynamic channel
> parameters (some of them are
> even present in `channel_update`, but no-one updates them yet because dir
Hi Zeeman,
> * It requires a lot more communication rounds and (symmetric, at least)
cryptographic operations.
At first sight, it sounds similar to HORNET/rendez-vous, at least in the
goal of achieving bidirectional communications.
* Intermediate nodes can guess the distance from the source by m
> There is no need to stop the channel's operations while you're updating
these parameters, since
they can be updated unilaterally anyway
I think it's just how you defne channel's operations, either emptying out
all pending HTLCs or more a `update_fee` alike semantic. You're right that
the latter
Thanks (again) Antoine and Zman for your answers,
On the other hand, a quick skim of your proposal suggests that it still
> respects the "initiator pays" principle.
> Basically, the fundee only pays fees for HTLCs they initiated, which is
> not relevant to the above attack (since in the above atta
Good morning Antoine and Zman,
Thanks for your answers!
I was thinking dynamic policy adjustment would be covered by the dynamic
> commitment mechanism proposed by Laolu
I didn't mention this as I think we still have a long-ish way to go before
dynamic commitments
are spec-ed, implemented and d
If I remember correctly, it looks very similar to how I2P establishes
tunnels, it may be worth
diving in their documentation to fish for ideas.
However in their case the goal is to establish a long-lived tunnel, which
is why it's ok to have
a slow and costly protocol. It feels to me that for payme
