Біткоїн-адреса

Аліса хоче заплатити Бобу. Боб відкриває в гаманці «Отримати», перевіряє адресу й надсилає її текстом або QR-кодом. Аліса зчитує її своїм гаманцем і перед надсиланням перевіряє одержувача та суму. Розбирати значення кожного символу не потрібно: це робить програма. З адреси гаманець формує умову майбутнього витрачання коштів — зазвичай потрібен підпис відповідним приватним ключем. Транзакція записує цю умову як скрипт scriptPubKey. У ній містяться сума та скрипт, а не звичний текст адреси. Отже, адреса зручно передає платіжні реквізити, але не є сховищем монет. [1] [3]

Довгу адресу краще скопіювати або зчитати QR-кодом, а не вводити вручну. Але перевірка на цьому не закінчується: шкідлива програма може підмінити адресу в буфері обміну. Порівняйте її повністю з реквізитами, отриманими від одержувача надійним каналом; якщо користуєтеся Hardware Wallet, перевірте також власний екран пристрою. Початку й кінця недостатньо — шахрайська адреса може їх імітувати. Адреси містять контрольну суму для виявлення помилок введення. Вона не визначає, чи належить правильно записана адреса потрібній людині. Гаманець також має підтримувати відповідний формат і мережу. Невеликий пробний платіж може допомогти, але не замінює перевірки адреси під час наступного переказу. Протокол не дозволяє просто скасувати підтверджений платіж на хибну, проте дійсну адресу. [2] [7] [8] [18]

Коли Боб знову відкриє «Отримати», він може побачити іншу адресу. Це не означає, що його гроші зникли. Нова адреса допомагає зберігати приватність: той, хто знає опубліковану адресу, може стежити за платежами на неї в блокчейні, але не повинен автоматично бачити всі надходження гаманця. Повторне використання полегшує таке пов’язування. Утім, нові адреси теж не гарантують анонімності: наступні транзакції можуть розкрити інші зв’язки. Адресою можна поділитися для оплати, але публікувати її всюди без потреби не варто. До того ж одна адреса не дорівнює одній людині: коштами можуть спільно керувати кілька осіб або сервіс для своїх клієнтів. [1] [14]

Гаманець керує ключами, знаходить платежі, які може витратити, і показує їхню суму. Тож баланс може складатися з надходжень на багато адрес. Звичайна HD Wallet створює цілі родини ключів зі спільної основи: нова адреса не означає відкриття іншого гаманця. Під час оплати програма також може повернути невикористаний залишок на власну Change Address — адресу решти. Але самих адрес недостатньо для відновлення. Резервна копія має дозволяти відновити потрібні ключі та правила їх використання. Багато гаманців використовують Seed Phrase — набір слів для відновлення; складніші налаштування можуть потребувати додаткових даних. Платнику ці слова та ваші приватні ключі ніколи не потрібні. [10] [14]

QR-код — лише спосіб запису інформації. Він може містити адресу або платіжний запит, що починається з bitcoin: і додає суму, позначення одержувача чи повідомлення. Цей механізм описував BIP21, а BIP321 його розширює. Перед підтвердженням перевірте, що саме зчитав гаманець. Запити Lightning Network, наприклад invoice для окремого платежу чи offer, за яким можна щоразу запитувати нову invoice, використовують інший порядок оплати; Lightning Address полегшує отримання такого запиту. Деякі запити пропонують кілька способів сплатити. Так само цифровий підпис повідомлення не є автоматичним посвідченням особи: BIP322 дозволяє довести можливість виконати умови скрипту, але сам по собі не засвідчує особу в юридичному розумінні чи згоду з довільним рахунком. [15] [16] [17]

Base58Check поєднує байт версії з даними, які називають payload. Додає перші чотири байти SHA256(SHA256(version || payload)) і кодує результат абеткою Base58. У mainnet 0x00 означає P2PKH, а 0x05 — P2SH; звідси звичні початкові 1 та 3. Тестові мережі використовують інші версії. Абетка не містить схожих символів 0, O, I та l. Ця 32-бітова контрольна сума виявляє багато помилок набору, але не засвідчує особу отримувача. [2] [3]

Запис нативного SegWit містить префікс bc для mainnet або tb для testnet, роздільник 1, witness-версію та дані, розбиті на групи по 5 бітів. Наприкінці стоять 6 символів контрольної суми. BIP173 запровадив Bech32; після виявлення слабкості щодо певних вставлень і видалень BIP350 залишив Bech32 для версії 0 та визначив Bech32m для версій 1–16. Літери можуть бути всі малими або всі великими, але не змішаними. Межа кодування — 90 символів. Навіть правильний запис може стосуватися іншої мережі чи непідтримуваної версії. [7] [8]

P2PKH та P2WPKH посилаються на 20-байтовий HASH160 публічного ключа. P2SH використовує HASH160 скрипту redeemScript, а P2WSH — SHA256 скрипту witnessScript. Отже, SegWit v0 розпізнає 20-байтовий P2WPKH та 32-байтовий P2WSH. P2TR за BIP341 влаштований інакше: його програма версії 1 містить 32-байтовий модифікований вихідний ключ Q у форматі x-only, а не хеш звичайного ключа отримання. Під час формування Q можна також врахувати корінь дерева додаткових скриптів. Так ключ криптографічно пов’язується з цими умовами витрачання. Тому сама адреса не розкриває всіх способів витрачання. [6] [9]

Ранні біткоїн-виходи часто платили безпосередньо на публічний ключ. P2PKH відклав його розкриття до витрачання. BIP13 та BIP16 дозволили передавати через P2SH хеш складнішого скрипту. BIP141 додав версійовані witness-програми, BIP173 — Bech32, а BIP341 разом із BIP350 — формат Taproot із Bech32m. За різним виглядом стоять різні умови перевірки. Не «перетворюйте» адресу ручною заміною префікса: можна створити інший або невитрачуваний вихід. Деякі нестандартні скрипти та ранні виходи pay-to-pubkey не мають звичайної канонічної адреси. [4] [5] [6] [7] [8] [9] [3]

HD Wallet за BIP32 виводить багато ключів зі спільного кореня. Шляхи розрізняють типи виходів: BIP44 використовує призначення 44' для P2PKH, BIP84 — 84' для P2WPKH, а BIP86 — 86' для P2TR з одним ключем. Далі йдуть тип монети (coin type), обліковий запис, гілка отримання чи решти та індекс адреси. Самої Seed Phrase може бути недостатньо для визначення всіх шляхів, облікових записів і правил Multisig. Output Descriptor зберігає також походження ключів і будову скрипту. Відновлення має знайти справжні кошти, а не лише знову показати одну знайому адресу. [10] [11] [12] [13] [14]

У P2PKH та P2WPKH спочатку зазвичай видно хеш ключа; під час витрачання розкривається публічний ключ. P2SH та P2WSH розкривають використаний redeemScript або witnessScript. Taproot уже містить модифікований публічний ключ у виході. Витрачання через key path зазвичай додає Schnorr Signature, а через script path — розкриває обраний скрипт, control block і шлях Меркла; невикористані гілки можуть залишатися прихованими. Тому не можна стверджувати, що кожна адреса приховує публічний ключ. [6] [9]