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 _______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
