MantisBT - Issues

0011740: challenger does not report permanent failure of address verification attempts to the exchange

Sun, 27 Sep 2026 01:36:07 +0200

... and thus the AML/KYC engine can't react to them.

What happened previously was that the process timed out, and the user was just stuck with a permanent error message (see 0011739).

0011826: test failures

Sat, 26 Sep 2026 11:37:49 +0200

libextractor 1.19 (as built in pkgsrc) reports 4 test failures running the test suite.
```
PASS: test_trivial
PASS: test_plugin_loading
PASS: test_plugin_load_multi
FAIL: test_ipc
FAIL: test_file
FAIL: test_gzip
FAIL: test_bzip2
============================================================================
Testsuite summary for libextractor 1.19
============================================================================
# TOTAL: 7
# PASS: 3
# SKIP: 0
# XFAIL: 0
# FAIL: 4
# XPASS: 0
# ERROR: 0
```
The test-suite log is not very helpful:
```
FAIL: test_ipc
==============

FAIL test_ipc (exit status: 2)

FAIL: test_file
===============

FAIL test_file (exit status: 2)

FAIL: test_gzip
===============

FAIL test_gzip (exit status: 2)

FAIL: test_bzip2
================

FAIL test_bzip2 (exit status: 2)

```

0011797: release Android wallet 1.6.8

Fri, 25 Sep 2026 21:31:49 +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

0011825: withdrawTestBalance needs error handling

Fri, 25 Sep 2026 11:52:46 +0200

Since it was once implemented as test call only, withdrawTestBalance doesn't support proper error handling.
But we use this call in the production wallet for "Get demo cash". If the user has a bad network connection, they might see an "Internal core error" instead of first "Network is slow" and then the real error with a Retry button.

It should support sending delayed and stalled notifications.

0011824: multiuser setup : can't stop system services if user services are up

Thu, 24 Sep 2026 21:16:38 +0200

gnunet-arm -s is launched as system service
[arm]
START_SYSTEM_SERVICES = YES
START_USER_SERVICES = NO

then a user start user services (fs, namestore, zonemaster)

if I try to stop/restart system service (gnunet-arm -e && gnunet-arm -s) stopping never returns
if I stop the user services, the gnunet-arm -e ends and services are restarted...

user service shall not block system services... if transport is down, then fs, namestore, zonemaster shall only report errors (as if network is down).

0011813: Inconsistent UI between order list and details view

Thu, 24 Sep 2026 21:07:12 +0200

the UI does not consistently show settled orders in the list view

0011823: only 4 peers?

Thu, 24 Sep 2026 21:06:09 +0200

Hi,
I now run gnunet for some time, seems stable, at least it keep up and I see peers,
but I wonder if is it normal that I see only 4 to 6 peers at most...
I'm a bit puzzled, because when I tested gns, it looked as if I could reach only the peers that I see, as if there was no forwarding....

# su gnunet -c "gnunet-gns -t EDKEY -u higepi.gnunet.gns.alt "
>>> Looking for `EDKEY' records under `higepi.gnunet.gns.alt'
<<< 1 record(s) found:

EDKEY: `000G056EKDRX45PDSVG8BCBH74A86X4DNK4FYNAJ0WVRX9B92H7SYVBG3M'

Resolution finished after 74 ms
Record set expires in 23 h.

so gns resolv.... but I don't know for exemple how I can test that I can reach higepi.gnunet.gns.alt

I wonder also if there is some file I can test to see if file sharing is working....
tried the files in the documentation like COPYING but never got any result
https://docs.gnunet.org/latest/users/fs.html

0009422: TALER_EXCHANGE_check_coin_conflict_ was never implemented

Thu, 24 Sep 2026 17:08:59 +0200

This is to check client-side that coins were actually in conflict (say different denoms or different age commitments).

0009828: Redesign recoup to accomodate for changes in withdraw and refresh API's

Thu, 24 Sep 2026 17:06:53 +0200

With the latest changes to the withdraw and refresh protocols, an individual delivered/signed coin can not be identified within the withdraw or refresh tables - we only store the hash over all blinded planchets coming in and the hashes of those being signed.

Therefore, right now the protocols for recoup for withdraw and refresh do not provide the necessary parameters in order to be able to perform _all_ of the following checks:

1) identify the right withdraw or refresh operation
2) ensure that the recouped coin was part of that operation
3) verify that the recoup request is signed by the recouped coin.

1) and 3) can already be done, but 2) is missing.

0009373: batch_ensure_coin_known not yet used [2d]

Thu, 24 Sep 2026 17:04:50 +0200

Plus the code is a pre-array nightmare. Should be fixed to use arrays and then actually used (especially in batch-deposit.c!).

0007868: recoup transaction not spec'ed in DD37

Thu, 24 Sep 2026 17:03:58 +0200

We have the recoup transaction that results from the exchange revoking denominations.

It's not yet specified in DD37, nor is the implementation DD37-conformant.

0008076: Brandt-Vickrey Auctions

Thu, 24 Sep 2026 14:38:22 +0200

This issue tracks the implementation of design document 032:
https://docs.taler.net/design-documents/032-brandt-vickrey-auctions.html

0006565: wallet should try recoup when payment fails with certain error codes

Thu, 24 Sep 2026 14:29:15 +0200

Currently recoup is only done when the exchange information is updated/queried.

0008943: integration test for recoup-refresh is incomplete

Thu, 24 Sep 2026 14:29:04 +0200

In recoupRefreshCoin, removing the code that refreshes the coin credited via recoup-refresh does not make the test case fail.

Thus, something in the test case is definitely missing.

0011798: checkPayForTemplate should return amountAvailable

Thu, 24 Sep 2026 12:28:11 +0200

When the user scans a pay-template talerURI, the amount can be nil, which means that the user can type in the amount to pay.
For this, we should show the user how much money they have available.
Instead of creating a new call (like getMaxPeerPushDebitAmount), wallet-core should always (mandatory) return "amountAvailable" (or "maxAmountAvailable") directly from checkPayForTemplate - not only if the requested amount is nil. If a fixed amount is set, wallets can immediately compare it with amountAvailable and show whether the payment is possible or not. If the user can type in an amount, wallets can limit it to amountAvailable.

Future: merchants can return multiple accepted currencies (array). The user first needs to choose an exchange, then type in the amount. Thus amountAvailable also should become an array. Consider using scopeIdx (0011651)

0011821: wallets should show notifications when balance changes due to double spending

Thu, 24 Sep 2026 12:21:23 +0200

When a wallet restored from a backup contains coins already spent, a payment can cause an unexpected balance jump: The balance decreases due to the completed payment *and* due to detected double-spending.

In this case, we should display some kind of notification to the user.

Alternatives would be separate transactions for double spending, but IMO dismissable notifications are better suited:
* These events don't fit the typical transaction lifecycle
* It doesn't make sense to merge them in backup/sync

0011811: [wip] Missing end-user docs: wallet backup/restore (Android + iOS)

Thu, 24 Sep 2026 01:26:16 +0200

Came in via support@; HD#0049.

docs.taler.net has no end-user page for wallet backup/restore.

Android: Settings -> Developer mode -> Export/Import database (JSON; also raw SQLite).
iOS: Settings -> More -> Backup/Restore (Taler-* files).

Please document both for end users (and whether Android export should leave Developer mode).

0011810: Missing end-user docs: wallet backup/restore (Android + iOS)

Thu, 24 Sep 2026 01:25:53 +0200

Helpdesk (ERPNext): user asked how to back up the Taler wallet on Android. docs.taler.net has no end-user backup page. Apps already support export/import (Android: Settings → Developer mode → Export/Import database; iOS: Settings → Backup/Restore). Please document backup + restore for Android and iOS wallets (JSON + raw sqlite where applicable), including overwrite warnings. Trigger: Pierre / ERPNext helpdesk.

0011816: ToS need to be accepted although not changed at server

Wed, 23 Sep 2026 16:14:34 +0200

We experienced that a lot at Datenspuren, can not reliably say if it happened every single time. On a new withdraw (bank transfer or cashier app) and / or reception of w2w-payment, the user was prompted to accept the ToS again although they had not changed.

On iOS, this was even more severe, and maybe would warrant a separate issue: Sometimes (tm) the ToS were shown, but not the button to accept them. So users could not continue to withdraw / receive the payment. Only option was to force quit the wallet and scan the QR code anew. Most of the time

0011768: consider supporting DD101 token semantics for templates

Wed, 23 Sep 2026 13:41:31 +0200

The merchant would need to know how to evaluate token semantics rules in that case.

0010509: need support for v1 contracts incl. subscription and discounts in UI

Wed, 23 Sep 2026 13:16:40 +0200

Giving choices at purchase, showing details about inputs/outputs of the contract. See Vlada design work and hopefully soon the Android implementation.

0011796: Unable to cancel payment

Wed, 23 Sep 2026 12:42:27 +0200

clicking on "Bezahlvorgang abbrechen" does not do anything.

may or not be related to https://bugs.gnunet.org/view.php?id=11793

0011802: Show "What's new" on app store page

Wed, 23 Sep 2026 12:42:01 +0200

As a user of the wallet app, I would like to know what the updates are in new versions.

Currently, I just see that a new version is available and am asked to upgrade. There is no transparency about what the upgrade is about - if it fixes bugs and what improvements or new features it contains. After the upgrade, there is no information either. I find it hard to find the release notes online. It's a blackbox.

In F-Droid for example, some apps show version-specific updates in a What's New box. Technically, this data comes from the metadata folder in the app's repository, typically in files named like com.example.app.yml with a WhatisNew: field.

Providing this information to users brings transparency, informs about the progress of the app, is a promotion for Taler Wallet and helps users to better decide if they should update immediately or if it can be done later. Overall it improves user experience and promotes trust in Taler Wallet.

Experienced with the update to version 1.6.8 (fdroid 997)

0011793: Android wallet hangs on template with fixed amount and summary

Wed, 23 Sep 2026 12:41:12 +0200

Likely some race condition.

0011752: Race conditions in TOPS/CHF payments -> order ID issue

Wed, 23 Sep 2026 12:40:44 +0200

Happens in google 95 (release today, 2026-08-28).

Error, JSON:

{
  "code": -1,
  "hint": "order not found (expired?)",
  "message": null
}