bug: automatic allowance payment takes about 40 seconds after the request arrives #1614

Activity

1. ovitrif

   added this to the 3.2.0 milestone on Oct 20, 2026
2. ovitrif

   added the

   Bug

   issue type on Oct 20, 2026
3. ovitrif

   added a parent issue on Oct 20, 2026

   • feat: allowances #1351
4. ovitrif commented on Oct 21, 2026

   

   ovitrif

   on Oct 21, 2026

   CollaboratorAuthor

   More actions

   Measured in the cross-device run on #1340 at e7b4477 against synonymdev/bitkit-ios#799, staging regtest (#1340 (comment)). From the Android payer's log, per automatic $2 or $4 payment:

   • about 20 to 30 s from the payee's send tap to the request stored on the payer;
   • about 16 to 19 s waiting for "Consumed private Paykit payment list version N", the payee's new private payment list, on every request including the first;
   • about 2 to 3 s to hand the payment to the node, and 3 to 4 s to the "Payment Executed" notification.

   Send to "Payment Executed" was 39 to 66 s with Android paying and 56 to 65 s with iOS paying. The payment-list wait is the largest step after delivery.
5. ovitrif

   modified the milestones: 3.2.0, 3.1.0 on Oct 26, 2026
6. ovitrif

   self-assigned this

   on Oct 27, 2026
7. ovitrif commented on Oct 27, 2026

   

   ovitrif

   on Oct 27, 2026

   CollaboratorAuthor

   More actions

   Measured on a local regtest (bitkit-docker: local Pubky homeserver and Paykit transport, Lightning channels from its LND fixture), two Android 16 emulators on the head of #1707, $5 a payment allowance, requests entered in sats. Seconds after the payee taps Send:

   Step	Request 1	Request 2	Request 3	Request 4
   Payee's outbound messages sent	2.7	3.4	3.1	2.8
   Payer stores the request	8.7	15.1	15.7	6.2
   Payee's payment list consumed	11.8	18.0	18.7	9.1
   Handed to the node	12.4	18.5	19.3	9.7
   "Payment Executed"	13.9	20.4	21.0	11.3

   • No request waited for an updated payment list: each was decided once, STARTED, with no deferral.
   • The largest step is the payer's next private-message poll after the payee sent (1 to 10 s); storing to handoff is about 3.5 s, and the payment itself about 1 s.
   • The iOS twin measured about 9 s send to paid on the same setup (bug: automatic allowance payment takes about a minute after the request arrives bitkit-ios#1142).

   So the 40 to 66 s seen on staging, with its 16 to 19 s payment-list wait, does not reproduce without the staging homeserver and relay; no app-side step stands out here. A staging measurement is still needed to tell whether that wait comes from the payee's list republish or from homeserver latency.
8. ovitrif commented on Oct 28, 2026

   

   ovitrif

   on Oct 28, 2026

   CollaboratorAuthor

   More actions

   Measured again on staging on 28 October 2026. Setup:

   • Two Android 16 emulators running synonymdev/bitkit-android#1707 at 2122f57, with fresh wallets and Pubky profiles on the staging homeserver.
   • Funded from the staging regtest faucet, with manual channels to Blocktank's staging node. The payee's channel pushed 25,000 sats to Blocktank for inbound capacity.
   • A $5 a payment, $50 a month allowance; 2,000-sat requests sent one at a time, each after the previous one was paid.

   Seconds after the payee taps Send, read from both apps' logs:

   Step	Request 1	Request 2	Request 3	Request 4	Request 5	Request 6
   Payee's request sent	7.1	7.3	11.6	10.9	12.0	17.4
   Payer stores the request	20.7	19.6	29.3	26.9	27.7	47.5
   Payer claims and accepts it	22.3	21.0	31.0	28.3	29.4	48.9
   Payer's acceptance sent	32.5	31.7	41.5	39.0	40.1	57.1
   Payee's payment list consumed	37.3	36.2	46.4	43.2	44.3	63.3
   Handed to the node	38.3	37.4	47.4	44.3	45.4	65.0
   "Payment Executed"	42.3	40.2	50.5	47.4	48.5	68.8

   Send to "Payment Executed" took 40 to 69 s, so the delay still reproduces on staging. Where the time goes:

   • Private-message transport, about 75%. Each processOutboundPrivateMessages call took 4.4 to 9.5 s on the payee and 4.9 to 7.8 s for the payer's acceptance. The same call took about 3 s on the local homeserver. HTTPS round trips to the staging homeserver took 0.13 to 0.25 s.
   • Delivery to the payer: 12 to 30 s from the payee's send to the payer storing the request. The payer polls every 10 s, so the rest is the receive itself.
   • The payment list: no request waited for the payee to republish it; each consumed the list it found on the first try. The 16 to 19 s list wait measured earlier did not show up.
   • The app's own steps: about 1.5 s for claim and accept, 4 to 6 s from the acceptance send to the consumed list (this includes another private-message read), and 1 s for the payment, plus 3 to 4 s to the notification.

   The time goes to Paykit's private-message transport over the staging homeserver, not to the payee's list republish. This needs a Paykit-side profile of processOutboundPrivateMessages and the receive path against staging, to find out whether the extra seconds are sequential homeserver calls or slow homeserver operations.

   On the app side, the payer sends its acceptance before it pays. That puts one private-message write, 5 to 8 s, on the path to "Payment Executed".

   One more request, sent at 16:13 UTC, stayed manual. The payee emulator had lost network for a minute just before it, so its private list had no Lightning invoice ("the payee offers no Lightning invoice"). It is left out of the table as an environment failure. This run had no iOS payer.
9. ovitrif

   modified the milestones: 3.1.0, 3.2.0 on Oct 28, 2026
10. ovitrif commented on Oct 28, 2026

    

    ovitrif

    on Oct 28, 2026

    CollaboratorAuthor

    More actions

    Moved to 3.2.0: no PR fixes this yet, and 3.1.0 keeps only work that has a PR.