From cebbeb88987af88418c478b7ccc50e95ba41273e Mon Sep 17 00:00:00 2001 From: Ovi Trif Date: Wed, 2 Sep 2026 02:03:19 +0200 Subject: [PATCH 1/9] test: add Pubky marketplace wallet-leg journey (#718) --- journeys/README.md | 1 + journeys/pubky-marketplace/README.md | 72 +++++++++++++++++++++++ journeys/pubky-marketplace/wallet-leg.xml | 34 +++++++++++ 3 files changed, 107 insertions(+) create mode 100644 journeys/pubky-marketplace/README.md create mode 100644 journeys/pubky-marketplace/wallet-leg.xml diff --git a/journeys/README.md b/journeys/README.md index 905af7d60..0ecfce268 100644 --- a/journeys/README.md +++ b/journeys/README.md @@ -135,6 +135,7 @@ Everything else — `N0`–`N9`, `N000`, `NDecimal`, `NRemove`, `SpendingAmount* | [notification-permission](notification-permission) | 4 | Background-setup toggles | | [cjit-notifications](cjit-notifications) | 3 | Adapted — iOS notification copy differs from Android | | [hardware-wallet](hardware-wallet) | 15 | Trezor over Bridge; see `Docs/AI_DEVICE_TESTS.md` | +| [pubky-marketplace](pubky-marketplace) | 1 | Two-wallet Paykit marketplace payment on regtest; external fixture required | ## Not ported diff --git a/journeys/pubky-marketplace/README.md b/journeys/pubky-marketplace/README.md new file mode 100644 index 000000000..84781dfaa --- /dev/null +++ b/journeys/pubky-marketplace/README.md @@ -0,0 +1,72 @@ +# Pubky marketplace wallet leg + +This suite covers the two-wallet Bitkit leg of a Pubky marketplace purchase: a seller grants a +watch-only account claim, a linked buyer receives the resulting Payment Request, and the buyer pays +the request on regtest through confirmation. It does not cover marketplace browsing, Locks content +delivery, fiat payment, or Hypercolor. + +## Required external fixture + +The journey needs a controlled marketplace fixture outside this repository. The fixture owns all +server-side state and must provide: + +- A fresh Pubky testnet or isolated staging namespace reachable by both simulator wallets. +- A Paykit Server with the marketplace wallet-interop fixes and a `/setup` flow whose auth URL + carries `x-bitkit-claim=watch-only-account-v1`. +- A regtest bitcoind and Electrum/Fulcrum endpoint on the same chain. The endpoint must be configured + in both wallets before first launch so neither wallet retains a taller foreign regtest tip. +- A clean seller wallet, a separate clean funded buyer wallet, and the seller Pubky public key. +- A marketplace driver that can create one purchase for the buyer, expose its Payment Request id, + report Paykit delivery, return the derived on-chain address and expected amount, mine one block, + and report the transaction and purchase status. + +The request and endpoint must satisfy the issuer contract from iOS issue +[#713](https://github.com/synonymdev/bitkit-ios/issues/713): lowercase `btc`, a network-correct +`btc-regtest-*` endpoint identifier, and a JSON endpoint payload with a non-empty string `value`. +The fixture must keep watch-only account material and spending authority separate. Evidence must +show the claimed account xpub and account index while omitting wallet seed material and tokens. + +The previously proven staging fixture is documented in +`BitcoinErrorLog/pubky-payment-rails/docs/wallet-leg.md`. Access to that repository, or an equivalent +fixture implementing the requirements above, is required to execute the journey. + +## Required app changes + +The full journey depends on the sibling work from the parent epic: + +- [#713](https://github.com/synonymdev/bitkit-ios/issues/713) defines the issuer interop contract. +- [#714](https://github.com/synonymdev/bitkit-ios/issues/714) supplies the stable per-request Pay + action identifier used by this journey. +- [#715](https://github.com/synonymdev/bitkit-ios/issues/715) opens the fixture's `pubkyauth` URL + directly in Bitkit. +- [#717](https://github.com/synonymdev/bitkit-ios/issues/717) prevents an Electrum-rejected broadcast + from reaching `SendSuccess`. + +The linked-contact prerequisite is existing Paykit behavior: the buyer must save the seller before +Bitkit's `receivePrivateMessagesFromLinkedPeers()` poll can receive the request. + +## Evidence contract + +Capture one timestamped evidence directory per run. Record the app commit, fixture commit, both +simulator identifiers, Payment Request id, transaction id, and regtest block height. Keep these +artifacts at each boundary: + +| Boundary | Bitkit evidence | Fixture evidence | +| --- | --- | --- | +| Watch-only claim | `PubkyAuthWatchOnlyConsent`, `PubkyAuthWatchOnlyApprove`, `PubkyAuthAuthorize`, and `PubkyAuthOK` snapshots | Setup completion and the claimed xpub/account index, with no spending key | +| Linked buyer | `Contact_` snapshot | Seller and buyer peer-link state | +| Incoming request | `PaymentRequestsSheet` and `PaymentRequestRow-` snapshots showing seller, note, and amount | Delivery record and exact Payment Request id | +| Payment approval | `PaymentRequestPay-`, `ReviewAmount`, and `ReviewUri` snapshots | Derived regtest address and expected amount | +| Broadcast | `SendSuccess` snapshot and buyer activity details | Transaction in the fixture mempool with an amount-matched output | +| Confirmation | Confirmed buyer activity snapshot | Transaction id at one or more confirmations and completed purchase status | + +`SendSuccess` is evidence of backend acceptance, not confirmation. The fixture's chain and purchase +status are the confirmation authority. + +## Baseline from 2026-09-02 + +The current implementation was built from `004a1082` on a freshly erased iPhone 17 Pro Max +simulator with Paykit UI enabled. A new wallet and Pubky profile reached the in-app scanner/paste +handoff used by the prior wallet-leg proof. The run stopped before watch-only approval because the +staging fixture repository and its setup URL were unavailable to the runner. This establishes the +app-side baseline without claiming an end-to-end pass. diff --git a/journeys/pubky-marketplace/wallet-leg.xml b/journeys/pubky-marketplace/wallet-leg.xml new file mode 100644 index 000000000..ba288fcc4 --- /dev/null +++ b/journeys/pubky-marketplace/wallet-leg.xml @@ -0,0 +1,34 @@ + + + Verifies a Bitkit seller grants a watch-only account claim and a separate linked Bitkit buyer + receives, approves, pays, and confirms the resulting marketplace Payment Request on regtest. + Precondition: two clean simulator wallets and the external fixture described in this suite's + README. Configure the fixture Electrum endpoint and Paykit UI before either wallet's first + launch. Start with the seller wallet open and the fixture's fresh setup auth URL available. + + + Open the fixture setup auth URL in the seller wallet + Verify the watch-only consent screen (id "PubkyAuthWatchOnlyConsent") is visible + Capture the watch-only consent evidence, then tap Approve (id "PubkyAuthWatchOnlyApprove") + Verify the authorization screen shows only the requested Paykit capabilities + Tap Authorize (id "PubkyAuthAuthorize") + Verify authorization succeeds (id "PubkyAuthOK") + Verify the fixture completes setup with the seller account xpub and no spending authority + Open Contacts in the buyer wallet and save the fixture's seller public key + Verify the seller contact (id "Contact_<seller-public-key>") is visible + Verify the fixture reports the seller and buyer as linked peers + Have the fixture create one marketplace purchase for the buyer and record its Payment Request id + Wait for the incoming requests sheet (id "PaymentRequestsSheet") + Verify the request row (id "PaymentRequestRow-<payment-request-id>") shows the seller, note, and expected amount + Capture the incoming-request evidence, then tap Pay (id "PaymentRequestPay-<payment-request-id>") + Verify the review amount (id "ReviewAmount") matches the fixture amount + Show details and verify the payment URI (id "ReviewUri") contains the fixture's regtest address + Capture the payment-approval evidence, then swipe to send (id "GRAB") + Verify Bitcoin Sent (id "SendSuccess") appears after the backend accepts the transaction + Verify the fixture mempool contains the transaction with an amount-matched output + Mine one block with the fixture and wait for both Bitkit and the marketplace status to refresh + Open the latest sent on-chain activity and verify its amount (id "ActivityAmount") and transaction details (id "ActivityTxDetails") + Verify the fixture reports the transaction confirmed and the marketplace purchase completed + Capture the final activity, transaction id, confirmation height, and completed purchase evidence + + From 32bd6948be9edb1d65b868622ebdb7410104ed0e Mon Sep 17 00:00:00 2001 From: Ovi Trif Date: Wed, 2 Sep 2026 02:11:17 +0200 Subject: [PATCH 2/9] docs: reference local marketplace fixture --- journeys/pubky-marketplace/README.md | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/journeys/pubky-marketplace/README.md b/journeys/pubky-marketplace/README.md index 84781dfaa..a48618a53 100644 --- a/journeys/pubky-marketplace/README.md +++ b/journeys/pubky-marketplace/README.md @@ -14,7 +14,9 @@ server-side state and must provide: - A Paykit Server with the marketplace wallet-interop fixes and a `/setup` flow whose auth URL carries `x-bitkit-claim=watch-only-account-v1`. - A regtest bitcoind and Electrum/Fulcrum endpoint on the same chain. The endpoint must be configured - in both wallets before first launch so neither wallet retains a taller foreign regtest tip. + in both wallets before first launch so neither wallet retains a taller foreign regtest tip. The + reference fixture keeps Fulcrum internal, so a live wallet run must publish or proxy that endpoint + to the simulator host. - A clean seller wallet, a separate clean funded buyer wallet, and the seller Pubky public key. - A marketplace driver that can create one purchase for the buyer, expose its Payment Request id, report Paykit delivery, return the derived on-chain address and expected amount, mine one block, @@ -26,9 +28,11 @@ The request and endpoint must satisfy the issuer contract from iOS issue The fixture must keep watch-only account material and spending authority separate. Evidence must show the claimed account xpub and account index while omitting wallet seed material and tokens. -The previously proven staging fixture is documented in -`BitcoinErrorLog/pubky-payment-rails/docs/wallet-leg.md`. Access to that repository, or an equivalent -fixture implementing the requirements above, is required to execute the journey. +The reference implementation is +[`BitcoinErrorLog/pubky-marketplace/payments-env`](https://github.com/BitcoinErrorLog/pubky-marketplace/tree/0259d994967961cb0b972eba2f11a567d7376dd7/payments-env). +Its `scripts/verify.sh` already proves the Locks, Paykit, Pubky, bitcoind, and Fulcrum protocol path. +For this journey, the seller wallet replaces `paykit-companion-auth` and the buyer wallet replaces +`paykit-reader-demo`; the other fixture roles remain unchanged. ## Required app changes @@ -67,6 +71,6 @@ status are the confirmation authority. The current implementation was built from `004a1082` on a freshly erased iPhone 17 Pro Max simulator with Paykit UI enabled. A new wallet and Pubky profile reached the in-app scanner/paste -handoff used by the prior wallet-leg proof. The run stopped before watch-only approval because the -staging fixture repository and its setup URL were unavailable to the runner. This establishes the +handoff used by the prior wallet-leg proof. The first run stopped before watch-only approval while +the local `payments-env` fixture was being prepared for live wallet roles. This establishes the app-side baseline without claiming an end-to-end pass. From c3d1560d8b2be7ff1136f36d3659e23ba165aec8 Mon Sep 17 00:00:00 2001 From: Ovi Trif Date: Wed, 2 Sep 2026 03:00:44 +0200 Subject: [PATCH 3/9] test: record marketplace wallet-leg baseline --- journeys/pubky-marketplace/README.md | 26 ++++++++++++++++------- journeys/pubky-marketplace/wallet-leg.xml | 4 ++++ 2 files changed, 22 insertions(+), 8 deletions(-) diff --git a/journeys/pubky-marketplace/README.md b/journeys/pubky-marketplace/README.md index a48618a53..2a96cc41b 100644 --- a/journeys/pubky-marketplace/README.md +++ b/journeys/pubky-marketplace/README.md @@ -46,8 +46,9 @@ The full journey depends on the sibling work from the parent epic: - [#717](https://github.com/synonymdev/bitkit-ios/issues/717) prevents an Electrum-rejected broadcast from reaching `SendSuccess`. -The linked-contact prerequisite is existing Paykit behavior: the buyer must save the seller before -Bitkit's `receivePrivateMessagesFromLinkedPeers()` poll can receive the request. +The linked-contact prerequisite is existing Paykit behavior: contact payments must be enabled in +General Settings and the buyer and seller must save each other before Bitkit's +`receivePrivateMessagesFromLinkedPeers()` poll can receive the request. ## Evidence contract @@ -58,7 +59,7 @@ artifacts at each boundary: | Boundary | Bitkit evidence | Fixture evidence | | --- | --- | --- | | Watch-only claim | `PubkyAuthWatchOnlyConsent`, `PubkyAuthWatchOnlyApprove`, `PubkyAuthAuthorize`, and `PubkyAuthOK` snapshots | Setup completion and the claimed xpub/account index, with no spending key | -| Linked buyer | `Contact_` snapshot | Seller and buyer peer-link state | +| Linked buyer | Enabled `ContactPaymentsToggle`, `Contact_`, and `Contact_` snapshots | Seller and buyer peer-link state | | Incoming request | `PaymentRequestsSheet` and `PaymentRequestRow-` snapshots showing seller, note, and amount | Delivery record and exact Payment Request id | | Payment approval | `PaymentRequestPay-`, `ReviewAmount`, and `ReviewUri` snapshots | Derived regtest address and expected amount | | Broadcast | `SendSuccess` snapshot and buyer activity details | Transaction in the fixture mempool with an amount-matched output | @@ -69,8 +70,17 @@ status are the confirmation authority. ## Baseline from 2026-09-02 -The current implementation was built from `004a1082` on a freshly erased iPhone 17 Pro Max -simulator with Paykit UI enabled. A new wallet and Pubky profile reached the in-app scanner/paste -handoff used by the prior wallet-leg proof. The first run stopped before watch-only approval while -the local `payments-env` fixture was being prepared for live wallet roles. This establishes the -app-side baseline without claiming an end-to-end pass. +The journey branch at `32bd6948` was built for two freshly erased simulators with Paykit UI enabled +against fixture commit `0259d994`. The seller completed the watch-only consent and exact Paykit +capability authorization through `PubkyAuthOK`; fixture setup completed without spending authority. +The buyer received 100,000 regtest sats, both wallets enabled contact payments, saved each other, +and linked the seller's `bitkit/server` and `bitkit/wallet` receivers. + +Paykit marked two iOS-targeted requests delivered, with Payment Request ids +`43c0f7d4-92f7-4ec1-b9c4-5cff67d72381` and `436a1fb4-9109-4a8f-bcae-6c700e218634`. The buyer SDK +received both as linked, proposed payer records for 15,000 sats, but the fixture emitted uppercase +`BTC` and `btc-bitcoin-p2wpkh`. Those values violate the issuer contract above, so Bitkit correctly +excluded the records from actionable requests and did not present `PaymentRequestsSheet`. A +coordinated Android buyer reproduced the same no-request result from a separately delivered +fixture request. The baseline therefore stops at the issuer-contract assertion; approval, +broadcast, and confirmation remain pending a fixture that emits the documented regtest contract. diff --git a/journeys/pubky-marketplace/wallet-leg.xml b/journeys/pubky-marketplace/wallet-leg.xml index ba288fcc4..8674fc0c2 100644 --- a/journeys/pubky-marketplace/wallet-leg.xml +++ b/journeys/pubky-marketplace/wallet-leg.xml @@ -14,10 +14,14 @@ Tap Authorize (id "PubkyAuthAuthorize") Verify authorization succeeds (id "PubkyAuthOK") Verify the fixture completes setup with the seller account xpub and no spending authority + Open General Settings in both wallets and verify contact payments (id "ContactPaymentsToggle") are enabled Open Contacts in the buyer wallet and save the fixture's seller public key Verify the seller contact (id "Contact_<seller-public-key>") is visible + Open Contacts in the seller wallet and save the buyer public key + Verify the buyer contact (id "Contact_<buyer-public-key>") is visible Verify the fixture reports the seller and buyer as linked peers Have the fixture create one marketplace purchase for the buyer and record its Payment Request id + Verify the request uses lowercase "btc", a regtest endpoint identifier, and a JSON endpoint value Wait for the incoming requests sheet (id "PaymentRequestsSheet") Verify the request row (id "PaymentRequestRow-<payment-request-id>") shows the seller, note, and expected amount Capture the incoming-request evidence, then tap Pay (id "PaymentRequestPay-<payment-request-id>") From b09916deea199b8a9dbded7ff3775583c382d978 Mon Sep 17 00:00:00 2001 From: Ovi Trif Date: Wed, 2 Sep 2026 03:01:35 +0200 Subject: [PATCH 4/9] docs: link marketplace fixture blocker --- journeys/pubky-marketplace/README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/journeys/pubky-marketplace/README.md b/journeys/pubky-marketplace/README.md index 2a96cc41b..c49db4aaa 100644 --- a/journeys/pubky-marketplace/README.md +++ b/journeys/pubky-marketplace/README.md @@ -84,3 +84,5 @@ excluded the records from actionable requests and did not present `PaymentReques coordinated Android buyer reproduced the same no-request result from a separately delivered fixture request. The baseline therefore stops at the issuer-contract assertion; approval, broadcast, and confirmation remain pending a fixture that emits the documented regtest contract. +The shared fixture blocker is tracked in +[`BitcoinErrorLog/pubky-marketplace#1`](https://github.com/BitcoinErrorLog/pubky-marketplace/issues/1). From c3791bbf7cccd9dfdd94f85081330ebe2d480692 Mon Sep 17 00:00:00 2001 From: Ovi Trif Date: Wed, 2 Sep 2026 03:19:39 +0200 Subject: [PATCH 5/9] docs: distinguish diagnostic wallet observations --- journeys/pubky-marketplace/README.md | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/journeys/pubky-marketplace/README.md b/journeys/pubky-marketplace/README.md index c49db4aaa..ab04333bb 100644 --- a/journeys/pubky-marketplace/README.md +++ b/journeys/pubky-marketplace/README.md @@ -71,10 +71,15 @@ status are the confirmation authority. ## Baseline from 2026-09-02 The journey branch at `32bd6948` was built for two freshly erased simulators with Paykit UI enabled -against fixture commit `0259d994`. The seller completed the watch-only consent and exact Paykit -capability authorization through `PubkyAuthOK`; fixture setup completed without spending authority. -The buyer received 100,000 regtest sats, both wallets enabled contact payments, saved each other, -and linked the seller's `bitkit/server` and `bitkit/wallet` receivers. +against fixture commit `0259d994`. The preserved app evidence confirms the final `PubkyAuthOK` +authorization success. The fixture's immutable protocol evidence independently passed all 15 +verification steps. + +An exploratory two-wallet run subsequently observed seller setup, a funded buyer, bilateral +contacts, linked `bitkit/server` and `bitkit/wallet` receivers, and delivered requests. That run did +not preserve the full boundary artifacts required above for consent and approval, exact +capabilities, both toggles and contact rows, claimed account details, or raw SDK and outbox state. +Those observations are diagnostic context, not passed journey boundaries. Paykit marked two iOS-targeted requests delivered, with Payment Request ids `43c0f7d4-92f7-4ec1-b9c4-5cff67d72381` and `436a1fb4-9109-4a8f-bcae-6c700e218634`. The buyer SDK @@ -82,7 +87,9 @@ received both as linked, proposed payer records for 15,000 sats, but the fixture `BTC` and `btc-bitcoin-p2wpkh`. Those values violate the issuer contract above, so Bitkit correctly excluded the records from actionable requests and did not present `PaymentRequestsSheet`. A coordinated Android buyer reproduced the same no-request result from a separately delivered -fixture request. The baseline therefore stops at the issuer-contract assertion; approval, -broadcast, and confirmation remain pending a fixture that emits the documented regtest contract. +fixture request. The diagnostic baseline therefore stops at the issuer-contract assertion; the +watch-only, linked-buyer, incoming-request, approval, broadcast, and confirmation boundaries all +remain pending a clean run with the complete evidence contract. + The shared fixture blocker is tracked in [`BitcoinErrorLog/pubky-marketplace#1`](https://github.com/BitcoinErrorLog/pubky-marketplace/issues/1). From c0cf2d553b1cdcf6dd1bba6d8865a80292b4d7e8 Mon Sep 17 00:00:00 2001 From: Ovi Trif Date: Wed, 2 Sep 2026 11:37:56 +0200 Subject: [PATCH 6/9] test: record marketplace wallet journey acceptance --- journeys/pubky-marketplace/README.md | 52 ++++++++++++++++++++--- journeys/pubky-marketplace/wallet-leg.xml | 4 +- 2 files changed, 47 insertions(+), 9 deletions(-) diff --git a/journeys/pubky-marketplace/README.md b/journeys/pubky-marketplace/README.md index ab04333bb..871cdddc3 100644 --- a/journeys/pubky-marketplace/README.md +++ b/journeys/pubky-marketplace/README.md @@ -29,7 +29,7 @@ The fixture must keep watch-only account material and spending authority separat show the claimed account xpub and account index while omitting wallet seed material and tokens. The reference implementation is -[`BitcoinErrorLog/pubky-marketplace/payments-env`](https://github.com/BitcoinErrorLog/pubky-marketplace/tree/0259d994967961cb0b972eba2f11a567d7376dd7/payments-env). +[`BitcoinErrorLog/pubky-marketplace/payments-env`](https://github.com/BitcoinErrorLog/pubky-marketplace/tree/ed03a32ecfe02deab40ad10ae1bac7fa18465c10/payments-env). Its `scripts/verify.sh` already proves the Locks, Paykit, Pubky, bitcoind, and Fulcrum protocol path. For this journey, the seller wallet replaces `paykit-companion-auth` and the buyer wallet replaces `paykit-reader-demo`; the other fixture roles remain unchanged. @@ -60,15 +60,54 @@ artifacts at each boundary: | --- | --- | --- | | Watch-only claim | `PubkyAuthWatchOnlyConsent`, `PubkyAuthWatchOnlyApprove`, `PubkyAuthAuthorize`, and `PubkyAuthOK` snapshots | Setup completion and the claimed xpub/account index, with no spending key | | Linked buyer | Enabled `ContactPaymentsToggle`, `Contact_`, and `Contact_` snapshots | Seller and buyer peer-link state | -| Incoming request | `PaymentRequestsSheet` and `PaymentRequestRow-` snapshots showing seller, note, and amount | Delivery record and exact Payment Request id | -| Payment approval | `PaymentRequestPay-`, `ReviewAmount`, and `ReviewUri` snapshots | Derived regtest address and expected amount | +| Incoming request | `PaymentRequestsSheet` and `PaymentRequestRow-` snapshots showing seller, amount, and note when present | Delivery record and exact Payment Request id | +| Payment approval | `PaymentRequestPay-`, `ReviewAmount`, and `ReviewContactRecipient` snapshots | Derived regtest address and expected amount | | Broadcast | `SendSuccess` snapshot and buyer activity details | Transaction in the fixture mempool with an amount-matched output | | Confirmation | Confirmed buyer activity snapshot | Transaction id at one or more confirmations and completed purchase status | `SendSuccess` is evidence of backend acceptance, not confirmation. The fixture's chain and purchase status are the confirmation authority. -## Baseline from 2026-09-02 +## Accepted corrected iOS run from 2026-09-02 + +The complete journey passed on iOS app commit `c3791bbf7cccd9dfdd94f85081330ebe2d480692` +against fixture commit `ed03a32ecfe02deab40ad10ae1bac7fa18465c10`, Paykit Server revision +`867fc883125c7b89a7b712c2551619cccdfdc0f7`, and Paykit revision +`6b241878a9bba5cecea919c0298c3f90624be6ff`. The Paykit Server image was +`sha256:2e5c2e8391a4a9f60dfaed3326fce0b772f01e81b4a51b69cbf08c0b02bd89e8`. + +- Seller simulator: `B379B7A4-715A-427F-8CB6-A6479BC73050`; Pubky + `pubkyhbn4tahj71yzpmtarz5amtqqf5fmicdd7rs8ao448tzaujdapfiy`. +- Buyer simulator: `1B8D53BA-43F9-4799-AC0D-32EFDA4BDAF6`; Pubky + `pubkysqy1tx5poq5djne846r4rfbkca8ggmru9jp8d34tbjp74ngtzxno`. +- The seller approved the watch-only claim and exact Paykit capabilities. The fixture persisted + account index `1` (`m/84h/1h/1h`) and its account tpub without Bitcoin spending authority. +- Both wallets enabled `ContactPaymentsToggle` and displayed reciprocal `Contact_` + rows before the fixture reported the buyer `Linked` at `bitkit/wallet` with failure count `0`. +- Buyer funding transaction `0baf24337a58449816a18f0bb984e9dbc993fd9cb1bbf4391aff333280bcb908` + paid exactly 1,000,000 sats and was confirmed in block + `642c3864f623d376d04dbc1c6fba5b64f6e72cfcdbb6029fa7d0ade7dc24383f` at height `16400`. +- Canonical request `60281cab-4914-40e9-979a-6572eebe69d6` used `0.00015000 btc`, endpoint identifier + `btc-regtest-p2wpkh`, and JSON endpoint value + `bcrt1qkhvgdehsp9y54tqp60f74phsqjjl77anrdmawn`. Its note was absent. +- `PaymentRequestsSheet` showed Seller and 15,000 sats. The approval retained 15,000 sats, + `ReviewContactRecipient` resolved to Seller, and the 143-sat fee and enabled `GRAB` were visible. +- Exactly one authorized swipe reached `SendSuccess` and broadcast transaction + `f15eb143e91904bac0b6d966627f60a37eb14862a96f7455a7ae00598ddb5150`. Output zero paid exactly + 15,000 sats to the request address, output one returned 984,857 sats, and the fee was 143 sats. +- Before mining, the transaction was the only mempool entry, Paykit reported `detected/0/true`, and + the Locks bundle remained pending. Exactly one block, + `4d607bf79dd4d94624f1f4fc6f8e90a38a25a474e9aa08298f85f971ecc2e0fc`, advanced the chain to + height `16401`; Paykit then reported `confirmed/1/true`, the Locks bundle completed without + failure, and the mempool was empty. +- The buyer displayed `StatusConfirmed`, `ActivityAmount` with a 15,000-sat payment and 143-sat fee, + `ActivityTxDetails`, and Seller. Request history retained exactly + `PaymentRequestRow-60281cab-4914-40e9-979a-6572eebe69d6` without Pay or Dismiss actions. + +Android replays exercised the same corrected fixture and shared protocol vocabulary. They are +diagnostic cross-platform evidence and are not the accepted iOS journey execution above. + +## Diagnostic baseline from 2026-09-02 The journey branch at `32bd6948` was built for two freshly erased simulators with Paykit UI enabled against fixture commit `0259d994`. The preserved app evidence confirms the final `PubkyAuthOK` @@ -88,8 +127,7 @@ received both as linked, proposed payer records for 15,000 sats, but the fixture excluded the records from actionable requests and did not present `PaymentRequestsSheet`. A coordinated Android buyer reproduced the same no-request result from a separately delivered fixture request. The diagnostic baseline therefore stops at the issuer-contract assertion; the -watch-only, linked-buyer, incoming-request, approval, broadcast, and confirmation boundaries all -remain pending a clean run with the complete evidence contract. +accepted corrected iOS run above supersedes its incomplete boundary coverage. -The shared fixture blocker is tracked in +The corrected fixture work is tracked in [`BitcoinErrorLog/pubky-marketplace#1`](https://github.com/BitcoinErrorLog/pubky-marketplace/issues/1). diff --git a/journeys/pubky-marketplace/wallet-leg.xml b/journeys/pubky-marketplace/wallet-leg.xml index 8674fc0c2..60f767fab 100644 --- a/journeys/pubky-marketplace/wallet-leg.xml +++ b/journeys/pubky-marketplace/wallet-leg.xml @@ -23,10 +23,10 @@ Have the fixture create one marketplace purchase for the buyer and record its Payment Request id Verify the request uses lowercase "btc", a regtest endpoint identifier, and a JSON endpoint value Wait for the incoming requests sheet (id "PaymentRequestsSheet") - Verify the request row (id "PaymentRequestRow-<payment-request-id>") shows the seller, note, and expected amount + Verify the request row (id "PaymentRequestRow-<payment-request-id>") shows the seller and expected amount, plus the fixture note when present Capture the incoming-request evidence, then tap Pay (id "PaymentRequestPay-<payment-request-id>") Verify the review amount (id "ReviewAmount") matches the fixture amount - Show details and verify the payment URI (id "ReviewUri") contains the fixture's regtest address + Show details and verify the recipient (id "ReviewContactRecipient") is the seller contact Capture the payment-approval evidence, then swipe to send (id "GRAB") Verify Bitcoin Sent (id "SendSuccess") appears after the backend accepts the transaction Verify the fixture mempool contains the transaction with an amount-matched output From fccc35dc5740e624c1b7771747be7a3e4a933525 Mon Sep 17 00:00:00 2001 From: Ovi Trif Date: Wed, 2 Sep 2026 13:18:01 +0200 Subject: [PATCH 7/9] test: record exact marketplace journey replay --- journeys/pubky-marketplace/README.md | 173 ++++++++++------------ journeys/pubky-marketplace/wallet-leg.xml | 4 +- 2 files changed, 77 insertions(+), 100 deletions(-) diff --git a/journeys/pubky-marketplace/README.md b/journeys/pubky-marketplace/README.md index 871cdddc3..642d98315 100644 --- a/journeys/pubky-marketplace/README.md +++ b/journeys/pubky-marketplace/README.md @@ -2,37 +2,33 @@ This suite covers the two-wallet Bitkit leg of a Pubky marketplace purchase: a seller grants a watch-only account claim, a linked buyer receives the resulting Payment Request, and the buyer pays -the request on regtest through confirmation. It does not cover marketplace browsing, Locks content -delivery, fiat payment, or Hypercolor. +the request on regtest through confirmation. It does not cover marketplace browsing, fiat payment, +or Hypercolor. -## Required external fixture +## Required integration fixture -The journey needs a controlled marketplace fixture outside this repository. The fixture owns all -server-side state and must provide: +The journey needs a controlled integration fixture outside this repository. The test operator owns +the fixture state and must provide: - A fresh Pubky testnet or isolated staging namespace reachable by both simulator wallets. -- A Paykit Server with the marketplace wallet-interop fixes and a `/setup` flow whose auth URL - carries `x-bitkit-claim=watch-only-account-v1`. -- A regtest bitcoind and Electrum/Fulcrum endpoint on the same chain. The endpoint must be configured - in both wallets before first launch so neither wallet retains a taller foreign regtest tip. The - reference fixture keeps Fulcrum internal, so a live wallet run must publish or proxy that endpoint - to the simulator host. -- A clean seller wallet, a separate clean funded buyer wallet, and the seller Pubky public key. -- A marketplace driver that can create one purchase for the buyer, expose its Payment Request id, - report Paykit delivery, return the derived on-chain address and expected amount, mine one block, - and report the transaction and purchase status. +- A Paykit Server compatible with the watch-only setup contract merged in + [`pubky/paykit-server#2`](https://github.com/pubky/paykit-server/pull/2), including a `/setup` auth + URL whose payload carries `x-bitkit-claim=watch-only-account-v1`. Revision + [`867fc883`](https://github.com/pubky/paykit-server/commit/867fc883125c7b89a7b712c2551619cccdfdc0f7) + is the producer provenance used by the accepted run. +- A regtest bitcoind and Electrum/Fulcrum endpoint on the same chain. Configure that endpoint in + both wallets before first launch so neither wallet retains a taller foreign regtest tip. +- A clean seller wallet, a separate clean funded buyer wallet, and bilateral Paykit peer links at + `bitkit/server` and `bitkit/wallet`. +- A driver that creates exactly one purchase for the buyer, reports the Payment Request id and + delivery state, returns the derived address and expected amount, mines exactly one authorized + block, and reports signed Paykit and marketplace completion state. The request and endpoint must satisfy the issuer contract from iOS issue [#713](https://github.com/synonymdev/bitkit-ios/issues/713): lowercase `btc`, a network-correct `btc-regtest-*` endpoint identifier, and a JSON endpoint payload with a non-empty string `value`. -The fixture must keep watch-only account material and spending authority separate. Evidence must -show the claimed account xpub and account index while omitting wallet seed material and tokens. - -The reference implementation is -[`BitcoinErrorLog/pubky-marketplace/payments-env`](https://github.com/BitcoinErrorLog/pubky-marketplace/tree/ed03a32ecfe02deab40ad10ae1bac7fa18465c10/payments-env). -Its `scripts/verify.sh` already proves the Locks, Paykit, Pubky, bitcoind, and Fulcrum protocol path. -For this journey, the seller wallet replaces `paykit-companion-auth` and the buyer wallet replaces -`paykit-reader-demo`; the other fixture roles remain unchanged. +The fixture must keep watch-only account material and spending authority separate. Evidence records +the claimed account xpub and account index while omitting wallet seed material and tokens. ## Required app changes @@ -46,88 +42,69 @@ The full journey depends on the sibling work from the parent epic: - [#717](https://github.com/synonymdev/bitkit-ios/issues/717) prevents an Electrum-rejected broadcast from reaching `SendSuccess`. -The linked-contact prerequisite is existing Paykit behavior: contact payments must be enabled in -General Settings and the buyer and seller must save each other before Bitkit's -`receivePrivateMessagesFromLinkedPeers()` poll can receive the request. +Contact payments must be enabled in General Settings and the buyer and seller must save each other +before Bitkit's `receivePrivateMessagesFromLinkedPeers()` poll can receive the request. ## Evidence contract -Capture one timestamped evidence directory per run. Record the app commit, fixture commit, both -simulator identifiers, Payment Request id, transaction id, and regtest block height. Keep these +Capture one timestamped evidence directory per run. Record the app commit, integration revision, +both simulator identifiers, Payment Request id, transaction id, and regtest block height. Keep these artifacts at each boundary: -| Boundary | Bitkit evidence | Fixture evidence | +| Boundary | Bitkit evidence | Integration evidence | | --- | --- | --- | | Watch-only claim | `PubkyAuthWatchOnlyConsent`, `PubkyAuthWatchOnlyApprove`, `PubkyAuthAuthorize`, and `PubkyAuthOK` snapshots | Setup completion and the claimed xpub/account index, with no spending key | | Linked buyer | Enabled `ContactPaymentsToggle`, `Contact_`, and `Contact_` snapshots | Seller and buyer peer-link state | -| Incoming request | `PaymentRequestsSheet` and `PaymentRequestRow-` snapshots showing seller, amount, and note when present | Delivery record and exact Payment Request id | +| Incoming request | `PaymentRequestsScreen` and `PaymentRequestRow-` snapshots showing seller, amount, and note when present | Delivery record and exact Payment Request id | | Payment approval | `PaymentRequestPay-`, `ReviewAmount`, and `ReviewContactRecipient` snapshots | Derived regtest address and expected amount | | Broadcast | `SendSuccess` snapshot and buyer activity details | Transaction in the fixture mempool with an amount-matched output | -| Confirmation | Confirmed buyer activity snapshot | Transaction id at one or more confirmations and completed purchase status | - -`SendSuccess` is evidence of backend acceptance, not confirmation. The fixture's chain and purchase -status are the confirmation authority. - -## Accepted corrected iOS run from 2026-09-02 - -The complete journey passed on iOS app commit `c3791bbf7cccd9dfdd94f85081330ebe2d480692` -against fixture commit `ed03a32ecfe02deab40ad10ae1bac7fa18465c10`, Paykit Server revision -`867fc883125c7b89a7b712c2551619cccdfdc0f7`, and Paykit revision -`6b241878a9bba5cecea919c0298c3f90624be6ff`. The Paykit Server image was -`sha256:2e5c2e8391a4a9f60dfaed3326fce0b772f01e81b4a51b69cbf08c0b02bd89e8`. - -- Seller simulator: `B379B7A4-715A-427F-8CB6-A6479BC73050`; Pubky - `pubkyhbn4tahj71yzpmtarz5amtqqf5fmicdd7rs8ao448tzaujdapfiy`. -- Buyer simulator: `1B8D53BA-43F9-4799-AC0D-32EFDA4BDAF6`; Pubky - `pubkysqy1tx5poq5djne846r4rfbkca8ggmru9jp8d34tbjp74ngtzxno`. -- The seller approved the watch-only claim and exact Paykit capabilities. The fixture persisted - account index `1` (`m/84h/1h/1h`) and its account tpub without Bitcoin spending authority. -- Both wallets enabled `ContactPaymentsToggle` and displayed reciprocal `Contact_` - rows before the fixture reported the buyer `Linked` at `bitkit/wallet` with failure count `0`. -- Buyer funding transaction `0baf24337a58449816a18f0bb984e9dbc993fd9cb1bbf4391aff333280bcb908` - paid exactly 1,000,000 sats and was confirmed in block - `642c3864f623d376d04dbc1c6fba5b64f6e72cfcdbb6029fa7d0ade7dc24383f` at height `16400`. -- Canonical request `60281cab-4914-40e9-979a-6572eebe69d6` used `0.00015000 btc`, endpoint identifier - `btc-regtest-p2wpkh`, and JSON endpoint value - `bcrt1qkhvgdehsp9y54tqp60f74phsqjjl77anrdmawn`. Its note was absent. -- `PaymentRequestsSheet` showed Seller and 15,000 sats. The approval retained 15,000 sats, - `ReviewContactRecipient` resolved to Seller, and the 143-sat fee and enabled `GRAB` were visible. -- Exactly one authorized swipe reached `SendSuccess` and broadcast transaction - `f15eb143e91904bac0b6d966627f60a37eb14862a96f7455a7ae00598ddb5150`. Output zero paid exactly - 15,000 sats to the request address, output one returned 984,857 sats, and the fee was 143 sats. -- Before mining, the transaction was the only mempool entry, Paykit reported `detected/0/true`, and - the Locks bundle remained pending. Exactly one block, - `4d607bf79dd4d94624f1f4fc6f8e90a38a25a474e9aa08298f85f971ecc2e0fc`, advanced the chain to - height `16401`; Paykit then reported `confirmed/1/true`, the Locks bundle completed without - failure, and the mempool was empty. -- The buyer displayed `StatusConfirmed`, `ActivityAmount` with a 15,000-sat payment and 143-sat fee, - `ActivityTxDetails`, and Seller. Request history retained exactly - `PaymentRequestRow-60281cab-4914-40e9-979a-6572eebe69d6` without Pay or Dismiss actions. - -Android replays exercised the same corrected fixture and shared protocol vocabulary. They are -diagnostic cross-platform evidence and are not the accepted iOS journey execution above. - -## Diagnostic baseline from 2026-09-02 - -The journey branch at `32bd6948` was built for two freshly erased simulators with Paykit UI enabled -against fixture commit `0259d994`. The preserved app evidence confirms the final `PubkyAuthOK` -authorization success. The fixture's immutable protocol evidence independently passed all 15 -verification steps. - -An exploratory two-wallet run subsequently observed seller setup, a funded buyer, bilateral -contacts, linked `bitkit/server` and `bitkit/wallet` receivers, and delivered requests. That run did -not preserve the full boundary artifacts required above for consent and approval, exact -capabilities, both toggles and contact rows, claimed account details, or raw SDK and outbox state. -Those observations are diagnostic context, not passed journey boundaries. - -Paykit marked two iOS-targeted requests delivered, with Payment Request ids -`43c0f7d4-92f7-4ec1-b9c4-5cff67d72381` and `436a1fb4-9109-4a8f-bcae-6c700e218634`. The buyer SDK -received both as linked, proposed payer records for 15,000 sats, but the fixture emitted uppercase -`BTC` and `btc-bitcoin-p2wpkh`. Those values violate the issuer contract above, so Bitkit correctly -excluded the records from actionable requests and did not present `PaymentRequestsSheet`. A -coordinated Android buyer reproduced the same no-request result from a separately delivered -fixture request. The diagnostic baseline therefore stops at the issuer-contract assertion; the -accepted corrected iOS run above supersedes its incomplete boundary coverage. - -The corrected fixture work is tracked in -[`BitcoinErrorLog/pubky-marketplace#1`](https://github.com/BitcoinErrorLog/pubky-marketplace/issues/1). +| Confirmation | `StatusConfirmed`, `ActivityAmount`, and `ActivityTxDetails` snapshots | Transaction id at one or more confirmations and completed purchase status | + +`SendSuccess` proves backend acceptance, not confirmation. The integration fixture's chain, signed +Paykit state, and marketplace state are the confirmation authority. Android uses a transient request +sheet; the iOS journey opens the persistent `PaymentRequestsScreen` before selecting the same +request-row and per-request Pay identifiers. + +## Accepted exact-head run from 2026-09-02 + +The final iOS acceptance replay used integration merge +`a87d298939b868b899a1f1139ce84a5227703a51`, composed from merged Pay-selector head +`70cd26346c6a539f792564e2e9bddb41cc00eecc` and this journey's pre-run documentation head +`c0cf2d553b1cdcf6dd1bba6d8865a80292b4d7e8`. Its production tree was identical to the selector +head. The installed Bitkit dylib SHA-256 was +`6c5a1be9db1f5985d92629021db7836befd0a3d31c0db638ea284988b123467c`. + +- The controlled seller identity was + `pubkyhbn4tahj71yzpmtarz5amtqqf5fmicdd7rs8ao448tzaujdapfiy`. The fresh buyer simulator was + `DED250A8-2952-42B9-B585-6654E361C87A`, with identity + `pubkyyrnr7smimj8fohmwk84jdoyn6xxdsgo175fu4xd844f1x3xk3xao`. +- The seller setup retained watch-only account index `1` without Bitcoin spending authority. The + buyer enabled `ContactPaymentsToggle`, saved the seller as + `Contact_pubkyhbn4tahj71yzpmtarz5amtqqf5fmicdd7rs8ao448tzaujdapfiy`, and linked at + `bitkit/wallet` with failure count `0`. +- Funding transaction `a57ec0f1b0ebaf493cb98799d3fbf126ecefa9f7f28dcb4f4f14386324b9faac` + paid the fresh buyer exactly 1,000,000 sats. One funding block advanced the shared chain to height + `16402` with tip `6b3dcd34ae81b07a064a1c3497ff47f60f2cda3cb5b27fc5b94777b829c6b6f1`. +- Bundle `SSK4TAEXNRSY2RA8E0FCNVXDE4` produced request + `5f07c465-dc67-42ce-96a0-4209e5389618` for `0.00015000 btc`. Endpoint + `btc-regtest-p2wpkh` contained JSON value + `bcrt1qhlqp9nv4awtzl6psdqmuavanlxzyaemv3pce60`. +- `PaymentRequestRow-5f07c465-dc67-42ce-96a0-4209e5389618` showed 15,000 sats and exposed + `PaymentRequestPay-5f07c465-dc67-42ce-96a0-4209e5389618`. Review preserved 15,000 sats, + `ReviewContactRecipient` resolved to `hbn4...pfiy`, and the 143-sat fee and enabled `GRAB` were + visible. +- Exactly one swipe reached `SendSuccess` and broadcast + `2822f6b43aebeb228e0bfe96c1b201cf41e0ed46a677d704403dc629b09d6f2a`. Output zero paid the + request address exactly 15,000 sats, output one returned 984,857 sats, and the fee was 143 sats. +- Before mining, the transaction was the only mempool entry, signed Paykit state was + `detected/0/true`, and the Locks bundle remained pending. Exactly one authorized block, + `6235eff06b00ed2b736635913e76269cd6524c4fed80f247d244102806816aed`, advanced the chain to + height `16403`. +- Signed Paykit state then reached `confirmed/1/true`, the Locks bundle completed without a failure, + guarded content returned HTTP 200, and the mempool was empty. Bitkit independently synchronized + to the same height and tip. +- The buyer displayed `StatusConfirmed`, a 15,000-sat payment, a 143-sat fee, the seller contact, + and the exact transaction under `ActivityTxDetails`. Request history retained exactly + `PaymentRequestRow-5f07c465-dc67-42ce-96a0-4209e5389618` without Pay or Dismiss actions. +- The sanitized replay video SHA-256 is + `ec6f0819c9e4e4066e8969f092328615bb286925599b6f92c733eba4b999c122`. diff --git a/journeys/pubky-marketplace/wallet-leg.xml b/journeys/pubky-marketplace/wallet-leg.xml index 60f767fab..2c8ebb86f 100644 --- a/journeys/pubky-marketplace/wallet-leg.xml +++ b/journeys/pubky-marketplace/wallet-leg.xml @@ -2,7 +2,7 @@ Verifies a Bitkit seller grants a watch-only account claim and a separate linked Bitkit buyer receives, approves, pays, and confirms the resulting marketplace Payment Request on regtest. - Precondition: two clean simulator wallets and the external fixture described in this suite's + Precondition: two clean simulator wallets and the integration fixture described in this suite's README. Configure the fixture Electrum endpoint and Paykit UI before either wallet's first launch. Start with the seller wallet open and the fixture's fresh setup auth URL available. @@ -22,7 +22,7 @@ Verify the fixture reports the seller and buyer as linked peers Have the fixture create one marketplace purchase for the buyer and record its Payment Request id Verify the request uses lowercase "btc", a regtest endpoint identifier, and a JSON endpoint value - Wait for the incoming requests sheet (id "PaymentRequestsSheet") + Open the incoming requests screen (id "PaymentRequestsScreen") Verify the request row (id "PaymentRequestRow-<payment-request-id>") shows the seller and expected amount, plus the fixture note when present Capture the incoming-request evidence, then tap Pay (id "PaymentRequestPay-<payment-request-id>") Verify the review amount (id "ReviewAmount") matches the fixture amount From 84e6210e65bb94186fd73dfdeb15fa6074ec61d1 Mon Sep 17 00:00:00 2001 From: Ovi Trif Date: Wed, 2 Sep 2026 13:24:34 +0200 Subject: [PATCH 8/9] docs: name marketplace integration fixture --- journeys/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/journeys/README.md b/journeys/README.md index 0ecfce268..4f0a565b3 100644 --- a/journeys/README.md +++ b/journeys/README.md @@ -135,7 +135,7 @@ Everything else — `N0`–`N9`, `N000`, `NDecimal`, `NRemove`, `SpendingAmount* | [notification-permission](notification-permission) | 4 | Background-setup toggles | | [cjit-notifications](cjit-notifications) | 3 | Adapted — iOS notification copy differs from Android | | [hardware-wallet](hardware-wallet) | 15 | Trezor over Bridge; see `Docs/AI_DEVICE_TESTS.md` | -| [pubky-marketplace](pubky-marketplace) | 1 | Two-wallet Paykit marketplace payment on regtest; external fixture required | +| [pubky-marketplace](pubky-marketplace) | 1 | Two-wallet Paykit marketplace payment on regtest; integration fixture required | ## Not ported From 48a85d1fb6457822fcfbe6cf8cd7f4a580577b12 Mon Sep 17 00:00:00 2001 From: Ovi Trif Date: Wed, 2 Sep 2026 13:55:35 +0200 Subject: [PATCH 9/9] docs: explain marketplace Electrum setup --- journeys/pubky-marketplace/README.md | 18 ++++++++++++++++-- journeys/pubky-marketplace/wallet-leg.xml | 5 +++-- 2 files changed, 19 insertions(+), 4 deletions(-) diff --git a/journeys/pubky-marketplace/README.md b/journeys/pubky-marketplace/README.md index 642d98315..1ad2f04b0 100644 --- a/journeys/pubky-marketplace/README.md +++ b/journeys/pubky-marketplace/README.md @@ -16,8 +16,10 @@ the fixture state and must provide: URL whose payload carries `x-bitkit-claim=watch-only-account-v1`. Revision [`867fc883`](https://github.com/pubky/paykit-server/commit/867fc883125c7b89a7b712c2551619cccdfdc0f7) is the producer provenance used by the accepted run. -- A regtest bitcoind and Electrum/Fulcrum endpoint on the same chain. Configure that endpoint in - both wallets before first launch so neither wallet retains a taller foreign regtest tip. +- A regtest bitcoind and Electrum/Fulcrum endpoint on the same chain. Before launching either + wallet, publish the fixture's Fulcrum endpoint to the simulator host at + `tcp://127.0.0.1:60001`; this is Bitkit's local-E2E default and prevents either wallet from + retaining a taller foreign regtest tip. - A clean seller wallet, a separate clean funded buyer wallet, and bilateral Paykit peer links at `bitkit/server` and `bitkit/wallet`. - A driver that creates exactly one purchase for the buyer, reports the Payment Request id and @@ -30,6 +32,18 @@ The request and endpoint must satisfy the issuer contract from iOS issue The fixture must keep watch-only account material and spending authority separate. Evidence records the claimed account xpub and account index while omitting wallet seed material and tokens. +Build and run each clean simulator against that endpoint before its first launch: + +```bash +xcodebuildmcp simulator build-and-run --simulator-id \ + --extra-args "SWIFT_ACTIVE_COMPILATION_CONDITIONS=\$(inherited) E2E_BUILD \ +E2E_BACKEND=local E2E_NETWORK=regtest \ +E2E_HOMESERVER_PUBKY=" +``` + +No stored Electrum override is required: `E2E_BUILD` with the local backend resolves Electrum to +`tcp://127.0.0.1:60001`. Repeat the command for the seller and buyer simulator identifiers. + ## Required app changes The full journey depends on the sibling work from the parent epic: diff --git a/journeys/pubky-marketplace/wallet-leg.xml b/journeys/pubky-marketplace/wallet-leg.xml index 2c8ebb86f..72ec3a062 100644 --- a/journeys/pubky-marketplace/wallet-leg.xml +++ b/journeys/pubky-marketplace/wallet-leg.xml @@ -3,8 +3,9 @@ Verifies a Bitkit seller grants a watch-only account claim and a separate linked Bitkit buyer receives, approves, pays, and confirms the resulting marketplace Payment Request on regtest. Precondition: two clean simulator wallets and the integration fixture described in this suite's - README. Configure the fixture Electrum endpoint and Paykit UI before either wallet's first - launch. Start with the seller wallet open and the fixture's fresh setup auth URL available. + README. Publish fixture Fulcrum at tcp://127.0.0.1:60001 and build both wallets with the local + E2E regtest settings before first launch. Start with the seller wallet open and the fixture's + fresh setup auth URL available. Open the fixture setup auth URL in the seller wallet