From matsjj at gmail.com Fri Nov 27 09:10:13 2015 From: matsjj at gmail.com (Mats Jerratsch) Date: Fri, 27 Nov 2015 10:10:13 +0100 Subject: [Lightning-dev] Payment channel without timeout protected from malleability In-Reply-To: References: Message-ID: Hm interesting. Couple of remarks: (1) 'without timeout' is only possible with OP_CSV - not naturally with what we have currently. ;) (2) 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. But I guess we can solve this by B demanding the transaction he signed before proceeding to accept any payments. B can then reassure himself that this transaction indeed resolves to the hash he signed and that it is revocable by B with any following commitments. Beside the pubkey we also need some revocation hash provided by B for creating the commitment transaction. (3) While this is a fair setup already, it does only protect us against targeted attacks against a specific transaction. An attacker could still mine a block with all P2SH transactions (probably not even that many) changed. If you have a large amount of hashing power, you can open up channels with hundreds of parties and then start attacking the network. It can be mitigated by waiting some time before broadcasting his anchor, but even then it remains some hack, and theres some chance someone will lose money doing that. 2015-11-27 8:37 GMT+01:00 Nicolas Dorier : > 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. > > B can't identify A's anchor before announcement because he does not know the > P2SH of the multisig. > > Am I missing something ? > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >