Hi Zeeman, > 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.
Mapping miners mempools will be a cost in spying infrastructure and thus make the malicious routing node job harder, providing a security improvement for zero-conf channels. I used "lower trust" intentionally, it's not binary (what about opening a channel with a reorg-powerful counterparty ?). > 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. I was assuming a no-mempool mobile LN client, thus not going to be blind by your high-fee RBF. But still able to speak with the p2p network thus you can actively seek that your transaction has been accepted by ~100 peers. Overall, I don't think this scheme is worthy to work on unless double-spend of zero-conf chans become a real issue, just to mention we have potential solutions in this case. > There Ain't No Such Thing As A Global Mempool! I know :) Le mar. 25 août 2020 à 03:38, ZmnSCPxj <zmnsc...@protonmail.com> a écrit : > 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 Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
