[bug]: On signet, min-relay-fee is not met if fee is not specified. Fee will be 1 sat short

[habibitcoin]

Background

When using signet, it seems that calls to AnchorVirtualPSBT RPC and to SendAsset RPC will result in a transaction that does not meet the min-relay-fee. The vsize of the transaction ends up being 254.5 vB usually (see https://mempool.space/signet/tx/aff4e70f1816ec611da03a89889be79b81b57067355abe99c14e89f0f2085ba8#vin=0 as an example).

Here is an example txn that will not relay with a fee rate of barely under 1.00 sats/vB (size is 254.5, fee is 254)

02000000000102aee61b60b329cd99950230a146a11b16ff53c85109d352aee5a5e87088f62b990000000000000000000c6c3c8409df4c95942069945a9cd867d657d13b635814d7884580d9c74a64be01000000000000000003e803000000000000225120b5b88d39d530a564e1b6e2b714e0d4c16bc284b49778898f98faffd8db135b13e803000000000000225120b59492b62792ca980cd5dd087099897d63b6f85fea0680a43e792d70191ee54d00b5eb0b00000000225120d430711c2a954904278394c6c9378713534a2d1d5c37fbea58deebef95596cea0140510398932e106f72156dc13213a7999ef77544a8bf5ee11b7b24859555908b8bd18b30c5889233c95abcc4f7cd2dddc2eab36266f89c38adb137c6e6bdda3a960140a2ccf5834b81952fe1c3eac8276743d6c4571ba232cc98ea0129e7b3582cca21dab09f0f953b98e5f0f8768ec0a4fd400a6b36cc496cb96cef7c47ba75fde17300000000

I'm not sure exactly the problem here, perhaps something related to the nature of signet transactions (I havent seen this problem on other networks). Also unfortunately it seems not everyone has adopted package relay, so unable to use CPFP via package relay to unstuck the above txn using the below child:

02000000000101f18d47aae097b364ad0dc9409c8b917db47cf1f1535606283614b943d84ed4c202000000000000000001a784eb0b0000000022512044be1fcf86a056efc21c6775b3b348756f3e099a3da70bbe5726558db2b595ac0140b16fcf7770feb3190b6a1bc524c3f80244e7d09399e66808a91594b16289d2b25d341e597834fc7622dc5857576c1a3d72592fce3105636cd5b7a2aad3438e597f5d0300

Your environment

tapcli getinfo                       # version of `tapd`, `lnd`, and network
{
    "version": "0.4.1-alpha commit=622c7929",
    "lnd_version": "0.18.3-beta",
    "network": "signet",
    "lnd_identity_pubkey": "026580b3316c7b10f487235d8e3247ba960f4d96952aa0edb85a4e096501bb4acc",
    "node_alias": "Tajfi",
    "block_height": 220574,
    "block_hash": "00000109ab0a6ba26dd8b8fb078368e5af4d8ad6fbaca796933d1d1cc4ab6a82",
    "sync_to_chain": true
}
uname -mrsv                          # operating system 
Linux 6.8.0-1015-gcp #17~22.04.1-Ubuntu SMP Tue Sep  3 16:11:52 UTC 2024 x86_64

bitcoind --version  # version of `btcd`, `bitcoind`, or other backend
Bitcoin Core version v28.0.0

Steps to reproduce

Mint any asset and finalize the batch. Then try to spend the asset using the CLI and do NOT specify a fee rate.

Expected behavior

Transaction should be generated with 254.5 sats --> round up to 255 sats

Actual behavior

Transaction generated is 254 sats

[dstadulis]

@habibitcoin was this behavior encountered while using litd or tapd?

[habibitcoin]

@dstadulis was using tapd specifically

[gijswijs]

I wasn't able to reproduce the issue, but for testing purposes I use regtest. so that might have to do with it.

What I did is create an itest that creates a synthetic situation where the fees don't meet the min relay fee. That way I recreated the issue. PR #1191 should fix this by bumping the fees to the min relay fee before broadcasting.

[habibitcoin]

awesome @gijswijs that should work! and yeah, i couldn't reproduce on regtest either, seemed to be strictly a signet issue

[jharveyb]

What chain backend are you using for the lnd that's backing tapd for your signet setup?

It's possible that the fee floor LND is using is misconfigured, or the min relay fee LND is reading from that chain backend is not being propagated correctly.

From mempool.space it looks like the feerate for signet is often 1 sat/vB, but I think LND has sanity checks before TX broadcast that maybe should have caught this anyways.

[kallerosenbaum]

I was asked to comment on this issue.

I encountered a similar issue on LITD 0.14.1-alpha.rc2 (first reported on slack: https://lightningcommunity.slack.com/archives/C03B3556HQ8/p1738575364775059). Copy-pasting it here:

I tried to send assets from one integrated litd node to another. But it seems the transaction feerate was below minrelayfee. Here's the log for the send:

2025-01-31 15:25:11.835 [INF] LITD: Handling gRPC request: /taprpc.TaprootAssets/SendAsset
2025-01-31 15:25:11.850 [INF] FRTR: Received to send request to 1 addrs: [TapAddr{id=607d62db87f540810dae9ed354a870c0a2588110be8036d5bb12050aae4ca3c5, amount=1000000000, script_key=022930
658a1adb7b11c34758e973d8113fe613c07f43c92b33ab536a9422095969}]
2025-01-31 15:25:11.850 [INF] FRTR: ChainPorter executing state: SendStateVirtualCommitmentSelect
2025-01-31 15:25:11.864 [INF] FRTR: Identified 1 eligible asset inputs for send of 1000000000 to group_key=0346fc2f578cec4edeb70a127d207c6b12e27512ef5f7d12b037568665ba6c8dd5, asset_id=607
d62db87f540810dae9ed354a870c0a2588110be8036d5bb12050aae4ca3c5, min_amt=1000000000: [3218a98b6c6a32b3c5e5134af0b4258226155cdf1385efc778f04ae276130902:0]
2025-01-31 15:25:11.870 [INF] FRTR: Selected 1 asset inputs for send of 1000000000 to 607d62db87f540810dae9ed354a870c0a2588110be8036d5bb12050aae4ca3c5
2025-01-31 15:25:11.881 [INF] FRTR: ChainPorter executing state: SendStateVirtualSign
2025-01-31 15:25:11.881 [INF] FRTR: Generating Taproot Asset witnesses for send to: 022930658a1adb7b11c34758e973d8113fe613c07f43c92b33ab536a9422095969
2025-01-31 15:25:11.883 [INF] FRTR: ChainPorter executing state: SendStateAnchorSign
2025-01-31 15:25:11.892 [INF] FRTR: estimated fee rate for parcel:, 1952 sat/kvb
2025-01-31 15:25:11.900 [INF] FRTR: Sending with fee rate: 1952 sat/kvb
2025-01-31 15:25:11.900 [INF] FRTR: Constructing new Taproot Asset commitments for send to: 022930658a1adb7b11c34758e973d8113fe613c07f43c92b33ab536a9422095969
2025-01-31 15:25:11.921 [INF] FRTR: Received funded PSBT packet
2025-01-31 15:25:11.923 [INF] FRTR: PSBT absolute fee: 254 sats
2025-01-31 15:25:11.925 [INF] FRTR: ChainPorter executing state: SendStateStorePreBroadcast
2025-01-31 15:25:11.935 [INF] FRTR: Committing pending parcel to disk
2025-01-31 15:25:11.942 [INF] FRTR: ChainPorter executing state: SendStateBroadcast
2025-01-31 15:25:11.944 [INF] LNWL: Imported address bc1pdmzrfqd9surnqd66wlqm6ghqsss7lgjrs67nf3sauhk2d4nhe5wstu89qt
2025-01-31 15:25:11.944 [INF] FRTR: Broadcasting new transfer tx, txid=e573ad52c31bdbd34fa3c4ef482b34077bee8f13a8e38aec50061bed65d3c66e
2025-01-31 15:25:11.947 [ERR] BTCN: Broadcast attempt failed: <nil>
2025-01-31 15:25:11.949 [WRN] BTWL: Transaction e573ad52c31bdbd34fa3c4ef482b34077bee8f13a8e38aec50061bed65d3c66e not accepted by mempool: min relay fee not met
2025-01-31 15:25:11.949 [ERR] RPCS: [/walletrpc.WalletKit/PublishTransaction]: undefined: min relay fee not met
2025-01-31 15:25:11.949 [ERR] FRTR: Error evaluating state (SendStateBroadcast): unable to broadcast transaction e573ad52c31bdbd34fa3c4ef482b34077bee8f13a8e38aec50061bed65d3c66e: rpc erro
r: code = Unknown desc = undefined: min relay fee not met
2025-01-31 15:25:11.950 [ERR] RPCS: [/taprpc.TaprootAssets/SendAsset]: unable to broadcast transaction e573ad52c31bdbd34fa3c4ef482b34077bee8f13a8e38aec50061bed65d3c66e: rpc error: code = 
Unknown desc = undefined: min relay fee not met

Unfortunately, the exact command I used to send is lost, but I think the command I issued might have looked like this:

tapcli --tlscertpath ~/.lit/tls.cert --rpcserver localhost:8443 --network=mainnet assets send --addr tapbc1qqqszqspqqzzqcravtdc0a2qsyx6a8kn2j58ps9ztzq3p05qxm2mkys9p2hyeg79q5ssx3hu9atcemzwm6ms5ynayp7xkyhzw5fw7hmaz2crw45xvkaxerw4qcss975znp95wtmszefsxtk4xaj2k9eqx3tfpy8pk8p806fc7s2xu2c3pqssycc8u995ddzyagzm89l9y3h3g8fvcz862tf3drpnlrfrsezq9h54pgyl7qqqqqp9gzlyqqxzuatwd9mx2unnv4e8qce69uhh2mnfwejhyum99ekxjemgw3hxjmn89enxjmnpde3k2w33xqcrywgv8fc89 --sat_per_vbyte 2

I'm not sure whethere I actually entered the --sat_per_vbyte option or what value I entered (but I recall something like 2). If I skipped the option, then why is the feerate set to 1952 sat/kvb (which is well above minrelayfee of 1000 sat/kvb) instead of 0 (default)?
Anyhow, is there a way out of this situation? Is there a way to undo this transaction? It locks up all my issued assets.

lnd-assets-main-0:~# litd --version
litd version 0.14.1-alpha.rc2 commit=v0.14.1-alpha.rc2

[gijswijs]

Based on this message in the log file estimated fee rate for parcel:, 1952 sat/kvb we can tell that no fee was set. In those cases it does not default to 0, but to EstimateFee from the WalletKit. It then checks against the min_relay_fee tapd knows about and it would bump the fee if the estimated rate doesn't meet the min_relay_fee. I can tell from the logs that it did not do that, so at that moment tapd was confident that the min_relay_fee was met.

It's really weird that it then doesn't meet the actual min_relay_fee. I can only assume that the estimation and the "view" of the WalletKit on the state of the mempool was incorrect. But the Tx didn't even hit the mempool, and tapd knows about the failed transaction, so you should be able to just try again. Maybe try it after a restart of litd/tapd with --sat_per_vbyte 2 which should do the trick. Please report back if that doesn't work out for you.

[kallerosenbaum]

It retries the broadcast upon restart:

2025-02-03 14:39:58.701 [INF] GRDN: Starting asset custodian
2025-02-03 14:39:58.701 [INF] GRDN: Gardener for ChainPlanter now active!
2025-02-03 14:39:58.701 [INF] GRDN: Loading pending inbound asset events
2025-02-03 14:39:58.701 [INF] RPCS: New transaction subscription
2025-02-03 14:39:58.702 [INF] GRDN: Starting re-org watcher
2025-02-03 14:39:58.702 [INF] NTFN: New block epoch subscription
2025-02-03 14:39:58.702 [INF] GRDN: New block at height 882140
2025-02-03 14:39:58.703 [INF] GRDN: Resuming 0 pending inbound asset events
2025-02-03 14:39:58.703 [INF] GRDN: Loading wallet transactions starting at block height 0
2025-02-03 14:39:58.709 [INF] GRDN: Checking 3 wallet transactions for inbound assets, this might take a while
2025-02-03 14:39:58.709 [INF] GRDN: Starting main custodian event loop
2025-02-03 14:39:58.712 [INF] FRTR: Starting ChainPorter
2025-02-03 14:39:58.717 [INF] FRTR: Attempting to resume asset transfer for 1 parcels
2025-02-03 14:39:58.717 [INF] FRTR: Encountered pending parcel (anchor_txid=e573ad52c31bdbd34fa3c4ef482b34077bee8f13a8e38aec50061bed65d3c66e, count_undelivered_proofs=1)
2025-02-03 14:39:58.717 [INF] UNIV: Starting FederationEnvoy
2025-02-03 14:39:58.717 [INF] FRTR: ChainPorter executing state: SendStateBroadcast
2025-02-03 14:39:58.718 [ERR] RPCS: [/walletrpc.WalletKit/ImportTapscript]: error importing script into wallet: address for script hash/key 6ec43481a5870730375a77c1bd22e08421efa24
386bd34c61de5eca6d677cd1d already exists
2025-02-03 14:39:58.718 [INF] FRTR: Broadcasting new transfer tx, txid=e573ad52c31bdbd34fa3c4ef482b34077bee8f13a8e38aec50061bed65d3c66e
2025-02-03 14:39:58.720 [ERR] BTCN: Broadcast attempt failed: <nil>
2025-02-03 14:39:58.723 [WRN] BTWL: Transaction e573ad52c31bdbd34fa3c4ef482b34077bee8f13a8e38aec50061bed65d3c66e not accepted by mempool: min relay fee not met
2025-02-03 14:39:58.723 [ERR] RPCS: [/walletrpc.WalletKit/PublishTransaction]: undefined: min relay fee not met
2025-02-03 14:39:58.723 [ERR] FRTR: Error evaluating state (SendStateBroadcast): unable to broadcast transaction e573ad52c31bdbd34fa3c4ef482b34077bee8f13a8e38aec50061bed65d3c66e: 
rpc error: code = Unknown desc = undefined: min relay fee not met

And retrying the send with 4 sat/vb still doesn't work:

lnd-assets-main-0:/# tapcli --tlscertpath ~/.lit/tls.cert --rpcserver localhost:8443 --network=mainnet assets send --addr tapbc1qqqszqspqqzzqcravtdc0a2qsyx6a8kn2j58ps9ztzq3p05qxm2mkys9p2hyeg79q5ssx3hu9atcemzwm6ms5ynayp7xkyhzw5fw7hmaz2crw45xvkaxerw4qcss975znp95wtmszefsxtk4xaj2k9eqx3tfpy8pk8p806fc7s2xu2c3pqssycc8u995ddzyagzm89l9y3h3g8fvcz862tf3drpnlrfrsezq9h54pgyl7qqqqqp9gzlyqqxzuatwd9mx2unnv4e8qce69uhh2mnfwejhyum99ekxjemgw3hxjmn89enxjmnpde3k2w33xqcrywgv8fc89 --sat_per_vbyte 4
[tapcli] unable to send assets: rpc error: code = Unknown desc = unable to fund address send: unable to list eligible coins: failed to find coin(s) that satisfy given constraints; if previous transfers are un-confirmed, wait for them to confirm before trying again

[ffranr]

This should solve the coin locking issue: #1348
Does not resolve the fee related problem.

[guggero]

Unfortunately we have to convert to sat/vByte on the RPC level when funding the PSBT:

taproot-assets/wallet_anchor.go

Line 84 in e111765

SatPerVbyte: uint64(feeRate.FeePerKVByte()) / 1000,

This converts the 1.952 sat/vByte (1952 sat/kvByte) down to 1 sat/vByte which is not enough.
I think we short term have to do a min relay fee aware conditional round up and long-term add a sat/kw unit on the FundPsbt RPC on the lnd side.

[gijswijs]

#1354 fixes this issue fully afaict.

We are also working on a solution where we cancel these stuck parcels and release the assets so that a user can retry but that is a bit more involved. Also, the particular way that @kallerosenbaum's parcel got stuck will not happen anymore with the fix mentioned above.

I think (but am not 100% sure) that updating to the latest build (don't forget to do a backup!) and restarting would probably get @kallerosenbaum's payment unstuck. But since you were on signet, I'm not even sure if this is needed anymore. Also, waiting for the next release is probably the better option.

Closing this issue.