> Well one of 6, 36, 144, 432 or 1008 is probably more than enough choice.
Indeed, that seems entirely reasonable.
> Most of the time, local commitments are not in play. But if your node
> drops out, remote commitments definitely will be.
That's true, although in my experience, the refund delay
Pierre writes:
>> > How would bruteforcing on the CSV delay be different from a BIP32
>> > wallet with look ahead keys? Especially given that we could try with
>> > most probable values first.
>>
>> It's a big multiplier, given that CSV can be specified by the
>> counterparty. If you accept up to
> > How would bruteforcing on the CSV delay be different from a BIP32
> > wallet with look ahead keys? Especially given that we could try with
> > most probable values first.
>
> It's a big multiplier, given that CSV can be specified by the
> counterparty. If you accept up to 1024 and offer 144, t
Pierre writes:
> Hi Rusty,
>
> How would bruteforcing on the CSV delay be different from a BIP32
> wallet with look ahead keys? Especially given that we could try with
> most probable values first.
It's a big multiplier, given that CSV can be specified by the
counterparty. If you accept up to 10
Hi Rusty,
How would bruteforcing on the CSV delay be different from a BIP32
wallet with look ahead keys? Especially given that we could try with
most probable values first.
Cheers,
Pierre
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundati
Hi all,
In Adelaide we proposed that CSV delays be symmetric; that the
to-self output would be delayed to avoid weird "no, you close!" games.
Unfortunately, Roasbeef points out that this undermines the
great strength of the option_static_remotekey, which allows a
disaster-recovery
