From rusty at rustcorp.com.au Wed Jul 24 00:37:51 2019 From: rusty at rustcorp.com.au (Rusty Russell) Date: Wed, 24 Jul 2019 10:07:51 +0930 Subject: [Lightning-dev] [PROPOSAL] Removal of proposal to make CSV delay symmetric In-Reply-To: References: <877e8hmom0.fsf@rustcorp.com.au> <87tvbi8sd8.fsf@rustcorp.com.au> Message-ID: <87tvbctggw.fsf@rustcorp.com.au> 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 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.