You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now the new secrets are allocated for a transaction regardless of whether the transaction confirms or not. So if you insert a secret into a wallet and the insertion fails, the replacement secret is still allocated.
This created an issue for me because I was inserting a batch of a few hundred secrets from webminer's webcash.log file. Unfortunately the my internet connection went out in the middle and so some secrets time out and weren't inserted. And because I am lazy I decided to just cat webcash.log | xargs -n 1 webcash insert the whole list again. I know, I know: bad on me for wasting server CPU time. But it got the job done since duplicate insertions are rejected by the server.
Only in the process my key counts increased by the size of the webcash.log file, even though only a few of them were valid. This means if I try to recover from a wallet backup it won't be successful, because I have a gap of 100's of secrets. It will still be recoverable, thankfully, but not with default options and not without an equivalently large drain of server resources.
Comparatively, miner.py "peeks" at the next secret and only commits if it actually finds a proof-of-work solution. This should be the behavior for all the wallet APIs: fetch a new secret to construct the transaction, but only commit it if the transaction confirms. Any error and the key counter is left at wherever it was before.
The text was updated successfully, but these errors were encountered:
Right now the new secrets are allocated for a transaction regardless of whether the transaction confirms or not. So if you insert a secret into a wallet and the insertion fails, the replacement secret is still allocated.
This created an issue for me because I was inserting a batch of a few hundred secrets from webminer's webcash.log file. Unfortunately the my internet connection went out in the middle and so some secrets time out and weren't inserted. And because I am lazy I decided to just
cat webcash.log | xargs -n 1 webcash insert
the whole list again. I know, I know: bad on me for wasting server CPU time. But it got the job done since duplicate insertions are rejected by the server.Only in the process my key counts increased by the size of the webcash.log file, even though only a few of them were valid. This means if I try to recover from a wallet backup it won't be successful, because I have a gap of 100's of secrets. It will still be recoverable, thankfully, but not with default options and not without an equivalently large drain of server resources.
Comparatively,
miner.py
"peeks" at the next secret and only commits if it actually finds a proof-of-work solution. This should be the behavior for all the wallet APIs: fetch a new secret to construct the transaction, but only commit it if the transaction confirms. Any error and the key counter is left at wherever it was before.The text was updated successfully, but these errors were encountered: