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

Nicolas Dorier nicolas.dorier at gmail.com
Fri Nov 27 16:18:21 UTC 2015


> 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.
(because B would know the txid of the anchor at broadcast time)
B does not have to verify it is in right format, because he does not have
anything to loose by signing a random hash.
B can verify he signed the hash of the first commitment after A announce
his already confirmed anchor.

> Someone other than B (ie a third party) could malleate the anchor between
> broadcast and confirmation just for their own amusement.

Yes, actually the only malleability vector which B can use to his advantage
is HighS, not all BIP62 vectors.
Knowing miners will most likely run at least 0.11.2 (if CLTV is acceepted)
HighS should be more likely rejected.

> 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.

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.
The only attack B can try is malleate all transaction to HighS.
When CLTV will pass, there is not lot of probability of such attack to
succeed, because bitcoind should block HighS.

> 'without timeout' is only possible with OP_CSV - not naturally
with what we have currently. ;)

The anchor does not have to use OP_CSV at all. But yes, for commitment, I'm
assuming OP_CSV passed.

> To be able to build a valid payment channel on top of the anchor,
B has to be sure that A cannot get her money back at any point in the
future. Given just a hash that B should sign, B has no clue what is
the output of the transaction he just signed.

Actually B do not care about it. Remember I am separating "A's anchor
broadcast" from "A's announcement of anchor to B".
When A announce the anchor, then B can check if he really signed the first
commitment or something else, but he can't malleate anything since the
anchor is already confirmed.
B does not have anything to loose by signing unknown hash. (if he use a non
reusable key)

Again, yes, a network-wide HighS attack would be the only way to malleate
the anchor.
If CLTV fork pass, then it is fair to consider that the odd of such attack
succeeding is very low. HighS should be blocked from 0.11.1 if I remember
well.


On Fri, Nov 27, 2015 at 6:09 PM, Anthony Towns <aj at erisian.com.au> wrote:

> On Fri, Nov 27, 2015 at 04:37:04PM +0900, Nicolas Dorier wrote:
> > By adapting an idea from gmaxwell (
> > https://bitcointalk.org/index.php?topic=303088.0) it is possible to
> open a
> > channel without suffering from malleability attack.
> > The process for A to open channel with B is the following:
> > * A asks B pubkey
> > * A create the first commitment transaction
> > * A extract the hash that B needs to sign to be able to broadcast the
> > commitment
> > * A asks B to sign the hash, but do not disclose the commitment
> > * A broadcast the anchor
> > * After confirmation, A announce the anchor to B.
>
> 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.
>
> > B can't identify A's anchor before announcement because he does not know
> > the P2SH of the multisig.
> > Am I missing something ?
>
> Someone other than B (ie a third party) could malleate the anchor between
> broadcast and confirmation just for their own amusement.
>
> B can't reuse pubkeys between different channels with this protocol
> either, but that's good practice anyway.
>
> From the same forum post, using child-pays-for-parent seems plausible.
> Doing:
>
>   txA: spend 6 BTC to
>      5 BTC to A&B
>      1 BTC to A
>
>   txB: spend 1 BTC from txA:1 to
>      0.999 BTC to A
>
> should be pretty safe: either someone malleates txA and mines it for
> 0 fee; or they mine both txA+txB for 0.001 BTC fee, and txA can't be
> malleated. But CPFP doesn't work yet, and segregated witness seems like
> it'll happen sooner anyway?
>
> Cheers,
> aj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151128/454bf694/attachment.html>


More information about the Lightning-dev mailing list