Я смущен. Вы возражая против использования X.509 сертификатов или нет?

Если да, то где же ваше программное обеспечение получить доказуемую идентичность от? В вашем примере хлебопекарных вы замалчивать, что вы просто предположите, пользователи покупали там раньше и назначить пользовательские метки для магазинов ключевых. Если у пользователя есть зараженный компьютер и магазины в новом купцу, ваша схема не поможет, если запрос формы заказа / оплаты не имеет какой-то автономной проверяемым идентичности, прикрепленной к ней, это смысл для пользователя первый раз .... как SSL сертификат.

Если компания владеет SSL сертификат, то почему бы не использовать его, чтобы обеспечить их веб-сайт тоже? Действительно ли мы хотим, чтобы препятствовать шифрованные веб-соединение?

Будучи в состоянии создавать и подписывать платежные требования полностью в автономном режиме потенциально полезно в условиях взломанного веба-сервере, если у вас нет какой-либо другой общепринятой формы идентичности на этом сервере, который может быть использован для подписания платежных требований. К сожалению, как два SSL сертификаты эквивалентны, это означает, что только случай не-обеспеченных сайтов. Есть много причин, сайт, возможно, захотите использовать SSL за Bitcoin.

Я не говорю, что идеи на бумаге плохо. Просто указывая на то, что на данный момент, для большинства торговцев / сайтов, было бы не сделать с практической точки зрения, потому что они не имеют отдельную идентичность, которая может быть использована только для платежей Bitcoin и не веб-соединений. Если мы сможем найти способ сделать это (приковав два сертификатов от выпущенного серт ??) было бы иметь гораздо более непосредственное влияние.

Несмотря на это, будущее расширение, которое позволяет платежное требование содержит базовые ключи (в запрошенных скриптах), которые модифицированы клиентом по-прежнему является хорошей идеей. Это то, что может быть добавлен в обратной совместимости. Как говорит Гэвин, вы бы просто добавить некоторые новые флаги в сообщении запроса платежа о том, что часть выходных сценариев, где ключи должны идти, должны иметь ключ, генерируемый клиентом.

Re: объем. Что касается, написание статьи не то же самое, как ее реализации во всех крупных клиентах. Имейте в виду, некоторые из наиболее широко используемых кошельков не поддерживают иерархические детерминированных бумажники на все еще, так что писать функции, предполагающие их просто задержать реализацию значительно.


Никто не любит его, но нет широко принят эквивалента. Люди бросают вокруг "Сеть доверия" как если бы этот подход не был даже больше, чем неудача ИПК.

Покажите мне другой механизм, чтобы получить сертификат, утверждающий свою личность таким образом, что интуитивно для всех конечных пользователей. Я не знаю одного. ИПК означает, что если кто-нибудь узнает о моем сайте от друга говорят "эй, проверить mikes-widget-shop.com" и они просматривают к нему, они будут видеть "mikes-widget-shop.com" на их второй фактор устройства, истории транзакций и т.д. Это смысл - это соответствует личности их друг дал им. Если они видят "Майкс Widget Shop, Ltd" и мои права на владение этой строки была проверена кем-то заслуживающим доверия (товарных знаков и т.д.), что еще лучше! EV сертификаты стоят дорого и трудно получить, но явно не вне досягаемости для сообщества Bitcoin, blockchain.info имеет один, например.

Во всяком случае, SSL PKI является основой, на которой мы можем построить, а не конец игры.