Протокол платежей (BIP70)

Сначала амбиции, затем отказ. Gavin Andresen и Mike Hearn опубликовали BIP70 29 июля 2013 года, Bitcoin Core включил его в 0.9.0 в марте 2014 года, объявил устаревшим в 0.19 в ноябре 2019 года и удалил в 0.20.0 3 июня 2020 года. Если страница оплаты все еще просит ваш кошелек поддерживать его, считайте это признаком того, что эту интеграцию не трогали годами.

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

Статус: объявлен устаревшим в Bitcoin Core 0.19 и полностью удален в 0.20.0 3 июня 2020 года. Ни один поддерживаемый кошелек его не реализует. Вместо него используют обычный URI BIP21 для ончейн-платежей, счета BOLT11 или BOLT12 в Lightning и тихие платежи BIP352, когда нужен многоразовый адрес получателя.

Конструкция представляла собой семейство из четырех BIP. BIP70 определял сообщения, BIP71 регистрировал тип MIME для каждого из трех, ходивших по сети, BIP72 добавил параметр r=, чтобы URI мог указывать на запрос, а BIP73 решал согласование содержимого для кошельков, которые не могли разобрать протокол.

Процесс работал как карточный терминал. Продавец отдавал по HTTPS подписанный PaymentRequest. Кошелек покупателя загружал его, проходил по приложенной цепочке сертификатов X.509 до корневого сертификата, которому уже доверял, и показывал название компании вместо строки символов. Покупатель подтверждал, кошелек отправлял транзакцию в сеть и вдобавок отсылал продавцу сообщение Payment с необработанными байтами транзакции и адресом для возврата. Продавец отвечал сообщением PaymentACK, которое служило квитанцией.

Четыре причины его провала, и их стоит понять, потому что каждая повторяется всякий раз, когда кто-то предлагает добавить идентичность поверх биткоина.

Он заимствовал доверие у удостоверяющих центров. Любой из сотен удостоверяющих центров в типовом хранилище корневых сертификатов может выдать сертификат на любое имя, а это именно тот сценарий отказа, обойти который биткоин и создавался. BIP70 также допускал тип подписи x509+sha1, а практическая коллизия SHA-1 была опубликована 23 февраля 2017 года.

Ему требовался продавец онлайн. Платеж нельзя было построить, если HTTPS-адрес продавца не отвечал, поэтому сбой останавливал платежи, которые иначе прошли бы по одному только адресу.

Он раскрывал данные. Кошелек делал исходящий запрос на сервер продавца, раскрывая IP-адрес покупателя, а поле возврата передавало новый адрес, принадлежащий плательщику.

Он давал очень мало. Сертификат доказывал, что кто-то контролирует доменное имя, а не что счет подлинный или товар настоящий.

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

Главная причина, по которой BIP70 до сих пор ходит как термин, в том, что справочник для разработчиков на bitcoin.org описывает протокол в настоящем времени, а этот справочник годами не отслеживает изменения в Bitcoin Core.

Помимо этого, BIP70 встречается в архивных исходниках кошельков, в старых руководствах по интеграции, написанных, когда крупные процессинговые компании продвигали его, и изредка в файле .bitcoinpaymentrequest, приложенном к счету десятилетней давности. Ничто из того, что вы покупаете сегодня, его не потребует. Продавцы, которым нужна страница оплаты, используют такое программное обеспечение, как BTCPay Server: оно выпускает URI BIP21 и счета Lightning и не требует от кошелька покупателя ничего необычного.

Протокол платежей (BIP70) vs PaymentRequest

Протокол платежей представляет собой весь обмен целиком; PaymentRequest является одним сообщением внутри него. Между кошельком и продавцом ходили три сообщения, и PaymentRequest был первым из них: тем подписанным конвертом, который отдавал продавец. Если использовать оба названия как взаимозаменяемые, старая документация становится труднее для чтения, чем нужно. Учтите также, что PaymentRequest является названием несвязанного браузерного стандарта для оплаты картой и кошельком, так что разработчик, использующий это слово сегодня, скорее всего, имеет в виду вовсе не биткоин.