Error creating XMR transaction #2213
Comments
ghost
added
the
|
Thanks for the report, @4c5af829b791b985! I was looking into code trying to check what could go wrong. But the search space is quite big, I didn't find any obvious reason why signing should fail in this case. I was not able to replicate the issue. Trezor supports also larger transactions. I've tested a transaction with 110 inputs on a real device and it worked, so I was wondering whether we could maybe obtain more information on this matter. Potential workaround - UTXO consolidationA potential workaround could be UTXO consolidation. It is not guaranteed to work but we have no reports of Trezor failing to sign smaller transactions. Your current transaction has 39 UTXOs (inputs), according to the bug report. You could try to create a new transaction with fewer UTXOs, sending it to yourself. E.g., create a transaction with 15 UTXOs. Later, when you try to create the original transaction, monero wallet won't see 39 UTXOs but 25 (39-15+1). If the consolidation transaction fails, there is no online trace. You could find UTXO causing problems this way (if it is the case) or reduce the total UTXO amount and avoid the bug (if the number of UTXOs is the culprit). If the consolidation transaction succeeds, you convert 15 of your UTXOs to 1 new UTXO, it will get to the blockchain, fees will be paid for this transaction. Also note that it may be better to use another number of UTXOs as the number is visible on the blockchain, one could link you to a new transaction appearing on a blockchain having 15 utxos. With a little bit of experimenting on your side, you could figure out whether a particular UTXO is the issue or the number of UTXOs. Even if the transaction is signed successfully, you can still avoid sending it to the network. Debugging logsWe could run Monero GUI wallet with debug logs enabled to see if we can spot a potential issue. However, the log contains privacy-sensitive information, such as UTXOs, a destination address, etc. So you may want to anonymize it before sending it. Initially, it may suffice to check if there is an warning/error message in the log as the error manifests. We can also establish a private 1:1 secure channel for addressing this issue, sending logs to avoid exposure of potentially sensitive info, such as UTXOs. Advanced cooperative debuggingDepending on your threat model, privacy requirements, a will to cooperate on solving this issue, and skills we could try a more advanced approach to find the culprit. Debugging walletFor example, when a monero bug is reported, Monero developers sometimes create an ad-hoc monero wallet version, with more debugging information included in the logs. You then can either build this special debugging version on your own or use our build so we can find the problem. On the other hand, as the bug is Trezor-related, we may not get all required information to solve this problem using this approach alone. Debugging firmwareIf we are still not able to find the problem and address it in any way, the last resort approach would be using debugging Trezor Firmware version with logging enabled so we can precisely see what went wrong. I am quite certain this will lead to finding the problem, but it is the most intrusive variant with certain risks. So I am just mentioning it here for completeness, but I am not advocating for it at all. How this scenario works: You would upload a debugging firmware to your Trezor, restore seed backup (as debug firmware wipes the device), and try signing the transaction with logger running on the PC, attached to the Trezor. If the transaction fails, the log will contain information about the error. Installing unverified unofficial Trezor firmware and using production seed with it is highly unadvised. How to build debugging firmwareFollow https://wiki.trezor.io/Developers_guide:Deterministic_firmware_build "Trezor Model T firmware" section.
diff --git a/build-docker.sh b/build-docker.sh
index ed6da5ea5..09217de93 100755
--- a/build-docker.sh
+++ b/build-docker.sh
@@ -111,6 +111,9 @@ for BITCOIN_ONLY in ${VARIANTS_core[@]}; do
git checkout "$TAG"
git submodule update --init --recursive
poetry install
+ export DEBUG_BUILD=1
+ export UNIX_PORT_OPTS="PYOPT=0 DEBUG_BUILD=1"
+ export PYOPT=0
poetry run make clean vendor build_firmware
poetry run ../python/tools/firmware-fingerprint.py \
-o build/firmware/firmware.bin.fingerprint \
Then attach serial logger to the Trezor. DisclaimerI do not represent Trezor/SatoshiLabs. None of my posts are officially affiliated nor consulted with Trezor unless stated otherwise. I work as an independent developer/researcher. |
|
Hi @ph4r05 The only thing I can really notice from the log is that the following warning appears consistently when signing fails: |
|
Thanks for the response @4c5af829b791b985. Tests you did are very helpful! It is quite interesting that you can replicate the bug with various wallets on the same device. It indicates that the bug is probably not caused by a specific UTXO but rather by a number of UTXOs in a transaction. I will try some more experiments to see if I can replicate it. Btw we are currently working on the code maintenance and optimizations. If the problem is memory-related, a new firmware version could solve this issue out of the box. Could you pls indicate approx number of UTXOs that pass vs fail? Thanks for the attached log. I will check if I can find anything in it, but initially it seems there are no indications on the possible culprit, unfortunately. TestsOn a real device I've performed the following tests with various firmware versions.
I will try to check if I can construct UTXOs in an another way that can cause different behaviour. |
|
@4c5af829b791b985 another question, is it possible that number of transaction outputs (destinations) is more than 2 (destination + change)? Currently, the maximum number of transaction outputs is 16. |
|
On one wallet ~20 UTXO fails but ~18 works, on the other ~19 UTXO fails but ~17 works. All transactions are with one recipient address (plus change) |
|
Hello @4c5af829b791b985, do you have a custom homescreen on your Trezor? |
|
@matejcik I did have a custom homescreen, but the issue persists even after resetting the homescreen to the default |
|
@4c5af829b791b985 unfortunately, I was not able to find the possible problem yet. I will try to do a similar experiment on the mainnet with 39 UTXOs but If I am not able to replicate it, there is very little I can do, without device logs. Maybe something will pop up. |
|
I've finished an experiment on mainnet, firmware version 2.4.3, 55 real UTXOs, custom background. Unfortunately, I was not able to replicate the bug. Yet we got another report: monero-project/monero#8290 |
|
@ph4r05 I faced with the same issue using Monero GUI v0.18.1.0 and Trezor T firmware version 2.5.2. OS: Kubuntu 20.04.4 LTS. |
|
@dvazar What is the exact error that you get? Can you try to use monero-wallet-cli ? Also can you say which wallet mode you are using in Settings -> Info? |
|
@selsta I got an error "E Can't create transaction: unexpected error: Trezor returned failure: code=99, message=Firmware error". |
|
@dvazar Do you have a custom homescreen on the device? If yes, try removing it (setting the default) and please try again. |
|
@prusnak Initially, I had a custom homescreen, but after reading the tips above, I returned it to the default. Unfortunately, the error has not gone away. |
|
@dvazar To rule out any update related issues, please close the GUI, delete the whole If you continue to get firmware related errors then it has likely to be fixed on Trezor's side. |
|
@selsta I did as you advised. I tried using each of the four remote nodes. But on each of them I got the same error. |
|
I am also experiencing this issue after updating to 2.5.2. The issue only occurs when sending to integrated addresses. I am on Manjaro, I run my own node (0.18.1.0), I had the Monero picture set from the gallery (I tried changing it back to default with no luck). |
|
Same for me: "Trezor returned failure: code=99, message=Firmware error" .Firmware 2.5.2, 0.18.1.0 GUI, default homescreen. The problem only occurs when sending to integrated addresses. |
|
Sending to a separate non-Trezor wallet should work as a workaround until this issue is resolved, at least for transactions that require an integrated address. Also ping @ph4r05, did you test sending to integrated address? |
|
Same issue here, but adding a bit more info in case it helps with debugging: |
|
@aleaomacedo are you sending to a regular address (95 characters) or integrated address (106 characters)? |
|
@selsta to an integrated address |
|
I am also getting this "Trezor returned failure: code=99, message=Firmware error" when sending to integrated addresses. |
same here |
|
seems to be an issue with integrated addresses - sending the funds to a regular wallet and then to the one you want seems to be a workaround until it is fixed. |
|
Integrated address issue is fixed in #2479, thanks for diagnosis assist! |
Warning: Following procedure may lead to fund loss if used incorrectly. Use only if you know what you are doing.btw, technically, another potential workaround could be to specify address and payment ID separated. according to the https://xmr.llcoins.net/addresstests.html, the following integrated address parses to Thus instead of We could do Note that this procedure can lead to a fund loss, e.g.,
|
|
It's safer to create a new non-Trezor wallet, top it up with the desired amount and send to the intended integrated address from there - either via |
|
Hello, issue is not resolved I still cannot do the paiement with the latest Trezor firmware (using latest monero cli and issue is the same with monero-gui app). |
|
The issue will be resolved via #2479 in November update (which will be published in the middle of November). |
|
@opyr There's nothing you can do until the Trezor November firmware update apart from sending to a separate address. |
|
Sorry, I misread and I thought you are reporting the same issue as the previous ones. Can you try to send a smaller amount for testing reasons? And do you have a custom background image? |
|
Sending to an integrated address (106 characters) does not work until the November firmware update.
Yes. |
|
Either you sent to a regular address, or you used a non Trezor wallet. Everything else is unlikely as this is a firmware bug. |
Can it be that Trezor Firmware was updated somehow? (e.g., via Trezor Suite). What is the firmware version you have? Sending to an integrated address worked previously, but is broken in the latest firmware version (new planned release fixes it). |
This test was added along with the fix to the pipeline. It should not happen again. |
|
@ghost can you please test in one more time after you upgrade firmware version to 2.5.3 |
Describe the bug
I'm unable to create an XMR transaction using the monero-gui wallet. When signing the transaction, it briefly displays "Signing input 1/39" before stopping. Monero GUI displays the error message "Can't create transaction: unexpected error: Trezor returned failure: code=99, message=Firmware error"
Firmware version and revision
Trezor Model T Firmware v2.4.3
Desktop/smartphone setup (please complete the following information):
The text was updated successfully, but these errors were encountered: