fix keypoolrefill perfomance and adjusted callback logic #1508
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When a wallet is created, the keypoolrefill-function get called for each address of probably 50 addresses wasting lots of time to write a csv-file dozens of times. This fixes this behaviour (in
wallet.py
).It also adjusts the behaviour of the
SPECTER_PERSISTENCE_CALLBACK
(orSPECTER_PERSISTENCE_CALLBACK_ASYNC
for a script which would run in a thread) to make it more flexible. This env-var takes an executable which will get called any time the persistence-layer is modifying a file.Example:
/usr/local/bin/my_rsync_script.sh
export SPECTER_PERSISTENCE_CALLBACK=/usr/local/bin/my_rsync_script.sh
write
ordelete
/usr/local/bin/my_rsync_script.sh write /home/someuser/.specter/config.json
SPECTER_PERSISTENCE_CALLBACK_ASYNC
and it'll be called in a thread.Those changes are in
persistence.py
.Also this PR contains an autodetection-mechanism for Liquid-nodes. So in parallel to
BTC_RPC_USER, BTC_RPC_PASSWORD, BTC_RPC_HOST, BTC_RPC_PORT, ELM_RPC_PROTOCOL
we now also haveELM_RPC_USER, ELM_RPC_PASSWORD, ELM_RPC_HOST, ELM_RPC_PORT ELM_RPC_PROTOCOL
.This was a bit tricky as a node was, up to now, indifferent about the type (until it queried the RPC-interface). Now we need to specify the type of the node upfront in order to make the autodetection work if someone uses both autodetection-mechanisms at the same time.
Also, the
NodeManager
created an initial Node if there wasn't one. So we needed to adjust that and we create a second Liquid-Node if there isn't one (AND an env-var is existing). See the node_type as the first argument (which will then differ in which Env-vars to pick up):