Good morning Antoine, > 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 ?).
A reorg-powerful entity would destroy all assumptions depended upon by higher layers, I think, and would be an extinction event on all higher layers. In particular, any timelock-based higher layer is at risk for anyone powerful enough to reorg, as they could potentially delay non-timelocked transactions to after the timelock expires. Mapping miner nodes is indeed a cost, but not a high one IMO --- presumably miners are the ones who get blocks earlier than everyone else, and would be incentivized to e.g. unsolicited `block` push, though I am uncertain if that has ever been implemented. > > 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. That seems to be a fairly high amount of bandwidth in `inv` messages? You also need to select the peers in a way that attackers find hard to predict, else sybil is possible. Hmmm. > 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. 0-conf is simply not safe, and I do not think this increases the costs on breaking the mechanism enough. With all that said, once deeply confirmed, the channel becomes perfectly safe. And in general, most 0-conf channel mechanisms are usually set up such that the one offering the 0-conf channel is a fiat-to-Bitcoin exchange, with a `push_msat` non-gift that is actually the equivalent amount of a number of fiat units. As it involves fiat, tr\*st is necessary anyway, so it is a negligible degradation of security in practice. And once the channel *does* get confirmed deeply, it is upgraded automatically to trust-reduced. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
