Skip to content
This repository has been archived by the owner on May 7, 2024. It is now read-only.

Some fix and optimization for rust engine #50

Merged
merged 2 commits into from
Jan 21, 2024

Conversation

miralandlabs
Copy link
Contributor

Changes listed in this PR:

  1. sync fee estimation bug fix from atomicals-js to atomicalsir
  2. add bitworkr/mint_bitworkr to struct Args
  3. add concurrency variable for future flexible threads setting
  4. fix max_fee comparison logic
  5. add retry-send transaction control
  6. log some values to assist tx recovery/replay in case that commit succeeds but reveal failed.
  7. fine-tuning of reveal nonce generation mechanism to try to keep solution nonce as small as possible to save byte-storage.
  8. add log outputs to improve user experience
  9. adjust test

@zgos
Copy link

zgos commented Jan 20, 2024

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,

@miralandlabs
Copy link
Contributor Author

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?

@miralandlabs
Copy link
Contributor Author

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".

@miralandlabs
Copy link
Contributor Author

Please delete those log please, I am not sure if these log exposure will cause any further asset loss.
Please save those logs, in theory, based on your logs, the locked asset is possible to recover. But I have no out-of-box tool for you, I still need to tailor the program for recovery purpse.

@zgos
Copy link

zgos commented Jan 20, 2024

Please delete those log please, I am not sure if these log exposure will cause any further asset loss. Please save those logs, in theory, based on your logs, the locked asset is possible to recover. But I have no out-of-box tool for you, I still need to tailor the program for recovery purpse.

Thank you for response. I'll wait for your further tools to recover the assets. Thanks again.

@AurevoirXavier AurevoirXavier mentioned this pull request Jan 20, 2024
@miralandlabs
Copy link
Contributor Author

Please delete those log please, I am not sure if these log exposure will cause any further asset loss. Please save those logs, in theory, based on your logs, the locked asset is possible to recover. But I have no out-of-box tool for you, I still need to tailor the program for recovery purpse.

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)
To be honest, it's been constructed in haste with very limited testing. Use it at your own discretion.
Please read the project README first. Good luck!

@DarrenLuo
Copy link

Please delete those log please, I am not sure if these log exposure will cause any further asset loss. Please save those logs, in theory, based on your logs, the locked asset is possible to recover. But I have no out-of-box tool for you, I still need to tailor the program for recovery purpse.

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) To be honest, it's been constructed in haste with very limited testing. Use it at your own discretion. Please read the project README first. Good luck!

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 time, and other param can find in mempool

@miralandlabs
Copy link
Contributor Author

Please delete those log please, I am not sure if these log exposure will cause any further asset loss. Please save those logs, in theory, based on your logs, the locked asset is possible to recover. But I have no out-of-box tool for you, I still need to tailor the program for recovery purpse.

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) To be honest, it's been constructed in haste with very limited testing. Use it at your own discretion. Please read the project README first. Good luck!

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 time, and other param can find in mempool

--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.

@DarrenLuo
Copy link

Please delete those log please, I am not sure if these log exposure will cause any further asset loss. Please save those logs, in theory, based on your logs, the locked asset is possible to recover. But I have no out-of-box tool for you, I still need to tailor the program for recovery purpse.

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) To be honest, it's been constructed in haste with very limited testing. Use it at your own discretion. Please read the project README first. Good luck!

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 time, and other param can find in mempool

--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

@AurevoirXavier
Copy link
Member

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.

@AurevoirXavier AurevoirXavier enabled auto-merge (squash) January 21, 2024 09:31
@AurevoirXavier AurevoirXavier enabled auto-merge (squash) January 21, 2024 09:31
@AurevoirXavier AurevoirXavier merged commit efc61e3 into hack-ink:main Jan 21, 2024
3 checks passed
// 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.;
Copy link
Member

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.

Copy link
Contributor Author

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

Copy link
Contributor Author

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants