View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011367 | Taler | wallet (all platforms) | public | 2026-04-30 11:06 | 2026-06-03 22:25 |
| Reporter | Christian Grothoff | Assigned To | Florian Dold | ||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | confirmed | Resolution | open | ||
| Platform | i7 | OS | Debian GNU/Linux | OS Version | squeeze |
| Product Version | git (master) | ||||
| Target Version | 1.6 | ||||
| Summary | 0011367: double-spending fun with pending transactions | ||||
| Description | Torsten on iphone managed the following: - Balance: 5 CHF - p2p send: 4.5 CHF -- transaction: pending (receiver did not yet accept) - p2p send AGAIN: 4.5 CHF *allowed* -- failed to generate QR code (but did NOT say insufficient balance) Main screen then shows 9 CHF outgoing pending transactions with 5 CHF balance. Abort 1st transaction -- hangs in cancellation. Abort 2st transaction -- also hangs in cancellation. AFAIK full balance is not inaccessible to the user. | ||||
| Tags | No tags attached. | ||||
| related to | 0011465 | assigned | Florian Dold | remove prospective coin selection feature from the wallet |
|
|
Please check which wallets are affected, if a wallet-core API change is needed, and plan a way to get locked-up balances unstuck for users where this happened (=> DB fixup?). |
|
|
Strange. First tx should reserve coins internally in the DB, then send them to the Exchange (if necessary spawn a task to withdraw change), receive the purse data back, and THEN generate the talerURI for the receiver. Thus if the user was able to see a QR code and send the talerURI to the receiver, the coins have already arrived at the Exchange. It should never be possible for a second tx to use these reserved coins. Wallet-core should show that (at most) 50Rp are available - or even less if the change didn't arrive yet. Affected wallets: Of course all, since all wallets only display what wallet-core tells them. |
|
|
Could not reproduce "double spending" on Android, second p2p send reports correct available balance (minus pending outgoing). However, p2p send transactions cannot be aborted, they get stuck on "aborting" state. |
|
|
I can't confirm Ivan's finding. On iOS, I could successfully abort a P2P send tx, and the amount was then available for spending. �"id":52 abortTransaction{"transactionId":"txn:peer-push-debit:JR0AFSB8X3Q0WV9D795Z576KEXFZPZJ8EBQ5KX5E43HD39HR9DS0"} Timestamp: 2026-04-30 15:02:29.483587+02:00 handleStateTransition: Aborting: txn:peer-push-debit:JR0AFSB8X3Q0WV9D795Z576KEXFZPZJ8EBQ5KX5E43HD39HR9DS0 Timestamp: 2026-04-30 15:02:29.499770+02:00 [9] 15:02:29.501 � WalletCore.swift:157 WalletCore#1 handleResponse(_:_:) {"type":"response","operation":"abortTransaction","id":52,"result":{}} [9] 15:02:29.513 � WalletCore.swift:319 WalletCore#1 handleNotification(_:_:) {"type":"notification","payload":{"type":"transaction-state-transition","transactionId":"txn:peer-push-debit:JR0AFSB8X3Q0WV9D795Z576KEXFZPZJ8EBQ5KX5E43HD39HR9DS0","oldTxState":{"major":"aborting","minor":"delete-purse"},"newTxState":{"major":"aborting","minor":"delete-purse"},"newStId":16973824}} after that wallet-core made the https call to the exchange: ❓52 DELETE https://exchange.demo.taler.net/purses/JR0AFSB8X3Q0WV9D795Z576KEXFZPZJ8EBQ5KX5E43HD39HR9DS0 Timestamp: 2026-04-30 15:02:29.514536+02:00 the network answer came after 308ms: ❗️ 52 https://exchange.demo.taler.net/purses/JR0AFSB8X3Q0WV9D795Z576KEXFZPZJ8EBQ5KX5E43HD39HR9DS0 Timestamp: 2026-04-30 15:02:29.822869+02:00 then the state changed to aborted: [9] 15:02:29.917 � WalletCore.swift:319 WalletCore#1 handleNotification(_:_:) {"type":"notification","payload":{"type":"transaction-state-transition","oldTxState":{"major":"aborting","minor":"delete-purse"},"newTxState":{"major":"aborted"},"transactionId":"txn:peer-push-debit:JR0AFSB8X3Q0WV9D795Z576KEXFZPZJ8EBQ5KX5E43HD39HR9DS0","newStId":84082688}} Took all in all 434 ms. |
|
|
We've now thoroughly diagnosed and reproduced the issue. There are two underlying problems: * the wallet didn't properly abort peer-push-debit transactions that did not have a coin selection * the wallet doesn't track how much of the "prospective balance" from pending refreshes has been used up. Thus with pending refreshes, arbitrary transactions (as long as each individual one is smaller than the pending refresh amount) can be confirmed. 0011465 is the bug to remove this (mis-)feature. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-04-30 11:06 | Christian Grothoff | New Issue | |
| 2026-04-30 11:06 | Christian Grothoff | Status | new => assigned |
| 2026-04-30 11:06 | Christian Grothoff | Assigned To | => Florian Dold |
| 2026-04-30 11:07 | Christian Grothoff | Note Added: 0028495 | |
| 2026-04-30 11:59 | MarcS | Note Added: 0028497 | |
| 2026-04-30 13:34 | avalos | Note Added: 0028499 | |
| 2026-04-30 15:26 | MarcS | Note Added: 0028500 | |
| 2026-06-03 22:25 | Florian Dold | Note Added: 0028768 | |
| 2026-06-03 22:25 | Florian Dold | Relationship added | related to 0011465 |
| 2026-06-03 22:25 | Florian Dold | Status | assigned => confirmed |
