feat: send paykit payment proofs

[ben-kaufman]

This PR sends a Paykit payment proof back to the requester after Bitkit successfully pays an incoming private payment request.

Description

1. Persists the payer identity, request, and selected endpoint before request acceptance, then associates the Lightning payment hash before sending so restart recovery keeps the correct correlation.
2. Persists successful on-chain transaction IDs and validated Lightning preimages before submitting them against the original one-time request and exact endpoint.
3. Uses Paykit's durable private outbox, retries incomplete submissions during normal request refresh, and suppresses duplicate proofs already recorded by the SDK.
4. Preserves earlier in-flight correlations across retries, clears the request after one proof is queued, and reads the secure store directly so wallet wipes cannot resurrect cached proof state.
5. Attempts immediate SDK delivery if persisting a completed proof fails, without adding any user-facing UI.

This PR is stacked on #1172. Companion iOS PR: synonymdev/bitkit-ios#683

Preview

N/A — there are no UI changes.

QA Notes

Manual Tests

• 1. Android → create a private request for iOS → iOS receives and pays on regtest: Android records the proof against the exact request, endpoint, and transaction ID.
• 2. iOS → create a private request for Android → Android receives and pays on regtest: iOS records the proof against the exact request, endpoint, and transaction ID.

Automated Checks

• PaykitPaymentProofRepoTest.kt: 8 tests cover restart retry, duplicate suppression, invalid Lightning preimage rejection, failed-payment cleanup, exact on-chain proof submission, overlapping retries, wallet-store clearing, and completed-proof persistence failure.
• AppViewModelSendFlowTest.kt: covers proof persistence before private-list consumption and request acceptance, plus successful and failed payment lifecycle handling.
• Full Android unit tests and focused proof/send-flow tests passed.
• Detekt passed with only pre-existing unrelated findings.
• git diff --check passed.

[ovitrif]

Two Lightning test gaps are missing:

• Crash recovery after an associated hash never exercises the LDK lookup, so a broken preimage path would not fail.
• Incoming-request send never asserts prepare, associate, pending keep, or fail-plus-cancel, so a skipped hash association would not fail.

[ovitrif]

Looks good: associated-hash Lightning crash recovery now submits from an LDK succeeded payment, and incoming-request send keeps or clears the proof correlation as required.

[piotr-iohk]

Will test after conflicts are resolved.

The base branch was changed.

[jvsena42]

@ben-kaufman conflicts

[jvsena42]

Root cause and logs for the disabled swipe in the review above.

Why it's disabled

SendConfirmScreen.kt:400 gates the control on:

enabled = uiState.isAmountInputValid &&!uiState.isFundingSourceLoading &&!isHardwareFeeLoading

isAmountInputValid defaults to false (AppViewModel.kt:4796), and the incoming-payment-request branch navigates to the confirm sheet without ever setting it (AppViewModel.kt:2798):

navigateToSendRoute(fromMainScanner, SendRoute.Confirm, SendEffect.NavigateToConfirm)
refreshOnchainSendIfNeeded()
estimateLightningRoutingFeesIfNeeded()
return

The sibling branch eight lines below (lnAmountSats > 0u, AppViewModel.kt:2806) does set it before its identical navigateToSendRoute call.

Confirmed on device

Two emulators on this branch build, each with its own pubky identity on the staging homeserver, added as contacts; B requested 16 000 sats from A.

• The sheet opens with the swiper dimmed, and injected drags do not move the thumb at all.
• One tap on the funding-source button — selectHardwareFundingSource and the savings branch both assign isAmountInputValid — flips it to full brightness, and the identical drag pays immediately.

Worth flagging that the funding-source toggle is only a workaround because that wallet had a paired Trezor. canSwitchFundingSource = availableFundingSources(state).size > 1 (AppViewModel.kt:2162), so with a single funding source there is no way to pay the request at all: the only control on the screen is dead.

Looks like a one-liner — assign isAmountInputValid = validateAmount(amount) in that branch before navigating, matching :2806.

The proof pipeline itself works once past this

Same run, payer side:

17:30:17.844 INFO [Keychain.kt:144] Upserted value for key 'PAYKIT_PENDING_PAYMENT_PROOFS'
17:30:27.162 INFO [Keychain.kt:144] Upserted value for key 'PAYKIT_PENDING_PAYMENT_PROOFS'
17:30:28.764 INFO [PaykitPaymentProofRepo.kt:270] Queued a Paykit payment proof for private delivery
17:30:32.407 INFO [Keychain.kt:144] Upserted value for key 'PAYKIT_PENDING_PAYMENT_PROOFS'

That is prepare() writing the pending record, completeOnchainPayment() filling in txid + proofData, submitReady() queueing delivery, then cleanup. Receiver side picked it up over the encrypted link:

paykit_lib::encrypted_link::link: receive_private_application_messages;
paykit_lib::encrypted_link::link: restore_encrypted_link; remote_pubkey=PublicKey("pubkyej5obc…") local_receiver_path=PaykitReceiverPath("bitkit/wallet") remote_receiver_path=PaykitReceiverPath("bitkit/wallet")

and the request moved from "Waiting for … to pay" into the settled group. A force-stop and relaunch of the payer produced no re-submission and no leftover pending record, and there were no Paykit warnings or errors on either device.

[ben-kaufman]

Fixed the disabled incoming-request swipe in 6d66ab6. The request branch validated the amount but did not persist that result, so Send Confirm kept the swipe disabled. It now writes the validation result before navigation, and the existing incoming payment request opens the existing confirm flow with its fixed amount test asserts that isAmountInputValid is true. The focused test and full unit suite pass.

[ben-kaufman]

The conflicts are resolved and the branch is current. It also now includes the proof-store/polling hardening and the disabled-swipe fix reported in the latest review. Please retest at 6d66ab6.

[ovitrif]

utACK

[ben-kaufman]

The reconciliation finding is fixed in signed commit ad132c8. Each pending proof is now isolated, so one temporary submission failure does not stop later proofs, with a focused regression covering that sequence. @ovitrif please re-review the updated head when E2E finishes.

[piotr-iohk]

Retested latest revision, Pixel emu ↔ iPhone 17 sim (same session as ios #683).

Incoming request pay on Android goes to Confirm with the amount locked. That matches this side — the amount-pad leak is iOS only (see #683).

Request lists don’t match
Same session, both on TODAY:

• Android: 2× 1000 + 26 000 + 25 000
• iOS: 3× 1000 + 26 000 (no 25 000)

Not amount-keyed overwrite in the app list — IDs are paymentRequestId + counterparty + path. This device sent the 25k on-chain; iOS activity shows +25 000, but iOS is missing that request-history row. Android is missing one of the 1k rows iOS still has. Hypothesis: after fulfill, one side drops the row when localRole is missing/unknown (history mapping skips those). Avatars I vs A are just the contact names.

Screenshot (Payment Requests list):

Logs:

logs-android.zip

Proofs still queued on the successful pays (LN + on-chain both ways). List drift looks like a follow-up, not a proofs blocker.

[ben-kaufman]

Thanks for confirming the Android amount path is correct. I also reran the clean cross-platform proof/history portion against the current Android and iOS heads: two requests succeeded in each direction, both apps ended with the same four history rows, and each remote request transitioned to paid after the payer logged durable proof-outbox acceptance. I could not reproduce a stuck proof or history divergence on clean state, so there is no speculative Android change for those observations. All Android checks are green on ad132c893.

[ovitrif]

The incoming-request swipe assignment in onScanOnchain still has no test that would fail if it were removed. The new isAmountInputValid assertion is on a lightning presentation that already sets that flag in onScanLightning.

[ovitrif]

utACK

[piotr-iohk]

QA LGTM.

Retested latest (10ff0df) Pixel emu ↔ iPhone 17 sim, regtest. 2 requests from each side (1k LN + 25k on-chain), all 4 paid.

• Incoming request pay stays on Confirm, amount locked
• Proofs queued after both LN pays and both on-chain pays (Queued a Paykit payment proof for private delivery)
• No proof UI, as expected
• No Failed to prepare/complete/reconcile or ignored-proof warnings

Payment Requests lists still diverge after the same session (3 rows each, different missing amount). Follow-up: #1219 (ios twin: synonymdev/bitkit-ios#723). Not a proofs blocker.

[jvsena42]

LGTM

[ben-kaufman]

This PR sends a Paykit payment proof back to the requester after Bitkit successfully pays an incoming private payment request.

Description

1. Persists the payer identity, request, and selected endpoint before request acceptance, then associates the Lightning payment hash before sending so restart recovery keeps the correct correlation.
2. Persists successful on-chain transaction IDs and validated Lightning preimages before submitting them against the original one-time request and exact endpoint.
3. Uses Paykit's durable private outbox, retries incomplete submissions during normal request refresh, and suppresses duplicate proofs already recorded by the SDK.
4. Preserves earlier in-flight correlations across retries, clears the request after one proof is queued, and reads the secure store directly so wallet wipes cannot resurrect cached proof state.
5. Attempts immediate SDK delivery if persisting a completed proof fails, without adding any user-facing UI.

This PR is stacked on #1172. Companion iOS PR: synonymdev/bitkit-ios#683

Preview

N/A — there are no UI changes.

QA Notes

Manual Tests

• 1. Android → create a private request for iOS → iOS receives and pays on regtest: Android records the proof against the exact request, endpoint, and transaction ID.
• 2. iOS → create a private request for Android → Android receives and pays on regtest: iOS records the proof against the exact request, endpoint, and transaction ID.

Automated Checks

• PaykitPaymentProofRepoTest.kt: 8 tests cover restart retry, duplicate suppression, invalid Lightning preimage rejection, failed-payment cleanup, exact on-chain proof submission, overlapping retries, wallet-store clearing, and completed-proof persistence failure.
• AppViewModelSendFlowTest.kt: covers proof persistence before private-list consumption and request acceptance, plus successful and failed payment lifecycle handling.
• Full Android unit tests and focused proof/send-flow tests passed.
• Detekt passed with only pre-existing unrelated findings.
• git diff --check passed.

[ovitrif]

Two Lightning test gaps are missing:

• Crash recovery after an associated hash never exercises the LDK lookup, so a broken preimage path would not fail.
• Incoming-request send never asserts prepare, associate, pending keep, or fail-plus-cancel, so a skipped hash association would not fail.

[ovitrif]

Looks good: associated-hash Lightning crash recovery now submits from an LDK succeeded payment, and incoming-request send keeps or clears the proof correlation as required.

[piotr-iohk]

Will test after conflicts are resolved.

The base branch was changed.

[jvsena42]

@ben-kaufman conflicts

[jvsena42]

Root cause and logs for the disabled swipe in the review above.

Why it's disabled

SendConfirmScreen.kt:400 gates the control on:

enabled = uiState.isAmountInputValid &&!uiState.isFundingSourceLoading &&!isHardwareFeeLoading

isAmountInputValid defaults to false (AppViewModel.kt:4796), and the incoming-payment-request branch navigates to the confirm sheet without ever setting it (AppViewModel.kt:2798):

navigateToSendRoute(fromMainScanner, SendRoute.Confirm, SendEffect.NavigateToConfirm)
refreshOnchainSendIfNeeded()
estimateLightningRoutingFeesIfNeeded()
return

The sibling branch eight lines below (lnAmountSats > 0u, AppViewModel.kt:2806) does set it before its identical navigateToSendRoute call.

Confirmed on device

Two emulators on this branch build, each with its own pubky identity on the staging homeserver, added as contacts; B requested 16 000 sats from A.

• The sheet opens with the swiper dimmed, and injected drags do not move the thumb at all.
• One tap on the funding-source button — selectHardwareFundingSource and the savings branch both assign isAmountInputValid — flips it to full brightness, and the identical drag pays immediately.

Worth flagging that the funding-source toggle is only a workaround because that wallet had a paired Trezor. canSwitchFundingSource = availableFundingSources(state).size > 1 (AppViewModel.kt:2162), so with a single funding source there is no way to pay the request at all: the only control on the screen is dead.

Looks like a one-liner — assign isAmountInputValid = validateAmount(amount) in that branch before navigating, matching :2806.

The proof pipeline itself works once past this

Same run, payer side:

17:30:17.844 INFO [Keychain.kt:144] Upserted value for key 'PAYKIT_PENDING_PAYMENT_PROOFS'
17:30:27.162 INFO [Keychain.kt:144] Upserted value for key 'PAYKIT_PENDING_PAYMENT_PROOFS'
17:30:28.764 INFO [PaykitPaymentProofRepo.kt:270] Queued a Paykit payment proof for private delivery
17:30:32.407 INFO [Keychain.kt:144] Upserted value for key 'PAYKIT_PENDING_PAYMENT_PROOFS'

That is prepare() writing the pending record, completeOnchainPayment() filling in txid + proofData, submitReady() queueing delivery, then cleanup. Receiver side picked it up over the encrypted link:

paykit_lib::encrypted_link::link: receive_private_application_messages;
paykit_lib::encrypted_link::link: restore_encrypted_link; remote_pubkey=PublicKey("pubkyej5obc…") local_receiver_path=PaykitReceiverPath("bitkit/wallet") remote_receiver_path=PaykitReceiverPath("bitkit/wallet")

and the request moved from "Waiting for … to pay" into the settled group. A force-stop and relaunch of the payer produced no re-submission and no leftover pending record, and there were no Paykit warnings or errors on either device.

[ben-kaufman]

Fixed the disabled incoming-request swipe in 6d66ab6. The request branch validated the amount but did not persist that result, so Send Confirm kept the swipe disabled. It now writes the validation result before navigation, and the existing incoming payment request opens the existing confirm flow with its fixed amount test asserts that isAmountInputValid is true. The focused test and full unit suite pass.

[ben-kaufman]

The conflicts are resolved and the branch is current. It also now includes the proof-store/polling hardening and the disabled-swipe fix reported in the latest review. Please retest at 6d66ab6.

[ovitrif]

utACK

[ben-kaufman]

The reconciliation finding is fixed in signed commit ad132c8. Each pending proof is now isolated, so one temporary submission failure does not stop later proofs, with a focused regression covering that sequence. @ovitrif please re-review the updated head when E2E finishes.

[piotr-iohk]

Retested latest revision, Pixel emu ↔ iPhone 17 sim (same session as ios #683).

Incoming request pay on Android goes to Confirm with the amount locked. That matches this side — the amount-pad leak is iOS only (see #683).

Request lists don’t match
Same session, both on TODAY:

• Android: 2× 1000 + 26 000 + 25 000
• iOS: 3× 1000 + 26 000 (no 25 000)

Not amount-keyed overwrite in the app list — IDs are paymentRequestId + counterparty + path. This device sent the 25k on-chain; iOS activity shows +25 000, but iOS is missing that request-history row. Android is missing one of the 1k rows iOS still has. Hypothesis: after fulfill, one side drops the row when localRole is missing/unknown (history mapping skips those). Avatars I vs A are just the contact names.

Screenshot (Payment Requests list):

Logs:

logs-android.zip

Proofs still queued on the successful pays (LN + on-chain both ways). List drift looks like a follow-up, not a proofs blocker.

[ben-kaufman]

Thanks for confirming the Android amount path is correct. I also reran the clean cross-platform proof/history portion against the current Android and iOS heads: two requests succeeded in each direction, both apps ended with the same four history rows, and each remote request transitioned to paid after the payer logged durable proof-outbox acceptance. I could not reproduce a stuck proof or history divergence on clean state, so there is no speculative Android change for those observations. All Android checks are green on ad132c893.

[ovitrif]

The incoming-request swipe assignment in onScanOnchain still has no test that would fail if it were removed. The new isAmountInputValid assertion is on a lightning presentation that already sets that flag in onScanLightning.

[ovitrif]

utACK

[piotr-iohk]

QA LGTM.

Retested latest (10ff0df) Pixel emu ↔ iPhone 17 sim, regtest. 2 requests from each side (1k LN + 25k on-chain), all 4 paid.

• Incoming request pay stays on Confirm, amount locked
• Proofs queued after both LN pays and both on-chain pays (Queued a Paykit payment proof for private delivery)
• No proof UI, as expected
• No Failed to prepare/complete/reconcile or ignored-proof warnings

Payment Requests lists still diverge after the same session (3 rows each, different missing amount). Follow-up: #1219 (ios twin: synonymdev/bitkit-ios#723). Not a proofs blocker.

[jvsena42]

LGTM

[ben-kaufman]

This PR sends a Paykit payment proof back to the requester after Bitkit successfully pays an incoming private payment request.

Description

1. Persists the payer identity, request, and selected endpoint before request acceptance, then associates the Lightning payment hash before sending so restart recovery keeps the correct correlation.
2. Persists successful on-chain transaction IDs and validated Lightning preimages before submitting them against the original one-time request and exact endpoint.
3. Uses Paykit's durable private outbox, retries incomplete submissions during normal request refresh, and suppresses duplicate proofs already recorded by the SDK.
4. Preserves earlier in-flight correlations across retries, clears the request after one proof is queued, and reads the secure store directly so wallet wipes cannot resurrect cached proof state.
5. Attempts immediate SDK delivery if persisting a completed proof fails, without adding any user-facing UI.

This PR is stacked on #1172. Companion iOS PR: synonymdev/bitkit-ios#683

Preview

N/A — there are no UI changes.

QA Notes

Manual Tests

• 1. Android → create a private request for iOS → iOS receives and pays on regtest: Android records the proof against the exact request, endpoint, and transaction ID.
• 2. iOS → create a private request for Android → Android receives and pays on regtest: iOS records the proof against the exact request, endpoint, and transaction ID.

Automated Checks

• PaykitPaymentProofRepoTest.kt: 8 tests cover restart retry, duplicate suppression, invalid Lightning preimage rejection, failed-payment cleanup, exact on-chain proof submission, overlapping retries, wallet-store clearing, and completed-proof persistence failure.
• AppViewModelSendFlowTest.kt: covers proof persistence before private-list consumption and request acceptance, plus successful and failed payment lifecycle handling.
• Full Android unit tests and focused proof/send-flow tests passed.
• Detekt passed with only pre-existing unrelated findings.
• git diff --check passed.

[ovitrif]

Two Lightning test gaps are missing:

• Crash recovery after an associated hash never exercises the LDK lookup, so a broken preimage path would not fail.
• Incoming-request send never asserts prepare, associate, pending keep, or fail-plus-cancel, so a skipped hash association would not fail.

[ovitrif]

Looks good: associated-hash Lightning crash recovery now submits from an LDK succeeded payment, and incoming-request send keeps or clears the proof correlation as required.

[piotr-iohk]

Will test after conflicts are resolved.

The base branch was changed.

[jvsena42]

@ben-kaufman conflicts

[jvsena42]

Root cause and logs for the disabled swipe in the review above.

Why it's disabled

SendConfirmScreen.kt:400 gates the control on:

enabled = uiState.isAmountInputValid &&!uiState.isFundingSourceLoading &&!isHardwareFeeLoading

isAmountInputValid defaults to false (AppViewModel.kt:4796), and the incoming-payment-request branch navigates to the confirm sheet without ever setting it (AppViewModel.kt:2798):

navigateToSendRoute(fromMainScanner, SendRoute.Confirm, SendEffect.NavigateToConfirm)
refreshOnchainSendIfNeeded()
estimateLightningRoutingFeesIfNeeded()
return

The sibling branch eight lines below (lnAmountSats > 0u, AppViewModel.kt:2806) does set it before its identical navigateToSendRoute call.

Confirmed on device

Two emulators on this branch build, each with its own pubky identity on the staging homeserver, added as contacts; B requested 16 000 sats from A.

• The sheet opens with the swiper dimmed, and injected drags do not move the thumb at all.
• One tap on the funding-source button — selectHardwareFundingSource and the savings branch both assign isAmountInputValid — flips it to full brightness, and the identical drag pays immediately.

Worth flagging that the funding-source toggle is only a workaround because that wallet had a paired Trezor. canSwitchFundingSource = availableFundingSources(state).size > 1 (AppViewModel.kt:2162), so with a single funding source there is no way to pay the request at all: the only control on the screen is dead.

Looks like a one-liner — assign isAmountInputValid = validateAmount(amount) in that branch before navigating, matching :2806.

The proof pipeline itself works once past this

Same run, payer side:

17:30:17.844 INFO [Keychain.kt:144] Upserted value for key 'PAYKIT_PENDING_PAYMENT_PROOFS'
17:30:27.162 INFO [Keychain.kt:144] Upserted value for key 'PAYKIT_PENDING_PAYMENT_PROOFS'
17:30:28.764 INFO [PaykitPaymentProofRepo.kt:270] Queued a Paykit payment proof for private delivery
17:30:32.407 INFO [Keychain.kt:144] Upserted value for key 'PAYKIT_PENDING_PAYMENT_PROOFS'

That is prepare() writing the pending record, completeOnchainPayment() filling in txid + proofData, submitReady() queueing delivery, then cleanup. Receiver side picked it up over the encrypted link:

paykit_lib::encrypted_link::link: receive_private_application_messages;
paykit_lib::encrypted_link::link: restore_encrypted_link; remote_pubkey=PublicKey("pubkyej5obc…") local_receiver_path=PaykitReceiverPath("bitkit/wallet") remote_receiver_path=PaykitReceiverPath("bitkit/wallet")

and the request moved from "Waiting for … to pay" into the settled group. A force-stop and relaunch of the payer produced no re-submission and no leftover pending record, and there were no Paykit warnings or errors on either device.

[ben-kaufman]

Fixed the disabled incoming-request swipe in 6d66ab6. The request branch validated the amount but did not persist that result, so Send Confirm kept the swipe disabled. It now writes the validation result before navigation, and the existing incoming payment request opens the existing confirm flow with its fixed amount test asserts that isAmountInputValid is true. The focused test and full unit suite pass.

[ben-kaufman]

The conflicts are resolved and the branch is current. It also now includes the proof-store/polling hardening and the disabled-swipe fix reported in the latest review. Please retest at 6d66ab6.

[ovitrif]

utACK

[ben-kaufman]

The reconciliation finding is fixed in signed commit ad132c8. Each pending proof is now isolated, so one temporary submission failure does not stop later proofs, with a focused regression covering that sequence. @ovitrif please re-review the updated head when E2E finishes.

[piotr-iohk]

Retested latest revision, Pixel emu ↔ iPhone 17 sim (same session as ios #683).

Incoming request pay on Android goes to Confirm with the amount locked. That matches this side — the amount-pad leak is iOS only (see #683).

Request lists don’t match
Same session, both on TODAY:

• Android: 2× 1000 + 26 000 + 25 000
• iOS: 3× 1000 + 26 000 (no 25 000)

Not amount-keyed overwrite in the app list — IDs are paymentRequestId + counterparty + path. This device sent the 25k on-chain; iOS activity shows +25 000, but iOS is missing that request-history row. Android is missing one of the 1k rows iOS still has. Hypothesis: after fulfill, one side drops the row when localRole is missing/unknown (history mapping skips those). Avatars I vs A are just the contact names.

Screenshot (Payment Requests list):

Logs:

logs-android.zip

Proofs still queued on the successful pays (LN + on-chain both ways). List drift looks like a follow-up, not a proofs blocker.

[ben-kaufman]

Thanks for confirming the Android amount path is correct. I also reran the clean cross-platform proof/history portion against the current Android and iOS heads: two requests succeeded in each direction, both apps ended with the same four history rows, and each remote request transitioned to paid after the payer logged durable proof-outbox acceptance. I could not reproduce a stuck proof or history divergence on clean state, so there is no speculative Android change for those observations. All Android checks are green on ad132c893.

[ovitrif]

The incoming-request swipe assignment in onScanOnchain still has no test that would fail if it were removed. The new isAmountInputValid assertion is on a lightning presentation that already sets that flag in onScanLightning.

[ovitrif]

utACK

[piotr-iohk]

QA LGTM.

Retested latest (10ff0df) Pixel emu ↔ iPhone 17 sim, regtest. 2 requests from each side (1k LN + 25k on-chain), all 4 paid.

• Incoming request pay stays on Confirm, amount locked
• Proofs queued after both LN pays and both on-chain pays (Queued a Paykit payment proof for private delivery)
• No proof UI, as expected
• No Failed to prepare/complete/reconcile or ignored-proof warnings

Payment Requests lists still diverge after the same session (3 rows each, different missing amount). Follow-up: #1219 (ios twin: synonymdev/bitkit-ios#723). Not a proofs blocker.

[jvsena42]

LGTM

[ben-kaufman]

This PR sends a Paykit payment proof back to the requester after Bitkit successfully pays an incoming private payment request.

Description

1. Persists the payer identity, request, and selected endpoint before request acceptance, then associates the Lightning payment hash before sending so restart recovery keeps the correct correlation.
2. Persists successful on-chain transaction IDs and validated Lightning preimages before submitting them against the original one-time request and exact endpoint.
3. Uses Paykit's durable private outbox, retries incomplete submissions during normal request refresh, and suppresses duplicate proofs already recorded by the SDK.
4. Preserves earlier in-flight correlations across retries, clears the request after one proof is queued, and reads the secure store directly so wallet wipes cannot resurrect cached proof state.
5. Attempts immediate SDK delivery if persisting a completed proof fails, without adding any user-facing UI.

This PR is stacked on #1172. Companion iOS PR: synonymdev/bitkit-ios#683

Preview

N/A — there are no UI changes.

QA Notes

Manual Tests

• 1. Android → create a private request for iOS → iOS receives and pays on regtest: Android records the proof against the exact request, endpoint, and transaction ID.
• 2. iOS → create a private request for Android → Android receives and pays on regtest: iOS records the proof against the exact request, endpoint, and transaction ID.

Automated Checks

• PaykitPaymentProofRepoTest.kt: 8 tests cover restart retry, duplicate suppression, invalid Lightning preimage rejection, failed-payment cleanup, exact on-chain proof submission, overlapping retries, wallet-store clearing, and completed-proof persistence failure.
• AppViewModelSendFlowTest.kt: covers proof persistence before private-list consumption and request acceptance, plus successful and failed payment lifecycle handling.
• Full Android unit tests and focused proof/send-flow tests passed.
• Detekt passed with only pre-existing unrelated findings.
• git diff --check passed.

[ovitrif]

Two Lightning test gaps are missing:

• Crash recovery after an associated hash never exercises the LDK lookup, so a broken preimage path would not fail.
• Incoming-request send never asserts prepare, associate, pending keep, or fail-plus-cancel, so a skipped hash association would not fail.

[ovitrif]

Looks good: associated-hash Lightning crash recovery now submits from an LDK succeeded payment, and incoming-request send keeps or clears the proof correlation as required.

[piotr-iohk]

Will test after conflicts are resolved.

The base branch was changed.

[jvsena42]

@ben-kaufman conflicts

[jvsena42]

Root cause and logs for the disabled swipe in the review above.

Why it's disabled

SendConfirmScreen.kt:400 gates the control on:

enabled = uiState.isAmountInputValid &&!uiState.isFundingSourceLoading &&!isHardwareFeeLoading

isAmountInputValid defaults to false (AppViewModel.kt:4796), and the incoming-payment-request branch navigates to the confirm sheet without ever setting it (AppViewModel.kt:2798):

navigateToSendRoute(fromMainScanner, SendRoute.Confirm, SendEffect.NavigateToConfirm)
refreshOnchainSendIfNeeded()
estimateLightningRoutingFeesIfNeeded()
return

The sibling branch eight lines below (lnAmountSats > 0u, AppViewModel.kt:2806) does set it before its identical navigateToSendRoute call.

Confirmed on device

Two emulators on this branch build, each with its own pubky identity on the staging homeserver, added as contacts; B requested 16 000 sats from A.

• The sheet opens with the swiper dimmed, and injected drags do not move the thumb at all.
• One tap on the funding-source button — selectHardwareFundingSource and the savings branch both assign isAmountInputValid — flips it to full brightness, and the identical drag pays immediately.

Worth flagging that the funding-source toggle is only a workaround because that wallet had a paired Trezor. canSwitchFundingSource = availableFundingSources(state).size > 1 (AppViewModel.kt:2162), so with a single funding source there is no way to pay the request at all: the only control on the screen is dead.

Looks like a one-liner — assign isAmountInputValid = validateAmount(amount) in that branch before navigating, matching :2806.

The proof pipeline itself works once past this

Same run, payer side:

17:30:17.844 INFO [Keychain.kt:144] Upserted value for key 'PAYKIT_PENDING_PAYMENT_PROOFS'
17:30:27.162 INFO [Keychain.kt:144] Upserted value for key 'PAYKIT_PENDING_PAYMENT_PROOFS'
17:30:28.764 INFO [PaykitPaymentProofRepo.kt:270] Queued a Paykit payment proof for private delivery
17:30:32.407 INFO [Keychain.kt:144] Upserted value for key 'PAYKIT_PENDING_PAYMENT_PROOFS'

That is prepare() writing the pending record, completeOnchainPayment() filling in txid + proofData, submitReady() queueing delivery, then cleanup. Receiver side picked it up over the encrypted link:

paykit_lib::encrypted_link::link: receive_private_application_messages;
paykit_lib::encrypted_link::link: restore_encrypted_link; remote_pubkey=PublicKey("pubkyej5obc…") local_receiver_path=PaykitReceiverPath("bitkit/wallet") remote_receiver_path=PaykitReceiverPath("bitkit/wallet")

and the request moved from "Waiting for … to pay" into the settled group. A force-stop and relaunch of the payer produced no re-submission and no leftover pending record, and there were no Paykit warnings or errors on either device.

[ben-kaufman]

Fixed the disabled incoming-request swipe in 6d66ab6. The request branch validated the amount but did not persist that result, so Send Confirm kept the swipe disabled. It now writes the validation result before navigation, and the existing incoming payment request opens the existing confirm flow with its fixed amount test asserts that isAmountInputValid is true. The focused test and full unit suite pass.

[ben-kaufman]

The conflicts are resolved and the branch is current. It also now includes the proof-store/polling hardening and the disabled-swipe fix reported in the latest review. Please retest at 6d66ab6.

[ovitrif]

utACK

[ben-kaufman]

The reconciliation finding is fixed in signed commit ad132c8. Each pending proof is now isolated, so one temporary submission failure does not stop later proofs, with a focused regression covering that sequence. @ovitrif please re-review the updated head when E2E finishes.

[piotr-iohk]

Retested latest revision, Pixel emu ↔ iPhone 17 sim (same session as ios #683).

Incoming request pay on Android goes to Confirm with the amount locked. That matches this side — the amount-pad leak is iOS only (see #683).

Request lists don’t match
Same session, both on TODAY:

• Android: 2× 1000 + 26 000 + 25 000
• iOS: 3× 1000 + 26 000 (no 25 000)

Not amount-keyed overwrite in the app list — IDs are paymentRequestId + counterparty + path. This device sent the 25k on-chain; iOS activity shows +25 000, but iOS is missing that request-history row. Android is missing one of the 1k rows iOS still has. Hypothesis: after fulfill, one side drops the row when localRole is missing/unknown (history mapping skips those). Avatars I vs A are just the contact names.

Screenshot (Payment Requests list):

Logs:

logs-android.zip

Proofs still queued on the successful pays (LN + on-chain both ways). List drift looks like a follow-up, not a proofs blocker.

[ben-kaufman]

Thanks for confirming the Android amount path is correct. I also reran the clean cross-platform proof/history portion against the current Android and iOS heads: two requests succeeded in each direction, both apps ended with the same four history rows, and each remote request transitioned to paid after the payer logged durable proof-outbox acceptance. I could not reproduce a stuck proof or history divergence on clean state, so there is no speculative Android change for those observations. All Android checks are green on ad132c893.

[ovitrif]

The incoming-request swipe assignment in onScanOnchain still has no test that would fail if it were removed. The new isAmountInputValid assertion is on a lightning presentation that already sets that flag in onScanLightning.

[ovitrif]

utACK

[piotr-iohk]

QA LGTM.

Retested latest (10ff0df) Pixel emu ↔ iPhone 17 sim, regtest. 2 requests from each side (1k LN + 25k on-chain), all 4 paid.

• Incoming request pay stays on Confirm, amount locked
• Proofs queued after both LN pays and both on-chain pays (Queued a Paykit payment proof for private delivery)
• No proof UI, as expected
• No Failed to prepare/complete/reconcile or ignored-proof warnings

Payment Requests lists still diverge after the same session (3 rows each, different missing amount). Follow-up: #1219 (ios twin: synonymdev/bitkit-ios#723). Not a proofs blocker.

[jvsena42]

LGTM

[ben-kaufman]

This PR sends a Paykit payment proof back to the requester after Bitkit successfully pays an incoming private payment request.

Description

1. Persists the payer identity, request, and selected endpoint before request acceptance, then associates the Lightning payment hash before sending so restart recovery keeps the correct correlation.
2. Persists successful on-chain transaction IDs and validated Lightning preimages before submitting them against the original one-time request and exact endpoint.
3. Uses Paykit's durable private outbox, retries incomplete submissions during normal request refresh, and suppresses duplicate proofs already recorded by the SDK.
4. Preserves earlier in-flight correlations across retries, clears the request after one proof is queued, and reads the secure store directly so wallet wipes cannot resurrect cached proof state.
5. Attempts immediate SDK delivery if persisting a completed proof fails, without adding any user-facing UI.

This PR is stacked on #1172. Companion iOS PR: synonymdev/bitkit-ios#683

Preview

N/A — there are no UI changes.

QA Notes

Manual Tests

• 1. Android → create a private request for iOS → iOS receives and pays on regtest: Android records the proof against the exact request, endpoint, and transaction ID.
• 2. iOS → create a private request for Android → Android receives and pays on regtest: iOS records the proof against the exact request, endpoint, and transaction ID.

Automated Checks

• PaykitPaymentProofRepoTest.kt: 8 tests cover restart retry, duplicate suppression, invalid Lightning preimage rejection, failed-payment cleanup, exact on-chain proof submission, overlapping retries, wallet-store clearing, and completed-proof persistence failure.
• AppViewModelSendFlowTest.kt: covers proof persistence before private-list consumption and request acceptance, plus successful and failed payment lifecycle handling.
• Full Android unit tests and focused proof/send-flow tests passed.
• Detekt passed with only pre-existing unrelated findings.
• git diff --check passed.

[ovitrif]

Two Lightning test gaps are missing:

• Crash recovery after an associated hash never exercises the LDK lookup, so a broken preimage path would not fail.
• Incoming-request send never asserts prepare, associate, pending keep, or fail-plus-cancel, so a skipped hash association would not fail.

[ovitrif]

Looks good: associated-hash Lightning crash recovery now submits from an LDK succeeded payment, and incoming-request send keeps or clears the proof correlation as required.

[piotr-iohk]

Will test after conflicts are resolved.

The base branch was changed.

[jvsena42]

@ben-kaufman conflicts

[jvsena42]

Root cause and logs for the disabled swipe in the review above.

Why it's disabled

SendConfirmScreen.kt:400 gates the control on:

enabled = uiState.isAmountInputValid &&!uiState.isFundingSourceLoading &&!isHardwareFeeLoading

isAmountInputValid defaults to false (AppViewModel.kt:4796), and the incoming-payment-request branch navigates to the confirm sheet without ever setting it (AppViewModel.kt:2798):

navigateToSendRoute(fromMainScanner, SendRoute.Confirm, SendEffect.NavigateToConfirm)
refreshOnchainSendIfNeeded()
estimateLightningRoutingFeesIfNeeded()
return

The sibling branch eight lines below (lnAmountSats > 0u, AppViewModel.kt:2806) does set it before its identical navigateToSendRoute call.

Confirmed on device

Two emulators on this branch build, each with its own pubky identity on the staging homeserver, added as contacts; B requested 16 000 sats from A.

• The sheet opens with the swiper dimmed, and injected drags do not move the thumb at all.
• One tap on the funding-source button — selectHardwareFundingSource and the savings branch both assign isAmountInputValid — flips it to full brightness, and the identical drag pays immediately.

Worth flagging that the funding-source toggle is only a workaround because that wallet had a paired Trezor. canSwitchFundingSource = availableFundingSources(state).size > 1 (AppViewModel.kt:2162), so with a single funding source there is no way to pay the request at all: the only control on the screen is dead.

Looks like a one-liner — assign isAmountInputValid = validateAmount(amount) in that branch before navigating, matching :2806.

The proof pipeline itself works once past this

Same run, payer side:

17:30:17.844 INFO [Keychain.kt:144] Upserted value for key 'PAYKIT_PENDING_PAYMENT_PROOFS'
17:30:27.162 INFO [Keychain.kt:144] Upserted value for key 'PAYKIT_PENDING_PAYMENT_PROOFS'
17:30:28.764 INFO [PaykitPaymentProofRepo.kt:270] Queued a Paykit payment proof for private delivery
17:30:32.407 INFO [Keychain.kt:144] Upserted value for key 'PAYKIT_PENDING_PAYMENT_PROOFS'

That is prepare() writing the pending record, completeOnchainPayment() filling in txid + proofData, submitReady() queueing delivery, then cleanup. Receiver side picked it up over the encrypted link:

paykit_lib::encrypted_link::link: receive_private_application_messages;
paykit_lib::encrypted_link::link: restore_encrypted_link; remote_pubkey=PublicKey("pubkyej5obc…") local_receiver_path=PaykitReceiverPath("bitkit/wallet") remote_receiver_path=PaykitReceiverPath("bitkit/wallet")

and the request moved from "Waiting for … to pay" into the settled group. A force-stop and relaunch of the payer produced no re-submission and no leftover pending record, and there were no Paykit warnings or errors on either device.

[ben-kaufman]

Fixed the disabled incoming-request swipe in 6d66ab6. The request branch validated the amount but did not persist that result, so Send Confirm kept the swipe disabled. It now writes the validation result before navigation, and the existing incoming payment request opens the existing confirm flow with its fixed amount test asserts that isAmountInputValid is true. The focused test and full unit suite pass.

[ben-kaufman]

The conflicts are resolved and the branch is current. It also now includes the proof-store/polling hardening and the disabled-swipe fix reported in the latest review. Please retest at 6d66ab6.

[ovitrif]

utACK

[ben-kaufman]

The reconciliation finding is fixed in signed commit ad132c8. Each pending proof is now isolated, so one temporary submission failure does not stop later proofs, with a focused regression covering that sequence. @ovitrif please re-review the updated head when E2E finishes.

[piotr-iohk]

Retested latest revision, Pixel emu ↔ iPhone 17 sim (same session as ios #683).

Incoming request pay on Android goes to Confirm with the amount locked. That matches this side — the amount-pad leak is iOS only (see #683).

Request lists don’t match
Same session, both on TODAY:

• Android: 2× 1000 + 26 000 + 25 000
• iOS: 3× 1000 + 26 000 (no 25 000)

Not amount-keyed overwrite in the app list — IDs are paymentRequestId + counterparty + path. This device sent the 25k on-chain; iOS activity shows +25 000, but iOS is missing that request-history row. Android is missing one of the 1k rows iOS still has. Hypothesis: after fulfill, one side drops the row when localRole is missing/unknown (history mapping skips those). Avatars I vs A are just the contact names.

Screenshot (Payment Requests list):

Logs:

logs-android.zip

Proofs still queued on the successful pays (LN + on-chain both ways). List drift looks like a follow-up, not a proofs blocker.

[ben-kaufman]

Thanks for confirming the Android amount path is correct. I also reran the clean cross-platform proof/history portion against the current Android and iOS heads: two requests succeeded in each direction, both apps ended with the same four history rows, and each remote request transitioned to paid after the payer logged durable proof-outbox acceptance. I could not reproduce a stuck proof or history divergence on clean state, so there is no speculative Android change for those observations. All Android checks are green on ad132c893.

[ovitrif]

The incoming-request swipe assignment in onScanOnchain still has no test that would fail if it were removed. The new isAmountInputValid assertion is on a lightning presentation that already sets that flag in onScanLightning.

[ovitrif]

utACK

[piotr-iohk]

QA LGTM.

Retested latest (10ff0df) Pixel emu ↔ iPhone 17 sim, regtest. 2 requests from each side (1k LN + 25k on-chain), all 4 paid.

• Incoming request pay stays on Confirm, amount locked
• Proofs queued after both LN pays and both on-chain pays (Queued a Paykit payment proof for private delivery)
• No proof UI, as expected
• No Failed to prepare/complete/reconcile or ignored-proof warnings

Payment Requests lists still diverge after the same session (3 rows each, different missing amount). Follow-up: #1219 (ios twin: synonymdev/bitkit-ios#723). Not a proofs blocker.

[jvsena42]

LGTM

[ben-kaufman]

This PR sends a Paykit payment proof back to the requester after Bitkit successfully pays an incoming private payment request.

Description

1. Persists the payer identity, request, and selected endpoint before request acceptance, then associates the Lightning payment hash before sending so restart recovery keeps the correct correlation.
2. Persists successful on-chain transaction IDs and validated Lightning preimages before submitting them against the original one-time request and exact endpoint.
3. Uses Paykit's durable private outbox, retries incomplete submissions during normal request refresh, and suppresses duplicate proofs already recorded by the SDK.
4. Preserves earlier in-flight correlations across retries, clears the request after one proof is queued, and reads the secure store directly so wallet wipes cannot resurrect cached proof state.
5. Attempts immediate SDK delivery if persisting a completed proof fails, without adding any user-facing UI.

This PR is stacked on #1172. Companion iOS PR: synonymdev/bitkit-ios#683

Preview

N/A — there are no UI changes.

QA Notes

Manual Tests

• 1. Android → create a private request for iOS → iOS receives and pays on regtest: Android records the proof against the exact request, endpoint, and transaction ID.
• 2. iOS → create a private request for Android → Android receives and pays on regtest: iOS records the proof against the exact request, endpoint, and transaction ID.

Automated Checks

• PaykitPaymentProofRepoTest.kt: 8 tests cover restart retry, duplicate suppression, invalid Lightning preimage rejection, failed-payment cleanup, exact on-chain proof submission, overlapping retries, wallet-store clearing, and completed-proof persistence failure.
• AppViewModelSendFlowTest.kt: covers proof persistence before private-list consumption and request acceptance, plus successful and failed payment lifecycle handling.
• Full Android unit tests and focused proof/send-flow tests passed.
• Detekt passed with only pre-existing unrelated findings.
• git diff --check passed.

[ovitrif]

Two Lightning test gaps are missing:

• Crash recovery after an associated hash never exercises the LDK lookup, so a broken preimage path would not fail.
• Incoming-request send never asserts prepare, associate, pending keep, or fail-plus-cancel, so a skipped hash association would not fail.

[ovitrif]

Looks good: associated-hash Lightning crash recovery now submits from an LDK succeeded payment, and incoming-request send keeps or clears the proof correlation as required.

[piotr-iohk]

Will test after conflicts are resolved.

The base branch was changed.

[jvsena42]

@ben-kaufman conflicts

[jvsena42]

Root cause and logs for the disabled swipe in the review above.

Why it's disabled

SendConfirmScreen.kt:400 gates the control on:

enabled = uiState.isAmountInputValid &&!uiState.isFundingSourceLoading &&!isHardwareFeeLoading

isAmountInputValid defaults to false (AppViewModel.kt:4796), and the incoming-payment-request branch navigates to the confirm sheet without ever setting it (AppViewModel.kt:2798):

navigateToSendRoute(fromMainScanner, SendRoute.Confirm, SendEffect.NavigateToConfirm)
refreshOnchainSendIfNeeded()
estimateLightningRoutingFeesIfNeeded()
return

The sibling branch eight lines below (lnAmountSats > 0u, AppViewModel.kt:2806) does set it before its identical navigateToSendRoute call.

Confirmed on device

Two emulators on this branch build, each with its own pubky identity on the staging homeserver, added as contacts; B requested 16 000 sats from A.

• The sheet opens with the swiper dimmed, and injected drags do not move the thumb at all.
• One tap on the funding-source button — selectHardwareFundingSource and the savings branch both assign isAmountInputValid — flips it to full brightness, and the identical drag pays immediately.

Worth flagging that the funding-source toggle is only a workaround because that wallet had a paired Trezor. canSwitchFundingSource = availableFundingSources(state).size > 1 (AppViewModel.kt:2162), so with a single funding source there is no way to pay the request at all: the only control on the screen is dead.

Looks like a one-liner — assign isAmountInputValid = validateAmount(amount) in that branch before navigating, matching :2806.

The proof pipeline itself works once past this

Same run, payer side:

17:30:17.844 INFO [Keychain.kt:144] Upserted value for key 'PAYKIT_PENDING_PAYMENT_PROOFS'
17:30:27.162 INFO [Keychain.kt:144] Upserted value for key 'PAYKIT_PENDING_PAYMENT_PROOFS'
17:30:28.764 INFO [PaykitPaymentProofRepo.kt:270] Queued a Paykit payment proof for private delivery
17:30:32.407 INFO [Keychain.kt:144] Upserted value for key 'PAYKIT_PENDING_PAYMENT_PROOFS'

That is prepare() writing the pending record, completeOnchainPayment() filling in txid + proofData, submitReady() queueing delivery, then cleanup. Receiver side picked it up over the encrypted link:

paykit_lib::encrypted_link::link: receive_private_application_messages;
paykit_lib::encrypted_link::link: restore_encrypted_link; remote_pubkey=PublicKey("pubkyej5obc…") local_receiver_path=PaykitReceiverPath("bitkit/wallet") remote_receiver_path=PaykitReceiverPath("bitkit/wallet")

and the request moved from "Waiting for … to pay" into the settled group. A force-stop and relaunch of the payer produced no re-submission and no leftover pending record, and there were no Paykit warnings or errors on either device.

[ben-kaufman]

Fixed the disabled incoming-request swipe in 6d66ab6. The request branch validated the amount but did not persist that result, so Send Confirm kept the swipe disabled. It now writes the validation result before navigation, and the existing incoming payment request opens the existing confirm flow with its fixed amount test asserts that isAmountInputValid is true. The focused test and full unit suite pass.

[ben-kaufman]

The conflicts are resolved and the branch is current. It also now includes the proof-store/polling hardening and the disabled-swipe fix reported in the latest review. Please retest at 6d66ab6.

[ovitrif]

utACK

[ben-kaufman]

The reconciliation finding is fixed in signed commit ad132c8. Each pending proof is now isolated, so one temporary submission failure does not stop later proofs, with a focused regression covering that sequence. @ovitrif please re-review the updated head when E2E finishes.

[piotr-iohk]

Retested latest revision, Pixel emu ↔ iPhone 17 sim (same session as ios #683).

Incoming request pay on Android goes to Confirm with the amount locked. That matches this side — the amount-pad leak is iOS only (see #683).

Request lists don’t match
Same session, both on TODAY:

• Android: 2× 1000 + 26 000 + 25 000
• iOS: 3× 1000 + 26 000 (no 25 000)

Not amount-keyed overwrite in the app list — IDs are paymentRequestId + counterparty + path. This device sent the 25k on-chain; iOS activity shows +25 000, but iOS is missing that request-history row. Android is missing one of the 1k rows iOS still has. Hypothesis: after fulfill, one side drops the row when localRole is missing/unknown (history mapping skips those). Avatars I vs A are just the contact names.

Screenshot (Payment Requests list):

Logs:

logs-android.zip

Proofs still queued on the successful pays (LN + on-chain both ways). List drift looks like a follow-up, not a proofs blocker.

[ben-kaufman]

Thanks for confirming the Android amount path is correct. I also reran the clean cross-platform proof/history portion against the current Android and iOS heads: two requests succeeded in each direction, both apps ended with the same four history rows, and each remote request transitioned to paid after the payer logged durable proof-outbox acceptance. I could not reproduce a stuck proof or history divergence on clean state, so there is no speculative Android change for those observations. All Android checks are green on ad132c893.

[ovitrif]

The incoming-request swipe assignment in onScanOnchain still has no test that would fail if it were removed. The new isAmountInputValid assertion is on a lightning presentation that already sets that flag in onScanLightning.

[ovitrif]

utACK

[piotr-iohk]

QA LGTM.

Retested latest (10ff0df) Pixel emu ↔ iPhone 17 sim, regtest. 2 requests from each side (1k LN + 25k on-chain), all 4 paid.

• Incoming request pay stays on Confirm, amount locked
• Proofs queued after both LN pays and both on-chain pays (Queued a Paykit payment proof for private delivery)
• No proof UI, as expected
• No Failed to prepare/complete/reconcile or ignored-proof warnings

Payment Requests lists still diverge after the same session (3 rows each, different missing amount). Follow-up: #1219 (ios twin: synonymdev/bitkit-ios#723). Not a proofs blocker.

[jvsena42]

LGTM

[ben-kaufman]

This PR sends a Paykit payment proof back to the requester after Bitkit successfully pays an incoming private payment request.

Description

1. Persists the payer identity, request, and selected endpoint before request acceptance, then associates the Lightning payment hash before sending so restart recovery keeps the correct correlation.
2. Persists successful on-chain transaction IDs and validated Lightning preimages before submitting them against the original one-time request and exact endpoint.
3. Uses Paykit's durable private outbox, retries incomplete submissions during normal request refresh, and suppresses duplicate proofs already recorded by the SDK.
4. Preserves earlier in-flight correlations across retries, clears the request after one proof is queued, and reads the secure store directly so wallet wipes cannot resurrect cached proof state.
5. Attempts immediate SDK delivery if persisting a completed proof fails, without adding any user-facing UI.

This PR is stacked on #1172. Companion iOS PR: synonymdev/bitkit-ios#683

Preview

N/A — there are no UI changes.

QA Notes

Manual Tests

• 1. Android → create a private request for iOS → iOS receives and pays on regtest: Android records the proof against the exact request, endpoint, and transaction ID.
• 2. iOS → create a private request for Android → Android receives and pays on regtest: iOS records the proof against the exact request, endpoint, and transaction ID.

Automated Checks

• PaykitPaymentProofRepoTest.kt: 8 tests cover restart retry, duplicate suppression, invalid Lightning preimage rejection, failed-payment cleanup, exact on-chain proof submission, overlapping retries, wallet-store clearing, and completed-proof persistence failure.
• AppViewModelSendFlowTest.kt: covers proof persistence before private-list consumption and request acceptance, plus successful and failed payment lifecycle handling.
• Full Android unit tests and focused proof/send-flow tests passed.
• Detekt passed with only pre-existing unrelated findings.
• git diff --check passed.

[ovitrif]

Two Lightning test gaps are missing:

• Crash recovery after an associated hash never exercises the LDK lookup, so a broken preimage path would not fail.
• Incoming-request send never asserts prepare, associate, pending keep, or fail-plus-cancel, so a skipped hash association would not fail.

[ovitrif]

Looks good: associated-hash Lightning crash recovery now submits from an LDK succeeded payment, and incoming-request send keeps or clears the proof correlation as required.

[piotr-iohk]

Will test after conflicts are resolved.

The base branch was changed.

[jvsena42]

@ben-kaufman conflicts

[jvsena42]

Root cause and logs for the disabled swipe in the review above.

Why it's disabled

SendConfirmScreen.kt:400 gates the control on:

enabled = uiState.isAmountInputValid &&!uiState.isFundingSourceLoading &&!isHardwareFeeLoading

isAmountInputValid defaults to false (AppViewModel.kt:4796), and the incoming-payment-request branch navigates to the confirm sheet without ever setting it (AppViewModel.kt:2798):

navigateToSendRoute(fromMainScanner, SendRoute.Confirm, SendEffect.NavigateToConfirm)
refreshOnchainSendIfNeeded()
estimateLightningRoutingFeesIfNeeded()
return

The sibling branch eight lines below (lnAmountSats > 0u, AppViewModel.kt:2806) does set it before its identical navigateToSendRoute call.

Confirmed on device

Two emulators on this branch build, each with its own pubky identity on the staging homeserver, added as contacts; B requested 16 000 sats from A.

• The sheet opens with the swiper dimmed, and injected drags do not move the thumb at all.
• One tap on the funding-source button — selectHardwareFundingSource and the savings branch both assign isAmountInputValid — flips it to full brightness, and the identical drag pays immediately.

Worth flagging that the funding-source toggle is only a workaround because that wallet had a paired Trezor. canSwitchFundingSource = availableFundingSources(state).size > 1 (AppViewModel.kt:2162), so with a single funding source there is no way to pay the request at all: the only control on the screen is dead.

Looks like a one-liner — assign isAmountInputValid = validateAmount(amount) in that branch before navigating, matching :2806.

The proof pipeline itself works once past this

Same run, payer side:

17:30:17.844 INFO [Keychain.kt:144] Upserted value for key 'PAYKIT_PENDING_PAYMENT_PROOFS'
17:30:27.162 INFO [Keychain.kt:144] Upserted value for key 'PAYKIT_PENDING_PAYMENT_PROOFS'
17:30:28.764 INFO [PaykitPaymentProofRepo.kt:270] Queued a Paykit payment proof for private delivery
17:30:32.407 INFO [Keychain.kt:144] Upserted value for key 'PAYKIT_PENDING_PAYMENT_PROOFS'

That is prepare() writing the pending record, completeOnchainPayment() filling in txid + proofData, submitReady() queueing delivery, then cleanup. Receiver side picked it up over the encrypted link:

paykit_lib::encrypted_link::link: receive_private_application_messages;
paykit_lib::encrypted_link::link: restore_encrypted_link; remote_pubkey=PublicKey("pubkyej5obc…") local_receiver_path=PaykitReceiverPath("bitkit/wallet") remote_receiver_path=PaykitReceiverPath("bitkit/wallet")

and the request moved from "Waiting for … to pay" into the settled group. A force-stop and relaunch of the payer produced no re-submission and no leftover pending record, and there were no Paykit warnings or errors on either device.

[ben-kaufman]

Fixed the disabled incoming-request swipe in 6d66ab6. The request branch validated the amount but did not persist that result, so Send Confirm kept the swipe disabled. It now writes the validation result before navigation, and the existing incoming payment request opens the existing confirm flow with its fixed amount test asserts that isAmountInputValid is true. The focused test and full unit suite pass.

[ben-kaufman]

The conflicts are resolved and the branch is current. It also now includes the proof-store/polling hardening and the disabled-swipe fix reported in the latest review. Please retest at 6d66ab6.

[ovitrif]

utACK

[ben-kaufman]

The reconciliation finding is fixed in signed commit ad132c8. Each pending proof is now isolated, so one temporary submission failure does not stop later proofs, with a focused regression covering that sequence. @ovitrif please re-review the updated head when E2E finishes.

[piotr-iohk]

Retested latest revision, Pixel emu ↔ iPhone 17 sim (same session as ios #683).

Incoming request pay on Android goes to Confirm with the amount locked. That matches this side — the amount-pad leak is iOS only (see #683).

Request lists don’t match
Same session, both on TODAY:

• Android: 2× 1000 + 26 000 + 25 000
• iOS: 3× 1000 + 26 000 (no 25 000)

Not amount-keyed overwrite in the app list — IDs are paymentRequestId + counterparty + path. This device sent the 25k on-chain; iOS activity shows +25 000, but iOS is missing that request-history row. Android is missing one of the 1k rows iOS still has. Hypothesis: after fulfill, one side drops the row when localRole is missing/unknown (history mapping skips those). Avatars I vs A are just the contact names.

Screenshot (Payment Requests list):

Logs:

logs-android.zip

Proofs still queued on the successful pays (LN + on-chain both ways). List drift looks like a follow-up, not a proofs blocker.

[ben-kaufman]

Thanks for confirming the Android amount path is correct. I also reran the clean cross-platform proof/history portion against the current Android and iOS heads: two requests succeeded in each direction, both apps ended with the same four history rows, and each remote request transitioned to paid after the payer logged durable proof-outbox acceptance. I could not reproduce a stuck proof or history divergence on clean state, so there is no speculative Android change for those observations. All Android checks are green on ad132c893.

[ovitrif]

The incoming-request swipe assignment in onScanOnchain still has no test that would fail if it were removed. The new isAmountInputValid assertion is on a lightning presentation that already sets that flag in onScanLightning.

[ovitrif]

utACK

[piotr-iohk]

QA LGTM.

Retested latest (10ff0df) Pixel emu ↔ iPhone 17 sim, regtest. 2 requests from each side (1k LN + 25k on-chain), all 4 paid.

• Incoming request pay stays on Confirm, amount locked
• Proofs queued after both LN pays and both on-chain pays (Queued a Paykit payment proof for private delivery)
• No proof UI, as expected
• No Failed to prepare/complete/reconcile or ignored-proof warnings

Payment Requests lists still diverge after the same session (3 rows each, different missing amount). Follow-up: #1219 (ios twin: synonymdev/bitkit-ios#723). Not a proofs blocker.

[jvsena42]

LGTM

[ben-kaufman]

This PR sends a Paykit payment proof back to the requester after Bitkit successfully pays an incoming private payment request.

Description

1. Persists the payer identity, request, and selected endpoint before request acceptance, then associates the Lightning payment hash before sending so restart recovery keeps the correct correlation.
2. Persists successful on-chain transaction IDs and validated Lightning preimages before submitting them against the original one-time request and exact endpoint.
3. Uses Paykit's durable private outbox, retries incomplete submissions during normal request refresh, and suppresses duplicate proofs already recorded by the SDK.
4. Preserves earlier in-flight correlations across retries, clears the request after one proof is queued, and reads the secure store directly so wallet wipes cannot resurrect cached proof state.
5. Attempts immediate SDK delivery if persisting a completed proof fails, without adding any user-facing UI.

This PR is stacked on #1172. Companion iOS PR: synonymdev/bitkit-ios#683

Preview

N/A — there are no UI changes.

QA Notes

Manual Tests

• 1. Android → create a private request for iOS → iOS receives and pays on regtest: Android records the proof against the exact request, endpoint, and transaction ID.
• 2. iOS → create a private request for Android → Android receives and pays on regtest: iOS records the proof against the exact request, endpoint, and transaction ID.

Automated Checks

• PaykitPaymentProofRepoTest.kt: 8 tests cover restart retry, duplicate suppression, invalid Lightning preimage rejection, failed-payment cleanup, exact on-chain proof submission, overlapping retries, wallet-store clearing, and completed-proof persistence failure.
• AppViewModelSendFlowTest.kt: covers proof persistence before private-list consumption and request acceptance, plus successful and failed payment lifecycle handling.
• Full Android unit tests and focused proof/send-flow tests passed.
• Detekt passed with only pre-existing unrelated findings.
• git diff --check passed.

[ovitrif]

Two Lightning test gaps are missing:

• Crash recovery after an associated hash never exercises the LDK lookup, so a broken preimage path would not fail.
• Incoming-request send never asserts prepare, associate, pending keep, or fail-plus-cancel, so a skipped hash association would not fail.

[ovitrif]

Looks good: associated-hash Lightning crash recovery now submits from an LDK succeeded payment, and incoming-request send keeps or clears the proof correlation as required.

[piotr-iohk]

Will test after conflicts are resolved.

The base branch was changed.

[jvsena42]

@ben-kaufman conflicts

[jvsena42]

Root cause and logs for the disabled swipe in the review above.

Why it's disabled

SendConfirmScreen.kt:400 gates the control on:

enabled = uiState.isAmountInputValid &&!uiState.isFundingSourceLoading &&!isHardwareFeeLoading

isAmountInputValid defaults to false (AppViewModel.kt:4796), and the incoming-payment-request branch navigates to the confirm sheet without ever setting it (AppViewModel.kt:2798):

navigateToSendRoute(fromMainScanner, SendRoute.Confirm, SendEffect.NavigateToConfirm)
refreshOnchainSendIfNeeded()
estimateLightningRoutingFeesIfNeeded()
return

The sibling branch eight lines below (lnAmountSats > 0u, AppViewModel.kt:2806) does set it before its identical navigateToSendRoute call.

Confirmed on device

Two emulators on this branch build, each with its own pubky identity on the staging homeserver, added as contacts; B requested 16 000 sats from A.

• The sheet opens with the swiper dimmed, and injected drags do not move the thumb at all.
• One tap on the funding-source button — selectHardwareFundingSource and the savings branch both assign isAmountInputValid — flips it to full brightness, and the identical drag pays immediately.

Worth flagging that the funding-source toggle is only a workaround because that wallet had a paired Trezor. canSwitchFundingSource = availableFundingSources(state).size > 1 (AppViewModel.kt:2162), so with a single funding source there is no way to pay the request at all: the only control on the screen is dead.

Looks like a one-liner — assign isAmountInputValid = validateAmount(amount) in that branch before navigating, matching :2806.

The proof pipeline itself works once past this

Same run, payer side:

17:30:17.844 INFO [Keychain.kt:144] Upserted value for key 'PAYKIT_PENDING_PAYMENT_PROOFS'
17:30:27.162 INFO [Keychain.kt:144] Upserted value for key 'PAYKIT_PENDING_PAYMENT_PROOFS'
17:30:28.764 INFO [PaykitPaymentProofRepo.kt:270] Queued a Paykit payment proof for private delivery
17:30:32.407 INFO [Keychain.kt:144] Upserted value for key 'PAYKIT_PENDING_PAYMENT_PROOFS'

That is prepare() writing the pending record, completeOnchainPayment() filling in txid + proofData, submitReady() queueing delivery, then cleanup. Receiver side picked it up over the encrypted link:

paykit_lib::encrypted_link::link: receive_private_application_messages;
paykit_lib::encrypted_link::link: restore_encrypted_link; remote_pubkey=PublicKey("pubkyej5obc…") local_receiver_path=PaykitReceiverPath("bitkit/wallet") remote_receiver_path=PaykitReceiverPath("bitkit/wallet")

and the request moved from "Waiting for … to pay" into the settled group. A force-stop and relaunch of the payer produced no re-submission and no leftover pending record, and there were no Paykit warnings or errors on either device.

[ben-kaufman]

Fixed the disabled incoming-request swipe in 6d66ab6. The request branch validated the amount but did not persist that result, so Send Confirm kept the swipe disabled. It now writes the validation result before navigation, and the existing incoming payment request opens the existing confirm flow with its fixed amount test asserts that isAmountInputValid is true. The focused test and full unit suite pass.

[ben-kaufman]

The conflicts are resolved and the branch is current. It also now includes the proof-store/polling hardening and the disabled-swipe fix reported in the latest review. Please retest at 6d66ab6.

[ovitrif]

utACK

[ben-kaufman]

The reconciliation finding is fixed in signed commit ad132c8. Each pending proof is now isolated, so one temporary submission failure does not stop later proofs, with a focused regression covering that sequence. @ovitrif please re-review the updated head when E2E finishes.

[piotr-iohk]

Retested latest revision, Pixel emu ↔ iPhone 17 sim (same session as ios #683).

Incoming request pay on Android goes to Confirm with the amount locked. That matches this side — the amount-pad leak is iOS only (see #683).

Request lists don’t match
Same session, both on TODAY:

• Android: 2× 1000 + 26 000 + 25 000
• iOS: 3× 1000 + 26 000 (no 25 000)

Not amount-keyed overwrite in the app list — IDs are paymentRequestId + counterparty + path. This device sent the 25k on-chain; iOS activity shows +25 000, but iOS is missing that request-history row. Android is missing one of the 1k rows iOS still has. Hypothesis: after fulfill, one side drops the row when localRole is missing/unknown (history mapping skips those). Avatars I vs A are just the contact names.

Screenshot (Payment Requests list):

Logs:

logs-android.zip

Proofs still queued on the successful pays (LN + on-chain both ways). List drift looks like a follow-up, not a proofs blocker.

[ben-kaufman]

Thanks for confirming the Android amount path is correct. I also reran the clean cross-platform proof/history portion against the current Android and iOS heads: two requests succeeded in each direction, both apps ended with the same four history rows, and each remote request transitioned to paid after the payer logged durable proof-outbox acceptance. I could not reproduce a stuck proof or history divergence on clean state, so there is no speculative Android change for those observations. All Android checks are green on ad132c893.

[ovitrif]

The incoming-request swipe assignment in onScanOnchain still has no test that would fail if it were removed. The new isAmountInputValid assertion is on a lightning presentation that already sets that flag in onScanLightning.

[ovitrif]

utACK

[piotr-iohk]

QA LGTM.

Retested latest (10ff0df) Pixel emu ↔ iPhone 17 sim, regtest. 2 requests from each side (1k LN + 25k on-chain), all 4 paid.

• Incoming request pay stays on Confirm, amount locked
• Proofs queued after both LN pays and both on-chain pays (Queued a Paykit payment proof for private delivery)
• No proof UI, as expected
• No Failed to prepare/complete/reconcile or ignored-proof warnings

Payment Requests lists still diverge after the same session (3 rows each, different missing amount). Follow-up: #1219 (ios twin: synonymdev/bitkit-ios#723). Not a proofs blocker.

[jvsena42]

LGTM