Save remaining utxos in a file #7
Conversation
| @@ -779,6 +780,9 @@ int main(int argc, char** argv) | |||
|
|
|||
| printf("done in %f4.2 sec\n", ((float)(end-start))/1000000000.0); | |||
| printf("create tx loop in %6.2f sec\n", ((float)(end-createTxLoopStart))/1000000000.0); | |||
| printf("Generate a block and push <Enter>... "); | |||
There was a problem hiding this comment.
I think we want to system() a script (configured in txunami.json) here. That script can just wait for an enter, or it can wait while polling for a block.
There was a problem hiding this comment.
Yeah a simple script like the one in point 7 by Mr Toomim would probably suffice.
I have encountered instances where only part of my fan-out transactions would confirm in the first block, even in two stage setups.
For now I'm just monitoring getmempoolinfo to know when to push Enter.
| CScript script = utxo.constraintScript; | ||
| entry.pushKV("scriptPubKey", HexStr(script.begin(), script.end())); | ||
| entry.pushKV("privKey", CBitcoinSecret(utxo.privKey).ToString()); | ||
| results.push_back(entry); |
There was a problem hiding this comment.
write the address as well (yeah I know that txunami doesn't need it)... but it could be useful for scripts that read this and do things like access the spends in an explorer.
There was a problem hiding this comment.
Yeah, I thought about it because it would be useful, but it's not part of the UTXO object, so didn't bother.
I have now added the address.
|
I have a thought about the approach -- if we wrote the newly created private keys (and addresses for convenience) to a file BEFORE executing the txunami loop, then a script could easily be written that accessed electrscash or some other service to find the UTXOs associated with these private keys, and produce this utxo.json file for input. I'm often ctrl-c -ing txunami to stop it, and even if you don't do that, as you get into higher rates you'll find that it sometimes "detaches" from the nodes state -- some tx gets rejected due to mempool policy or a dropped packet and then all spends are rejected due to missing parents. All of these utxo would then be lost. So this would allow us to recover all coins even in these 2 cases. What do you think? |
|
Reagarding recovering utxos on a non successful run: it makes perfect sense, but there are lower hanging fruit before I'd think to tackle that. Regarding this PR in general, unfortunately it's broken, don't merge it yet. I have realised that the last iteration is not saved/considered in the array I'm saving. So I end up with an array of txos of which some are spent (starting from the top) and some are unspent. The proportion is a lottery. I haven't dug into the code in great detail, do you know how can one update the txos easily after the last iteration? |
|
Regarding recovering utxos on a non successful run: oh, do you mean to simply store the privkeys and let an external service to recover the UTXOs from that. It's simply doable, yeah. |
At the end of a successful run an attempt to save the remaining utxos is made in utxos.json file. This will not work if the run is interrupted.
The new utxos can be simply copy-pasted to the txunami.json configuration file.
A small off-by-one bug is corrected: if the number of utxos read was already equal to the desired number of utxos, the old code would still cycle once. WIth this fix the preparation phase can be skipped entirely if the number of utxos read is already sufficient.