MantisBT - Issues

0011873: merchant: reject @ in merchant_base_url / instance id (breaks /pay ec=2008)

Wed, 14 Oct 2026 18:50:03 +0200

Related to 0011866 (Case 2).

Problem:
merchant_base_url in the contract embeds the instance id. If the instance
id contains '@' (e.g., kontakt@example.ch), the URL becomes
https://HOST/instances/kontakt@example.ch/ and fails TALER_url_valid_charset
on /pay re-parse (TALER_JSON_spec_web_url_copy). Wallet /pay then returns
HTTP 500 ec=2008 (pay-no-deposit). Journal:

WARNING ... Failed to parse proto contract at field merchant_base_url
ASSERT ... pay.c (contract parse)
HTTP 500  ec=2008

This is independent of bare merchant.website (0011848 / #11849). The website
field can be a valid https URL while merchant_base_url is still invalid.
taler_pay_uri also embeds the instance id, so the payment URI path is
affected as well.

Observed charset (exchange src/util/url.c): no '@'
(...9/:;&?-.,=_~%+#).

Desired:
- Reject instance ids / merchant_base_url values that contain characters
outside TALER_url_valid_charset (at least '@') on instance create and
PATCH.
- Prefer a clear client-facing error at write time instead of /pay 500.
- Optionally document allowed instance-id charset for operators.

cf. 0011866 (repro/test ticket for /pay 500 with invalid merchant URL)
cf. https://git.taler.net/taler/exchange/file/src/util/url.c.html

0011866: test/reproduce: merchant /pay HTTP 500 (ec=2008) when contract embeds invalid merchant URL

Wed, 14 Oct 2026 16:33:01 +0200

Wallet /pay can return HTTP 500 (ec=2008) when the contract embeds an
invalid merchant URL. Two cases on two different instances; both
occurred on the same day (2026-10-09):

1) Bare merchant.website (no scheme). Instance-side fix already in
production since 2026-10-07 (bare host rewritten to https://...).
Despite that fix, /pay still failed on 2026-10-09: unpaid contracts
created before 2026-10-07 still embed the bare host and are not
rewritten. New orders after the fix are expected to work.

2) Invalid merchant_base_url (observed: '@'). Same 500/ec=2008; no
production fix yet.

0011872: Bank account verification: Next step unclear after initiating the transfer

Wed, 14 Oct 2026 15:56:34 +0200

During the test, Martin reported that he had initiated the verification transfer. After returning to “Bank Accounts & Payouts”, the portal still indicated that action was required. The available action led back to the transfer instructions. He only opened “Setup Status” after being prompted.

Impact:
The merchant cannot tell whether to wait or take further action. It is also unclear how they will be notified when verification is complete.

Expected behaviour / Suggested solution:
Offer a “Transfer initiated” confirmation and then redirect the merchant to “Setup Status”. Clearly display: “You have marked the transfer as initiated. Receipt of funds has not yet been confirmed.”

Once verification is complete or further information is required, an email should explain the next step and include a link to the portal.

0011871: Bank account verification: Purpose of the verification transfer is easy to miss

Wed, 14 Oct 2026 15:48:44 +0200

During onboarding on 14 October 2026, Martin asked why he needed to transfer money. The explanation below “Verify this bank account” was present, but he only noticed it after it was explicitly pointed out.

Impact:
The merchant needed clarification about the purpose of the transfer before proceeding.

Expected behaviour:
The purpose of the verification transfer should be immediately apparent before the merchant makes the payment.

Suggestion:
Make the existing explanation that the transfer verifies bank account ownership more prominent, directly next to the QR code and the manual transfer details.

0011870: Merchant portal: Make registration and sign-in easier to distinguish

Wed, 14 Oct 2026 15:38:47 +0200

During onboarding on 14 October 2026, Martin started entering his details in the sign-in form, although he wanted to create a new merchant account. He initially overlooked the existing link for creating a new account.

Impact: New merchants may confuse the sign-in form with the registration form.

Expected behaviour: Before entering any details, users can clearly distinguish between registration for new merchants and sign-in for existing merchants. Suggestion: Prominently present two distinct options: “Create a new merchant account” and “Sign in to an existing merchant account”.

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

Wed, 14 Oct 2026 13:58:29 +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.

0011828: p2p pull url fails

Tue, 13 Oct 2026 19:03:04 +0200

{
"code": 7064,
"when": {
"t_ms": 1790589705839
},
"hint": "the pull-payment invoice lacks an exchange-authenticated purse commitment"
}

0009422: TALER_EXCHANGE_check_coin_conflict_ was never implemented

Tue, 13 Oct 2026 11:05:38 +0200

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

0009373: batch_ensure_coin_known not yet used [2d]

Tue, 13 Oct 2026 11:05:28 +0200

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

0011830: exchange should return more metadata about purses for better safety and error handling in pull payments

Tue, 13 Oct 2026 10:31:34 +0200

Currently, the status signature does not sign over the purse's target amount or contract hash. A dishonest payee can supply inconsistent terms. Detecting this in the deposit confirmation happens after coins may have been deposited.

We should consider either:
* also returning and signing over the additional information
* reusing/returning the TALER_SIGNATURE_EXCHANGE_CONFIRM_PURSE_CREATION signature

0011859: Send BalanceChange after restore

Mon, 12 Oct 2026 22:14:11 +0200

After a successful restore the balances (and other cached state) are not refreshed — the old wallet's money stays on screen

0011861: Hide deposit option if DISABLE_DIRECT_DEPOSIT=YES

Mon, 12 Oct 2026 14:27:52 +0200

For the Datenspuren deployment we deactivated direct deposits to bank accounts using DISABLE_DIRECT_DEPOSIT=YES. With that option in the exchange-config, the wallet UI does prevent users from depositing by just not enabling the confirmation button (see screenshot), but it would be much better if it would actually either not offer the deposit option in the first place or show a warning that deposits are not allowed, even before selecting a bank account.

0011863: Position in transaction list is lost

Mon, 12 Oct 2026 14:27:39 +0200

In the beta version (UI rewrite), going back to the transaction list from a transaction details screen often (not always) looses the position in the transaction list. The list is scrolled to the top. Little annoying :P

I think this used to work in the current stable version, at least I could not reproduce it there.

0011860: setup public test system with some KYC for testing

Sat, 10 Oct 2026 23:32:50 +0200

Currently no public demo/test system exists for testing KYC processes by external developers. We should
set up a demo-kyc.taler.net or similar where KYC is enabled and people can play around with KYC processes.

0011789: consider sending merchant sign-up confirmation email

Sat, 10 Oct 2026 14:06:27 +0200

We've had customers that don't remember their log-in name.

The confirmation email might help them more easily find their log-in details.

0011825: withdrawTestBalance needs error handling

Sat, 10 Oct 2026 13:37:21 +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.

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

Fri, 09 Oct 2026 21:45:21 +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.

0011575: update checkPeerPushDebit to checkPeerPushDebitV2

Fri, 09 Oct 2026 20:30:42 +0200

iOS uses the non-V2 op (Model+P2P.swift:58) whose response is ok-only;
its struct has no "type" discriminator / insufficient-balance branch, so it surfaces a thrown error instead of the structured insufficient-balance result.
Android uses checkPeerPushDebitV2 with a sealed ok|insufficient-balance type (peer/PeerManager.kt:192-216).
Both ops exist -> divergence, not a break.

0011858: No appropriate error message, in case of no withdrawal dominations available.

Fri, 09 Oct 2026 20:29:51 +0200

In case of no withdrawal dominations avalable the Android app is showing a reasonable error message (see attachment 1000107960.png). The iOS app is lacking a reasonable error message (see attachment ima_d7c968b.png).

0011838: gnunet-transport using 100% cpu

Fri, 09 Oct 2026 18:05:45 +0200

after a few days running gnunet, gnunet-transport end consumming 100% CPU
I have some log in /var/lib/gnunet/.cache/gnunet
but last log is strange :

2026-09-30T09:02:51.712199+0200 util-service-3139963 WARNING `bind' failed for `/tmp/gnunet-gnunet-runtime//gnunet-service-arm.sock': address already in use
2026-09-30T09:02:51.712253+0200 arm-3139963 ERROR `bind' failed at ../gnunet-0.29.0/src/lib/util/service.c:1627 with error: Address already in use
2026-09-30T09:02:51.712264+0200 arm-3139963 ERROR Could not bind to any of the ports I was supposed to, refusing to run!
2026-09-30T13:24:49.761370+0200 util-service-3240810 WARNING `bind' failed for `/tmp/gnunet-gnunet-runtime//gnunet-service-arm.sock': address already in use
2026-09-30T13:24:49.761420+0200 arm-3240810 ERROR `bind' failed at ../gnunet-0.29.0/src/lib/util/service.c:1627 with error: Address already in use
2026-09-30T13:24:49.761432+0200 arm-3240810 ERROR Could not bind to any of the ports I was supposed to, refusing to run!
2026-09-30T19:24:36.038733+0200 util-service-3341539 WARNING `bind' failed for `/tmp/gnunet-gnunet-runtime//gnunet-service-arm.sock': address already in use
2026-09-30T19:24:36.038784+0200 arm-3341539 ERROR `bind' failed at ../gnunet-0.29.0/src/lib/util/service.c:1627 with error: Address already in use
2026-09-30T19:24:36.038797+0200 arm-3341539 ERROR Could not bind to any of the ports I was supposed to, refusing to run!

so there is a loop, however all services are up and seems running
su gnunet -c "gnunet-arm -I"
Services (excluding stopped services):
(started: 20 / stopped: 15)
cadet (binary='gnunet-service-cadet', status=started)
core (binary='gnunet-service-core', status=started)
datastore (binary='gnunet-service-datastore', status=started)
dht (binary='gnunet-service-dht', status=started)
gns (binary='gnunet-service-gns', status=started)
hostlist (binary='gnunet-daemon-hostlist', status=started)
namecache (binary='gnunet-service-namecache', status=started)
nat (binary='gnunet-service-nat', status=started)
nse (binary='gnunet-service-nse', status=started)
peerstore (binary='gnunet-service-peerstore', status=started)
pils (binary='gnunet-service-pils', status=started)
rest (binary='gnunet-rest-server', status=started)
revocation (binary='gnunet-service-revocation', status=started)
rps (binary='gnunet-service-rps', status=started)
setu (binary='gnunet-service-setu', status=started)
statistics (binary='gnunet-service-statistics', status=started)
topology (binary='gnunet-daemon-topology', status=started)
transport (binary='gnunet-service-transport', status=started)
communicator-tcp (binary='gnunet-communicator-tcp', status=started)
communicator-udp (binary='gnunet-communicator-udp', status=started)

and gnunet-transport -a returns peers :
PEER ROUTE VIA CORE-WIN STALLED PENDING RTT
860B direct udp 4 0 3 0 ms
C2QA direct udp 4 0 1 341 ms
DXYV direct udp,tcp 25 0 0 0 ms
EATG dv (2 hops) udp,tcp 4 0 0 49 s

but top report gnunet-transport as the consumer of CPU....

0011823: only 4 peers?

Fri, 09 Oct 2026 11:09:25 +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

0011857: Implement TalDir for iOS

Thu, 08 Oct 2026 18:59:06 +0200

See DD 70: Alias Lookup and Mailbox — GNU Taler

0011548: release iOS wallet 1.6.17

Thu, 08 Oct 2026 18:55:36 +0200

Tracking bug for the next iOS wallet production release.

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

0010675: iOS wallet should show shopping URL(s) for currency

Thu, 08 Oct 2026 16:26:06 +0200

The balances now contains a list of shopping URLs for each scope, the wallet UI should display it to the user in the action dialogue.

The dev experiment taler://dev-experiment/fake-shopping-url?url=https%3A%2F%2Ftaler.example.com can be used to test this even without an exchange that sets the shopping URL.

0011848: merchant: enforce http(s) website URL - bare host breaks /pay (pay-no-deposit) since v1.6.15

Wed, 07 Oct 2026 23:37:08 +0200

On /pay, contract re-parse fails when merchant.website is a bare host
(e.g., www.example.ch) instead of a full http(s) URL.

Observed (merchant log):

WARNING ... Failed to parse JSON in merchant.website
ASSERT ... TALER_JSON_spec_web_url_copy
HTTP 500  ec=2008  pay-no-deposit

Since v1.6.15, website is parsed with TALER_JSON_spec_web_url_copy in
merchant_parse.c. TALER_is_web_url requires an http or https scheme.
Instance create/PATCH already use TALER_JSON_spec_web_url ("website");
legacy DB rows and old contracts still carry bare hosts and break /pay.
cf. https://git.taler.net/taler/merchant/commit/567107a79abf3ad446901ec5d4602ea5a5e2b17c.html
(2026-08-05, use spec_web_url instead of spec_string where applicable)

Possible solution:
- Reject bare hosts on write and/or migrate stored website to https://...
- Keep create/PATCH web_url checks; align contract re-parse error to a
clear client-facing code instead of pay-no-deposit 500 where possible.

Code (merchant_parse.c, since 567107a79abf):

TALER_JSON_spec_web_url_copy ("website", &merchant->website),

Valid: https://www.example.ch
Invalid: www.example.ch