#Туторіал. Чому змінюється Bitcoin-адреса після переказу

Чому змінюється Bitcoin-адреса після переказу? Ситуація типова: Ви отримали біткоїн на свій гаманець, усе дійшло. Через тиждень заходите поповнити його ще раз і бачите зовсім іншу адресу. Стара зникла з екрана. Перша реакція у багатьох однакова: щось зламалося або гроші підуть не туди.

Нічого не зламалося. Для сучасних HD-гаманців ротація адрес — нормальна поведінка, закладена у стандартах Bitcoin. Але відповідь «не хвилюйтеся, це нормально» нічого не пояснює. Нижче розберемо тему до рівня протоколу: як адреси пов’язані з ключами, чому їх може бути дуже багато, куди повертається здача, як це аналізують блокчейн-аналітики, що таке gap limit і що робити, якщо Вам об’єктивно потрібна одна статична адреса.

Гайд не прив’язаний до конкретного гаманця чи виробника. Базова механіка визначається стандартами Bitcoin, хоча конкретний момент, коли застосунок показує нову адресу, залежить від реалізації гаманця.

Коротка відповідь

Якщо Ви прийшли із пошуку і Вам треба лише переконатися, що з грошима все гаразд:

• HD-гаманець працює не з однією адресою, а з детермінованим деревом ключів, яке виводиться із seed. З одного seed можна отримати практично необмежену кількість адрес.
• Після використання адреси для отримання коштів гаманець зазвичай пропонує наступну вільну адресу. Деякі гаманці можуть згенерувати нову адресу й раніше — наприклад, за окремою командою користувача.
• Усі попередні адреси, виведені з того самого seed і шляху деривації, залишаються під контролем Вашого гаманця. Терміну дії в Bitcoin-адрес немає, тому монети, надіслані на стару адресу, не зникають.
• Баланс, який Ви бачите, це сума монет на всіх адресах акаунта, а не на одній.
• Якщо після власної відправки в експлорері видно другий вихід на незнайому адресу, дуже часто це адреса здачі Вашого ж гаманця.

Далі механіка. Тут корисно розібратися один раз, бо на цьому знанні тримається половина практичних питань про приватність, відновлення гаманця і роботу з біржами.

Що таке Bitcoin-адреса технічно

Найважливіше для розуміння всієї теми: в самому протоколі Bitcoin поняття «адреса» не існує. У блоках лежать не адреси, а скрипти умов витрачання (scriptPubKey). Адреса — це людиночитабельне представлення такого скрипта, зручна обгортка рівня гаманця. У мережі немає жодного реєстру адрес: про Вашу адресу там не з’явиться жодного запису, поки на неї не прийде перша транзакція.

Звідси наслідок, який знімає більшість страхів: адресу не потрібно «створювати» чи «реєструвати». Її можна порахувати офлайн, мільйонами, без інтернету і без згоди будь-кого.

Від приватного ключа до адреси

Ланцюжок перетворень виглядає так:

1. Приватний ключ — це секретне число в допустимому діапазоні кривої secp256k1, яке зазвичай представляють 256 бітами.
2. Публічний ключ обчислюється з приватного за правилами еліптичної кривої secp256k1. Зворотне відновлення приватного ключа з публічного вважається обчислювально нездійсненним для класичних комп’ютерів.
3. Далі все залежить від типу виходу. У P2PKH і P2WPKH використовується HASH160 публічного ключа — RIPEMD-160(SHA-256(pubkey)). У P2SH і P2WSH хешується скрипт, а в P2TR використовується tweaked x-only публічний ключ.
4. Після цього дані кодуються у людиночитабельну адресу з контрольною сумою: Base58Check для старих форматів, Bech32 для SegWit v0 і Bech32m для witness-версій 1 та вище, зокрема Taproot.

Ключова деталь: не всі Bitcoin-адреси приховують один і той самий об’єкт. P2PKH і P2WPKH містять хеш публічного ключа, P2SH — хеш redeem script, а P2TR напряму комітиться до x-only output key. Це важливо, коли ми нижче говоритимемо про повторне використання адрес і розкриття публічного ключа.

Навіщо адресі контрольна сума

Адреса — це рядок, який людина копіює, іноді переписує вручну або зчитує з QR-коду. Без перевірки помилка могла б призвести до неправильної адреси, тому формати Bitcoin мають вбудовану контрольну суму: більшість випадкових одруківок гаманець відхиляє ще до створення або підписання транзакції.

Base58Check (зокрема адреси, що починаються на 1 і 3) використовує контрольну суму на основі подвійного SHA-256 і скорочений алфавіт без символів 0, O, I та l, які легко сплутати між собою.

Bech32 (BIP173) використовує BCH-код і дає сильні гарантії виявлення типових помилок. Bitcoin-адреси цього формату зазвичай записують у нижньому регістрі, а змішаний регістр недопустимий. Код також дозволяє реалізаціям вказувати, де може бути помилка, але автоматично «виправляти» адресу небезпечно.

Важливо не плутати дві речі. Префікс bc1q відповідає witness-версії 0, а bc1p — witness-версії 1, яку використовує Taproot. Окремо в оригінальному Bech32 знайшли слабкість: якщо останній символ рядка — «p», вставка або видалення певної кількості «q» безпосередньо перед ним може не зламати контрольну суму. Для SegWit v0 це не створювало практичної проблеми через обмеження довжини, але для майбутніх witness-версій проблему треба було усунути.

Тому BIP350 ввів Bech32m — схему з іншою константою у фінальному обчисленні контрольної суми. Witness-версія 0 залишилася на Bech32, а версії 1 і вище використовують Bech32m. Старе ПЗ, яке знає лише Bech32, має відхилити таку адресу як некоректну, а не мовчки трактувати її як звичайну адресу SegWit v0.

Один seed і нескінченно багато адрес: BIP32

Ранні гаманці зберігали просто набір не пов’язаних між собою приватних ключів. Це означало, що резервна копія застарівала щоразу, коли гаманець генерував новий ключ. Люди втрачали монети саме через це: бекап є, але зроблений він до появи тієї адреси, на яку прийшли гроші.

У 2012 році Pieter Wuille запропонував BIP32, стандарт ієрархічно-детермінованих гаманців (HD wallets), і це закрило проблему.

Як будується дерево

Якщо Ви використовуєте BIP39 seed-фразу, спочатку з неї отримується бінарний seed, а вже BIP32 за допомогою HMAC-SHA512 формує master private key і chain code. Далі функція виводу дочірнього ключа бере батьківський ключ, chain code та індекс і створює наступний вузол дерева.

Дерево детерміноване: однаковий seed за однакових правил деривації дає однакові ключі в тому самому порядку. Для звичайного single-sig HD-гаманця seed-фраза є основою відновлення, але важливо знати правильний тип скрипта і derivation path; у складніших схемах, наприклад multisig, можуть знадобитися й додаткові дані.

Hardened і non-hardened деривація: два режими виводу ключів

Ось тут ховається деталь, без якої не зрозуміти ані xpub (розширений публічний ключ, з якого виводяться всі адреси акаунта), ані watch-only гаманці, ані ризики.

Існує два режими виводу дочірніх ключів. У звичайному (non-hardened) режимі дочірній публічний ключ можна обчислити з батьківського розширеного публічного ключа без приватного ключа. У hardened-режимі використовуються індекси від 2³¹ і вище, які зазвичай позначають апострофом або літерою h, і для виводу потрібен батьківський приватний ключ.

Практичне значення різне. Non-hardened деривація дає змогу створити watch-only гаманець: застосунок із розширеним публічним ключем бачить похідні адреси й баланс, але не може підписувати транзакції. Hardened-деривація не дозволяє відновити батьківський або сусідні приватні ключі лише з одного hardened дочірнього приватного ключа.

Derivation path (шлях виводу): як гаманець знаходить потрібну гілку

Дерево BIP32 саме по собі не задає, де саме лежать «Ваші» адреси. Це визначає BIP44 (і BIP43, який ввів поле purpose). Шлях виглядає так:

m / purpose' / coin_type' / account' / change / address_index

Перші три рівні hardened, останні два ні. Це не випадковість, а конструкція: саме тому розширений публічний ключ рівня акаунта здатен вивести всі адреси отримання і всі адреси здачі цього акаунта, не маючи жодного приватного ключа.

Розбір рівнів

• purpose: який стандарт адрес використовується. 44 — це legacy (BIP44), 49 — вкладений SegWit (BIP49), 84 — Native SegWit (BIP84), 86 — Taproot (BIP86).
• coin_type: монета за реєстром SLIP-44. Для Bitcoin це 0, для тестової мережі 1. Різні монети живуть у повністю незалежних гілках, щоб ключі не перетиналися між мережами.
• account: номер акаунта всередині монети. Це логічний «підгаманець» зі своєю історією і своїм балансом.
• change: 0 для зовнішнього ланцюжка (адреси, які Ви комусь даєте), 1 для внутрішнього (адреси здачі). Ключовий рівень для нашої теми.
• address_index: порядковий номер адреси в ланцюжку, від 0 і вгору.

Приклад. m/84’/0’/0’/0/5 це шоста за рахунком (індекс 5) адреса отримання першого Native SegWit-акаунта Bitcoin.

Один seed і кілька окремих типів акаунтів

Оскільки purpose входить у derivation path, один і той самий seed може давати окремі набори адрес для legacy, вкладеного SegWit, Native SegWit і Taproot. Це не «різні написання однієї адреси», а різні гілки з різними ключами та окремими UTXO. Водночас вони не незалежні з погляду резервного копіювання: компрометація основного seed ставить під загрозу всі ці гілки.

UTXO: чому здача повертається на нову адресу

Це друга і значно менш очевидна причина появи нових адрес. Вона лякає сильніше за першу, бо в блокчейн-експлорері виглядає як зникнення частини грошей.

Що таке UTXO

У Bitcoin немає рахунків з балансами. Є набір невитрачених виходів транзакцій, UTXO (Unspent Transaction Output). UTXO — це неподільний шматок монет із прив’язаними умовами витрачання. Ваш «баланс» — це сума всіх UTXO, які Ваш гаманець вміє розблокувати.

Найближча побутова аналогія — це готівкові купюри. У Вас не «сума на рахунку», а конкретні купюри в кишені. Купюру не можна розрізати навпіл.

Вибір монет (coin selection) і вихід здачі

Коли Ви відправляєте платіж, гаманець виконує coin selection: підбирає набір своїх UTXO, сумарної вартості яких вистачить на суму платежу плюс комісію. Витратити UTXO частково неможливо, тільки цілком.

Якщо гаманець витрачає UTXO на 0.1 BTC, а надіслати треба 0.03 BTC, транзакція витрачає весь UTXO і зазвичай створює щонайменше два виходи: 0.03 BTC отримувачу та решту за мінусом комісії назад собі. Ця решта і є здача. Сучасний HD-гаманець зазвичай повертає її на свіжу адресу внутрішнього ланцюжка.

На прикладі Taproot-акаунта: отримання йде на m/86’/0’/0’/0/0, /0/1, /0/2, а здача повертається на m/86’/0’/0’/1/0, далі /1/1, /1/2. Одне дерево, дві різні гілки.

Не завжди виходів два. Якщо потенційна здача надто мала, гаманець може не створювати окремий change-вихід, і різниця фактично збільшить комісію. Деякі алгоритми coin selection, зокрема Branch and Bound у Bitcoin Core, спеціально шукають варіант без здачі — це може бути корисно і для приватності, і для майбутніх комісій.

Отже, адреса змінюється з трьох різних причин

Плутанина в цій темі виникає тому, що три різні механізми зводять до одного:

1. Ви отримали монети, після чого гаманець може запропонувати наступну адресу зовнішнього ланцюжка (change = 0). Точний момент залежить від конкретного ПЗ: одні інтерфейси тримають поточну невикористану адресу, інші дозволяють згенерувати нову вручну ще до надходження коштів.
2. Ви відправили монети, і здача повернулася на адресу внутрішнього ланцюжка (change = 1), яку звичайний інтерфейс «Отримати» зазвичай не показує.
3. Ви дивитеся на акаунт іншого типу: legacy, вкладений SegWit, Native SegWit або Taproot. У кожного типу своя гілка деривації та свій набір UTXO.

Чи працюють старі адреси

Так. Bitcoin-адреса не має вбудованого терміну дії чи механізму відкликання. Якщо приватний ключ або скрипт, що контролює відповідний вихід, і далі доступний Вашому гаманцю, кошти на стару адресу залишаються витратними так само, як і раніше.

Реальна проблема може виникнути не через «старіння» адреси, а через те, як конкретний гаманець шукає похідні адреси під час відновлення seed.

Gap limit: скільки адрес гаманець перевіряє при відновленні

Коли Ви відновлюєте seed у новому гаманці, софт не знає, скільки адрес Ви встигли використати. Він перебирає їх послідовно і мусить десь зупинитися, бо адрес нескінченно багато.

BIP44 описує address gap limit: якщо під час пошуку трапляються 20 послідовних невикористаних адрес зовнішнього ланцюжка, стандартний алгоритм discovery може припинити сканування. Використаність визначається за історією транзакцій, а не за поточним балансом.

Схожий принцип BIP44 застосовує і до акаунтів: під час account discovery пошук наступного акаунта припиняється, якщо попередній не має історії транзакцій. Сам стандарт також рекомендує ПЗ не створювати новий акаунт, якщо попередній ще не використовувався.

У процедурі account discovery BIP44 сканує зовнішній ланцюжок, тому що внутрішній призначений для здачі, пов’язаної з активністю того самого акаунта. Конкретна реалізація відновлення й розмір keypool можуть відрізнятися між гаманцями.

Проблемний сценарій виглядає так: Ви згенерували багато receive-адрес поспіль, не використовуючи перші з них, а потім отримали кошти на адресу далеко за межами стандартного gap limit. Під час відновлення деякі гаманці можуть зупинити пошук раніше й тимчасово не показати ці кошти.

Монети при цьому не втрачені. Вони залишаються в блокчейні й можуть з’явитися після збільшення gap limit або правильного рескану в гаманці, який це підтримує. Практичне правило просте: не генеруйте десятки receive-адрес «про запас» без потреби.

Чому одного xpub недостатньо: дескриптори виводу (output descriptors)

Розширений публічний ключ (xpub) сам по собі не завжди описує повний контекст гаманця: важливо знати його origin/derivation path і тип скрипта. Той самий набір похідних публічних ключів можна обгорнути, наприклад, у різні типи виходів, тому одного рядка xpub для надійного майбутнього відновлення метаданих може бути недостатньо.

Розробники гаманців спершу полагодили це нашвидкуруч: у SLIP-132 ввели префікси ypub і zpub, які натякають на тип адрес. Це не стандарт Bitcoin, підтримка нерівномірна, і саме звідси беруться питання «мій гаманець дає zpub, а сервіс просить xpub».

Нормальне рішення — це output descriptors, дескриптори виводу, описані в BIP380 і сусідніх. Дескриптор — це рядок, який однозначно задає тип скрипта, відбиток майстер-ключа, шлях виводу, сам розширений ключ і власну контрольну суму. Виглядає приблизно так:

wpkh([d34db33f/84h/0h/0h]xpub6.../0/*)#checksum

Підтримка output descriptors з’явилася в Bitcoin Core 0.17, а з версії 23.0 descriptor wallets стали типом гаманця за замовчуванням. Якщо Ваш гаманець уміє експортувати дескриптор, корисно зберігати його як додатковий опис структури гаманця. Але дескриптор із xpub не замінює seed або приватні ключі й сам по собі не дає можливості витрачати кошти.

Навіщо ротація потрібна: приватність

Зміна адрес існує не для краси інтерфейсу. Bitcoin публічний: кожну транзакцію назавжди видно будь-кому. Питання лише в тому, наскільки легко зв’язати ці транзакції між собою і з Вами.

Що дає повторне використання адреси

Якщо Ви використовуєте одну адресу для всіх надходжень, будь-хто, хто її знає, може напряму бачити в експлорері всі UTXO та транзакції, пов’язані саме з цією адресою. Тобто замість одного платежу Ви відкриваєте значно більшу частину своєї фінансової історії.

Свіжа адреса не має власної попередньої історії, тому не розкриває всі інші надходження напряму. Це підвищує приватність, хоча блокчейн-аналітика все одно може зв’язувати різні адреси за поведінковими та транзакційними евристиками.

Спільне володіння входами (common-input-ownership heuristic)

Основний інструмент аналітичних компаній. Якщо кілька адрес виступають входами в одній транзакції, аналітик припускає, що всі вони належать одній особі: щоб підписати транзакцію, треба володіти приватними ключами до всіх входів.

Це припущення ймовірнісне, а не гарантоване. Його можуть ламати CoinJoin та інші спільні транзакції, де входи належать різним людям. Для звичайних single-user транзакцій евристика часто залишається корисною.

Виявлення адреси здачі

Друга за важливістю техніка у блокчейн-форензиці, тобто в аналізі транзакцій на ланцюжку. У транзакції з двома виходами протокол ніяк не позначає, який з них платіж, а який здача. Обидва виглядають однаково. Аналітики визначають це набором евристик:

• Збіг типу скрипта. Гаманці зазвичай надсилають здачу тим самим типом адрес, яким витрачають. Якщо всі входи P2WPKH і один вихід P2WPKH, а другий P2TR (Taproot), то перший імовірніше здача.
• Круглі числа. Платіж на рівно 0.05 BTC при залишку 0.03847291 BTC робить круглий вихід очевидним платежем, а некруглий здачею.
• Свіжа адреса. Вихід на адресу без жодної попередньої історії ймовірніше є здачею, згенерованою HD-гаманцем відправника.
• Зайвий вхід. Якщо транзакцію можна було зібрати з меншої кількості входів, «зайвий» вхід натякає, який з виходів є здачею.
• Заміна транзакції через RBF. RBF (Replace-by-Fee) дає змогу перевипустити транзакцію з вищою комісією. У багатьох гаманцях додаткова комісія береться зі change-виходу, тому спостереження за кількома версіями транзакції може допомогти визначити, який вихід є здачею. Але це не універсальне правило для всіх реалізацій.
• Цифровий відбиток гаманця. Різні гаманці по-різному сортують виходи, встановлюють nLockTime (поле, яке забороняє включити транзакцію в блок раніше вказаного часу), обирають типи адрес. За цими слідами визначають софт і потім розпізнають наступні транзакції того самого користувача.

Кожна евристика окремо ймовірнісна, але в сумі вони дають високу впевненість. Результат — це так званий peeling chain: довгий ланцюжок, у якому від великої суми послідовно «відщипують» платежі, а решта йде далі по адресах здачі. Цей патерн добре видно після великих транзакцій бірж, маркетплейсів і майнінг-пулів.

Ротація адрес ускладнює аналіз, але не робить Вас анонімним. За наявності додаткових даних — наприклад, інформації від біржі або повторного об’єднання UTXO — аналітик може знову пов’язати частину адрес між собою.

Розширений публічний ключ зводить усе нанівець

Account-level xpub у стандартній HD-схемі дозволяє виводити всі non-hardened receive- і change-адреси відповідного акаунта. Тому той, хто отримав такий xpub разом із правильним контекстом деривації, може стежити за всією історією та балансом цього акаунта.

Сам по собі xpub не дає можливості витрачати монети, бо не містить приватних ключів. Винятково небезпечний сценарій виникає, якщо разом із відповідним xpub витікає хоча б один non-hardened дочірній приватний ключ: тоді за BIP32 можна відновити батьківський приватний ключ.

xpub інколи просять сторонні сервіси для watch-only моніторингу чи бухгалтерського обліку. Це легітимний сценарій, але давати ключ варто лише тим, кому Ви готові показати повну виписку по цьому акаунту, і краще заводити під це окремий акаунт.

Розкриття публічного ключа і виняток Taproot

Технічніший аргумент, який у популярних статтях часто подають неправильно.

У P2PKH (1…) і P2WPKH (bc1q…) вихід комітиться до хешу публічного ключа, тому сам публічний ключ стає видимим лише під час витрачання — у scriptSig або witness поруч із підписом. P2SH (3…) натомість комітиться до хешу redeem script, тому конкретна поведінка залежить від того, який скрипт прихований усередині.

Для P2PKH/P2WPKH повторне отримання на вже витрачену адресу означає, що нові кошти знову прив’язані до публічного ключа, який уже був розкритий у блокчейні. Це не створює практичної можливості крадіжки сьогодні, але прибирає один шар «приховування ключа за хешем».

Стійкість таких виходів спирається на складність задачі дискретного логарифмування на secp256k1. Для класичних комп’ютерів практичного способу відновити приватний ключ з публічного не існує. Квантовий ризик залишається теоретичним: достатньо потужного квантового комп’ютера, здатного атакувати ці ключі на практиці, сьогодні немає.

Для звичайного користувача це не привід уникати Taproot: приватність від кластеризації ротація дає в обох випадках, а Taproot має власні переваги. Але подавати розкриття публічного ключа як універсальний аргумент проти повторного використання адрес некоректно.

Модель акаунтів: чому в Ethereum одна адреса на акаунт

Bitcoin і монети його сімейства (Litecoin, Bitcoin Cash, Dogecoin, Dash) працюють на UTXO-моделі. На спорідненій моделі, хоч і не будучи родичами Bitcoin, працюють Cardano (eUTXO) та прозорі транзакції Zcash. Ethereum, Solana, Tron, Cosmos, Polkadot використовують модель акаунтів.

У моделі акаунтів одна конкретна адреса відповідає одному акаунту, окремого change-виходу немає, а баланс зберігається як частина стану мережі. При цьому один seed, звісно, може виводити багато різних акаунтів і адрес — просто ротація не відбувається автоматично за UTXO-моделлю Bitcoin.

Наслідок для приватності неприємний і незворотний. Якщо Ви два роки отримуєте USDT на одну адресу, будь-хто, хто цю адресу знає, одразу бачить усю історію надходжень і витрат разом із поточним балансом. Жодних евристик не потрібно, все лежить відкрито.

У Bitcoin ротація ускладнює це за замовчуванням. У моделі акаунтів розділяти потоки доводиться вручну, заводячи окремі акаунти під різні задачі: один для бірж, другий для отримання оплат, третій для зберігання. Це один з практичних аргументів проти того, щоб тримати основний запас стейблкоїнів на тій самій адресі, яку Ви світите у чатах і публічних профілях.

Що робити, якщо потрібна одна статична адреса

Іноді ротація об’єктивно заважає: адреса в білому списку біржі, адреса виплат майнінг-пулу, адреса для донатів у профілі. Варіанти є, і вони різного рівня зрілості.

Свідоме повторне використання

Найпростіший варіант, і він не завжди поганий. Якщо мова про виведення з біржі, яка вже провела Ваш KYC, приватності від цієї конкретної біржі Ви й так не маєте. Використовувати одну адресу з білого списку для регулярних виведень з неї — це прийнятний компроміс.

Мінімальна гігієна: під такий потік заведіть окремий акаунт (не адресу, а саме акаунт з власним xpub) і ніколи не витрачайте ці монети разом з рештою в одній транзакції.

BIP47: багаторазові платіжні коди

Ідея: Ви публікуєте статичний платіжний код, а відправник за допомогою одноразової транзакції-повідомлення домовляється з Вами про спільний секрет і далі виводить з нього нові адреси на кожен платіж. На блокчейні платежі виглядають як звичайні виходи на різні адреси.

Широкої підтримки BIP47 не отримав. Найпомітніша реалізація працювала під брендом PayNym у Samourai Wallet, а після зупинки цього проєкту у 2024 році частина інфраструктури PayNym стала недоступною. Перш ніж розраховувати на цей варіант, перевірте актуальний стан підтримки у своєму гаманці. Окремий мінус самої схеми — це потреба в транзакції-повідомленні перед першим платежем, тобто витрати і слід на ланцюжку.

Silent Payments (BIP352)

Silent Payments дозволяють опублікувати одну багаторазову payment address із префіксом sp1. Кожен платіж на неї створює унікальний Taproot-вихід, а сам протокол не залишає прямого on-chain зв’язку між опублікованою Silent Payment address і конкретними отриманими виходами. Окрема notification-транзакція перед першим платежем не потрібна.

Працює це так: відправник обчислює спільний секрет з підсумованих публічних ключів входів своєї транзакції і ключа сканування з Вашої адреси. Отримувач знаходить свої платежі, скануючи транзакції і виконуючи те саме обчислення за протоколом ECDH (обмін ключами Діффі-Геллмана на еліптичній кривій, коли дві сторони отримують спільний секрет, не передаючи його мережею).

Компроміс — сканування. Отримувач має перевіряти придатні транзакції та виконувати обчислення, необхідні для виявлення своїх платежів. Для full node це практичніше, а ефективна підтримка легких клієнтів залишається окремою інженерною задачею. Отримані Silent Payment outputs мають формат P2TR.

Станом на серпень 2026 року BIP352 має версію 1.1.1 від 16 квітня 2026 року. Sparrow Wallet підтримує відправку на Silent Payment addresses з версії 2.3.0, а з 2.5.0 — також приймання, включно з підтримкою air-gapped hardware signers. У Bitcoin Core інтеграція BIP352 ще ведеться як окрема робота: повноцінна send/receive-функціональність гаманця не є завершеною частиною релізної версії.

Lightning

Якщо задача — приймати повторювані платежі, а не зберігати їх безпосередньо on-chain, частину проблеми знімає Lightning. BOLT12 описує багаторазові offers: отримувач може публікувати одну пропозицію, на основі якої для конкретного платежу формується invoice. Це інший рівень зі своїми компромісами щодо ліквідності, доступності та резервного копіювання, тому як заміна холодному on-chain зберіганню він не підходить.

Коли зміна Bitcoin-адреси створює незручності

Білий список біржі та верифікація гаманця

Багато бірж вимагають додати адресу виведення до білого списку, після чого може діяти затримка перед першим виведенням. Якщо гаманець уже пропонує нову receive-адресу, виникає спокуса щоразу оновлювати whitelist. У такому сценарії допустимо свідомо використовувати одну перевірену адресу для конкретної біржі, розуміючи компроміс із приватністю.

Окремо існують процедури підтвердження володіння гаманцем, прив’язані до конкретної адреси. Зміна адреси між верифікацією і транзакцією ламає процес. Виконуйте верифікацію і транзакцію за один раз, не роблячи паузу на тиждень.

Майнінг-пул і сервіси з фіксованою адресою виплат

Пули, стейкінг-сервіси і частина платіжних процесорів дозволяють вказати лише одну адресу виплат. Вибору тут немає. Рішення те саме: окремий акаунт під цей потік, щоб повторне використання не тягнуло за собою решту історії.

Донати і публічні платежі

Опублікована адреса для донатів за визначенням буде перевикористана, і з погляду приватності це найгірший сценарій: адреса публічно пов’язана з Вашим іменем. Для українських зборів і волонтерських гаманців це типова ситуація: адресу викладають у соцмережах, і далі вона назавжди прив’язана до того, хто збирає. Саме тут Silent Payments або BIP47 дають найбільший виграш. Якщо використати їх не виходить, то мінімум окремий акаунт і жодної консолідації цих монет з основними.

Бухгалтерія і watch-only

Якщо потрібно давати комусь доступ до перегляду балансу, не робіть це через передачу адрес по одній. Заведіть окремий акаунт і віддайте дескриптор або xpub саме цього акаунта. Так у людини буде повна і завжди актуальна картина по потрібному потоку і жодної інформації про решту.

Типові помилки

• Звіряти адресу лише на екрані комп’ютера. Шкідливе ПЗ може підміняти адресу в буфері обміну. Якщо Ви користуєтеся апаратним гаманцем, одна з його ключових переваг — можливість перевірити receive-адресу на довіреному екрані самого пристрою перед використанням.
• Плутати ротацію з отруєнням історії (address poisoning). Окрема атака: Вам надсилають мікроскопічну суму з адреси, візуально схожої на Вашу (ті самі перші й останні символи), розраховуючи, що наступного разу Ви скопіюєте адресу з історії транзакцій. У списку операцій це виглядає схоже на звичайну появу нових адрес. Ніколи не копіюйте адресу отримувача з історії.
• Генерувати адреси пачками «про запас». Це типовий спосіб створити великий розрив між використаними адресами й упертися в стандартний gap limit під час відновлення.
• Зберігати як бекап лише xpub. Без типу скрипта і шляху виводу він неоднозначний. Зберігайте дескриптор, якщо гаманець уміє його експортувати.
• Вважати ротацію повноцінною анонімністю. Вона лише підвищує вартість аналізу. Консолідація UTXO, круглі суми і повторне використання в іншому місці зводять ефект нанівець.
• Панікувати, побачивши другий вихід у власній транзакції. Це здача.

Підсумок

Bitcoin-адреса працює не як постійний номер банківського рахунку. У HD-гаманці адреси виводяться з детермінованого дерева ключів, а receive-адреси можна регулярно ротувати без створення нового seed.

Старі адреси не мають терміну дії. Баланс гаманця формується з усіх контрольованих ним UTXO, а здача зазвичай повертається на внутрішню гілку. Legacy, nested SegWit, Native SegWit і Taproot можуть використовувати різні derivation paths, тому під час відновлення важливо вибрати правильний тип акаунта.

Одна з практичних пасток — gap limit: якщо створити великий проміжок невикористаних receive-адрес, деякі гаманці під час стандартного сканування можуть не дійти до адреси, на яку вже надійшли кошти.

Якщо Ваш гаманець постійно показує одну й ту саму BTC-адресу, це саме по собі ще не означає несправність. Перевірте документацію конкретного гаманця: це може бути особливість інтерфейсу, імпорт одного ключа або інша схема керування адресами.

Що почитати далі

• Втратили seed-фразу, але гаманець працює: що робити
• Зберігання seed-фрази: 5 безпечних способів у 2026
• Апаратний гаманець vs біржа: де реально безпечніше зберігати крипту
• Виведення крипти на картку з Binance, OKX, Bybit у 2026 році

Джерела

Стандарти:

• BIP32: Hierarchical Deterministic Wallets
• BIP39: Mnemonic code for generating deterministic keys
• BIP43: Purpose Field for Deterministic Wallets
• BIP44: Multi-Account Hierarchy for Deterministic Wallets — алгоритм виявлення акаунтів і gap limit.
• BIP49 / BIP84 / BIP86: деривація для вкладеного SegWit, Native SegWit і Taproot.
• BIP173: Base32 address format for native v0-16 witness outputs (Bech32)
• BIP350: Bech32m format for v1+ witness addresses
• BIP352: Silent Payments
• BIP380: Output Script Descriptors General Operation
• SLIP-44 та SLIP-132

Інше:

• Bitcoin Optech: Bech32 / Bech32m та Silent Payments.
• Bitcoin Wiki: Privacy
• M. Möser, A. Narayanan. Resurrecting Address Clustering in Bitcoin. Financial Cryptography 2022
• Learn Me A Bitcoin: HD Wallets та Derivation Paths.
• Wallets Recovery: таблиця шляхів виводу і форматів експорту по гаманцях.
• Silent Payments: специфікація і трекер підтримки BIP352.