[Lightning-dev] Payment channel without timeout protected from malleability

Anthony Towns aj at erisian.com.au
Fri Nov 27 20:11:13 UTC 2015

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 <revoke> OP_EQUALVERIFY)

But B won't be able to guess what the <revoke> hash is, so won't be
able to correlate with potential anchor transactions at all, afaics,
even if pubkeys <A> and <B> 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,


More information about the Lightning-dev mailing list