Skip to content

Conversation

@HowHsu
Copy link

@HowHsu HowHsu commented Sep 8, 2025

-loadblock doesn't support XOR-ed files, mention it in its help text to avoid troubles for users.

@DrahtBot
Copy link
Contributor

DrahtBot commented Sep 8, 2025

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33343.

Reviews

See the guideline for information on the review process.
A summary of reviews will appear here.

Conflicts

Reviewers, this pull request conflicts with the following ones:

  • #17783 (common: Disallow calling IsArgSet() on ALLOW_LIST options by ryanofsky)
  • #17581 (refactor: Remove settings merge reverse precedence code by ryanofsky)
  • #17580 (refactor: Add ALLOW_LIST flags and enforce usage in CheckArgFlags by ryanofsky)
  • #17493 (util: Forbid ambiguous multiple assignments in config file by ryanofsky)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

LLM Linter (✨ experimental)

Possible typos and grammar issues:

  • "Imports blocks from external file" -> "Imports blocks from an external file" [missing article "an" makes the phrase ungrammatical and may hinder comprehension]

drahtbot_id_5_m

Copy link
Contributor

@l0rinc l0rinc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure it's a documentation issue, I think we should rather fix it by adding the obfuscation key to the AutoFile instead.
I will investigate if adding a fix and updating feature_loadblock.py makes more sense and will push an alternative PR to see what people think is more appropriate here.
Thanks for jumping on this so quickly.

@l0rinc
Copy link
Contributor

l0rinc commented Sep 8, 2025

I wasn't aware of this, it seems we have a dedicated tool to https://github.com/bitcoin/bitcoin/tree/master/contrib/linearize.
It's explicitly written to deobfuscate blocks from your node’s blk*.dat (handling XOR if present) and writes them plain to output_file or to an output/blkNNNNN.dat.

@HowHsu
Copy link
Author

HowHsu commented Sep 9, 2025

I'm not sure it's a documentation issue, I think we should rather fix it by adding the obfuscation key to the AutoFile instead. I will investigate if adding a fix and updating feature_loadblock.py makes more sense and will push an alternative PR to see what people think is more appropriate here. Thanks for jumping on this so quickly.

I'm not sure it's a documentation issue, I think we should rather fix it by adding the obfuscation key to the AutoFile instead. I will investigate if adding a fix and updating feature_loadblock.py makes more sense and will push an alternative PR to see what people think is more appropriate here. Thanks for jumping on this so quickly.

Hi l0rinc,
I don't think it's good to either

  1. update the Autofile code to use the current obfuscation key by the running node
    this makes it too restrictive.
  2. add a new argument like -loadblock-xor=xor_value to indicate the xor key used by -loadblock
    since we can restore the obfuscated file with some external tools, it's already very flexible, adding -loadblock-xor would be kind of meaningless.
    That's why I only updated the help message.

@l0rinc
Copy link
Contributor

l0rinc commented Sep 9, 2025

I wrote that before I found the contrib/linearize tool, which seems to be designed for unobfuscated block sharing anyway - maybe it can solve your problem of using -loadblock. If it does, we might want to mention that instead in the argument's documentation.

@mzumsande
Copy link
Contributor

mzumsande commented Sep 10, 2025

I wrote that before I found the contrib/linearize tool, which seems to be designed for unobfuscated block sharing anyway

It was originally designed to to something else (create a linear, in order chain), so using the tool has side effects (maybe the users doesn't want to lose historical forks for some reason). Could mention it as an example though.

I'm not convinced that changing the interface to support adding a xor-key per -loadblock arg (or one for all?) is really worth the effort, since I'm not sure people out there actually use this feature today, and, if so, to what end.

@HowHsu HowHsu force-pushed the loadblock-help branch 3 times, most recently from d96fac4 to c1789d4 Compare September 13, 2025 14:30
@HowHsu HowHsu requested a review from l0rinc September 13, 2025 18:12
`-loadblock` doesn't support obfuscated blocks, mention it in its help text
to avoid troubles for users.

Signed-off-by: Hao Xu <hao.xu@linux.dev>
Copy link
Contributor

@l0rinc l0rinc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@HowHsu Did you try contrib/linearize yourself to export the .blk files for -loadblock? Did it solve your issue? I have suggested a simpler documentation, do you think that help others to use the linearize tool when they're in your situation?

argsman.AddArg("-includeconf=<file>", "Specify additional configuration file, relative to the -datadir path (only useable from configuration file, not command line)", ArgsManager::ALLOW_ANY, OptionsCategory::OPTIONS);
argsman.AddArg("-allowignoredconf", strprintf("For backwards compatibility, treat an unused %s file in the datadir as a warning, not an error.", BITCOIN_CONF_FILENAME), ArgsManager::ALLOW_ANY, OptionsCategory::OPTIONS);
argsman.AddArg("-loadblock=<file>", "Imports blocks from external file on startup", ArgsManager::ALLOW_ANY, OptionsCategory::OPTIONS);
argsman.AddArg("-loadblock=<file>", "Imports blocks from external file on startup (does not support obfuscated blocks, see Issue #33280 for related conversation, and see contrib/linearize tool for clues of deobfuscation and reobfuscation)", ArgsManager::ALLOW_ANY, OptionsCategory::OPTIONS);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
argsman.AddArg("-loadblock=<file>", "Imports blocks from external file on startup (does not support obfuscated blocks, see Issue #33280 for related conversation, and see contrib/linearize tool for clues of deobfuscation and reobfuscation)", ArgsManager::ALLOW_ANY, OptionsCategory::OPTIONS);
argsman.AddArg("-loadblock=<file>", "Imports blocks from external file on startup (obfuscated block files are not supported; use contrib/linearize to export blocks to a plain, loadable format)", ArgsManager::ALLOW_ANY, OptionsCategory::OPTIONS);

@HowHsu
Copy link
Author

HowHsu commented Sep 16, 2025

@HowHsu Did you try contrib/linearize yourself to export the .blk files for -loadblock? Did it solve your issue? I have suggested a simpler documentation, do you think that help others to use the linearize tool when they're in your situation?

I didn't, but I read the code of them (files under contrib/linearize), linearize-data.py only generates a list of blocks based on a list of block hashes generated by linearize-hashes.py, which accepts a height range [min_height, max_height] and get block hashes of these heights from RPC. That is said, the blocks are not arbitrary, if a user use -loadblock to load some discontinuous blocks, it has to generate its own block hashes list to feed linearize-data.py. So I just add for clues of deobfuscation and reobfuscation. For my scenario, I've found another way to do the test, so I didn't continue it with -loadblock

@HowHsu HowHsu requested a review from l0rinc September 16, 2025 13:41
@l0rinc
Copy link
Contributor

l0rinc commented Sep 16, 2025

I think we should try it ourselves before recommending it in the documentation

@luke-jr
Copy link
Member

luke-jr commented Sep 18, 2025

I think it would make sense to support XOR for loadblock if we're assuming the chain has data that can trigger bad things

@maflcko
Copy link
Member

maflcko commented Sep 25, 2025

I think we should try it ourselves before recommending it in the documentation

It is already tested in test/functional/feature_loadblock.py, no?

@HowHsu
Copy link
Author

HowHsu commented Sep 25, 2025

I think it would make sense to support XOR for loadblock if we're assuming the chain has data that can trigger bad things

Hi Luke, what do you mean by "assuming the chain has data that can trigger bad things"

@HowHsu
Copy link
Author

HowHsu commented Sep 25, 2025

I think we should try it ourselves before recommending it in the documentation

I'll try that later when I have some time for it, though the function of the script is already clear enough for me by carefully reading the code.

@l0rinc
Copy link
Contributor

l0rinc commented Sep 25, 2025

It is already tested in test/functional/feature_loadblock.py, no?

That's where I found it, but to see if it solves the original problem for why this PR was opened, it would help to have personal experience with the script so that we can document it such that others don't need to browse the tests. I'm also fine with anyone else having experience with the script suggesting a useful help text.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants