The command-line wallet that ships with Rusty Kaspa, the main Kaspa node software, will no longer sign a shared transaction file that leaves the payment open to change. Ori Newman, who maintains the node, wrote the fix after a developer called SkullElf reported that the wallet signed whatever signature type a file asked for, without showing it to the person signing (pull request).
Some of those signature types let whoever holds the signed file change where the money goes and how much is sent, and the signature still counts. The fix is in the main Rusty Kaspa code but not yet in a release, so the version most people download still behaves the old way.
A signature can seal everything or almost nothing
When you sign a normal Kaspa payment, your signature covers the whole transaction. It covers the coins you're spending and every output, meaning every address that receives money and every amount. Change one character after signing and the signature no longer matches, so the network rejects the payment.
That full seal is called SIG_HASH_ALL, and it's what wallets use almost all the time. Kaspa, like Bitcoin, also supports looser kinds of signature. SIG_HASH_NONE covers your coins but none of the outputs. SIG_HASH_SINGLE covers only the one output that sits in the same position as your coin. A modifier called ANYONECANPAY lets other people add their own coins to the transaction after you sign.
The network accepts all six combinations (list of allowed types). The difference shows up in what gets sealed. With SIG_HASH_NONE, the part of the signature that should describe the outputs is replaced by zeros, so the outputs can be anything (code). A signature like that works much like a signed cheque with the payee and amount left blank.
Where a shared file comes in
Not every payment is signed in one place. Shared savings that need two of three people to approve, or a trade where each side adds its own coins, pass around a partially signed file. In the Rusty Kaspa wallet that file is called a PSKB, short for partially signed Kaspa bundle. One person builds it, the others sign it with the pskb sign command, and someone broadcasts it.
Each input in a PSKB carries a field saying which signature type to use. Before the fix, the wallet read that field and signed with it, whatever it said (signing code). Nothing on the screen mentioned it. A person who received a file from someone else could check the amounts, sign it, and hand back a signature that let the sender redirect the funds afterwards.
The pull request doesn't describe any loss, and kaspa.news has found no reported theft. The attack needed someone to sign a file prepared by another person, which is exactly what shared signing is for.
What the wallet does now
The fix changes three things. The pskb parse command, which prints a readable view of a file, now shows the signature type for every input (display code). The pskb sign and pskb script sign commands now refuse any input that asks for something other than SIG_HASH_ALL. And there's a new flag, --allow-non-sighashall, for people who really mean to use another type (check and error message).
The refusal names the types it found, so the person signing sees, for example, that a file asks for SIG_HASH_NONE before anything is signed. For pskb sign, the check now runs before the wallet asks for its password, so a bad file is turned away at the first step. IzioDev reviewed and approved the change, and it includes tests for both the refusal and the opt-in.
Why the loose types aren't simply banned
The looser signatures have honest uses. A fundraiser can collect pledges where each donor signs with ALL plus ANYONECANPAY. The output paying the fundraiser stays sealed, while other donors keep adding their coins. A sell order can be signed with SINGLE plus ANYONECANPAY. The seller seals only the output that pays them, and the buyer fills in the rest. Bitcoin has the same set of options and the same trap. A security advisory for one Bitcoin wallet extension describes an approval screen that showed 546 satoshis coming in while the signature actually left about 1 BTC open to be taken (advisory).
So the fix doesn't stop anyone using them. It makes the risky choice visible and turns it into a deliberate step rather than a silent default.
What isn't covered yet
The change was merged after Rusty Kaspa v2.1.0, the latest release. Until the next release, people get it only by building the wallet from the main branch themselves.
The guard sits in the command-line wallet only. The shared wallet library underneath still signs with the type a file requests, so other apps built on that library need their own check. Browser and mobile wallets have their own signing screens, and this change says nothing about them.
Until the release arrives, run pskb parse on any file someone sends you and look for anything other than SIG_HASH_ALL before you sign. If a file you didn't build asks for a looser type, ask the sender why first.
