Одна из проблем, я вижу, с Bitcoin URI, что это невозможно, как клиент, чтобы доказать, экс-постфактум, что вы сделали платеж (а) к определенному субъекту или (б) для конкретной цели. В то время как вы можете доверять, что адрес Bitcoin / URI принадлежит поставщику на основании того, что было представлено с помощью SSL на странице этого поставщика, как только вы сделали платеж у вас нет механизма, чтобы доказать, что (а) вы видели, что URI на страница поставщика, (б) вы сделали оплату за какой-либо конкретной цели, или (с) вы заплатили сумму в полном объеме. Короче говоря, нет ничего, чтобы обеспечить соблюдение безотказности от Bitcoin URI накладной поставщика, как только платеж. Другими словами, это легко создать счет-фактуру, но как клиент показать квитанцию, что это доказуемо из счета-фактуры?

Это происходит со мной, что у нас уже есть инфраструктура в месте для решения this-- SSL. (SSL не является совершенным, но это лучше, чем ничего.)

Поскольку URI для оплаты Bitcoin (BIP 0021) предназначен быть продлен, я предлагаю следующее:

Поставщик может присоединять два (или три *) поля в конце URI: "sigdomain", а также "сиг",  "sigdomain" указывает имя DNS, где открытый ключ SSL может быть извлечена, который проверяет подпись сделки, и "сиг" это база-64 кодировке SHA1RSA подпись URI вплоть до и включая "знак равно" знак после того, как "сиг", ("сиг" ДОЛЖЕН быть последним поле URI.) Если "сиг" используется, то "sigdomain" ДОЛЖЕН быть также включены.

Пример:

Bitcoin: 1NYTSZeZ6axJhnR41AfxxB4ks5fEgkjDQ8 sigdomain = darylb.net&сиг = b9FUOZOmvlIYAMD6FH4mTw9fipCLi8WSnN9laSg% 2BlRagU5EwHe9VFN0NlX1B% 2FKKNtcKlbqBel1C4WOh9bH2uibg5eNKBwDXUWenLk% 2BT3i5G5iUn0uG5SNtz69zOYAloFRn5E8CAFXElqoBFj24XcU6tgRJuFv7EwFMGiNhenaauHaohB8sYr8HNKqoeLC5zMbG9sB% 2FCy% 2F8N3Vj7QSFYh4bQt4W% 2FJI% 2Fai8Fq4E7U% 2FEUHR% 2BHINb% 2FX% 2FSwUxXMva6LuDRQq% 2FzhhNUFmbtd1ahne% 2ff% 2FADm8UQMM1LPj% 2FZMtbpE6EUEW5% 2BVkFYiaK2tOIBauQb% 2FbrstOcIkxZgS7VdC3% 2BQgw% 3D% 3D

Или:

Этот адрес был подписан с помощью закрытого ключа, соответствующего открытого ключа, которая доступна при подключении к "https://darylb.net", Клиент должен хранить сертификат открытого ключа вместе с фактурой, так что проверка подписи replayable, даже если ключ сервера будет заменен.

Конечно, это делает для довольно плотной QR коды, но с 4.кАми жестким пределом для буквенно-цифровых кодов QR, это не приближается к максимуму.

Клиенты не знают о Bitcoin счета-фактуры подписях (BIS) будет просто игнорировать дополнительные данные; но клиенты, которые знают BIS могут представить (а) все поля включены, и (б) значение sigdomain (или необязательно различающееся имя, что сертификат был выдан в) и (с) тем фактом, что продавец подписал сделка И что клиент подтверждено, что подпись.

В случае возникновения спора оплаты, клиент может представить оригинал счета-фактуры Bitcoin URI, и доказать, что их оплата была произведена через общественный blockchain. URI в этом случае становится и фактура / и / квитанция.

* Действительно: ограничить допустимое время для оплаты счета-фактуры, в вендор МОЖЕТ добавить поле, помеченное "sigexpiration" могут быть добавлены перед "сиг" поле, которое будет кодироваться ГГГГММДДччммсс, а во временной зоне UTC. (HH использует 24-часовой). Клиентам следует перевести это время в часовом поясе пользователя, и не должны допускать оплаты, которые будут представлены после этого обрезания. (Оплата подтверждается после обрезания стал спор за рамки данного предложения.)

Я знаю BIP 0070, но это гораздо более легким, будет использоваться в автономном режиме, может быть реализована в относительно короткий период времени, и не будет нарушать существующий Bitcoin клиентов.

Исходный код Java для этого:  https://github.com/dbanttari/bitcoin-invoice