`sendtoaddress`/`sendfrom`/`sendmany` build unfundable txs → `-511 InsufficientFunds` at relay

[MIRIK1297]

Summary

The wallet RPC send methods can build, sign, and relay a transaction whose fee-payer (Signers[0]) cannot cover the network fee, producing InsufficientFunds (-511) at relay — even though Wallet.MakeTransaction already validated that the selected sender could afford the fee. The network fee is raised after MakeTransaction (i.e. after the signer was selected and the fee validated), with no re-check that the selected sender can still pay. Verified on neo-node v3.9.2 / neo core v3.9.1.

Root cause

Wallet.MakeTransaction selects the fee-payer (Signers[0]) from GAS-holding accounts (L600) and only returns a tx the chosen sender can afford:

tx.NetworkFee = tx.CalculateNetworkFee(...);            // Wallet.cs:669
if (value >= tx.SystemFee + tx.NetworkFee) return tx;   // Wallet.cs:670  ← signer selected + fee validated here

Then, after that selection, EnsureNetworkFee raises the network fee, with no re-check of the chosen sender:

long calFee = tx.Size * NativeContract.Policy.GetFeePerByte(snapshot) + 100000;
if (tx.NetworkFee < calFee) tx.NetworkFee = calFee;     // raises NetworkFee above the validated value

At relay, Transaction.VerifyStateDependent requires GAS.BalanceOf(Signers[0]) >= SystemFee + NetworkFee(raised). When the raised fee exceeds what was validated at Wallet.cs:670, the selected sender no longer covers it and the tx is rejected with -511. Affects sendtoaddress, sendfrom, and sendmany (all call EnsureNetworkFee).

[cschuchardt88]

What's the problem you want solved? Are you saying this feature should be removed?

Either way i don't see a problem. Nodes MUST be able to except any transactions that are crafted. Whether Witnesses and/or Signers have funds don't matter at a transaction level. The only thing that matters is that the Sender can pay Network costs. You must pay that in order for the node to have the transaction to be added to the MemoryPool to be stored on chain.

[MIRIK1297]

The only thing that matters is that the Sender can pay Network costs.

Exactly. Here is the problem: sendtoaddress itself selects a Sender that can't pay the final Network cost. The Sender is selected and its GAS checked in MakeTransaction against CalculateNetworkFee - before EnsureNetworkFee runs. So if the wallet contains an account whose GAS is more than SystemFee + CalculateNetworkFee but less than SystemFee + <EnsureNetworkFee result>, that account gets chosen as Sender, the fee is then bumped above its balance, and the node rejects the tx at relay with -511.

Example:

Wallet accounts:

Account	TOKEN	GAS
A	100	0
B	0	0.003 (300 000 datoshi)
C	0	5.0

sendtoaddress(TOKEN, dest, 100) → MakeTransaction(snapshot, [output]):

1. candidates   accounts = GetAccounts().Where(!Lock && !WatchOnly) = {A, B, C}       Wallet.cs:544
2. cosigners    token holders of TOKEN = {A} -> A added as cosigner                              Wallet.cs:574/584
                script: transfer(A, dest, 100)            // A must witness moving its own token
3. Sender pool  balances_gas = accounts with GAS>0, [B=0.003, C=5.0]                         Wallet.cs:600
4. selection    foreach (account, value) in balances_gas:  -- tries B first --                        Wallet.cs:645
                  Signers = GetSigners(B, {A}) = [B, A]                                                                     Wallet.cs:653
                            // B -> Signers[0] (Sender); A -> Signers[1] (cosigner)
                  tx.SystemFee  = 215 926                                                                                         Wallet.cs:666
                  tx.NetworkFee = CalculateNetworkFee // i.e.  2*32784 + 382*20 = 73208   Wallet.cs:669
                  if (B.GAS 300000 >= 215 926 + 73 208 = 289 134) return tx                  Wallet.cs:670  (B chosen)

Resulting signers:

Signers[0] = B   (Sender) 
Signers[1] = A   (cosigner)

B is chosen - its GAS (300 000) is above sys+net (289 134) so it passes the check at Wallet.cs:670.

EnsureNetworkFee then raises NetworkFee to 382*20 + 100000 = 107 640. B's 300 000 is below than 215 926 + 107 640 = 323 566, relay rejects.

Expected behavior: MakeTransaction chooses a Sender that is compliant with EnsureNetworkFee at selection time i.e. apply the same floor inside the selection check (value >= SystemFee + max(CalculateNetworkFee, tx.Size * FeePerByte + 100000)), so it only picks a Sender that can pay the fee actually broadcast.

[cschuchardt88]

Here is the differences in code

https://github.com/neo-project/neo/blob/a09eeaecc458d3a604e2f586cc02047996bedfe5/src/Neo/Wallets/Helper.cs#L111-L231

https://github.com/neo-project/neo/blob/a09eeaecc458d3a604e2f586cc02047996bedfe5/src/Neo/Network/P2P/Payloads/Transaction.cs#L323-L366

[cschuchardt88]

Also the Sender for a transaction is alway the 1st signer no matter what.

https://github.com/neo-project/neo/blob/df4026753787c93adf978a94dc63685cf54d2c82/src/Neo/Network/P2P/Payloads/Transaction.cs#L124-L128-L28

[MIRIK1297]

I rechecked the code - the problem is the following (neo-node v3.9.2 / neo core v3.9.1 - pretty same on v3.10.0):

1. MakeTransaction chooses the signer based on the not-floored network fee (CalculateNetworkFee): https://github.com/neo-project/neo/blob/v3.9.1/src/Neo/Wallets/Wallet.cs#L669-L670
2. After the signer is chosen and its balance verified, NetworkFee is increased by EnsureNetworkFee: https://github.com/neo-project/neo-node/blob/v3.9.2/plugins/RpcServer/RpcServer.Wallet.cs#L543
3. The adjusted fee is then checked again at relay: https://github.com/neo-project/neo/blob/v3.9.1/src/Neo/Ledger/TransactionVerificationContext.cs#L63-L66

So if the signer is chosen on NetworkFee = CalculateNetworkFee (e.g. 40 424 = 32784 verification + 382*20 size) and has enough balance (e.g. 100 000), then EnsureNetworkFee raises it to 382*20 + 100000 = 107 640. The transaction now fails to relay because the signer's 100 000 is below the new 107 640. (SystemFee omitted here for clarity)

Is this valid and expected behavior? It seems MakeTransaction should select the signer against the same (floored) fee that will actually be broadcast, so it doesn't hand back a transaction that can't relay.