From ZmnSCPxj at protonmail.com Thu Apr 27 13:28:57 2017 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Thu, 27 Apr 2017 09:28:57 -0400 Subject: [Lightning-dev] Transaction revocation within transaction malleability via anyone-can-revoke hashlocks In-Reply-To: <87mvb2hckp.fsf@rustcorp.com.au> References: <87mvb2hckp.fsf@rustcorp.com.au> Message-ID: Hi ZmnSCPxj! Good morning Rusty, thank you for your reply. I want to know about whether Lightning can be implemented even without SegWit, given only the current features that could be activated as of today 2017-04. 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. Yes, although you can build a revocation transaction to claim all of your counterparty's funding.in case of fraud. As you mentioned, also normal "watchers" cannot work if the revoked commitment transaction is malleated. However with my burn window, anyone can be a watcher, but they claim the entirety of the fraudulent counterparty's funds, rather than a watching bonus. 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. I'm sorry. I read only the whitepaper and could not find the above text in the whitepaper, so maybe my knowledge is obsolete. My last knowledge is that the proof of revocation is a revocation transaction constructed specifically for the old commitment transaction. But, it means malleation of commitment transaction will disable the revocation transaction. I searched your quoted text and I could find about the lightningnetwork/lightning-rfc repository on github. It seems, this is the "draft" you refer to? Now I'm reading more about this set of documents. I started at BOLT#3 (which contains your quoted text). From what little I could understand, it seems, the conditions for a revocable Bob output are one of: (Bob's private key AND CSV+1) OR (Alice's private key and revocationkey). Thus, the data of the revocationkey is sufficient for Alice to enforce revocation. Is my understanding correct? 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. My concern is that there are countries with difficulty to get Internet, and maybe censorship and so on. If a Lightning Network user is disconnected because of such geopolitical concerns, perhaps the counterparty may attempt to defraud him or her. So I would very much like to have watchers, even if they cannot be trusted to give the money to the poor victim of geopolitical concerns, in order to prevent taking advantage of other's inadvertent disconnection. 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... I understand. From what I can gather so far, it seems, the issue of transaction revocation even with transaction malleability appears to be solved. Although, I want to know, is my idea (which support selfish untrustworthy watchers) better than what Lightning now has? Or has different tradeoffs? It seems to me, at first glance, if the revocation key in my idea is not publicized but sent only to the counterparty, it is effectively equivalent to the current technique. But the receiving counterparty has the option of publishing this revocation key in order to allow anyone to enforce and get free money, even with malleability. Regards, ZmnSCPxj -------------- next part -------------- An HTML attachment was scrubbed... URL: