scripts: Add create_load_fund_wallet() make sure bitcoind wallet is setup correctly

[Christewart]

fixes parts of #79

This PR adds functionality to ./run-everything.sh to

1. Check if bitcoind has a wallet (note: after bitcoin core 0.21 bitcoind stopped creating a wallet by default)
2. If it does not, create one called spark-wallet
3. Check spark-wallet's balance
4. If it has less than 1 BTC in it, generate 101 blocks to fund it with the mining reward (note: only 1 block of mining reward will be available for spending in the wallet).

This gets more unit tests passing locally for me (unfortunately, i'm running into more instances of #90 ). I'll eventually get around to putting this into #71 to see what tests look like on CI. I think this can be merged independently though to make lives of non-minikube users easier.

---

Note

Ensures a usable regtest wallet is available immediately after starting bitcoind.

• Adds create_load_fund_wallet to create/load spark-wallet, check balance, and generatetoaddress 101 blocks if balance < 1 BTC
• Calls wallet setup after launching bitcoind in tmux (with a short sleep to allow startup)
• Uses RPC creds from bitcoin_regtest.conf via parse_bitcoin_config

^{Written by Cursor Bugbot for commit 6559e71. This will update automatically on new commits. Configure here.}

[cursor]

This PR is being reviewed by Cursor Bugbot

Details

Your team is on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle for each member of your team.

To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.

[cursor]

Wallet detection uses wrong command for existing wallets

Medium Severity

The listwallets command only returns currently loaded wallets, not wallets that exist on disk. When getwalletinfo fails and the code checks listwallets, a wallet that exists on disk but isn't loaded won't appear in the list. This causes the code to incorrectly call createwallet instead of loadwallet. The create operation will fail silently (due to &>/dev/null) because the wallet already exists, leaving the wallet in an unloaded state. To detect wallets on disk, listwalletdir is needed, or the code could try loadwallet first and fall back to createwallet on failure.

 

[pictetlabs]

Thank you Chris! This should be fixed now. Please let us know if you’re still running into any issues.

[Christewart]

Yeah it looks like its addressed in a combination of

• 00343a3
• 2838bc4
• 1f668c0
• de0f01b
• 76dc9bb

Another suggestion

• Consider moving away from using mainnet ports (such as 8332 for RPC) for your testing environment. This clashes with users (such as myself) that run bitcoind on mainnet while developing applications that require a regtest environment.

I can put this on my backlog of things to do if there is appetite for this internally at lightspark.

Another q:

Can you explain to me why sometimes the go is managing bitcoind state (00343a3) and sometimes the script is? Seems like it may be worth just moving all bitcoind state handling logic into the go test harness. Perhaps there isn't a clean separation of concerns between a "localized" setup and unit/integration testing the application - might be worth thinking about this as these will likely become a bigger problem as spark becomes more successful 🤷‍♂️

[zhenlu]

Thanks Chris for all the recommendations! We will file these tickets internally and working on those.

The commit you pointed out is actually the branch commit which is reverted in later commits without squashing all commits. But yes we will try to manage the bitcoind state by script from now on, and will move the legacy testing setup from go side to script side.

[Christewart]

But yes we will try to manage the bitcoind state by script from now on, and will move the legacy testing setup from go side to script side.

Just to be clear, both contexts can make sense. For instance, your test suite should be able to call generatetoaddress() if you need activity to confirm a utxo on the network. Otherwise you will need to wait for whatever the polling interval is in the script to generate a block on the network (every 30 seconds right now) which could slow down the test suite - especially as the suite grows.

Hopefully you guys can move to segregating the testing environment and running the app locally which would make this problem go away, admittedly that will take some work though and I can understand why that isn't the highest of priorities.

Thanks for the responses!