listfunds does not contains unconfirmed transactions

[asocjal]

Issue and Steps to Reproduce

1. Create new address by "newaddr" command
2. Send some funds to the newest created address
3. listfunds does not contains this transaction as long, as it is unconfirmed

getinfo output

{ "id": "035a71a8d2e36f5ff894fd6f97225a493e0cdf013c60c3b1c6992be19bd901a9ca", "alias": "cln-tst-01", "color": "035a71", "address": [ { "type": "ipv4", "address": "176.107.130.62", "port": 9735 } ], "binding": [ { "type": "ipv6", "address": "::", "port": 9735 }, { "type": "ipv4", "address": "0.0.0.0", "port": 9735 } ], "version": "v0.6.1", "blockheight": 551232, "network": "bitcoin" }

[kristapsk]

I would also like to have listfunds to output unconfirmed incoming blockchain transactions too.

Probably some additional parameter to specify minimum number of confirmations for listing would be nice to have (like Bitcoin's listunspent have). It could default to 1 (not 0), so the current default behaviour would not change, also 1 is default for minconf for listunspent too.

[kristapsk]

Ahh, but listfunds only shows "status": "confirmed", so either that proposed parameter in my comment above should be confirmed/unconfirmed boolean of listfunds should also show the number of confirmations, for the sake of consistency.

[asocjal]

I pray for give high priority for this feature, as this is the only obstacle that prevent us to finish clightning-based wallet/management tool.

[conscott]

After investigating, this is my understanding...

It looks like, at the moment c-lightning only polls for new block searching for transactions relevant to the addresses it cares about, which explains why you would normally only ever see a "confirmed" state (it's already in a block). Note that in case of a re-org it can be 'undone' and the txid can roll back to "unconfirmed"

It seems in order to add support for listing unconfirmed transactions in listfund you would need to either find these unconfirmed transactions via ZMQ notification or polling getrawmempool. I think ZMQ would be more elegant, but c-lightning already uses polling for blocks rather than ZMQ, so there may be a reason not to do that. Polling getrawmempool (keeping track of set difference from last poll), could possibly be a resource hog if there is a tx burst, so it could get messy.

Any thoughts here @cdecker ?

[darosior]

listfunds now shows confirmation status, so I think this can be closed @asocjal

[cdecker]

It seems in order to add support for listing unconfirmed transactions in listfund you would need to either find these unconfirmed transactions via ZMQ notification or polling getrawmempool. I think ZMQ would be more elegant, but c-lightning already uses polling for blocks rather than ZMQ, so there may be a reason not to do that. Polling getrawmempool (keeping track of set difference from last poll), could possibly be a resource hog if there is a tx burst, so it could get messy.

We have been playing with the idea of using plugins as the interface to the bitcoin network for a while, maybe falling back on bitcoin-cli polling if no plugin can provide a better solution (plugin hook chaining described in #2796 would be useful here). So we could have the plugin notify lightningd about incoming transactions that were observed on the network, but not yet confirmed.

[andrewtoth]

I've created a plugin that has a new RPC, listmempoolfunds, that does exactly this.

[kristapsk]

Hmmm... if the only purpose of specific Bitcoin Core instance is to run CLN on top of it, it can be safely switched to blocksonly mode, CLN does not care about incoming unconfirmed mempool transactions, right? (so some RAM can be saved on VPS where it is expensive resource)

[darosior]

It does care about fee estimation, which needs a mempool. ------- Original Message ------- Le mardi 10 mai 2022 à 1:51 AM, Kristaps Kaupe ***@***.***> a écrit :

…

Hmmm... if the only purpose of specific Bitcoin Core instance is to run CLN on top of it, it can be safely switched to blocksonly mode, CLN does not care about incoming unconfirmed mempool transactions, right? (so some RAM can be saved on VPS where it is expensive resource) — Reply to this email directly, [view it on GitHub](#2104 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AFLK3F6HMO5X7EPGDYMROB3VJGQIPANCNFSM4GGEJS5A). You are receiving this because you commented.Message ID: ***@***.***>

[kristapsk]

Ahhh, right, CLN calls estimatesmartfee.