-
Notifications
You must be signed in to change notification settings - Fork 261
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error on Bech32m format introduced in BIP 350 - invalid bech32 checksum variant found Bech32 when Bech32m was expected #287
Comments
Can you provide more information? What function from this library were you calling? Is the library outputting data with the wrong checksum or trying to read data with the wrong checksum? |
Certainly. The functions being called from the bitcoincore_rpc library when the error occurs are get_raw_transaction, get_raw_transaction_info, and get_tx_out. Here's a minimal code snippet to reproduce the error. Error: JSON-RPC error: JSON decode error: invalid bech32 checksum variant found Bech32 when Bech32m was expected at line 1 column 77318 cargo.toml
main.rs
The error specifically occurs during address parsing, likely in this line:
The library is trying to read data with the wrong checksum format, as it seems to expect a Bech32 checksum but encounters a Bech32m checksum instead. This suggests that the library may not yet fully support the Bech32m format. |
Upon investigating the root of the problem, it becomes clear that bitcoincore_rpc is not responsible for decoding addresses; instead, it relies on bitcoincore_rpc_json, that relies on rust_bitcoin (specifically bitcoin = { version = "0.29.0", features = ["serde"]}). It might be worthwhile for bitcoincore_rpc_json to update the dependency version to bitcoin 0.30.0, or if that doesn't resolve the issue, the error may need to be reported to the rust_bitcoin maintainer. This is the diff between 0.29.0, and 0.30.0: Your feedback on the above would be appreciated Andrew Poelstra |
Update. I managed to make the code work, but using the method get_raw_transaction instead of get_raw_transaction_info. It is still unclear to me why get_raw_transaction_info produces that error. I have had the intuition that it should provide the same as get_raw_transaction, but with additional details. I add below the corrected code in case it is of interest to others.
|
I am the rust-bitcoin maintainer :). I will deal with it upstream once I understand the issue. Thanks very much for the specific reproduction!
This is surprising to me -- both methods should ultimately hand off to rust-bitcoin, which shouldn't have any idea what RPC the request is coming from, and fail in the same way. |
@lukasdll I am not able to reproduce the issue, because the call to So I changed your code to call So I tried changing that to use the new So I tried changing your Cargo.toml to use the current |
@lukasdll what RPC server are you trying to connect to? Given the advanced age of the My suspicion that the other end is broken, not rust-bitcoin. |
All my respect for your work honestly. I'm extremely grateful to people like you maintaining open source projects.
The client is connecting to a Bitcoin Core node, so I checked the version and it is still Bitcoin Core 21, which is probably why I could use the address field. I presume backwards compatibility has certain limitations and I should probably update that node :) Your suspicions are perfectly right, and accurate. |
Ok, thanks! I'll try with a Core 21 node then -- I don't think Core would've ever gotten bech32m and bech32 mixed up, so now I'm back to thinking the bug is with rust-bitcoin. |
@lukasdll sorry, even with Bitcoin Core 0.21 I get the same results -- Is there anything special in your bitcoin.conf? |
Are you sure that you couldn't reproduce the error replacing get_raw_transaction() with get_raw_transaction_info() on the last version of the code I sent above, and connecting to a v 0.21 node? I made a mistake on the first version of the simplified code, as you very well pointed out, Also, I would suggest using this transaction: 371a5a5c3f4344e8f6d49395bfa3f76fe38e5a25db10640a5523c0377a825015 I don't think there is anything special in my bitcoin.conf:
|
Are you saying that the second code, which you described as "corrected" and that you "got it to work", is actually code that exbhibits the bug? :) I will try it later today. |
Sorry, I've been a bit messy on my last messages, please give me the opportunity to catch up. Calling get_raw_transaction_info() is enough, and below I send the simplest code that allows me to reproduce the error. The transaction characteristics can be observed using an explorer: https://blockstream.info/tx/062ba7a58cc79eaf3275a3552ef9067e8bc4c3b3b12db213775f3965ab4dd83b
And those are the dependencies:
Proof : https://imgur.com/a/Si5M4ty I managed to "avoid" the error, by not using the method get_raw_transaction_info(), and call instead get_raw_transaction(), which works without any problem, however, I had to do some extra lifting afterwards to reach the data I needed. |
Your proof notwithstanding, I cannot reproduce this even with 0.21, using exactly the code you just pasted. It works fine on my end. |
That is, extremely weird. Do I need to checksum the Bitcoin Core node? I'm pretty sure I did not mess with that at all though. |
Could it be due to the length of the transaction, that gets truncated at some point? That transaction is particularly large. |
Maaaaybe. That seems really unlikely -- there is only a tiny tiny chance that a malformed address would appear to be bech32m when it was supposed to be bech32, or vice-versa. What I suspect is that somehow the node is really really old and doesn't support bech32m. But I dunno, no explanation really seems to make sense to me. |
I could perhaps parse all transactions in a block, and do stats on how many cause an error. If all of them, or only those with certain characteristics. I could also sync a new Bitcoin Core node, up to date, or with a specific version, and observe whether calling the same code causes the error or not. Let me know what would you recommend to pin point the source of the problem. |
I think you should use |
JsonRpc(Json(Error("invalid bech32 checksum variant found Bech32 when Bech32m was expected", line: 1, column: 77318)))
This error is related to an incorrect Bech32 checksum variant in the JSON-RPC response. The error message indicates that a Bech32 checksum variant was found, but a Bech32m checksum variant was expected.
This issue is most likely caused by an inconsistency between the Bitcoin node (or other service) and the Bitcoin library Bitcoincore_rpc.
The Bech32m format was introduced in BIP 350 to address some limitations of the original Bech32 format and is used for native segregated witness (SegWit) v1+ addresses.
The transaction below is an example that should allow to reproduce the error, it is one of the new Wasabi transactions they introduced in their last update.
https://mempool.space/tx/371a5a5c3f4344e8f6d49395bfa3f76fe38e5a25db10640a5523c0377a825015
The text was updated successfully, but these errors were encountered: