PaymentDetails

PaymentDetails представлял собой ту часть, которую продавец действительно подписывал, а внешний конверт нес только сертификат, который это подтверждал. В нем было семь полей: имя сети со значением по умолчанию main, список выходов, обязательная отметка времени, необязательный срок действия, примечание, URL обратного вызова и непрозрачный блок merchant_data. Сейчас URI BIP21 вместе со страницей оформления заказа выполняет ту же задачу без подписи и без сервера.

Как это работает

Статус: исторический. Bitcoin Core удалил BIP70 в версии 0.20.0 3 июня 2020 года, и у PaymentDetails нет действующей реализации. Здесь он описан потому, что имена полей до сих пор встречаются в старых руководствах по интеграции и в справочнике для разработчиков bitcoin.org.

Структуру передавал Protocol Buffers, а не JSON. Этот выбор имел значение по причине, на которой стоит задержаться: продавец сериализовал PaymentDetails в строку байтов и помещал эти точные байты внутрь внешнего PaymentRequest как непрозрачное поле, а не как вложенное сообщение. Подпись покрывала строку байтов, поэтому ни одна библиотека, повторно кодирующая те же поля в другом порядке, не могла сделать недействительной действительную подпись.

Семь полей делились на инструкции и учетные сведения.

• network, строка со значением по умолчанию "main", где "test" является единственным другим определенным значением.
• outputs, повторяющийся список, каждый элемент которого связывает сумму в сатоши со скриптом. Более одного выхода допускалось, и продавцы использовали это, чтобы разделить один платеж клиента между горячим кошельком и холодным хранением, не прося клиента отправлять дважды.
• time, обязательная отметка времени unix, фиксирующая, когда был создан запрос.
• expires, необязательная отметка времени unix, после которой кошелек должен был отказать. Именно это поле придавало BIP70 сходство с карточным терминалом, потому что продавец мог назвать цену в фиатной валюте и гарантировать ее на фиксированный период.
• memo, примечание в UTF-8, отображаемое плательщику.
• payment_url, адрес, по которому кошелек отправлял свое сообщение Payment после отправки транзакции в сеть.
• merchant_data, непрозрачные байты, возвращаемые без изменений, чтобы продавец мог сопоставить платеж с корзиной покупок.

Обязательными были только time и скрипты выходов. Все остальное продавец мог опустить, и большинство так и делало.

Где это встречается

Идея, стоящая за PaymentDetails, пережила само сообщение, и это полезно заметить.

Сейчас истечение срока цены обрабатывается на бирже, а не в вашем кошельке. При покупке через экран мгновенной покупки вы получаете котировку курса с обратным отсчетом рядом; если отсчет закончится, котировка пересчитывается по новой цене. Это expires, реализованное заново в веб-приложении, и оно защищает продавца от волатильности точно так же. Сопоставление ордеров в книге ордеров биржи делает ту же работу иначе: оно вообще никогда не называет фиксированную цену.

Эквивалентом всего сообщения на стороне продавца служит запись счета в программном обеспечении для оформления заказов. BTCPay Server и подобные инструменты создают URI BIP21, держат его открытым заданное число минут и сверяют входящую транзакцию с внутренним идентификатором заказа, что как раз и было назначением merchant_data.

PaymentDetails vs квитанция

PaymentDetails был запросом; квитанцией в BIP70 было сообщение PaymentACK, которое продавец возвращал после. Одно описывало, что должно произойти, другое подтверждало, что продавец увидел, что это произошло. Ни то, ни другое не было фактом блокчейна, и в этом заключается ограничение, которое люди недооценивали: подписанное подтверждение от продавца доказывает, что сервер продавца что-то сказал, а не что транзакция подтверждена. Платеж в биткоине закрывают подтверждения, а не квитанции.