From nicolas.dorier at gmail.com Fri Nov 27 21:46:34 2015 From: nicolas.dorier at gmail.com (Nicolas Dorier) Date: Sat, 28 Nov 2015 06:46:34 +0900 Subject: [Lightning-dev] Payment channel without timeout protected from malleability In-Reply-To: <20151127201113.GA16433@sapphire.erisian.com.au> References: <20151127090946.GB7151@sapphire.erisian.com.au> <20151127201113.GA16433@sapphire.erisian.com.au> Message-ID: > 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? Did not thought about that, yes you are right. > Yeah, it's 99% of the way there; I just worry about random vandalism, > personally. Yes, I was worrying about B pro actively malleating everything. But since A controls broadcast time, he can choose to delay the broadcast when a vast malleability attack happens. On Sat, Nov 28, 2015 at 5:11 AM, Anthony Towns wrote: > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: