[bug]: In Ver lightning-terminal:v0.13.99-alpha.rc4 #1019
Comments
You have recovery mode activated in your config, which means it will always do a rescan from the wallet birthday. If you don't want to rescan each time the daemon starts up (can take time depending on how old the wallet is), then you can safely remove that config. |
|
Thanks for the issue report! I agree with what @Roasbeef set above, if you see I'll look into removing the pending channels if it isn't funded properly. For the crash, do you happen to have the logs still? How did you initiate the transfer? Through an invoice or with a keysend payment? |
|
About Crash , here is my cmd(I could't get the logs as the docker container crashed) : |
|
I’ll look into removing the pending channels if they aren’t funded properly. I called the fundChannel method twice:
As a result, there has been a pending channel ever since. |
|
" I agree with what @Roasbeef set above, if you see RECOVERY MODE ENABLED you're probably doing something wrong (sounds like you're specifying recovery_window as non-zero when unlocking the wallet?)." name: ${LIT_NAME}-${LIT_NETWORK}
services:
lit:
image: lightninglabs/lightning-terminal:v0.13.99-alpha.rc4
container_name: ${LIT_NAME}-${LIT_NETWORK}
volumes:
- ${LIT_DATA_PATH}/lit:/root/.lit
- ${LIT_DATA_PATH}/lnd:/root/.lnd
- ${LIT_DATA_PATH}/loop:/root/.loop
- ${LIT_DATA_PATH}/tapd:/root/.tapd
- ${TOR_PATH}:/root/.tor
expose:
- "8443"
- "8442"
- "10009"
- "10010"
ports:
- "${LIT_PORT_HTTPS}:8443"
- "${LIT_PORT_INSECURE_HTTPS}:8442"
- "${LIT_PORT_LND}:10009"
command:
- "lightning-terminal"
- "--httpslisten=0.0.0.0:8443"
- "--insecure-httplisten=0.0.0.0:8442"
- "--uipassword=${LIT_UI_PASSWORD}"
- "--network=${LIT_NETWORK}"
- "--tlsextradomain=${LIT_TLSEXTRADOMAIN}"
- "--tlsextradomain=${LND_TLSEXTRADOMAIN}"
- "--tlsextradomain=${TAPD_TLSEXTRADOMAIN}"
- "--tlsextraip=${LIT_TLSEXTRAIP}"
- "--tlsextraip=127.0.0.1"
- "--lnd-mode=integrated"
- "--lnd.bitcoin.active"
- "--lnd.bitcoin.node=bitcoind"
- "--lnd.alias=${LND_ALIAS}"
- "--lnd.tlsextradomain=${LIT_TLSEXTRADOMAIN}"
- "--lnd.tlsextradomain=${LND_TLSEXTRADOMAIN}"
- "--lnd.tlsextradomain=${TAPD_TLSEXTRADOMAIN}"
- "--lnd.tlsextradomain=localhost"
- "--lnd.tlsextraip=${LIT_TLSEXTRAIP}"
- "--lnd.tlsextraip=127.0.0.1"
- "--lnd.externalip=${LND_EXTERNALIP}"
- "--lnd.rpclisten=0.0.0.0:10009"
- "--lnd.listen=0.0.0.0:9735"
- "--lnd.debuglevel=info"
- "--lnd.rpcmiddleware.enable"
- "--lnd.protocol.wumbo-channels"
- "--lnd.maxpendingchannels=10"
- "--lnd.protocol.option-scid-alias"
- "--lnd.protocol.zero-conf"
- "--lnd.protocol.simple-taproot-chans"
- "--lnd.protocol.simple-taproot-overlay-chans"
- "--lnd.protocol.custom-message=17"
- "--lnd.accept-keysend"
- "--lnd.bitcoind.rpchost=${BITCOIND_RPCHOST}"
- "--lnd.bitcoind.rpcuser=${BITCOIND_RPCUSER}"
- "--lnd.bitcoind.rpcpass=${BITCOIND_RPCPASS}"
- "--lnd.bitcoind.zmqpubrawblock=${BITCOIND_ZMQBLOCK}"
- "--lnd.bitcoind.zmqpubrawtx=${BITCOIND_ZMQRAWTX}"
# - "--lnd.tor.active"
# - "--lnd.tor.v3"
# - "--lnd.tor.skip-proxy-for-clearnet-targets"
# - "--lnd.tor.dns=nodes.lightning.directory"
# - "--lnd.tor.socks=${TOR_SOCKS}"
# - "--lnd.tor.control=${TOR_CONTROL}"
- "--autopilot.disable"
- "--taproot-assets-mode=integrated"
- "--taproot-assets.rpclisten=0.0.0.0:10029"
- "--taproot-assets.restlisten=0.0.0.0:8089"
- "--taproot-assets.tlsextradomain=${TAPD_TLSEXTRADOMAIN}"
- "--taproot-assets.tlsextraip=${TAPD_TLSEXTRAIP}"
- "--taproot-assets.tlsextraip=127.0.0.1"
- "--taproot-assets.universe.public-access=rw"
- "--taproot-assets.allow-public-uni-proof-courier"
- "--taproot-assets.allow-public-stats"
- "--taproot-assets.experimental.rfq.priceoracleaddress=use_mock_price_oracle_service_promise_to_not_use_on_mainnet"
- "--taproot-assets.experimental.rfq.skipacceptquotepricecheck"
- "--taproot-assets.experimental.rfq.mockoraclesatsperasset=10"
# - "--taproot-assets.tapddir=/root/.lit/tapd"
# - "--taproot-assets.tlskeypath=/root/.lit/tls.key"
# - "--taproot-assets.tlscertpath=/root/.lit/tls.cert"
- "--faraday-mode=disable"
- "--faraday.min_monitored=24h"
- "--faraday.connect_bitcoin"
- "--faraday.bitcoin.host=${BITCOIND_RPCHOST}"
- "--faraday.bitcoin.user=${BITCOIND_RPCUSER}"
- "--faraday.bitcoin.password=${BITCOIND_RPCPASS}"
- "--faraday.debuglevel=info"
- "--loop-mode=disable"
- "--loop.network=${LIT_NETWORK}"
- "--loop.tlsautorefresh"
- "--loop.server.host=${LOOP_SERVER}"
- "--loop.server.notls"
- "--pool-mode=disable"
networks:
- lnfi_network
logging:
driver: "json-file"
options:
max-file: "3" # number of files or file count
max-size: "50m" # file size
networks:
lnfi_network:
external: true |
@guggero Thank you for your response. Here is some additional information regarding the three issues mentioned above |
|
See my comment above regarding recovery mode:
|
|
Was able to reproduce the crash due to sending the full balance, thanks for the additional info. |
I haven't specified recovery_window when unlocking the wallet. |
|
So where does this value come from then? Looks like something from an example script that was copied by accident: |
|
Are you using some sort of startup script that creates or unlocks the wallet? |
[Edited whitespace] |
The bitcoind was only 10,000+ blocks and had few transactions, yet the sync took over an hour. Is this normal, or does it seem to be taking too much time? |
|
Did you perhaps at one point compile The other thing to consider on regtest is that if the last block is more than 2 hours old, |
|
@lukegao209 I just tried creating a channel with insufficient BTC balance and got the following: And then I also tried with not enough asset balance and got this error: So I don't see how you could've gotten into that state.
I think docker should allow you to get the logs of a shutdown container still. |
I can’t reproduce this issue now. At that time, I had just created two litd instances for Alice and Bob, and then started fundChannel, which led to the issue. I will try more later |
|
I think I was able to repro the pending channel issue with the following steps:
Here's the full log for this node. |
|
Thanks a lot for the reproduction @jamaljsr! So this issue should be fully closed by #1030. |
|
@guggero I tested #1030 today, repeating the same steps above and received the following errors. It seems like the asset went missing after the first channel funding failed. |
|
Looking at the logs, the first funding attempt failed as Bob wasn't able to verify that the asset actually existed: Was the new asset uploaded to the Universe before the fund call as executed? Also I only see one funding attempt in the logs oddly. |
I am using the
In Polar, every node is a universe server. I only have them syncing assets when generating a receive address. In prior testing with RC4, I never needed to sync the asset to the channel recipient before funding. Is this going to be required going forward? It looks like funding channels when the node has enough BTC fails as well with this change. |
Hmm, so the way we have it right now, when you go to generate an address, if you don't yet know of that asset, then it'll try to fetch it from the connected universe. In the logs it tries to sync from the configured remote universe server. Looking a bit deeper, looks like none are configured: |
github-project-automation
bot
moved this from 💇♂️Needs Shaping
to ✅ Done
in Taproot-Assets Project Board
|
Re-opening as we want to make sure the asset unlock issue is fully resolved. |
Uh oh!
There was an error while loading. Please reload this page.
Background
I understand that you guys might be working on bugs in this version, but I wanted to share the issues I’ve encountered in case it helps.
Issues:
The text was updated successfully, but these errors were encountered: