Thank you for explaining.  This is a design flaw:


The logical way, and the secure-by-default way is for a light wallet to store the newly-created transaction and its txid, and then ask the server for its status by txid.^*

What does Electrum do, if the untrusted server discards or otherwise loses the transaction without broadcasting (and if necessary, re-broadcasting) it on the P2P network?  Rely on the user to notice the missing tx, and recreate it from scratch?  How would the user know that it’s really gone forever?  What if they’re in a hurry to meet the expiry deadline of an online invoice, and they make mistakes in haste?  If the user accidentally chooses different input to redo a seemingly missing tx, and the first tx then shows up, they could double-pay the recipient; failure to keep a record of the original tx can thus cause loss of funds.

Whenever the light wallet needs to gain its first knowledge of a tx from the server, it obviously needs to verify all signature(s) and other internal evidence of potential validity.  This is a mundane application of the tautological programming rule, “Don’t trust untrusted inputs.”  Are there any cases where Electrum still isn’t verifying the signatures?  My out-of-context skim of the security patch’s diff suggests there may be, though I could be wrong about that.


If there are any remaining cases where Electrum isn’t verifying all signature(s), I can think of interesting attacks...

---

^* A complete design also needs to keep track of wtxid, and be aware of potential variations in valid signatures.  I don’t immediately see how this could have an impact on transactions originated by the wallet—but DTRT here protects against unforeseen corner cases.  Anyway, Electrum still supports pre-Segwit txes—so it should (?) have code paths to handle malleation in all cases.  Proper design of databasing one P2WPKH tx by txid and potentially multiple wtxid(s) suggests design of the proper data model and codepaths to mitigate Bitcoin’s pre-Segwit design flaw in txids.

My advice is do not go directly to goggle play store to actually download or update your electrum app or any other wallet rather the best option is to go directly to the main website; https://electrum.org/#download to download the application which gives you the ability to verify even the signatures there. Becareful they are lots of fake electrum apps out there

What was the funny observations you found out earlier.

Immediately, I saw this news from Electrum official site on X, was the moment I upgraded my Electrum wallet to the latest version that fix these bugs. It's alarming how hackers are so much focused on attacking crypto wallets these days. I don't recheck the receiving address that I do send funds to when using RBF because I believe that's the same address which I pasted but henceforth, I will always do a thorough check and recheck before broadcasting any transaction.

Is Electrum SPV?  I thought that Electrum used the Electrum protocol; I’ve never heard it referred to as SPV.  I just double-checked the Electrum wiki article (current version permalink), Ctrl-F “SPV” and “simpli”; if Electrum is actually SPV, that information should probably be added to the article by an Electrum topical expert.


Non sequitur.  “Doesn’t know that a transaction that it created belongs to it” does not follow from “has neither the blockchain nor a mempool”.

It would follow from “completely stateless”, but Electrum is not stateless.  It has some sort of a tx database.  And I don’t think a useful wallet ever could be stateless.


That’s orthogonal to the case where you do know the txid.


In my opinion, a light client should always verify what it reasonably can.  Choosing not to verify the internal validity of a transaction, within its four corners, means blindly trusting the server not to hand you any garbage—with the results seen here, in this high-severity security bug!

Although a light client by definition cannot validate all blockchain consensus rules, it can easily validate a transaction within its four corners to assure that it’s not facially invalid.

(To my understanding, ever since Satoshi’s whitepaper, SPV clients have always been expected to validate the transaction from block headers, through a Merkle proof.  I think that this level of validation reasonably implies also checking the transaction’s internal validity, within its four corners.  This level of validation is still vulnerable to some potential attacks, but absolutely nothing like what is seen here.)


How hard is it to verify a signature?  It is an operation that takes milliseconds even on an embedded CPU, and it easily can be done from stack buffers with no dynamic memory allocation.  Simple.

I think that to begin with, the code should be designed to validate untrusted data.  If properly designed, there is no “every workaround”; validity checks occur naturally, at every point on the network security boundary where the client says, “Okay, an untrusted party on the network just handed me a bag of bits; what is it?”  If no such boundary is well-defined at the design stage, then that, itself, is a security problem.

---

Personal note:  This is of peculiar interest to me, as I’ve been slowly drafting a topic OP about my urgent need for a new light wallet.  Electrum wasn’t under consideration anyway, as I’m hoping for a BIP 157/158 wallet with TUI written in C or Rust.  I will add to my list of requirements, “The wallet must never in any circumstance accept facially invalid transactions from the network.”