From aj at erisian.com.au Fri Nov 27 20:11:13 2015 From: aj at erisian.com.au (Anthony Towns) Date: Sat, 28 Nov 2015 06:11:13 +1000 Subject: [Lightning-dev] Payment channel without timeout protected from malleability In-Reply-To: References: <20151127090946.GB7151@sapphire.erisian.com.au> Message-ID: <20151127201113.GA16433@sapphire.erisian.com.au> On Sat, Nov 28, 2015 at 01:18:21AM +0900, Nicolas Dorier wrote: > > A also passes the original unsigned commitment to B, who verifies that > > it's in the right format (ie, can be revoked), and hashes to the hash > > that he signed. > No, if A pass the unsigned commitment to B then B can malleate the anchor. Sorry, I meant the above needs to happen after the anchor's confirmed in the blockchain (and A's told B about the anchor). > > B can't reuse pubkeys between different channels with this protocol > > either, but that's good practice anyway. > Right, neither A should. If A reuse a key, then B can guess the redeem > hash, then would identify the transaction to malleate at broadcast time, > before A's announcement. B will be providing a signature for a tx that: - has the anchor as input - has a single refund output payable to (A && OP_CSV) | (B && OP_HASH OP_EQUALVERIFY) But B won't be able to guess what the hash is, so won't be able to correlate with potential anchor transactions at all, afaics, even if pubkeys and are both known to B? > I'd prefer seggregated witness to fix the problem cleanly, but I think that > opening the channel as I said is a good enough workaround until it happen. Yeah, it's 99% of the way there; I just worry about random vandalism, personally. Cheers, aj