{"id":70229,"date":"2026-08-10T22:25:08","date_gmt":"2026-08-10T19:25:08","guid":{"rendered":"https:\/\/lwallet.com.ua\/?p=70229"},"modified":"2026-08-10T22:25:08","modified_gmt":"2026-08-10T19:25:08","slug":"why-does-your-bitcoin-address-keep-changing","status":"publish","type":"post","link":"https:\/\/lwallet.com.ua\/en\/why-does-your-bitcoin-address-keep-changing\/","title":{"rendered":"#Tutorial. Why does your Bitcoin address keep changing?"},"content":{"rendered":"\r\n\r\n\r\n

Why does your Bitcoin address keep changing?<\/strong> This is a common situation: you receive bitcoin into your wallet and everything arrives as expected. A week later, you open the wallet to receive more and see a completely different address. The old one is no longer on the screen. For many people, the first reaction is the same: something must be broken, or the funds might go to the wrong place.<\/p>\r\n\r\n\r\n\r\n

Nothing is broken.<\/strong> In modern HD wallets, address rotation is normal behavior<\/strong> built into the Bitcoin wallet standards. But \u201cdon\u2019t worry, it\u2019s normal\u201d does not explain much. Below, we go all the way down to the protocol level: how addresses relate to keys, why a wallet can derive so many of them, where change goes, how blockchain analysts link addresses together, what the gap limit is, and what to do if you genuinely need one permanent address.<\/p>\r\n\r\n\r\n\r\n

This guide is not tied to any particular wallet or manufacturer. The underlying mechanics come from Bitcoin standards<\/strong>, although the exact moment an app displays a new address depends on the wallet implementation.<\/p>\r\n\r\n\r\n\r\n

The short answer<\/h2>\r\n\r\n\r\n\r\n

If you came here from search and only want to make sure your funds are safe:<\/p>\r\n\r\n\r\n\r\n

    \r\n
  • An HD wallet does not rely on a single address.<\/strong> It uses a deterministic tree of keys derived from one seed. A single seed can produce a practically unlimited number of addresses.<\/li>\r\n\r\n\r\n\r\n
  • After a receiving address has been used<\/strong>, the wallet will usually offer the next unused address. Some wallets can generate a new one earlier, for example when you explicitly request another address.<\/li>\r\n\r\n\r\n\r\n
  • All previous addresses<\/strong> derived from the same seed and derivation path remain under your wallet\u2019s control. Bitcoin addresses do not expire, so funds sent to an old address do not disappear.<\/li>\r\n\r\n\r\n\r\n
  • The balance you see<\/strong> is the total value of the coins controlled across the entire account, not the balance of one address.<\/li>\r\n\r\n\r\n\r\n
  • If a transaction you sent shows a second output going to an unfamiliar address<\/strong>, that output is very often change returning to your own wallet.<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n

    Now for the mechanics. This is worth understanding once, because it answers a surprising number of practical questions about privacy, wallet recovery, and withdrawals from exchanges.<\/p>\r\n\r\n\r\n\r\n

    What a Bitcoin address actually is<\/h2>\r\n\r\n\r\n
    \r\n
    \"Diagram<\/figure>\r\n<\/div>\r\n\r\n\r\n

    The most important point in this entire topic is that the Bitcoin protocol itself does not really have a concept called an \u201caddress.\u201d<\/strong> Blocks contain spending conditions in the form of scripts, or scriptPubKeys. An address is a human-readable representation of such a script: a wallet-level wrapper that is easier for people to copy and share. There is no global registry of Bitcoin addresses, and nothing about your address appears on-chain until it is actually used in a transaction.<\/p>\r\n\r\n\r\n\r\n

    That leads to an important consequence: a Bitcoin address does not need to be \u201ccreated\u201d or \u201cregistered.\u201d<\/strong> A wallet can calculate addresses offline, by the millions, without an internet connection or permission from anyone.<\/p>\r\n\r\n\r\n\r\n

    From a private key to an address<\/h3>\r\n\r\n\r\n\r\n

    The chain of transformations looks like this:<\/p>\r\n\r\n\r\n\r\n

      \r\n
    1. A private key is a secret number within the valid range of the secp256k1 curve, commonly represented as a 256-bit value.<\/li>\r\n\r\n\r\n\r\n
    2. The public key is calculated from the private key using the secp256k1 elliptic curve. Recovering the private key from the public key is considered computationally infeasible on classical computers.<\/li>\r\n\r\n\r\n\r\n
    3. What happens next depends on the output type. P2PKH and P2WPKH use HASH160 of the public key \u2014 RIPEMD-160(SHA-256(pubkey)). P2SH and P2WSH hash a script, while P2TR uses a tweaked x-only public key.<\/li>\r\n\r\n\r\n\r\n
    4. The result is then encoded into a human-readable address with a checksum: Base58Check for older formats, Bech32 for SegWit v0, and Bech32m<\/strong> for witness versions 1 and above, including Taproot.<\/li>\r\n<\/ol>\r\n\r\n\r\n\r\n

      The key detail is that not every Bitcoin address commits to the same kind of object<\/strong>. P2PKH and P2WPKH contain a public-key hash, P2SH contains the hash of a redeem script, and P2TR commits directly to an x-only output key. This distinction matters later when we discuss address reuse and public-key exposure.<\/p>\r\n\r\n\r\n\r\n

      Why addresses have checksums<\/h3>\r\n\r\n\r\n\r\n

      An address is a string people copy, scan from a QR code, and sometimes type manually. Without validation, a typo could result in an invalid or unintended destination. Bitcoin address formats therefore include checksums, which means wallets can reject most accidental typing errors<\/strong> before a transaction is created or signed.<\/p>\r\n\r\n\r\n\r\n

      Base58Check, used by addresses beginning with 1 and 3, uses a checksum based on double SHA-256 and a reduced alphabet that excludes 0, O, I, and l because those characters are easy to confuse.<\/p>\r\n\r\n\r\n\r\n

      Bech32 (BIP173) uses a BCH code and provides strong guarantees for detecting common errors. Bitcoin addresses in this format are normally written in lowercase, and mixed case is invalid. Implementations can also use the checksum structure to help locate an error, although automatically \u201ccorrecting\u201d an address is unsafe.<\/p>\r\n\r\n\r\n\r\n

      Two separate ideas are easy to mix up here. The bc1q<\/strong> prefix corresponds to witness version 0, while bc1p<\/strong> corresponds to witness version 1, which is used by Taproot. Separately, the original Bech32 design was found to have an unexpected weakness: under specific conditions, inserting or deleting certain numbers of \u201cq\u201d characters immediately before a final \u201cp\u201d could leave the checksum valid. This was not a practical problem for SegWit v0 because of its length restrictions, but future witness versions needed a fix.<\/p>\r\n\r\n\r\n\r\n

      That is why BIP350 introduced Bech32m<\/strong>, which changes the constant used in the final checksum calculation. Witness version 0 remains on Bech32, while witness versions 1 and above use Bech32m<\/strong>. Older software that understands only Bech32 should reject such an address as invalid rather than silently interpret it as a normal SegWit v0 address.<\/p>\r\n\r\n\r\n

      [vc_message color=”warning” message_box_style=”classic” message_box_color=”alert-warning” style=”rounded”] If a service refuses your bc1p<\/strong> address, the problem may be an outdated validator on the service side. Third-party online address validators can also return false negatives if they do not support Bech32m<\/strong>. [\/vc_message]<\/p>\n\r\n\r\n\r\n

      One seed, countless addresses: BIP32<\/h2>\r\n\r\n\r\n
      \r\n
      \"BIP32<\/figure>\r\n<\/div>\r\n\r\n\r\n

      Early wallets often stored a collection of unrelated private keys. That meant a backup became outdated every time the wallet generated a new key. People really did lose coins this way: the backup existed, but it had been made before the key controlling a later receiving address was created.<\/p>\r\n\r\n\r\n\r\n

      In 2012, Pieter Wuille proposed BIP32, the standard for hierarchical deterministic wallets, or HD wallets, which solved this problem.<\/p>\r\n\r\n\r\n\r\n

      How the key tree is built<\/h3>\r\n\r\n\r\n\r\n

      If you use a BIP39 seed phrase, it is first converted into a binary seed. BIP32 then uses HMAC-SHA512 to generate a master private key and a chain code. From there, the child-key derivation function takes a parent key, its chain code, and an index to create the next node in the tree.<\/p>\r\n\r\n\r\n\r\n

      The tree is deterministic<\/strong>: the same seed, used with the same derivation rules, produces the same keys in the same order. For a standard single-sig HD wallet, the seed phrase is the foundation of recovery, but you still need the correct script type and derivation path. More complex setups, such as multisig wallets, may also require additional information.<\/p>\r\n\r\n\r\n\r\n

      Hardened vs non-hardened derivation<\/h3>\r\n\r\n\r\n\r\n

      This distinction is essential for understanding xpubs \u2014 extended public keys used to derive account addresses \u2014 as well as watch-only wallets and some of the risks that come with them.<\/p>\r\n\r\n\r\n\r\n

      There are two child-key derivation modes. With normal, or non-hardened, derivation, a child public key can be calculated from the parent extended public key without access to the private key. Hardened derivation uses indexes from 2\u00b3\u00b9 upward, usually written with an apostrophe or the letter h, and requires the parent private key.<\/p>\r\n\r\n\r\n\r\n

      The practical difference is important. Non-hardened derivation makes a watch-only wallet<\/strong> possible: an app with the extended public key can derive addresses and monitor balances, but it cannot sign transactions. Hardened derivation prevents someone from recovering a parent or sibling private key from a single hardened child private key.<\/p>\r\n\r\n\r\n

      [vc_message color=”warning” message_box_style=”classic” message_box_color=”alert-warning” style=”rounded”] BIP32 has an important property: if an attacker has your account-level xpub and also obtains one corresponding non-hardened child private key, they can calculate the parent private key. That is why an xpub should not be treated as harmless public information<\/strong>. [\/vc_message]<\/p>\n\r\n\r\n\r\n

      Derivation paths: how a wallet finds the right branch<\/h2>\r\n\r\n\r\n\r\n

      The BIP32 tree by itself does not specify where \u201cyour\u201d addresses are located. That structure is defined by BIP44, together with BIP43, which introduced the purpose field. A typical path looks like this:<\/p>\r\n\r\n\r\n\r\n

      m \/ purpose' \/ coin_type' \/ account' \/ change \/ address_index<\/code><\/pre>\r\n\r\n\r\n\r\n
      The first three levels are hardened; the last two are not.<\/strong> This is deliberate: it allows an account-level extended public key to derive every receiving address and every change address in that account without exposing any private key.<\/p>\r\n\r\n\r\n\r\n
      Breaking down the path<\/h3>\r\n\r\n\r\n\r\n
        \r\n
      • purpose:<\/strong> which address standard is being used. 44 is legacy (BIP44), 49 is nested SegWit (BIP49), 84 is Native SegWit (BIP84), and 86 is Taproot (BIP86).<\/li>\r\n\r\n\r\n\r\n
      • coin_type:<\/strong> the asset identifier from the SLIP-44 registry. Bitcoin uses 0; Bitcoin test networks use 1. Different assets live on separate branches so their key spaces do not overlap.<\/li>\r\n\r\n\r\n\r\n
      • account:<\/strong> the account number within the asset. Think of it as a logical sub-wallet with its own history and balance.<\/li>\r\n\r\n\r\n\r\n
      • change:<\/strong> 0 for the external chain \u2014 addresses you give to other people \u2014 and 1 for the internal chain, which is normally used for change.<\/li>\r\n\r\n\r\n\r\n
      • address_index:<\/strong> the sequential address number within that chain, starting at 0.<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n
        For example, m\/84’\/0’\/0’\/0\/5 is the sixth receiving address, index 5, of the first Native SegWit Bitcoin account.<\/p>\r\n\r\n\r\n\r\n
        One seed can contain several account types<\/h3>\r\n\r\n\r\n\r\n
        Because purpose is part of the derivation path, the same seed can produce separate address sets for legacy, nested SegWit, Native SegWit, and Taproot. These are not \u201cdifferent ways of writing the same address.\u201d They are different branches with different keys and separate UTXOs. They are not independent from a backup perspective, however: compromising the master seed compromises all of those branches.<\/p>\r\n\r\n\r\n
        [vc_message color=”warning” message_box_style=”classic” message_box_color=”alert-warning” style=”rounded”] After restoring a wallet, a zero balance often means the wallet is looking at the wrong derivation path or script type<\/strong>, not that the coins are gone. If you still have the seed but cannot see the funds, check which account type the original wallet was using. [\/vc_message]<\/p>\n\r\n\r\n\r\n
        UTXOs: why change goes to a new address<\/h2>\r\n\r\n\r\n
        \r\n
        \"Bitcoin<\/figure>\r\n<\/div>\r\n\r\n\r\n
        This is the second, much less obvious reason new addresses appear. It tends to scare people more because, in a block explorer, it can look as though part of the money has disappeared.<\/p>\r\n\r\n\r\n\r\n
        What is a UTXO?<\/h3>\r\n\r\n\r\n\r\n
        Bitcoin does not use account balances.<\/strong> Instead, it tracks unspent transaction outputs, or UTXOs. A UTXO is an indivisible chunk of bitcoin locked by a set of spending conditions. Your \u201cbalance\u201d is the total value of all UTXOs<\/strong> your wallet can spend.<\/p>\r\n\r\n\r\n\r\n
        The closest everyday analogy is physical cash. You do not have one abstract number in your pocket; you have individual banknotes. You cannot cut a banknote in half and spend only part of it.<\/p>\r\n\r\n\r\n\r\n
        Coin selection and the change output<\/h3>\r\n\r\n\r\n\r\n
        When you make a payment, the wallet performs coin selection: it chooses enough of your UTXOs to cover the payment amount plus the transaction fee. A UTXO cannot be spent partially; it is consumed in full.<\/strong><\/p>\r\n\r\n\r\n\r\n
        If the wallet spends a 0.1 BTC UTXO to send 0.03 BTC, the transaction consumes the entire 0.1 BTC input and will usually create at least two outputs: 0.03 BTC to the recipient, and the remaining amount, minus the fee, back to your wallet. That remainder is the change.<\/strong> A modern HD wallet will usually send it to a fresh address on the internal chain.<\/p>\r\n\r\n\r\n\r\n
        For a Taproot account, for example, receiving addresses might follow m\/86’\/0’\/0’\/0\/0, then \/0\/1, \/0\/2, while change returns to m\/86’\/0’\/0’\/1\/0, then \/1\/1, \/1\/2. One tree, two separate branches.<\/p>\r\n\r\n\r\n\r\n
        A transaction does not always have exactly two outputs. If the potential change amount is too small, a wallet may choose not to create a separate change output at all, effectively adding that difference to the fee. Some coin-selection algorithms, including Branch and Bound in Bitcoin Core, deliberately search for no-change transactions when possible. That can be useful for both privacy and future fee efficiency.<\/p>\r\n\r\n\r\n
        [vc_message color=”warning” message_box_style=”classic” message_box_color=”alert-warning” style=”rounded”] Change addresses normally do not appear in the regular Receive screen.<\/strong> If a transaction you sent shows an unfamiliar output, first check whether your wallet balance decreased by the payment amount plus the fee. If it did, that is a strong sign the second output is your change. [\/vc_message]<\/p>\n\r\n\r\n\r\n
        So why does the address change? Three different reasons<\/h2>\r\n\r\n\r\n\r\n
        The confusion comes from treating three separate mechanisms as if they were the same thing:<\/p>\r\n\r\n\r\n\r\n
          \r\n
        1. You receive coins and the wallet may move on to the next address on the external chain (change = 0).<\/strong> The exact timing depends on the software. Some wallets keep displaying the current unused address, while others let you generate another one manually before any funds arrive.<\/li>\r\n\r\n\r\n\r\n
        2. You send coins and the change returns to an address on the internal chain (change = 1).<\/strong> The normal Receive interface usually does not show these addresses.<\/li>\r\n\r\n\r\n\r\n
        3. You are looking at a different account type: legacy, nested SegWit, Native SegWit, or Taproot.<\/strong> Each type uses its own derivation branch and has its own set of UTXOs.<\/li>\r\n<\/ol>\r\n\r\n\r\n\r\n
          Do old Bitcoin addresses still work?<\/h2>\r\n\r\n\r\n\r\n
          Yes. A Bitcoin address has no built-in expiration date<\/strong> and there is no revocation mechanism. As long as your wallet still has the private key or script data required to spend the corresponding output, funds sent to an old address remain spendable exactly as before.<\/p>\r\n\r\n\r\n\r\n
          The real edge case is not that an address \u201cexpires,\u201d but that a wallet may fail to discover a far-away derived address when you restore the seed.<\/p>\r\n\r\n\r\n\r\n
          Gap limit: how far a wallet scans during recovery<\/h3>\r\n\r\n\r\n\r\n
          When you restore a seed in a new wallet, the software does not know how many addresses you previously used. It scans them in order and eventually needs a stopping point because the derivation tree is effectively endless.<\/p>\r\n\r\n\r\n\r\n
          BIP44 defines an address gap limit: if discovery encounters 20 consecutive unused addresses<\/strong> on the external chain, the standard discovery algorithm may stop scanning. \u201cUsed\u201d is determined from transaction history, not from the current balance.<\/p>\r\n\r\n\r\n\r\n
          BIP44 applies a similar idea at the account level. During account discovery, software stops looking for later accounts once the previous account has no transaction history. The standard also recommends that wallets not create another account while the previous one remains unused.<\/p>\r\n\r\n\r\n\r\n
          In the BIP44 account-discovery procedure, the wallet scans the external chain because the internal chain is intended for change generated by activity in the same account. Actual recovery behavior and keypool sizes can vary between wallet implementations.<\/p>\r\n\r\n\r\n\r\n
          The problematic case looks like this: you generate many receiving addresses in a row without using the earlier ones, then receive funds at an address far beyond the standard gap limit. During recovery, some wallets may stop scanning before they reach that address and temporarily fail to show the funds.<\/p>\r\n\r\n\r\n\r\n
          The coins are not lost.<\/strong> They are still on the blockchain and can reappear after increasing the gap limit or performing the correct rescan in software that supports it. The practical rule is simple: do not generate dozens of receiving addresses \u201cjust in case\u201d unless you actually need them.<\/p>\r\n\r\n\r\n\r\n
          Why an xpub alone may not be enough: output descriptors<\/h3>\r\n\r\n\r\n\r\n
          An extended public key (xpub) does not always describe the full wallet context by itself. You also need to know its origin or derivation path and the script type. The same derived public keys can be wrapped in different output types, so one bare xpub string<\/strong> may not be enough to reconstruct the wallet metadata reliably years later.<\/p>\r\n\r\n\r\n\r\n
          Wallet developers initially worked around this with SLIP-132 prefixes such as ypub and zpub, which hint at the intended address type. This is not a Bitcoin consensus standard and support is inconsistent, which is why users sometimes run into situations where one wallet exports zpub while another service asks for xpub.<\/p>\r\n\r\n\r\n\r\n
          The cleaner solution is output descriptors, defined by BIP380 and related standards. A descriptor is a string that explicitly specifies the script type, master-key fingerprint, derivation path, extended key, and its own checksum. A simplified example looks like this:<\/p>\r\n\r\n\r\n\r\n
          wpkh([d34db33f\/84h\/0h\/0h]xpub6...\/0\/*)#checksum<\/code><\/pre>\r\n\r\n\r\n\r\n
          Output descriptor support appeared in Bitcoin Core 0.17, and descriptor wallets became the default wallet type in Bitcoin Core 23.0. If your wallet can export a descriptor, it is useful to keep it as additional documentation of the wallet structure. But a descriptor containing an xpub does not replace the seed or private keys<\/strong> and, by itself, cannot spend funds.<\/p>\r\n\r\n\r\n\r\n
          Why Bitcoin wallets rotate addresses: privacy<\/h2>\r\n\r\n\r\n
          \r\n
          \"Bitcoin<\/figure>\r\n<\/div>\r\n\r\n\r\n
          Address rotation is not just a cosmetic wallet feature. Bitcoin is public<\/strong>: every transaction remains visible to anyone. The privacy question is how easily those transactions can be linked together and then linked to you.<\/p>\r\n\r\n\r\n\r\n
          What address reuse reveals<\/h3>\r\n\r\n\r\n\r\n
          If you use one address for every payment you receive<\/strong>, anyone who knows that address can directly see every UTXO and transaction associated with it in a block explorer. Instead of exposing one payment, you expose a much larger slice of your financial history.<\/p>\r\n\r\n\r\n\r\n
          A fresh address<\/strong> has no previous history of its own, so it does not directly reveal your other incoming payments. This improves privacy, although blockchain analysis can still connect separate addresses through behavioral and transaction-level heuristics.<\/p>\r\n\r\n\r\n\r\n
          The common-input-ownership heuristic<\/h3>\r\n\r\n\r\n\r\n
          This is one of the main tools used in blockchain analysis. If several addresses appear as inputs to the same transaction, an analyst may assume they belong to the same owner, because spending all of those inputs normally requires access to all of the corresponding private keys.<\/p>\r\n\r\n\r\n\r\n
          The assumption is probabilistic, not absolute. CoinJoin and other collaborative transactions can break it because their inputs belong to multiple unrelated participants. For ordinary single-user transactions, however, the heuristic often remains useful.<\/p>\r\n\r\n\r\n
          [vc_message color=”warning” message_box_style=”classic” message_box_color=”alert-warning” style=”rounded”] Address rotation does not preserve privacy if you later combine those UTXOs in a normal transaction.<\/strong> Consolidation creates a strong on-chain link between the inputs involved. [\/vc_message]<\/p>\n\r\n\r\n\r\n
          How analysts identify change outputs<\/h3>\r\n\r\n\r\n\r\n
          This is another major technique in blockchain forensics. In a transaction with two outputs, the protocol does not label one \u201cpayment\u201d and the other \u201cchange.\u201d They look the same on-chain. Analysts try to distinguish them using a collection of heuristics:<\/p>\r\n\r\n\r\n\r\n
            \r\n
          • Matching script types.<\/strong> Wallets often send change back to the same script type they are spending from. If every input is P2WPKH and one output is P2WPKH while the other is P2TR (Taproot), the P2WPKH output may be more likely to be change.<\/li>\r\n\r\n\r\n\r\n
          • Round amounts.<\/strong> A payment of exactly 0.05 BTC next to an output of 0.03847291 BTC makes the round output look more like the intended payment and the irregular amount more like change.<\/li>\r\n\r\n\r\n\r\n
          • A fresh address.<\/strong> An output to an address with no previous history may be more likely to be a new change address generated by the sender\u2019s HD wallet.<\/li>\r\n\r\n\r\n\r\n
          • An unnecessary input.<\/strong> If the transaction could have been funded with fewer inputs, the extra input can sometimes provide clues about which output is change.<\/li>\r\n\r\n\r\n\r\n
          • RBF replacements.<\/strong> Replace-by-Fee allows a transaction to be reissued with a higher fee. Many wallets fund that fee increase by reducing the change output, so comparing multiple versions of an RBF transaction can help identify which output is change. This is not universal across every wallet implementation.<\/li>\r\n\r\n\r\n\r\n
          • Wallet fingerprints.<\/strong> Different wallets sort outputs differently, set nLockTime in characteristic ways, and choose different script types. These patterns can help analysts identify the software and recognize later transactions created by the same wallet.<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n
            Each heuristic is uncertain on its own, but together they can produce high confidence. The result is often a so-called peeling chain: a long sequence in which smaller payments are \u201cpeeled off\u201d from a larger amount while the remainder keeps moving through new change addresses. This pattern is especially visible in large exchange, marketplace, and mining-pool flows.<\/p>\r\n\r\n\r\n\r\n
            Address rotation makes analysis harder, but it does not make you anonymous.<\/strong> With additional information \u2014 for example, exchange records or later UTXO consolidation \u2014 an analyst may still reconnect separate addresses.<\/p>\r\n\r\n\r\n\r\n
            An xpub defeats address rotation for the observer who has it<\/h3>\r\n\r\n\r\n\r\n
            An account-level xpub in a standard HD setup can derive all non-hardened receiving and change addresses for that account. Anyone who obtains that xpub together with the correct derivation context can monitor the entire account history and balance.<\/p>\r\n\r\n\r\n\r\n
            An xpub alone cannot spend your bitcoin<\/strong> because it contains no private keys. The dangerous exception is when the corresponding xpub leaks together with even one non-hardened child private key. Under BIP32, that combination can be used to recover the parent private key.<\/p>\r\n\r\n\r\n\r\n
            Third-party services sometimes request an xpub for watch-only monitoring or accounting. That is a legitimate use case, but only share it with someone you are comfortable giving a complete view of that account. A better approach is to create a separate account<\/strong> specifically for that purpose.<\/p>\r\n\r\n\r\n\r\n
            Public-key exposure and the Taproot exception<\/h2>\r\n\r\n\r\n\r\n
            This is a more technical argument, and it is often oversimplified in popular explanations.<\/p>\r\n\r\n\r\n\r\n
            In P2PKH (1\u2026) and P2WPKH (bc1q<\/strong>\u2026), the output commits to a hash of the public key, so the public key itself becomes visible only when the output is spent, where it appears in the scriptSig or witness next to the signature. P2SH (3\u2026) instead commits to the hash of a redeem script, so the exact behavior depends on the script being wrapped.<\/p>\r\n\r\n\r\n\r\n
            For P2PKH and P2WPKH, receiving new funds to an address that has already been spent from means those new coins are again tied to a public key that has already been revealed on-chain. This does not create a practical theft risk today, but it removes one layer of \u201cpublic key hidden behind a hash.\u201d<\/p>\r\n\r\n\r\n\r\n
            The security of these outputs relies on the hardness of the elliptic-curve discrete logarithm problem on secp256k1. Classical computers do not have a practical way to recover the private key from the public key. The quantum-computing concern remains theoretical: no sufficiently powerful quantum computer capable of attacking these keys in practice exists today.<\/p>\r\n\r\n\r\n
            [vc_message color=”warning” message_box_style=”classic” message_box_color=”alert-warning” style=”rounded”] This \u201cpublic key hidden behind a hash\u201d argument does not apply to Taproot.<\/strong> A P2TR output contains the tweaked x-only output key directly. Rotating Taproot addresses is therefore primarily useful for privacy and avoiding address reuse, not for hiding the output key until the coins are spent. [\/vc_message]<\/p>\n\r\n\r\n\r\n
            For ordinary users, this is not a reason to avoid Taproot. Address rotation still helps against simple clustering in both cases, and Taproot brings its own advantages. It is simply inaccurate to present delayed public-key exposure as a universal argument against address reuse.<\/p>\r\n\r\n\r\n\r\n
            Why Ethereum usually keeps one address per account<\/h2>\r\n\r\n\r\n
            \r\n
            \"Comparison<\/figure>\r\n<\/div>\r\n\r\n\r\n
            Bitcoin and several Bitcoin-family networks, including Litecoin, Bitcoin Cash, Dogecoin, and Dash, use the UTXO model. Cardano uses the related eUTXO model, and transparent Zcash transactions also use a UTXO-style design. Ethereum, Solana, Tron, Cosmos, and Polkadot use account-based models.<\/p>\r\n\r\n\r\n\r\n
            In an account model, one specific address represents one account<\/strong>. There is no separate change output, and the balance is part of the network\u2019s account state. One seed can still derive many separate accounts and addresses, of course; the difference is that the wallet does not automatically rotate through addresses in the same way a Bitcoin HD wallet does.<\/p>\r\n\r\n\r\n\r\n
            The privacy consequence is straightforward. If you receive USDT at the same address for two years, anyone who knows that address can immediately see the complete history of incoming and outgoing activity associated with it, along with the current balance. No clustering heuristic is required.<\/p>\r\n\r\n\r\n\r\n
            Bitcoin makes this kind of direct tracking harder by rotating addresses by default. In account-based systems, separating activity usually means creating different accounts manually: one for exchange withdrawals, one for receiving payments, and another for long-term storage. That is a practical reason not to keep your main stablecoin balance on the same address you post in chats or public profiles.<\/p>\r\n\r\n\r\n\r\n
            What if you need one permanent Bitcoin address?<\/h2>\r\n\r\n\r\n\r\n
            Sometimes address rotation genuinely gets in the way: an exchange withdrawal whitelist, a mining-pool payout address, or a donation address posted publicly. There are several ways to handle this, with different trade-offs and levels of wallet support.<\/p>\r\n\r\n\r\n\r\n
            Intentional address reuse<\/h3>\r\n\r\n\r\n\r\n
            This is the simplest option, and it is not always a bad one. If you are withdrawing from an exchange that has already completed KYC on you, you do not have privacy from that exchange anyway. Reusing one whitelisted address for regular withdrawals from that specific exchange can be a reasonable compromise.<\/p>\r\n\r\n\r\n\r\n
            The minimum privacy hygiene is to create a separate account<\/strong> for that flow \u2014 not just a separate address, but an account with its own xpub \u2014 and avoid spending those coins together with your other UTXOs in the same transaction.<\/p>\r\n\r\n\r\n\r\n
            BIP47: reusable payment codes<\/h3>\r\n\r\n\r\n\r\n
            The idea is that you publish one static payment code. The sender uses a one-time notification transaction to establish a shared secret with you, and future payments derive new addresses from that relationship. On-chain, the payments appear as normal outputs to different addresses.<\/p>\r\n\r\n\r\n\r\n
            BIP47 never achieved broad wallet support. Its most visible implementation was PayNym in Samourai Wallet, and after that project shut down in 2024, parts of the PayNym infrastructure became unavailable. Before relying on BIP47, check the current support status in the wallet you plan to use. The design also requires a notification transaction before the first payment, which adds both a fee and an on-chain footprint.<\/p>\r\n\r\n\r\n\r\n
            Silent Payments (BIP352)<\/h3>\r\n\r\n\r\n\r\n
            Silent Payments let you publish one reusable payment address<\/strong> beginning with sp1. Each payment to it creates a unique Taproot output, while the protocol avoids leaving a direct on-chain link between the published Silent Payment address and the individual outputs you receive. No separate notification transaction is required before the first payment.<\/p>\r\n\r\n\r\n\r\n
            At a high level, the sender calculates a shared secret from the aggregated public keys of the transaction inputs and the scan key encoded in your address. The recipient discovers payments by scanning transactions and performing the corresponding ECDH calculation \u2014 elliptic-curve Diffie\u2013Hellman, where two parties derive the same secret without transmitting that secret over the network.<\/p>\r\n\r\n\r\n\r\n
            The trade-off is scanning. The recipient must inspect eligible transactions and perform the calculations needed to detect their payments. That is more practical for a full node, while efficient light-client support remains a separate engineering challenge. Silent Payment outputs themselves use P2TR.<\/p>\r\n\r\n\r\n\r\n
            As of August 2026, BIP352 is at version 1.1.1<\/strong>, dated April 16, 2026. Sparrow Wallet supports sending to Silent Payment addresses from version 2.3.0 and receiving from version 2.5.0, including support for air-gapped hardware signers. Bitcoin Core integration is still ongoing work; full wallet-level send and receive functionality is not yet a completed feature in a released version.<\/p>\r\n\r\n\r\n
            [vc_message color=”warning” message_box_style=”classic” message_box_color=”alert-warning” style=”rounded”] A standard mainnet Silent Payment address is much longer than a normal Taproot address: BIP352 states that it requires at least 117 characters<\/strong>. Before publishing one, make sure the people or services that normally pay you actually support Silent Payments. [\/vc_message]<\/p>\n\r\n\r\n\r\n
            Lightning<\/h3>\r\n\r\n\r\n\r\n
            If the goal is to receive recurring payments rather than store everything directly on-chain, Lightning can remove part of the problem. BOLT12 defines reusable offers: a recipient can publish one offer, and a payer can use it to obtain the invoice needed for a specific payment. This is a different layer with its own trade-offs around liquidity, availability, and backups, so it is not a replacement for cold on-chain storage.<\/p>\r\n\r\n\r\n\r\n
            When changing Bitcoin addresses becomes inconvenient<\/h2>\r\n\r\n\r\n
            \r\n
            \"Examples<\/figure>\r\n<\/div>\r\n\r\n\r\n
            Exchange whitelists and wallet verification<\/h3>\r\n\r\n\r\n\r\n
            Many exchanges let you add withdrawal addresses to a whitelist and then impose a waiting period before the first withdrawal. If your wallet is already showing a new receiving address by then, it can be tempting to keep updating the whitelist. In this situation, intentionally reusing one verified address for that particular exchange can be acceptable as long as you understand the privacy trade-off.<\/p>\r\n\r\n\r\n\r\n
            Some ownership-verification procedures are also tied to a specific address. If the address changes between verification and the transaction, the process can fail. When possible, complete the verification and the transaction in the same session instead of leaving a long gap between them.<\/p>\r\n\r\n\r\n\r\n
            Mining pools and services with fixed payout addresses<\/h3>\r\n\r\n\r\n\r\n
            Mining pools, staking services, and some payment processors allow only one payout address. In that case there may be no choice. The same solution applies: use a separate account<\/strong> for that flow so repeated address use does not expose the rest of your wallet activity.<\/p>\r\n\r\n\r\n\r\n
            Donations and public payment addresses<\/h3>\r\n\r\n\r\n\r\n
            A publicly posted donation address will be reused by definition, and from a privacy perspective that is one of the worst cases because the address is publicly tied to an identity. This is common with fundraising and volunteer wallets: once an address is posted on social media, it may remain permanently associated with the person or organization collecting funds. Silent Payments or BIP47 are especially valuable here. If neither is practical, the minimum is a separate account<\/strong> and no consolidation of those coins with your main holdings.<\/p>\r\n\r\n\r\n\r\n
            Accounting and watch-only access<\/h3>\r\n\r\n\r\n\r\n
            If someone needs read-only access to a balance, do not send them addresses one by one. Create a separate account<\/strong> and share the descriptor or xpub for that account only. They will get a complete and continuously updated view of the relevant activity without learning anything about your other accounts.<\/p>\r\n\r\n\r\n\r\n
            Common mistakes<\/h2>\r\n\r\n\r\n\r\n