-
Notifications
You must be signed in to change notification settings - Fork 72
Some fix and optimization for rust engine #50
Conversation
I've encountered a problem while using your code involving transaction broadcasting and UTXO retrieval. Specifically, the program crashes when it tries to get UTXO after broadcasting the commit-tx, leading to my assets being locked in a taproot address. Could you please guide me on how to recover the locked assets or suggest a workaround? Any help you can provide would be greatly appreciated. Thank you, |
Can you find payload time and payload nonce in your console log? |
I guess you are missing some log outputs from the beginning, It's close to/just below your command line issued. try to search line containing "payload time". |
Please delete those log please, I am not sure if these log exposure will cause any further asset loss. |
Thank you for response. I'll wait for your further tools to recover the assets. Thanks again. |
I forked and temporarily develop a simple tool aimed at recovering only transctions executed by atomicalsir rust-engine for the time being. You can [access it] (https://github.com/miraland-labs/miraland-atomicalsir-resume-after-commit) |
I try to use it, but it must need --commit-nonce, I don't have it, I think --commit-time can find in https://www.blockchain.com/explorer/transactions/btc/000000b64b7b91e41f8df8b773df6312702e3cecee6b6970f873700e78c6b242 in json |
--commit-time and --commit-nonce are generated as console output from the temporarily forked version miraland-atomicalsir-rust which has not been merged yet(see above, @AurevoirXavier is refactoring those parts). BTW, I highly suspect the time you mentioned in the url is exactly the --commit-time required. It needs more time to investigate. |
I try to use the time as param to run nonce from 1 to 10_000_000, wait my result |
I'll merge this first, then refactor based on the updated version. Thanks for your contribution. I'll ping you once I've finished refactoring. You may want to review it. |
// OP_RETURN size | ||
// 8-bytes value(roughly estimate), a one-byte script’s size | ||
// actual value size depends precisely on final nonce | ||
const OP_RETURN_BYTES: f64 = 21. + 8. + 1.; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm curious about how you obtained these values.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi Aurevior, my understanding is:
<8 bytes value/amount> + <1 byte len of following script> + <1 byte OP_RETURN(0x6a)> + <1 byte len indicating the rest> + <10 byte unix_timestamp> + <1 byte for colon separator(:)> + <8 bytes nonce, roughly estimation>
so: 8 + 1 + 1 + 1 + 10 + 1 + 8 = 30 bytes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so the comments maybe a little confusing: 8-bytes nonce
rather than 8-bytes value
and value size
should be nonce size
@AurevoirXavier
Changes listed in this PR: