From rusty at rustcorp.com.au Thu Apr 27 01:19:18 2017 From: rusty at rustcorp.com.au (Rusty Russell) Date: Thu, 27 Apr 2017 10:49:18 +0930 Subject: [Lightning-dev] Transaction revocation within transaction malleability via anyone-can-revoke hashlocks In-Reply-To: References: Message-ID: <87mvb2hckp.fsf@rustcorp.com.au> Hi ZmnSCPxj! Your suggestion for a "burn window" is interesting, but it still allows the attacker to burn your coins. The attacker also has a chance to steal the coins themselves; quite a good chance if they are a miner. The current draft uses a revocation key, which only the sender knows; this part is actually malleation-proof: The revocationkey is a blinded key: the remote node provides the base, and the local node provides the blinding factor which it later reveals, so the remote node can use the secret revocationkey for a penalty transaction. The DoS problem is a difficult one, but in practice it's very hard to cut someone off the bitcoin network for very long; they can always send out a transaction via various web interfaces on their phone if they have to. But even the DoS problem is prevented by Tadge's watchers, though they *are* subject to malleation. There was a suggestion in the original Lightning paper to add a TX_NOINPUT sighash flag, which would allow watchers to operate even in the case where malleation occurred. But as that would be a soft fork too, we're better off waiting for SegWit... Thanks for your input! Rusty. ZmnSCPxj via Lightning-dev writes: > One primitive that is necessary for bidirectional channels is revocable transactions. Briefly, in the absence of transaction malleability, in order to generate a revocable output, the output is encumbered such that either the receiver can receive the output after some time (via CSV opcode), or the output may be signed by both the sender and receiver. If the receiver wants to provide a proof of revocation, the receiver constructs a revocation transaction spending the output and sending it to the sender. The receiver signs that transaction and gives it to the sender. If the receiver subsequently attempts to realize the revoked output by broadcasting its transaction on the public blockchain, the sender may revoke it by sending the revocation transaction. > > However, in the presence of malleability, a fraudluent receiver may simply malleate the transaction producing the output. The output will then be referred to via a different txid, invalidating the existing revocation transaction. > > Another issue with this style of revocable transactions is that it is still possible for the receiver to defraud the sender via a two-prong attack: the sender DDOS'es or otherwise prevents the sender from successfully sending the revocation transaction, and transmits the revoked transaction on the network. If the receover is capable of keeping the sender off-network until the CSV expires, the receiver may defraud the sender. It would be desirable if a separate bounty hunter may be hired in order to prevent fraud, so that the fraudulent receiver needs to keep many more agents away from the Bitcoin network. > > Fortunately, a single solution fixes both issues. > > When constructing a revocable output, the receiver first generates a secure truely random number, the revocation key. The revocation lock is the hash of the revocation key (i.e. hashlock). The revocable output may be spent in any of the following conditions: > > 1. After CSV +2 days, by the receiver. > > 2. By the sender, if the sender can show the revocation key. > > 3. After CSV +1 days, by anyone who can show the revocation key (anyone can revoke). > > To revoke the revocable output, the receiver of the revocable output publishes the revocation key to the sender and to any interested participants in the Lightning Network. > > If the output has not been revoked, the receiver has never published the revocation key and simply needs to wait 2 days to spend. > > If the output has been revoked, and the receiver attempts to realize the revoked output on the Bitcoin network, if the sender is online, it can construct a revocation transaction by itself by signing the transaction and showing the published revocation key. > > In addition, if the sender is unavailable or disconnected, after 1 day, anyone who has heard and kept the revocation key may claim the receiver's coins. Thus, the receiver, in order to use a revoked output, needs to prevent everyone to whom the revocation key has been sent from the Bitcoin network during the 1 day between the CSV+1 and CSV+2 periods. > > I would like to know if my consideration is correct or if I have missed or incorrectly analyzed some aspect of transaction revocation. > > I hope for your discussion. > > Regards, > ZmnSCPxj > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev