MantisBT - Issues

0011735: Try to isolate performance issues observerd w/ Android Wallet v1.6.2 (google 86) against talersticker mytops shop

Thu, 20 Aug 2026 17:34:59 +0200

Testing w/ our TOPS/CHF test shop "talersticker": https://taler-ops.ch/de/testshop.html

Time from QR code / order creation and visible paid status of orders in the amounts of CHF 0.04, CHF 0.44 and 4.44 took from a few seconds in the first case in total to almost a minute in the last case; the attempt to create an order w/ CHF 5.55 didn't reach the server even, Android continued spinning, "creating the order"; app had to be stopped by force.

It might be that I've a (grown) old, broken local DB on this production wallet: in any case, we must find out what happens here, and if this is by any means reproducible.

0011736: 0011555: release Android wallet 1.6.x

Wed, 19 Aug 2026 21:03:08 +0200

https://docs.taler.net/developer/prod-release-process.html

Tracking bug for the next Android wallet production release.

Release covers both F-Droid and Google Play

0011243: aborting a partially completed payment results in temporarily wrong balance display and failed refresh transaction

Wed, 19 Aug 2026 18:56:27 +0200

When aborting a payment, we:
* create a refresh group to refresh all involved coins (in case the merchant didn't submit them to the exchange yet)
* try to pick up a refund from the merchant
* create a refresh group for refunded coins

Since usually the merchant is able to give the refund (as an abort-refund), the first refresh transaction succeeds. However, when the refresh happens before the refund, the refresh transaction fails.

We instead should teach the refund group to ignore when the expected payment has been made and the coin can't be refreshed.

Furthermore, the transaction should only show as aborted once the refresh has been completed. The output from the refresh should also not be counted towards the (non-material!) available balance, since we don't know whether it will succeed or not.

0011588: manual withdrawing partially inform non-withdrawn part as fee, even with 0 fee configured in exchange

Wed, 19 Aug 2026 18:19:26 +0200

create a manual withdraw of X
send a wire transfer of X - Y
wallet will show Y as fee and wallet core won't look for new funds

some other issue will tackle the fact that wallet-core might keep looking for new funds for uncompleted manual-withdrawal
but the UI shows Y as fee because fee is calculated as effective - raw based on https://docs.taler.net/design-documents/041-wallet-balance-amount-definitions.html

we also see this happening on other transactions, for example when p2p transaction is aborted mobile shows instructed X and fee -X

=====
i propose change this https://docs.taler.net/design-documents/041-wallet-balance-amount-definitions.html
and remove the "raw" definition

raw: The raw amount always refers to the amount with fees applied. The exact interpretation of that depends on the transaction type.

change it for list of fee

fees: list of operation reference and fee amount

The main problem is the raw is based on assumption that are not always a satisfied and when this happen the problem raised in the UI.
Instead wallet-core should inform transactions with the list of fee and this list is mutable over the time.
We may have an initial calculation of expected fee (informed when the user prepare the transaction) and it allows to add additional based on (abort, refresh coins, etc..)
Old raw can be calculated adding-up or subtracting-from instructed amount.
Operation reference can be shown in the UI in case the user wants to inspect the reason of that number. (it can be a taskId or the name + id of the operation like refresh#1)

in the withdrawal case fee will be always 0 since all operation are free of charge (the list will have N elements with amount = 0)

0010753: test that unconfirmed pay transaction transition to failed state automatically

Wed, 19 Aug 2026 17:56:27 +0200

Marc reported a case where this didn't happen.

We need to review the automated tests and do some manual testing.

0011730: merchant portal uses same email address for MFA, KYC notifications and in contract terms

Wed, 19 Aug 2026 15:43:21 +0200

These two (or three?) should be separate settings.

0010911: wallets should provide better diagnostics about why deposit is possible / not possible [meta]

Wed, 19 Aug 2026 15:31:42 +0200

We need to design better error reporting / a way to explain to the user why an account can or cannot be used for deposits.

0009746: improve error reporting when order can't be created due to wire method mismatch

Wed, 19 Aug 2026 14:46:37 +0200

Currently we can't distinguish the following cases:
(a) merchant doesn't have (up-to-date or any) information about the exchange
=> UIs can show hint about config problem or taler-merchant-exchangekeyupdate helper
(b) exchange knows for a fact that the exchange doesn't support the wire method
=> UIs can tell the user to use a different wire method

0011618: refine insufficient balance reporting [4h]

Wed, 19 Aug 2026 12:12:25 +0200

* findMatchingWire is only used during coin selection, but not during insufficient balance reporting. Thus the selection function might have different rules than the report function. This could lead to mismatches and wrong reports.
* We don't report some more exotic issues, such as a mismatched public key (when the base URL matches)

0008597: Use Elligator KEM in Core KX

Wed, 19 Aug 2026 07:50:52 +0200

Since CORE cannot assume that TNG provides encryption, it does its own KX and we may want to protect the public key of the respective KX.
Needs investigation into the Core KX if this makes sense at all.

0011527: GNUnet PQ migration meta issue

Wed, 19 Aug 2026 07:48:17 +0200

We probably want this.

We need to settle algorithm replacements including PQ-KEMs and combiners we want to implement along with suitable dependencies.
e.g. PQclear

0005886: Use more secure algorithms in CADET

Wed, 19 Aug 2026 07:48:17 +0200

Upon reading https://docs.gnunet.org/handbook/gnunet.html#CADET-Subsystem I found:

- CADET provides confidentiality with so-called perfect forward secrecy; we use ECDHE powered by Curve25519 for the key exchange and then use symmetric encryption, encrypting with both AES-256 and Twofish
- authentication is achieved by signing the ephemeral keys using Ed25519, a deterministic variant of ECDSA
- integrity protection (using SHA-512 to do encrypt-then-MAC, although only 256 bits are sent to reduce overhead)
[...]

My questions are:

1) Would it not be more ideal to use Salsa20 or XSalsa20 instead of AES-256 and Twofish?
2) Should not we use BLAKE2? Its digest sizes are 224, 256, 384, and 512 bits. There would be no need to truncate, AND it is much faster than SHA-512. See https://blake2.net/ for benchmarks and more information.

0011172: send notification to merchant when KYC status changes [meta]

Tue, 18 Aug 2026 23:28:56 +0200

Right now, the merchant has to go to the backend to see the change. We should trigger an automatic notification.

0011242: when multiple bank accounts are configured, the order is non-deterministic and causes extra notifications

Tue, 18 Aug 2026 23:28:18 +0200

See additional information for two e-mails that contain exactly the same info but in different order. We send these out every few hours, despite nothing changing except the order of bank accounts.

0011244: implement harness test for KYC status notifications [1h]

Tue, 18 Aug 2026 23:27:57 +0200

See 0011172 for details.

0011731: merchant backend does not require old password to change password

Tue, 18 Aug 2026 15:51:02 +0200

There is a MFA check required when MFA is enabled, but changing the password does not require the old password in the API.

0011729: investigate paivana issues on git-www.taler.net

Tue, 18 Aug 2026 12:14:11 +0200

Users reported issues.

0011728: spec NFC protocol used by vending machine

Mon, 17 Aug 2026 21:25:13 +0200

We currently don't have any specification of the NFC flow for (1) reading taler:// URIs and (2) responding with a xTOTP confirmation code.

It also looks like the current implementation (in taler-ios and taler-android, not sure where the current mdb code lives) of step (2) use an NDEF packet that's not compliant with the standard and thus can't be generated by WebNFC clients.

0009007: iOS wrongly reports a network failure when wallet-core cancels a long-poll network call (~ 4-6 hours)

Mon, 17 Aug 2026 18:33:40 +0200

... which of course stops wallet-core from starting any new network calls.

0011107: Backend for sms auth needs fixing for cases where number wrong (e.g., too short, too long, or invalid (like flipped digit))

Mon, 17 Aug 2026 18:33:24 +0200

Unfortunately, from our current helper scripts we get status codes like 400 or 404 for the two gateway providers we have, when we do like

+41 79 NNN NN NN K, while K is too much
+41 79 NNN NN N, with a missing digit somewhere (e.g., at the end)
+41 79 NNN NN WN, with a W turning the number invalid (e.g., at the end)

or just any other number which clearly is wrong,

0011305: merchant fails to communicate with exchange with http3 enabled

Mon, 17 Aug 2026 18:33:15 +0200

The second attempt/retry seems to succeed.

0011656: implement taler-harness playground for quickly expiring orders

Mon, 17 Aug 2026 18:32:59 +0200

This allows the UI to test rendering of expired payments (both in the tx history and during payment confirmation).

0009899: Rewrite exchangedb/test_exchange_db.c

Mon, 17 Aug 2026 18:32:12 +0200

The recent change to the new refresh/melt API requires
changes to test_exchange_db.c, which are not trivial to make.

0011666: improve integration test suite performance

Mon, 17 Aug 2026 18:28:30 +0200

... by grouping together tests and figuring out what's slow.

0011222: adding taler-ops.ch exchange takes 4-6 seconds!

Mon, 17 Aug 2026 18:19:56 +0200

This is bad for onboarding new users!

Here are the performance stats in a fresh Android wallet, running wallet-core 1.3.13 (c0a35f4), where the only performed action was adding the exchange.taler-ops.ch exchange as part of the new "Withdraw CHF" button.

{
"http-fetch": [
{
"url": "https://exchange.taler-ops.ch/keys",
"maxDurationMs": 2497,
"count": 1
},
{
"url": "https://exchange.taler-ops.ch/terms",
"maxDurationMs": 180,
"count": 1
}
],
"db-query": [
{
"name": "",
"location": "updateExchangeFromUrlHandler",
"maxDurationMs": 3442,
"count": 1
},
{
"name": "",
"location": "processValidateDenoms",
"maxDurationMs": 163,
"count": 4
},
{
"name": "",
"location": "processValidateDenoms/callOperationHandlerForTaskId",
"maxDurationMs": 104,
"count": 6
},
{
"name": "",
"location": "checkState/genericWaitForState",
"maxDurationMs": 97,
"count": 3
},
{
"name": "",
"location": "processTaskExchangeAutoRefresh/callOperationHandlerForTaskId",
"maxDurationMs": 93,
"count": 2
},
{
"name": "",
"location": "updateWithdrawalDenomsForExchange/doExchangeAutoRefresh",
"maxDurationMs": 90,
"count": 1
},
{
"name": "",
"location": "updateExchangeFromUrlHandler/callOperationHandlerForTaskId",
"maxDurationMs": 89,
"count": 3
},
{
"name": "",
"location": "listExchanges/dispatchRequestInternal",
"maxDurationMs": 72,
"count": 2
},
{
"name": "",
"location": "getBalances/dispatchRequestInternal",
"maxDurationMs": 71,
"count": 2
},
{
"name": "",
"location": "handleSetWalletRunConfig/dispatchRequestInternal",
"maxDurationMs": 58,
"count": 1
}
],
"crypto": [
{
"operation": "isValidDenom",
"maxDurationMs": 26,
"count": 344
},
{
"operation": "isValidGlobalFees",
"maxDurationMs": 1,
"count": 1
}
],
"wallet-request": [
{
"operation": "addExchange",
"maxDurationMs": 6507,
"count": 1
},
{
"operation": "initWallet",
"maxDurationMs": 121,
"count": 1
},
{
"operation": "getWithdrawalDetailsForAmount",
"maxDurationMs": 103,
"count": 1
},
{
"operation": "listExchanges",
"maxDurationMs": 75,
"count": 2
},
{
"operation": "getBalances",
"maxDurationMs": 73,
"count": 2
},
{
"operation": "getExchangeEntryByUrl",
"maxDurationMs": 61,
"count": 1
},
{
"operation": "getCurrencySpecification",
"maxDurationMs": 32,
"count": 4
},
{
"operation": "hintNetworkAvailability",
"maxDurationMs": 21,
"count": 2
},
{
"operation": "testingGetPerformanceStats",
"maxDurationMs": 2,
"count": 2
}
],
"wallet-task": [
{
"taskId": "exchange-update:https%3A%2F%2Fexchange.taler-ops.ch%2F",
"maxDurationMs": 6720,
"count": 2
},
{
"taskId": "validate-denoms:",
"maxDurationMs": 459,
"count": 5
},
{
"taskId": "exchange-auto-refresh:https%3A%2F%2Fexchange.demo.taler.net%2F",
"maxDurationMs": 93,
"count": 1
},
{
"taskId": "exchange-update:https%3A%2F%2Fexchange.demo.taler.net%2F",
"maxDurationMs": 90,
"count": 1
},
{
"taskId": "exchange-auto-refresh:https%3A%2F%2Fexchange.taler-ops.ch%2F",
"maxDurationMs": 14,
"count": 1
}
]
}