«Изменить адрес» — это обозначение адреса сценария в этом выводе, но технически это scriptPubKey и новый UTXO, а не баланс счета. При сумме входов I, выходов получателям R и комиссии F справедливо C = I − R − F. В случае точного вывода или неэкономического остатка кошелек может вообще не создать сдачу.
Биткойн тратит все UTXO; из одного входа нельзя вычесть только часть. Если кошелек выбирает входы 120 000 сат для оплаты 100 000 сат и комиссии в 2 000 сат, он должен положить оставшиеся 18 000 сат на следующий вывод или оставить их в качестве комиссии. Вывод получателя и изменение занимают одну и ту же позицию в сериализации, и порядок не имеет согласованного значения. После подтверждения изменение представляет собой новый UTXO со своей собственной минусовой точкой, подтверждением и будущей ценой расходов. [Руководство для разработчиков биткойнов — Транзакции]
При выборе монет выбираются входы, комиссии и возможные сдачи вместе. Точная комбинация не даст результата; в противном случае кошелек сравнивает баланс со стоимостью его создания и последующей траты. Финансирование RPC Bitcoin Core может заполнить не более одного вывода изменения и вернуть свою позицию, в то время как функция отправки всех не имеет ни одного. Монетное управление изменяет используемые входы, таким образом, изменяются, но каждый выбранный вручную вход потребляется полностью. Проверьте окончательные записи, суммы получателей, комиссию и сдачу. [Bitcoin Core — реализация выбора монет] [Bitcoin Core RPC — fundrawtransaction] [Bitcoin Optech — выбор монет]
HD-кошельки обычно получают скрипты принятия во внешней ветке и изменения во внутренней. BIP44 помечает изменение=0 как внешнее, а изменение=1 как внутреннее: например, m/84'/0'/0'/0/i и m/84'/0'/0'/1/i для собственной учетной записи SegWit. Это соглашение о применении, а не консенсус; Кошелек дескриптора может иметь другую политику. Новый внутренний адрес ограничивает повторное использование адреса, в то время как возврат к исходному адресу действителен, но связан с историей. [BIP 32 — Иерархические детерминированные кошельки] [BIP 44 — Иерархия нескольких аккаунтов]
Выходной дескриптор объединяет тип сценария, ключи, происхождение и подстановочный знак происхождения, указывающий право собственности. Пара wpkh([fingerprint/84h/0h/0h]xpub…/0/*) и …/1/* описывает получение изменения; BIP389 допускает многопутевую запись. Внутренний флаг выбирает дескриптор для изменения, но не меняет сам скрипт. Начальное значение без информации об учетной записи, типа сценария и политики получения может оставить действительные изменения невидимыми после обновления, даже если ключи существуют. [BIP 380 — Дескрипторы выходных сценариев] [BIP 389 — Выражения клавиш дескриптора многопутевого доступа] [Bitcoin Core — Дескрипторы вывода]
Блок содержит значения и scriptPubKeys, а не метки плательщика, получателя платежа или изменения. Кошелек распознает собственные изменения по производным записям, проводник только догадывается. Порядок вывода или правило «второго вывода» ненадежны. Транзакция может иметь без изменений, один, несколько самоуправляемых выходов или выходов нескольких участников. Таким образом, изменение — это классификация, относящаяся к кошельку, а не свойство, записанное протоколом. [Руководство для разработчиков биткойнов — Транзакции]
Общие эвристики обозначают изменение выходных данных того же типа сценария, что и входные, нелестно округленной суммы, нового адреса или значения, соответствующего арифметике входных данных. Зачастую они работают на обычную оплату с двумя выходами, но у каждого есть контрпримеры. BIP78 Payjoin намеренно нарушает эвристику как общего ввода, так и скриптового типа, а также эвристику округленных сумм; CoinJoin, пакетная обработка и самостоятельная передача добавляют еще большей двусмысленности. Результат должен иметь определенную степень уверенности и поддержки, а не статус подтверждения протокола. [BIP 78 — Payjoin] [Meiklejohn et al. — Пригоршня биткойнов]
Dust — это политика ретрансляции узла, рассчитываемая на основе типа вывода, предполагаемого размера его будущих расходов и регулируемой платы за ретрансляцию пыли; это не универсальный подсчет сатоши или консенсусный запрет. Кошелек может отклонить сдачу высоко над пылью, если создание и последующая трата обходятся дороже, чем ее стоимость. Экономический лимит зависит от текущей и долгосрочной ставки, а также размера скрипта. Подавление изменений увеличит сегодняшнюю комиссию, слишком небольшое изменение может застрять. [Bitcoin Core — Политика ретрансляции транзакций]
В PSBT выходные данные BIP32 позволяют аппаратному или автономному подписывающему лицу получить предлагаемые выходные данные и проверить возврат к той же политике кошелька. BIP174 описывает обнаружение как одноключевого, так и многоподписного ключей; для мультиподписи сопоставления одного локального ключа недостаточно. Злонамеренный координатор может подменить изменение своими собственными выводами или скрыть остальное за непомерную плату. Подписывающая сторона должна проверить получателя, общую сумму комиссии и каждое заявленное изменение на доверенном дисплее. [BIP 174 — формат частично подписанных биткойн-транзакций]
Замена комиссией меняет экономику неподтвержденной транзакции. Bumpfee в Bitcoin Core может платить более высокую комиссию за счет уменьшения сдачи, добавления входных данных или создания сдачи; после падения ниже уровня политического или экономического изменения он исчезает. Расходование неподтвержденных изменений создает потомка, зависящего от замены родителя, а CPFP использует вывод, контролируемый кошельком, для увеличения комиссии за пакет. Не считайте неподтвержденный txid/outpoint окончательным до того, как будут произведены замены. [Bitcoin Core RPC — комиссия]
Для полного восстановления требуются начальные ключи или ключи подписи, а также дескрипторы получения/внутренние, происхождение ключей, учетная запись, сеть, политика сценариев, диапазоны деривации и достаточно старый запуск сканирования. Отсутствие /1/* обычно приводит к усечению баланса, поскольку изменение не обнаружено. Для мультиподписи сохраните все xpubs cosigner, порог и порядок в обеих ветвях. Протестируйте восстановление, сопоставив известные сценарии получения/изменения, реконструировав UTXO, создав PSBT и проверив изменение на каждой подписывающей стороне. [BIP 32 — Иерархические детерминированные кошельки] [BIP 380 — Дескрипторы выходных сценариев] [BIP 389 — Ключевые выражения дескриптора многопутевого доступа]
Для полной картины прочитайте эту статью вместе с Биткоин-адрес, UTXO, Coin Control, Кошелёк, Coin Selection, HD Wallet. На эту статью также ссылаются Биткоин-адрес, Coin Control, Приватность в Bitcoin, Псевдонимность.