trezor-firmware
trezor-firmware copied to clipboard
trezor
Error creating XMR transaction
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):
- Wallet software: Monero GUI 0.17.3.1-release (Qt 5.15.2)
- OS: Win10 21H2
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 consolidation
A 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 logs
We 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.
MONERO_LOG_LEVEL=4 monero-wallet-gui --log-file=path/to/log.file
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 debugging
Depending 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 wallet
For 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 firmware
If 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 firmware
Follow https://wiki.trezor.io/Developers_guide:Deterministic_firmware_build "Trezor Model T firmware" section. Basically:
- install Docker
- clone the firmware repository:
git clone https://github.com/trezor/trezor-firmware.git - go into the firmware folder:
cd trezor-firmware - checkout the release tag:
git checkout core/v2.4.3 - run
export PRODUCTION=0 - modify
build-docker.sh:
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 \
- run
PRODUCTION=0 bash build-docker.sh core/v2.4.3 - upload a new firmware to a Trezor with
trezorctl firmware_update -f build/core/firmware/firmware.bin
Then attach serial logger to the Trezor.
For example, use one from [email protected]:ph4r05/monero-agent.git:
python -m monero_poc.log_aux --serial /dev/tty.usbmodem142143204
Disclaimer
I 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 As a quick test I'm able to get the transaction to sign by reducing the amount of the transaction (and therefore UTXOs). I'm having this issue with multiple wallets (all using the same trezor seed w/ different passphrases), and in each instance reducing the number of UTXOs allows for the transaction to be signed.
The only thing I can really notice from the log is that the following warning appears consistently when signing fails:
2022-04-11 19:01:11.126 11696 DEBUG wallet.wallet2 src/wallet/wallet2.cpp:10410 Total received by REDACTED: ?.??, expected ?.??
2022-04-11 19:01:11.126 11696 TRACE device.trezor src/device_trezor/device_trezor_base.cpp:204 Ask for UNLOCKING for device in thread
2022-04-11 19:01:11.126 11696 TRACE device.trezor src/device_trezor/device_trezor_base.cpp:206 Device UNLOCKed
2022-04-11 19:01:11.126 11696 INFO wallet.wallet2 src/wallet/wallet2.cpp:950 Decrypted payment ID: <0000000000000000>
2022-04-11 19:01:11.126 11696 DEBUG wallet.wallet2 src/wallet/wallet2.cpp:10841 Using v13 rules
2022-04-11 19:01:11.126 11696 TRACE net contrib/epee/include/net/net_helper.h:460 READ ENDS: Success. bytes_tr: 479
2022-04-11 19:01:11.126 11696 TRACE net.http contrib/epee/include/net/http_client.h:654 http_stream_filter::parse_cached_header(*)
2022-04-11 19:01:11.164 11696 TRACE net contrib/epee/include/net/net_helper.h:460 READ ENDS: Success. bytes_tr: 645
2022-04-11 19:01:11.164 11696 TRACE net.http contrib/epee/include/net/http_client.h:654 http_stream_filter::parse_cached_header(*)
2022-04-11 19:01:11.727 11696 TRACE net contrib/epee/include/net/net_helper.h:460 READ ENDS: Success. bytes_tr: 192
2022-04-11 19:01:11.727 11696 TRACE net.http contrib/epee/include/net/http_client.h:654 http_stream_filter::parse_cached_header(*)
2022-04-11 19:01:11.727 11696 DEBUG device.trezor src/device_trezor/device_trezor_base.cpp:426 on_button_request, code: 8
2022-04-11 19:01:11.727 11696 DEBUG frontend src/wallet/api/wallet.cpp:404 onDeviceButtonRequest
2022-04-11 19:01:13.111 20908 DEBUG frontend src/wallet/api/wallet.cpp:404 Checking connection status
2022-04-11 19:01:13.112 20908 TRACE net contrib/epee/include/net/net_helper.h:460 READ ENDS: Success. bytes_tr: 601
2022-04-11 19:01:13.112 20908 TRACE net.http contrib/epee/include/net/http_client.h:654 http_stream_filter::parse_cached_header(*)
2022-04-11 19:01:13.924 11696 TRACE net contrib/epee/include/net/net_helper.h:460 READ ENDS: Success. bytes_tr: 188
2022-04-11 19:01:13.924 11696 TRACE net.http contrib/epee/include/net/http_client.h:654 http_stream_filter::parse_cached_header(*)
2022-04-11 19:01:13.924 11696 DEBUG frontend src/wallet/api/wallet.cpp:404 onDeviceButtonPressed
2022-04-11 19:01:13.924 11696 DEBUG device.trezor src/device_trezor/device_trezor_base.cpp:426 on_button_request, code: 8
2022-04-11 19:01:13.924 11696 DEBUG frontend src/wallet/api/wallet.cpp:404 onDeviceButtonRequest
2022-04-11 19:01:15.116 25180 TRACE net contrib/epee/include/net/net_helper.h:460 READ ENDS: Success. bytes_tr: 601
2022-04-11 19:01:15.116 25180 TRACE net.http contrib/epee/include/net/http_client.h:654 http_stream_filter::parse_cached_header(*)
2022-04-11 19:01:16.386 11696 TRACE net contrib/epee/include/net/net_helper.h:460 READ ENDS: Success. bytes_tr: 329
2022-04-11 19:01:16.386 11696 TRACE net.http contrib/epee/include/net/http_client.h:654 http_stream_filter::parse_cached_header(*)
2022-04-11 19:01:16.386 11696 DEBUG frontend src/wallet/api/wallet.cpp:404 onDeviceButtonPressed
2022-04-11 19:01:16.826 11696 TRACE net contrib/epee/include/net/net_helper.h:460 READ ENDS: Success. bytes_tr: 220
2022-04-11 19:01:16.826 11696 TRACE net.http contrib/epee/include/net/http_client.h:654 http_stream_filter::parse_cached_header(*)
2022-04-11 19:01:16.826 11696 DEBUG WalletAPI src/wallet/api/wallet.cpp:2274 startRefresh: refresh started/resumed...
2022-04-11 19:01:16.826 22456 TRACE WalletAPI src/wallet/api/wallet.cpp:2222 refreshThreadFunc: refresh lock acquired...
2022-04-11 19:01:16.826 22456 TRACE WalletAPI src/wallet/api/wallet.cpp:2223 refreshThreadFunc: m_refreshEnabled: 1
2022-04-11 19:01:16.826 11696 WARNING frontend src/wallet/api/wallet.cpp:412 QObject: Cannot create children for a parent that is in a different thread.
2022-04-11 19:01:16.826 11696 WARNING frontend src/wallet/api/wallet.cpp:412 (Parent is Wallet(0x2a2806d0), parent's thread is QThread(0x694b340), current thread is QThreadPoolThread(0x1a87cac0)
2022-04-11 19:01:16.826 22456 TRACE WalletAPI src/wallet/api/wallet.cpp:2224 refreshThreadFunc: m_status: 1
2022-04-11 19:01:16.826 22456 TRACE WalletAPI src/wallet/api/wallet.cpp:2225 refreshThreadFunc: m_refreshShouldRescan: 0
2022-04-11 19:01:16.826 22456 TRACE WalletAPI src/wallet/api/wallet.cpp:2227 refreshThreadFunc: refreshing...
2022-04-11 19:01:16.826 22456 TRACE WalletAPI src/wallet/api/wallet.cpp:2240 doRefresh: doRefresh, rescan = 0
2022-04-11 19:01:16.826 1060 DEBUG frontend src/wallet/api/wallet.cpp:404 Transaction created
2022-04-11 19:01:16.826 22456 TRACE wallet.wallet2 src/wallet/wallet2.cpp:2968 update_pool_state start
2022-04-11 19:01:16.828 22456 TRACE net contrib/epee/include/net/net_helper.h:460 READ ENDS: Success. bytes_tr: 12015
2022-04-11 19:01:16.828 22456 TRACE net.http contrib/epee/include/net/http_client.h:654 http_stream_filter::parse_cached_header(*)
2022-04-11 19:01:16.828 22456 TRACE wallet.wallet2 src/wallet/wallet2.cpp:2986 update_pool_state got pool
2022-04-11 19:01:16.828 22456 TRACE wallet.wallet2 src/wallet/wallet2.cpp:3047 update_pool_state done first loop
2022-04-11 19:01:16.828 22456 TRACE wallet.wallet2 src/wallet/wallet2.cpp:3056 update_pool_state done second loop
2022-04-11 19:01:16.828 22456 DEBUG wallet.wallet2 src/wallet/wallet2.cpp:3076 Already seen <feb6443115ae8cfe857191f2793c383cd5c0b5bfc9aa8a086f86ace686d7a301>, and not for us, skipped
2022-04-11 19:01:16.828 22456 DEBUG wallet.wallet2 src/wallet/wallet2.cpp:3076 Already seen <86e47ea968be70716901431abbf062e078bd6ae56190866069994a6710208b02>, and not for us, skipped
2022-04-11 19:01:16.828 22456 DEBUG wallet.wallet2 src/wallet/wallet2.cpp:3076 Already seen <2705752b3d1b5ff2fde9454e003163b68b564ffc7072e81b3a18fb9ef4d79102>, and not for us, skipped
2022-04-11 19:01:16.828 22456 DEBUG wallet.wallet2 src/wallet/wallet2.cpp:3076 Already seen <b9742d1120a96a9b7ce3b72fedcf4aa90b20e280cc413ae58a105a4ce610cb02>, and not for us, skipped
2022-04-11 19:01:16.828 22456 DEBUG wallet.wallet2 src/wallet/wallet2.cpp:3076 Already seen <e7fbdcf647c3543e56582776c4d084387a827e2ef10bb54d621595d69c444205>, and not for us, skipped
2022-04-11 19:01:16.828 22456 DEBUG wallet.wallet2 src/wallet/wallet2.cpp:3076 Already seen <9158d72b0a1d42627fa40b646e084a8ffa96eff545d99d7da653a58c28126f07>, and not for us, skipped
2022-04-11 19:01:16.828 22456 DEBUG wallet.wallet2 src/wallet/wallet2.cpp:3076 Already seen <b9bd777dadd88a5bb6630fbe8fe45856310cad80d29bade493f7f7ff1c51b107>, and not for us, skipped
2022-04-11 19:01:16.828 22456 DEBUG wallet.wallet2 src/wallet/wallet2.cpp:3076 Already seen <4b51dbf59379dfc7b24e725273264f73166b2ce83d02c7554b856081d6dae308>, and not for us, skipped
2022-04-11 19:01:16.828 22456 DEBUG wallet.wallet2 src/wallet/wallet2.cpp:3076 Already seen <b3cff0e9fba8be447743ea9242027eb931e2f64e3b6c274a1987936589587409>, and not for us, skipped
2022-04-11 19:01:16.828 1060 ERROR frontend src/wallet/api/wallet.cpp:416 Can't create transaction: unexpected error: Trezor returned failure: code=99, message=Firmware error
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.
Tests
On a real device I've performed the following tests with various firmware versions.
-
v2.4.3 release 110 UTXOs transaction & 2 transaction outputs + full trezor-monero test suite, pass. There is no sign of a memory problem signing large transaction, memory usage is stable during UTXO processing, no sign of memory leaks, memory free/allocated during signing 1/110:
F: 56912 A: 102448. More than enough of free RAM is available. - v2.4.3 release 110 UTXOs, 16 transaction outputs. pass
- monero-dev branch (current devel with the newest updates), same suite, same results. pass.
F: 54128 A: 105232.
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? If yes, please try again after resetting the homescreen to the default. We thought that we solved all homescreen related issues already, but it just might be the case that Monero still has a problem.
@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: https://github.com/monero-project/monero/issues/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. But unlike the author of this ticket, I didn't get messages like this: "Signing input 1/39". Is there anything I can do to help solve this issue?
@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". I tried to make transfers in two wallet modes. The first time I did it in simple mode and after that I switched to "Advanced mode (Local node)". The error still persists. I did another experiment: I created an additional account in the same wallet and tried to transfer from the previous account to the new one. This transfer was successful without any errors. After that, I tried to make a transfer from a new account to another wallet. And I ran into the same "Trezor returned failure: code=99, message=Firmware error" error again. And the last one: I tried to do it as you requested to make a transfer in the monero-wallet-cli and again I got the same 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 ~/.shared-ringdb folder and then set a custom remote node with a node that is definitely updated: https://github.com/monero-project/monero-gui/issues/3989#issuecomment-1214412781
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: I used to run monerod 0.17 from Ubuntu repositories on a POP_OS installation (all updates applied). Monero-gui installed from the Pop_Shop as flatpak. No problem sending or receiving transactions with this setup. With the latest fork, and the unavailbaility of monerod 0.18 in the repository, i started to run the node included in the monero-gui flatpak. I was getting a different error a few days ago (can't remember exactly which one was), but after updating Trezor firmware to 2.5.2, I only get the same "Trezor returned failure: code=99, message=Firmware error" as reported above. For info: default homescreen
@aleaomacedo are you sending to a regular address (95 characters) or integrated address (106 characters)?
I am also getting this "Trezor returned failure: code=99, message=Firmware error" when sending to integrated addresses. Firmware 2.5.2, 0.18.1.0 GUI
I am also getting this "Trezor returned failure: code=99, message=Firmware error" when sending to integrated addresses. Firmware 2.5.2, 0.18.1.0 GUI
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.
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. e.g.,
according to the https://xmr.llcoins.net/addresstests.html, the following integrated address
4LL9oSLmtpccfufTMvppY6JwXNouMBzSkbLYfpAV5Usx3skxNgYeYTRj5UzqtReoS44qo9mtmXCqY45DJ852K5Jv2bYXZKKQePHES9khPK
parses to
4AdUndXHHZ6cfufTMvppY6JwXNouMBzSkbLYfpAV5Usx3skxNgYeYTRj5UzqtReoS44qo9mtmXCqY45DJ852K5Jv2684Rge
payment ID: 8a125052fe6f3877
Thus instead of
transfer 4LL9oSLmtpccfufTMvppY6JwXNouMBzSkbLYfpAV5Usx3skxNgYeYTRj5UzqtReoS44qo9mtmXCqY45DJ852K5Jv2bYXZKKQePHES9khPK 1
We could do
transfer 4AdUndXHHZ6cfufTMvppY6JwXNouMBzSkbLYfpAV5Usx3skxNgYeYTRj5UzqtReoS44qo9mtmXCqY45DJ852K5Jv2684Rge 1 8a125052fe6f3877
Note that this procedure can lead to a fund loss, e.g.,
- if you send funds to a normal address which does not correspond to the integrated address (bug, bad usage, invalid address parsing tool)
- or if you make a typo or forget to include the payment ID (e.g., exchange will not register this payment as received)
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 sweep_all directly or by doing that after a normal transfer.
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 https://github.com/trezor/trezor-firmware/pull/2479 in November update (which will be published in the middle of November).