Pierre <[email protected]> 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 1024 and offer 144, that's 880 >> variants to look for, per key. > > We could restrict CSV delays to be e.g. multiple of 144 between 144 > and 2016, that would only be 14 variants.
Well one of 6, 36, 144, 432 or 1008 is probably more than enough choice. >> It also can't be done with a normal bitcoin wallet, which is unfortunate >> too. > > Right, but it wouldn't work for local commitments. > > I feel like alignment of incentives should prevail here. Funds are > still recoverable with just the seed, which is a huge improvement vs > what is currently the case. Most of the time, local commitments are not in play. But if your node drops out, remote commitments definitely will be. I think being able to rescue some funds from a pre-lightning wallet is a nice thing to have at this stage. In five years, it might not be as useful, though. Cheers, Rusty. _______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
