XMR signature verification proposal｜Clarify the boundaries of view-only wallets｜Don’t chase before $647
My approach is to treat wallet security improvements as something to monitor over the long term, rather than hype unmerged code as a short-term catalyst. Proposal #11675 in Monero’s official code repository is still open and awaiting review. It concerns rejecting message signatures that cannot be verified. The developers explain that a view-only wallet may currently try to use a spend key it does not possess when signing via the wallet API’s signMessage or the wallet RPC’s default signing mode. A release build may return a signature that cannot be verified, while a debug build triggers an assertion. The proposed change first checks that the public key derived from the selected private key matches the public key required by the address, and then signs. The API returns an error status if something goes wrong, while RPC returns an error. Another boundary condition is that, when an explicit address is supplied, both the spend public key and the view public key must be checked, to avoid producing a signature that does not correspond to the given address merely because one of them matches. The code diff and its explanation corroborate each other, but this is not yet a released version.
I think this affects how much wallet users can trust a “signature successful” message, especially when using message signatures to prove control of an address. It does not support the conclusion that on-chain transaction signatures have generally stopped working, and there is no evidence that XMR has been double-spent or that funds have been stolen from the Monero mainnet. The developers list unit tests, wallet API tests, and RPC functional tests as having been run. That helps with the review, but it is not a security audit finding. The latest official release currently listed on the website is still the October 16 patch release, version 0.18.5.4, and the announcement does not list #11675 as a fix that has shipped. Only if the code is later merged, released, and installed by users can we say that the practical usage boundaries have changed.
The regulatory picture also needs to be corrected at the same time: in my earlier XMR post, I cited the French National Assembly’s November 3 vote in favor of an amendment requiring declarations for self-custodied holdings of €100,000 or more. That vote count is still accurate, but subsequent parliamentary records show that the first-reading text of the 2027 Finance Bill was rejected in its entirety on November 4. The amendment’s passage in a vote should not be presented as a declaration requirement already in force. The text also does not name XMR or propose a ban on privacy coins. Conflating a wallet-signing PR with the French tax debate into a narrative that “privacy coins are being banned” would mislead people’s position decisions. What is really worth tracking is the progress of the formal bill and Monero’s release announcements.
The market price does not yet support a reliable attribution. XMR/USD on Kraken was about $639.99 just now, with a 24-hour low of $624.75, a high of $647.02, and an open of $641.39. The price is slightly below the open and remains within the day’s range. There is no trading-volume data or event study to support causal claims that “the signature fix pushed XMR higher” or “the French news weighed on XMR.” My view is that if the price cannot hold convincingly near $647, the current strength is just a bounce within the range. If it falls below $641 and fails to reclaim it on a rebound, short-term bullish momentum weakens. If it also loses the area around $624, the risk needs to be reassessed rather than using a development proposal to reassure myself.
If I were trading this myself: I would stay out for now. The only direction I would consider is a leveraged-free spot long, with no more than 1% of total capital allocated to a single trade. The entry trigger is a break above $647.02 followed by a retest that holds, and no new negative official security or regulatory announcements. If that trigger does not occur, I stay flat. The first target is $660, where I would take half off; the second target is $675, with a tighter protective stop on the remaining position. The initial stop goes below $641. If the price falls back below $641 after entry and fails to rebound, I would close the entire position. If it first breaks below $624, I would cancel the long plan. If #11675 is rejected or the official release notes change the boundaries of the issue, I would also revisit my view. I will not write about the plan as if the trade had already been executed.
#XMR
The above is only my personal market observation and does not constitute investment advice.
My approach is to treat wallet security improvements as something to monitor over the long term, rather than hype unmerged code as a short-term catalyst. Proposal #11675 in Monero’s official code repository is still open and awaiting review. It concerns rejecting message signatures that cannot be verified. The developers explain that a view-only wallet may currently try to use a spend key it does not possess when signing via the wallet API’s signMessage or the wallet RPC’s default signing mode. A release build may return a signature that cannot be verified, while a debug build triggers an assertion. The proposed change first checks that the public key derived from the selected private key matches the public key required by the address, and then signs. The API returns an error status if something goes wrong, while RPC returns an error. Another boundary condition is that, when an explicit address is supplied, both the spend public key and the view public key must be checked, to avoid producing a signature that does not correspond to the given address merely because one of them matches. The code diff and its explanation corroborate each other, but this is not yet a released version.
I think this affects how much wallet users can trust a “signature successful” message, especially when using message signatures to prove control of an address. It does not support the conclusion that on-chain transaction signatures have generally stopped working, and there is no evidence that XMR has been double-spent or that funds have been stolen from the Monero mainnet. The developers list unit tests, wallet API tests, and RPC functional tests as having been run. That helps with the review, but it is not a security audit finding. The latest official release currently listed on the website is still the October 16 patch release, version 0.18.5.4, and the announcement does not list #11675 as a fix that has shipped. Only if the code is later merged, released, and installed by users can we say that the practical usage boundaries have changed.
The regulatory picture also needs to be corrected at the same time: in my earlier XMR post, I cited the French National Assembly’s November 3 vote in favor of an amendment requiring declarations for self-custodied holdings of €100,000 or more. That vote count is still accurate, but subsequent parliamentary records show that the first-reading text of the 2027 Finance Bill was rejected in its entirety on November 4. The amendment’s passage in a vote should not be presented as a declaration requirement already in force. The text also does not name XMR or propose a ban on privacy coins. Conflating a wallet-signing PR with the French tax debate into a narrative that “privacy coins are being banned” would mislead people’s position decisions. What is really worth tracking is the progress of the formal bill and Monero’s release announcements.
The market price does not yet support a reliable attribution. XMR/USD on Kraken was about $639.99 just now, with a 24-hour low of $624.75, a high of $647.02, and an open of $641.39. The price is slightly below the open and remains within the day’s range. There is no trading-volume data or event study to support causal claims that “the signature fix pushed XMR higher” or “the French news weighed on XMR.” My view is that if the price cannot hold convincingly near $647, the current strength is just a bounce within the range. If it falls below $641 and fails to reclaim it on a rebound, short-term bullish momentum weakens. If it also loses the area around $624, the risk needs to be reassessed rather than using a development proposal to reassure myself.
If I were trading this myself: I would stay out for now. The only direction I would consider is a leveraged-free spot long, with no more than 1% of total capital allocated to a single trade. The entry trigger is a break above $647.02 followed by a retest that holds, and no new negative official security or regulatory announcements. If that trigger does not occur, I stay flat. The first target is $660, where I would take half off; the second target is $675, with a tighter protective stop on the remaining position. The initial stop goes below $641. If the price falls back below $641 after entry and fails to rebound, I would close the entire position. If it first breaks below $624, I would cancel the long plan. If #11675 is rejected or the official release notes change the boundaries of the issue, I would also revisit my view. I will not write about the plan as if the trade had already been executed.
#XMR
The above is only my personal market observation and does not constitute investment advice.
