[Lightning-dev] Proposal for skip channel confirmation.

ZmnSCPxj ZmnSCPxj at protonmail.com
Thu Aug 27 01:29:55 UTC 2020


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


More information about the Lightning-dev mailing list