From ZmnSCPxj at protonmail.com Tue Aug 25 02:38:15 2020 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Tue, 25 Aug 2020 02:38:15 +0000 Subject: [Lightning-dev] Proposal for skip channel confirmation. In-Reply-To: References: Message-ID: Good morning Antoine, > Hi Roei, > You might have a mechanism to lower trust in zero-conf channel opener. Actually the local party can be in charge of broadcasting the funding transaction, thus ensuring it's well-propagated across network mempools and then start to accept incoming payment on the zero-conf channel. Per BIP 125 rules, a malicious funder/opener would have to pay a higher fee to replace the channel funding tx and thus double-spend the HTLC. A local party may require a higher fee funding transaction than it is necessary wrt ongoing congestion to increase level of protection. And I think it's okay on the economic-side, you will amortize this fee premium on the channel lifecycle. Until the transaction gets confirmed you might only accept HTLC under this fee. So you have game-theory security for your zero-conf channels as it would cost more in fees than a HTLC double-spend win for the malicious opener, under the assumption of non-miner-collusion with the attacker. Since RBF is opt-in for Bitcoin Core nodes, and I believe most miners are running Bitcoin Core, it is trivial to double-broadcast. i.e. I send my high-fee RBF-enabled channel funding to you, at the same time I send a conflicting low-fee RBF-disabled transaction (that pays the entire channel amount to myself) to all the miners I can find. Since the miners received an RBF-disabled tx, they will not evict it even if they see a higher-fee RBF-enabled tx. And your fullnode will not see the conflicting low-fee RBF-disabled tx either because it is lower fee than what you have in your mempool and you will reject it. You really have to trust that I do not do this when I offer a channel to you. There Ain't No Such Thing As A Global Mempool! Regards, ZmnSCPxj