Receiving Bitcoin Into SSP

Receiving Bitcoin sounds simple — someone sends you coins, they appear in your wallet. But the details matter, especially in a 2-of-2 multisig wallet like SSP. Knowing how to receive Bitcoin in a wallet correctly is what separates a smooth deposit from a stuck transaction or, worse, a permanent loss. This guide walks through the address SSP gives you, how to share it safely, what change addresses are, and how to verify an incoming payment on your own.

If you have already worked through Bitcoin in SSP, the canonical overview of self-custody with SSP, this article is the practical companion: receiving is the other half of the transaction skill set you started building in sending Bitcoin with SSP.

The address SSP gives you

When you tap "Receive" on the Bitcoin asset in SSP, the wallet generates a Bitcoin address for you. That address is not arbitrary — it encodes the rules under which the received coins can later be spent.

SSP is a 2-of-2 multisig wallet. Your funds are protected by two keys: one held on your phone in the SSP app, and one held on a second device through the SSP Key companion app. Spending requires both. Because of this, the address SSP shows you is a native SegWit P2WSH multisig address — a pay-to-witness-script-hash address. It starts with bc1q and is longer than a single-signature bc1q address because it commits to a 2-of-2 script rather than one public key.

That address is derived jointly from both of your keys. SSP follows the BIP-48 multisig derivation standard, which defines how multisig wallets derive a shared address tree from multiple extended public keys. Neither key alone can produce the address; both must contribute their public key at the same derivation path. This is why an address from SSP is genuinely a 2-of-2 address and not just a normal address with extra steps.

Getting and sharing a receive address

In SSP, open the Bitcoin asset and choose Receive. You will see the address as text and as a QR code. To get paid, give the sender either form:

• The QR code for an in-person transfer or a sender on another device. They scan it; their wallet fills in the address.
• The text string for a transfer arranged remotely. Copy it from SSP rather than typing it — Bitcoin addresses are long, and a typo usually produces an invalid address (the sender's wallet rejects it) but occasionally produces a different valid address belonging to no one you know.

A receive address is not a secret. Sharing it does not expose your funds or your keys; an address only lets someone send coins to you. The privacy concern is different: an address is a public label, and anyone who knows it can watch its balance on a block explorer. That is the reasoning behind fresh addresses, covered next.

When you ask for a payment, confirm the address out-of-band when the amount is significant — read the first and last few characters back to the sender over a separate channel. Address-swapping malware exists; a quick verbal check defeats it.

Change addresses and why a fresh address appears

Bitcoin does not have account balances the way a bank does. Your wallet holds discrete chunks of coin called UTXOs — unspent transaction outputs. When you spend, you consume whole UTXOs and the network returns the difference to you as a new UTXO. That returned difference is change, and it lands on a fresh address your wallet controls — a change address.

This is normal and automatic. After you send Bitcoin from SSP, you may notice the "Receive" screen now shows a different address than before. Nothing went wrong. SSP rotates addresses so each incoming payment and each change output uses a new one. The old address still belongs to you and any coins already sent there are still yours; the wallet simply prefers not to reuse it.

Reusing one address for every payment is a real privacy weakness. It ties all your transactions to a single public label, letting an observer reconstruct your balance and payment history. Letting SSP hand you a fresh address each time keeps your activity harder to correlate. You never have to manage this manually — but if you saved an address and the screen later shows a different one, this is why.

Verifying an incoming transaction

You do not have to take SSP's word that a payment arrived. Bitcoin is a public ledger, and you can confirm any incoming transaction yourself on a block explorer — this is watch-only verification: looking up an address or transaction without exposing any key.

Paste your receive address into a reputable block explorer and you will see transactions paying to it. A new payment first appears in the mempool — the set of transactions broadcast to the network but not yet included in a block. A mempool transaction is real but not yet final.

Once a miner includes the transaction in a block, it has one confirmation. Each subsequent block adds another. The confirmation count is how deeply buried the transaction is, and depth is what makes it irreversible: reversing a confirmed transaction would mean rewriting blocks, which gets exponentially harder with each one added.

A common rule of thumb is to treat a payment as settled after a few confirmations for ordinary amounts, and to wait longer for large sums. SSP shows you the confirmation status; the explorer lets you cross-check it independently.

Common pitfalls

• Treating a 0-confirmation transaction as final. A transaction sitting in the mempool can still be replaced — Bitcoin supports replace-by-fee (RBF), and an unconfirmed payment can be bumped or, in adversarial cases, swapped. For anything that matters, wait for confirmations before releasing goods or considering the deal closed.
• Address reuse. Pasting an old address into a payment request still works, but it erodes your privacy. Use the address SSP currently shows you.
• Sending the wrong asset or network to a BTC address. A Bitcoin address only accepts Bitcoin on the Bitcoin network. Sending a token from another chain — or "BTC" on a different network — to your SSP Bitcoin address will not credit your wallet, and such transfers are often unrecoverable. Always match the asset and the network on both ends before sending.
• Underestimating fees on the sending side. If a payment is taking a long time to confirm, the cause is usually a low fee, not a problem with your address. Our Bitcoin fee strategy in SSP guide explains how to read mempool conditions and set an appropriate fee.

Wrapping up

Receiving Bitcoin into SSP comes down to four ideas: the address is a 2-of-2 P2WSH multisig address derived from both your keys via BIP-48; you can share it openly because it only accepts funds; a fresh change address appearing after you spend is expected behaviour, not a bug; and a payment is only as final as its confirmation count. Verify incoming funds on a block explorer, wait for confirmations on anything significant, and always match the asset and network. With those habits, receiving becomes the dependable, low-drama half of using Bitcoin in self-custody.