This might not be good practice.. especially if RBF is enabled. can easily exploit things.

We should always wait for confirmations.

This might not be good practice.. especially if RBF is enabled. can easily exploit things.

@nolimit How do you think this could be easily exploited?

Normally a merchant shouldn't accept a zero conf transaction for goods because if the customer has the goods and then double spends the transactions back to themselves then the merchant has lost the goods and doesn't have the payment.

That isn't relevant in the scenario of Umbrel. Users shouldn't be receiving transactions from third parties in the on-chain wallet on Umbrel, only depositing themselves for opening channels. They also aren't giving out goods. And transaction double spends also aren't very easy to pull off without RBF.

So the worse case scenario would be if an Umbrel user:

• was accepting transactions from other people on their on-chain dashboard wallet (not intended use case)
• the sender then double spent the transaction (not that easy to pull off)
• Umbrel user then immediately opens a channel with this exact UTXO (unlikely)
• now the channel will just not be opened (not that bad)

That's not a very likely scenario and the downsides are minor.

Compared with the current situation for all users in the common scenario of depositing some funds and opening some channels:

• Deposit funds on Umbrel
• Go to open channel (error due to no confirmations)
• Wait
• Go to open channel (works)
• Go to open another channel (error due to no confirmations)
• Wait
• Go to open channel (works)

This is a pretty poor user experience and it would be solved by allowing channels to be opened with unconfirmed UTXOs.

We should always wait for confirmations.

There are times when it's not that important to wait for confirmation. e.g when the transaction comes from yourself so you know it won't be double spent or if there are no downsides to the UTXO being double spent (both applicable here).

I don't see a non trivial way to implement fee calculations with this since all our current logic requires on LNDs estimateFee RPC which only takes confirmed inputs into account.

Relevant issue here: lightningnetwork/lnd#4764