synonymdev / bitkit

Self-custodial Bitcoin and Lightning Wallet for Android and iOS.
https://bitkit.to
MIT License
113 stars 23 forks source link

[Bug]: LN Connection established via Blocktank widget stuck pending in Bitkit #2103

Open catch-21 opened 1 month ago

catch-21 commented 1 month ago

Describe the bug

Using the Blocktank widget to create a new LN connection, the payment was made via lightning and the "claim channel" QR was displayed. Payment was instantly received on Blocktank but stuck pending on Bitkit. Proceeding to scan to add LN connection, it was added to bitkit but as pending and status "Opening connection". It took a while for onchain tx to confirm due to slow blocks, but eventually blocktank opened the channel, see internal alert. After 5 confirmations, Bitkit has not realised the connection is open, it still displays "Opening connection".

Order id: 29d25f1f-1f4e-495b-b4e7-7d862559642c


Second recreation

On second attempt to recreate, the payment to Blocktank was received and stuck pending on Bitkit again. This somehow caused the channel that was stuck pending from the first attempt to become active, however, Bitkit thinks there is a spending balance of 10_100 yet the connection shows all of that is in reserve (see video 1). This attempt to claim the connection results in a "Unable To Open Channel (LNURL)" "Bitkit could not connect to Blocktank." error (see screenshot 4).

Order id: 29d25f1f-1f4e-495b-b4e7-7d862559642c

Reproduce

  1. Visit https://blocktank.to/
  2. Configure a channel with 10_000 sats spending and default settings otherwise
  3. Scan the QR with Bitkit wallet to pay for channel via Lightning
  4. Blocktank widget immediately recognised the payment (see screenshot 1) but Bitkit gets stuck pending payment (see screenshot 2)
  5. Whilst payment is still pending in Bitkit, scan the "claim channel' QR in Blocktank widget
  6. Confirm the channel connection in Bitkit. At this point, Bitkit recognised the payment as successful.
  7. Go to Lightning Connections and observe pending connection with status "Opening connection". Even after the onchain tx confirms, connection is still stuck in this state and is unusable (see screenshot 3).

Screenshots / Recording

Screenshot 1

Blocktank widget showing "Claim channel".


Screenshot 2

Bitkit showing "Payment Pending" even though Blocktank recognises the payment is successful.


Screenshot 3

Bitkit still showing pending connection with status "Opening connection", 5 confirmations, 55 minutes after blocktank opened the connection.


Screenshot 4


Video 1

https://github.com/user-attachments/assets/f88a5a58-65d4-48df-a7a9-726c4b12a4d9

Operating system

Android 13 TKQ1.221114.001

Bitkit version

v130 d8f96e7d6475d2eef04ae08f9d9dd2c8894a8218

Log output

bitkit_ldk_logs_1722245083134.zip

dzdidi commented 1 month ago

Based on slack notification linked in issue (status open) blocktank seem to have everything right. There was however one error in logs related to the bitkit's public key 0246faa6660c0457172b520bfddf824e753523fd0a9cdaf7f21e83246118704c6a http://grafana.blocktank.prod/goto/F0_uJ_XSR?orgId=1 however, after quarter of second channel was opened. SERVICE: http://grafana.blocktank.prod/goto/WZi61_uSg?orgId=1 WATCHER: http://grafana.blocktank.prod/goto/Cs_6JlXSg?orgId=1

catch-21 commented 1 month ago

Thanks @dzdidi. I am suspecting more that this is an issue on Bitkit side. I did manage to close and get reimbursed for the first connection after attempting to create the second connection, but I am unable to use or close the second at this point.

Edit: As I finished writing this comment, the channel status changed to open in Bitkit. Although, same as before, 0 spending balance and the entire 10_100 in reserve (unspendable).

Jasonvdb commented 1 month ago

Not seeing anything broken in the logs. I suspect this might be mostly a UI sync related bug.

The stuck pending is always due to the hodl invoice type which is expected. There's no way to tell which are hodl invoices from the sender side so we can't differentiate those in the UI unfortunately.

Channels from the widgets are never zero conf channels so we do expect them to be pending for a little while as the logs show. Although maybe the redux state didn't update when the actual channel became ready and usable.