Stack Wallet

This commit is a routine user-interface refactor for the Stack Wallet desktop app. It moves the existing ShopInBit service page into a new container so the app can show both 'Services' and 'Gift Cards' tabs. No security-sensitive logic was added or changed; the code that opens web links and starts shopping dialogs is copied unchanged into a new file.

This commit fixes two user-interface bugs in the Stack Wallet app's ShopInBit payment flow. First, it prevents the app from crashing or showing a confusing error dialog if the user navigates away while a transaction is being broadcast. Second, it correctly displays the token symbol (for example, a stablecoin ticker) on the desktop send-confirmation screen. There is no indication these changes address a security vulnerability.

This commit fixes the ShopInBit payment feature so it can correctly pay with USDT (an Ethereum token) instead of only supporting Bitcoin and Monero. It also adds a 'check for payment' button when the user has no compatible wallet, and makes several UI labels and navigation fixes. There is no clear security vulnerability in the diff; it is a feature/bug-fix patch.

This commit changes a desktop cryptocurrency wallet's send confirmation dialog so it can display a custom token ticker (for tokens built on a coin) instead of always showing the base coin's ticker. The title says it removes a tokenTicker parameter, but the code actually adds one. The change is mostly a UI label fix and does not appear to alter how transactions are authorized, signed, or sent.

This commit changes the Stack Wallet app so that when it fetches the list of supported countries from the ShopInBit service, it no longer sends the user's authentication token with the request. It also tidies up how login credentials are formatted before being sent. The main security-relevant change is removing unnecessary authentication from a public metadata endpoint, which reduces the risk that the user's token could be leaked or logged if that endpoint is compromised or misbehaves.

This commit adds a new settings page for a third-party shopping feature called ShopInBit. It lets users generate, view, copy, and restore a 'customer key' used to identify them to the ShopInBit service. The change is mostly user-interface wiring and does not, on its own, appear to fix or introduce a security vulnerability. It does surface a sensitive-looking key in the UI and allows it to be copied to the system clipboard, which could matter if the key is later shown to be a secret, but the commit itself does not change how that key is stored or generated.

This commit simply adds a new 'Services' menu item to the bottom navigation bar in the mobile wallet view. It lets users open an existing screen called ServicesView. There is no security-relevant change in the code shown.

This commit adds two new screens that let a user pay a ShopInBit invoice from inside the Stack Wallet app. It fetches payment details from ShopInBit, shows a QR code and address, and can start a wallet-to-address send for BTC or XMR. There is no obvious malicious code, but the new code trusts a third-party API and URIs/addresses supplied by it, and contains a small hard-coded test fallback that could send real money if the sandbox flag were misused.

This commit is a routine user-interface improvement for the ShopInBit settings page in the Stack Wallet app. It adds a settings gear icon on mobile, a settings button on desktop, and restyles the warning dialogs that remind users to save their customer key before changing it. There is no security-relevant change in behavior.

This commit simply deletes the pubspec.lock file, which is Dart/Flutter's record of exact dependency versions used to build the app. Removing it does not change any application code or fix a security bug. It is a routine project-maintenance change, though it means future builds will resolve dependency versions from pubspec.yaml rather than using pinned versions.

This commit updates the Paynym (BIP47 reusable payment code) claim flow in Stack Wallet so that newly claimed payment codes advertise both SegWit and Taproot support. Previously the claim screen requested a non-SegWit payment code; now it requests a code with both feature bits set. The wallet's payment-code generator also gains a new optional `isTaproot` flag. This is a feature/correctness change rather than a clear security fix, but enabling the right address-type flags can affect which addresses are derived when other wallets pay you, so it has mild security/reliability relevance.

This commit changes a dependency reference in a build template from the project's official BIP47 repository to a personal fork owned by a user named 'sneurlax'. The commit message says this is a temporary TODO step to merge a pull request. On its own, this is a supply-chain risk signal: it points the build to code outside the project's normal trusted source, but the diff does not show what changed in that fork or whether the fork contains malicious or vulnerable code.

This commit adds support for Bitcoin Taproot (P2TR) addresses to the Paynym feature in Stack Wallet. Paynyms are reusable payment codes that let users receive payments without sharing a new address each time. The change extends the existing support for legacy and SegWit addresses to also handle Taproot addresses, and refactors the code to choose address types more cleanly. There is no indication in the commit that this fixes a security vulnerability.

This commit fixes how Stack Wallet handles Bitcoin PayNym notification transactions when the wallet has taproot-style coins. PayNym notification transactions need the sender's raw public key to set up a private payment channel. Taproot inputs hide that raw public key, so the previous code could crash or fail to parse/build notifications when taproot coins were selected. The fix avoids picking taproot coins for notification transactions and gracefully returns null instead of crashing when a taproot input is encountered during parsing.

This commit changes how the 'Create Masternode' screen appears on desktop computers. Previously it was pushed as a full page after confirming a transaction; now it is shown as a popup dialog on desktop, while mobile behavior stays the same. It also adds a safety check that the screen context is still valid before showing the dialog. There is no clear security problem here—this looks like a normal user-interface fix.