TX for claiming funds for a peer's swap-in fails to be broadcasted?

[tsjk]

Running CLN v23.11.2 with peerswap 9d41480.

Scenario:
Peer initiated swap-in, but the on-chain funds never arrived to my wallet. Note that there are no errors or anything indicating strangeness. Just funds unclaimed. =)

From my side the status is:

      "asset": "lbtc",
      "type": "swap-in",
      "role": "receiver",
      "state": "State_ClaimedPreimage",

CLN logs:

2024-12-27T04:33:17.827Z DEBUG   plugin-peerswap: [Messenger] From: <nodeid> got msgtype: a455 for swap: <swapid>
2024-12-27T04:33:17.858Z INFO    lightningd: Sending <amount>000msat over 1 hops to deliver <amount>000msat
2024-12-27T04:33:26.728Z INFO    <nodeid>-chan#212: htlc 2549 failed from 0th node with code 0x400f (WIRE_INCORRECT_OR_UNKNOWN_PAYMENT_DETAILS)
2024-12-27T04:33:27.161Z DEBUG   plugin-peerswap: [FSM] event:id: <swapid>, Event_SwapInReceiver_OnRequestReceived on
2024-12-27T04:33:27.169Z DEBUG   plugin-peerswap: [FSM] event:id: <swapid>, Event_ActionSucceeded on State_SwapInReceiver_CreateSwap
2024-12-27T04:33:27.170Z INFO    plugin-peerswap: [Swap:<swapid>] swap-in request received: peer: <nodeid> chanId: <chanId> initiator: <nodeid> amount <amount>
2024-12-27T04:33:27.174Z DEBUG   plugin-peerswap: [FSM] event:id: <swapid>, Event_ActionSucceeded on State_SwapInReceiver_SendAgreement
2024-12-27T04:33:27.851Z DEBUG   plugin-peerswap: [Messenger] From: <nodeid> got msgtype: a45d for swap: <swapid>
2024-12-27T04:33:28.013Z DEBUG   plugin-peerswap: [FSM] event:id: <swapid>, Event_OnTxOpenedMessage on State_SwapInReceiver_AwaitTxBroadcastedMessage
2024-12-27T04:33:28.032Z INFO    plugin-peerswap: adding tx watcher for <swapid>
2024-12-27T04:33:28.032Z DEBUG   plugin-peerswap: starting chain observer for <swapid>
2024-12-27T04:33:28.034Z DEBUG   plugin-peerswap: Await confirmation for tx with id: <txid> on swap <swapid>
2024-12-27T04:33:28.034Z DEBUG   plugin-peerswap: new block height=3180754, starting_height=3180754, safety_limit=30 for <swapid>
2024-12-27T04:33:35.648Z DEBUG   plugin-peerswap: new block height=3180755, starting_height=3180754, safety_limit=30 for <swapid>
2024-12-27T04:33:37.793Z DEBUG   plugin-peerswap: [Messenger] From: <nodeid> got same message for swap: <swapid>
2024-12-27T04:33:47.764Z DEBUG   plugin-peerswap: [Messenger] From: <nodeid> got same message for swap: <swapid>
2024-12-27T04:33:57.764Z DEBUG   plugin-peerswap: [Messenger] From: <nodeid> got same message for swap: <swapid>
2024-12-27T04:34:07.755Z DEBUG   plugin-peerswap: [Messenger] From: <nodeid> got same message for swap: <swapid>
2024-12-27T04:34:17.759Z DEBUG   plugin-peerswap: [Messenger] From: <nodeid> got same message for swap: <swapid>
2024-12-27T04:34:27.789Z DEBUG   plugin-peerswap: [Messenger] From: <nodeid> got same message for swap: <swapid>
2024-12-27T04:34:36.200Z DEBUG   plugin-peerswap: new block height=3180756, starting_height=3180754, safety_limit=30 for <swapid>
2024-12-27T04:34:37.775Z DEBUG   plugin-peerswap: [Messenger] From: <nodeid> got same message for swap: <swapid>
2024-12-27T04:34:47.791Z DEBUG   plugin-peerswap: [Messenger] From: <nodeid> got same message for swap: <swapid>
2024-12-27T04:34:57.766Z DEBUG   plugin-peerswap: [Messenger] From: <nodeid> got same message for swap: <swapid>
2024-12-27T04:35:07.767Z DEBUG   plugin-peerswap: [Messenger] From: <nodeid> got same message for swap: <swapid>
2024-12-27T04:35:17.756Z DEBUG   plugin-peerswap: [Messenger] From: <nodeid> got same message for swap: <swapid>
2024-12-27T04:35:27.772Z DEBUG   plugin-peerswap: [Messenger] From: <nodeid> got same message for swap: <swapid>
2024-12-27T04:35:35.608Z DEBUG   plugin-peerswap: new block height=3180757, starting_height=3180754, safety_limit=30 for <swapid>
2024-12-27T04:35:35.804Z DEBUG   plugin-peerswap: [FSM] event:id: <swapid>, Event_OnTxConfirmed on State_SwapInReceiver_AwaitTxConfirmation
2024-12-27T04:35:37.790Z DEBUG   plugin-peerswap: [Messenger] From: <nodeid> got same message for swap: <swapid>
2024-12-27T04:35:45.879Z INFO    lightningd: Sending <amount>000msat over 1 hops to deliver <amount>000msat
2024-12-27T04:35:47.798Z DEBUG   plugin-peerswap: [Messenger] From: <nodeid> got same message for swap: <swapid>
2024-12-27T04:35:50.253Z DEBUG   plugin-peerswap: [FSM] event:id: <swapid>, Event_ActionSucceeded on State_SwapInReceiver_ValidateTxAndPayClaimInvoice
2024-12-27T04:35:50.253Z DEBUG   plugin-peerswap: [FSM] event:id: <swapid>, Event_ActionSucceeded on State_SwapInReceiver_ClaimSwap
2024-12-27T04:35:50.253Z INFO    plugin-peerswap: [Swap:<swapid>] Swap claimed with preimage <preimage>
2024-12-27T04:40:09.098Z INFO    <nodeid>-channeld-chan#212: Peer connection lost
2024-12-27T04:40:09.098Z INFO    <nodeid>-chan#212: Peer transient failure in CHANNELD_NORMAL: channeld: Owning subdaemon channeld died (62208)
2024-12-27T04:41:00.405Z INFO    <nodeid>-channeld-chan#212: Splice resume check with local_next_funding: omitted, remote_next_funding: empty, inflights: 0

elementsd (Elements Core version v23.2.4 (release build)) logs:

2024-12-27T04:35:49Z [peerswap] keypool added 1 keys (1 internal), size=2000 (1000 internal)
2024-12-27T04:35:49Z [peerswap] keypool reserve <n>
2024-12-27T04:35:49Z [peerswap] keypool keep <n>
2024-12-27T04:35:50Z [peerswap] AddToWallet <txid>  new

listtransactions:

  {
    "address": "<address>",
    "category": "receive",
    "amount": n.m,
    "amountblinder": "...",
    "asset": "...",
    "assetblinder": "...",
    "label": "peerswap -- ClaimByInvoice(swap id=....)",
    "vout": 0,
    "confirmations": 0,
    "trusted": false,
    "txid": "<txid>",
    "walletconflicts": [
    ],
    "time": 1735274150,
    "timereceived": 1735274150,
    "bip125-replaceable": "yes"
  }

[grubles]

Possibly related? From @wtogami on discord:

Discount CT is live on liquid on the default relay nodes and 10/15 of the functionary servers. Two more next week. This means there is currently a 5/15 chance at the moment of needing to wait until the next block. That's good enough to begin using it.

[tsjk]

For the record, this is my first swap where my side is to receive l-btc using v4.0rc1. I have done swaps where my side has sent l-btc.

[tsjk]

I used https://blockstream.info/liquid/tx/push to broadcast my tx in the end. Doing a sendrawtransaction just echoed the txid and seemingly did nothing.

My getinfo:

Chain: liquidv1
Blocks: 3181676
Headers: 3181676
Verification progress: 100.0000%
Difficulty: 

Network: in 3, out 10, total 13
Version: 230204
Time offset (s): 0
Proxies: 10.0.2.2:19050 (ipv4, ipv6, onion, cjdns)
Min tx relay fee rate (BTC/kvB): 0.00000100

Wallet: peerswap
Keypool size: 999
Transaction fee rate (-paytxfee) (BTC/kvB): 0.00000000

Balance: {"bitcoin":Infinity}

Warnings: 

My elements config:

dbcache=512
maxorphantx=256
txindex=1
blockfilterindex=1
coinstatsindex=1
bind=0.0.0.0:xyzw
bind=0.0.0.0:abcd=onion
discover=0
externalip=microsoftconspireswithscammersd.onion
listen=1
listenonion=0
peerbloomfilters=1
peerblockfilters=1
port=xyzw
proxy=tor-proxy:port
upnp=0
whitelist=addr,bloomfilter,download,mempool,noban,relay@10.0.0.0/8
zmqpubhashblock=tcp://0.0.0.0:<port>
zmqpubhashtx=tcp://0.0.0.0:<port>
zmqpubrawblock=tcp://0.0.0.0:<port>
zmqpubrawtx=tcp://0.0.0.0:<port>
logips=1
logtimestamps=1
printtoconsole=1
chain=liquidv1
creatediscountct=1
server=1
rest=1
rpcbind=0.0.0.0
rpcauth=get_phucked:real_hard
rpcport=<rpcport>
rpcallowip=0.0.0.0/0
rpcthreads=8
rpcworkqueue=128
validatepegin=1
mainchainrpchost=10.0.2.2
mainchainrpcport=8332
mainchainrpcuser=get_phucked
mainchainrpcpassword=in_the_arse

[wtogami]

    "subver": "/Elements Core:23.2.2/",
    "subver": "NBXplorer-840652740337079693",
    "subver": "/Elements Core:23.2.2/",
    "subver": "/Elements Core:22.1.1/",
    "subver": "/Elements Core:23.2.2/",
    "subver": "/Elements Core:23.2.4/",
    "subver": "/Elements Core:23.2.2/",
    "subver": "/Elements Core:23.2.2/",
    "subver": "/Elements Core:23.2.1/",
    "subver": "/Elements Core:23.2.2/",
    "subver": "/Elements Core:23.2.1/",
    "subver": "/Elements Core:0.18.1.12/",
    "subver": "/Elements Core:23.2.2/",

An examination of elements-cli getpeerinfo found this node had 100% tor peers. At the moment prior to the enabled-by-default elementsd only the default IPv4 bridge nodes are guaranteed to mempool accept discount CT. I had assumed IPv4 elementsd would not run into this problem because they connect to the IPv4 bridge nodes by default. I had forgotten Tor nodes have a higher chance to not always connect with those nodes. This will become increasingly less likely after the official release.

Temporary workaround: addnode=u35hiqs3xje7dsawqahhlv3ofx4fyqv4rphrostoafmkydn7rjee73qd.onion

This reinforces the fact we should not announce the peerswap v4 release until elementsd discount CT is more widely deployed. In the mean time power users know how to make it work.