Maker closes channel due to unconfirmed funding transaction

[holzeis]

env: regtest

2022-11-29 10:08:56 DEBUG ten_ten_one::lightning: Received ChannelClosed { channel_id: [244, 7, 171, 215, 235, 60, 118, 135, 15, 108, 121, 122, 8, 175, 213, 174, 63, 41, 130, 20, 7, 19, 82, 83, 170, 226, 233, 87, 56, 116, 61, 173], user_channel_id: 0, reason: CounterpartyForceClosed { peer_msg: "Channel closed because of an exception: Funding transaction was un-confirmed. Locked at 0 confs, now have 0 confs." } }

Even though I am fauceting several times after opening a channel.

How to reproduce

0. clean maker and taker directories
1. fund taker (and maker if not already)
2. open channel (this will succeed)
3. mine a block

---

This might not be necessary, but I always did in my test scenarios. At least it verifies that the channel is actually usable.

5. open a cfd
6. settle cfd

---

7. close channel
8. mine a block
9. open channel
10. mine a block

--- It seems at this point we are in a broken state, opening a CFD will fail, even though we got a ChannelReady event.

Eventually the channel will be force-closed with the message above.

[holzeis]

It seems the issue is only happening when closing a channel. There is a state between an openend channel until it gets closed again where the channel appears to be unavailable resulting in the following error when trying to open a CFD.

{FfiException(RESULT_ERROR, Could not retrieve short channel id, null)}

[holzeis]

Judging from the rust-lightning code, it looks like this error should only happen upon a reorg

https://github.com/lightningdevkit/rust-lightning/search?q=Funding+transaction+was+un-confirmed.

However, I couldn't identify a reorg when watching closely at http://localhost:5000/blocks/recent.

[holzeis]

Also it looks like that if the wallet is not synced the short channel id is not yet set, so we have to wait some time before opening a CFD succeeds. I guess this was always the case, but wasn't that obvious since we synced much more frequent than now. Note, we are now syncing only once a minute - and this is about the time you have to wait to open a cfd after opening a channel. @bonomat What was the reason for reducing the frequency? as this seems also to be the reason for #427.

[holzeis]

Tested on testnet

• At step 9/10 the channel remains open and does not get closed
• List channels also show the created channel, however the channel is not usable
• CFD can't be opened, due to unusable channel - Could not retrieve short channel id

[holzeis]

@luckysori: It looks like this scenario only happens after a channel has been closed. I have the suspicion that we are using something like first channel somewhere. I haven't found anything in our code. Can you have a look at our rust-lightning fork?

[luckysori]

@luckysori: It looks like this scenario only happens after a channel has been closed. I have the suspicion that we are using something like first channel somewhere. I haven't found anything in our code. Can you have a look at our rust-lightning fork?

Does it happen every time a channel has been closed or just sometimes? I thought it only happened sometimes, which is why the source of the bug has been hard to pin down thus far.

[bonomat]

@bonomat What was the reason for reducing the frequency?

The reasoning for this was that scanning the blockchain is expensive and usually things don't happen that fast on-chain, e.g. we have 10 min block time.

[bonomat]

as this seems also to be the reason for #427.

I don't think this is related. The issue might come from us syncing the frontend in two steps:
https://github.com/itchysats/10101/blob/a7c7e8bc1e2ab2a55cf4295630d8f80a79807bd2/lib/main.dart#L228-L231

[holzeis]

@luckysori: It looks like this scenario only happens after a channel has been closed. I have the suspicion that we are using something like first channel somewhere. I haven't found anything in our code. Can you have a look at our rust-lightning fork?

Does it happen every time a channel has been closed or just sometimes? I thought it only happened sometimes, which is why the source of the bug has been hard to pin down thus far.

For me it happened every time.. and only when I close a channel.

[holzeis]

@bonomat What was the reason for reducing the frequency?

The reasoning for this was that scanning the blockchain is expensive and usually things don't happen that fast on-chain, e.g. we have 10 min block time.

I agree on confirmed transactions, but what about transactions in the mempool..? these could come very quickly and would already provide some feedback to the users actions?

[bonomat]

I agree on confirmed transactions, but what about transactions in the mempool..? these could come very quickly and would already provide some feedback to the users actions?

Unfortunately we cannot sync only the mempool and querying against electrs is unfortunately expensive.

On a different note: I know that people are always pushing for speed, but a transaction in mempool might not mean anything yet. It can drop out due to low fees (happened to us before), or it can be replaced by another (happened as well). Meaning, doing an action based on an external transaction (not created from within our app) based on seeing it in the mempool is not the best idea.

[bonomat]

This was hopefully solved by @luckysori in get10101/bdk-ldk@c66ad84

[klochowicz]

On a different note: I know that people are always pushing for speed, but a transaction in mempool might not mean anything yet. It can drop out due to low fees (happened to us before), or it can be replaced by another (happened as well). Meaning, doing an action based on an external transaction (not created from within our app) based on seeing it in the mempool is not the best idea.

some wallets have a switch "better UX / safety" in their settings so that the user can choose which behaviour they prefer - awaiting for more confirmations or showing things ASAP at the risk of it dropping out of the mempool