Это мое мнение, что выставляя SHA256 хеш для широкой публики плохой юзабилити. Люди бы предпочел опубликовать дружественный адрес в формате, который может быть легко продиктовал по телефону, записанному или запомненной, подобно тому, как PayPal / Skrill / Neteller работы, где адрес электронной почты является личность владельца счета. Они также хотели бы включить частные платежные реквизиты с каждой сделкой, такие как номера счетов-фактур, а также иметь возможность легко обеспечивая возврат, когда они желают.

Кроме того, публикация одного base58 хеш снижает конфиденциальность потому что он может помочь отслеживать связанные платежи по этому адресу. Политический кандидат может не захотеть раскрывать общую сумму пожертвований, полученных. В качестве донора, я бы не хотел моего друга и деловых партнеров, чтобы выяснить, что часть денег, они послали меня в конечном итоге в хорошо известной травосборник. Поскольку ключи ECDSA дешевы, максимальная конфиденциальность достигается, когда каждый реальный мир сделка имеет свой уникальный адрес, и они не будут объединены в мастер-ключа, а потратил индивидуально получателю.

Объединяя два требования, я предлагаю распределенный онлайн протокол, который разрешает дружественные имена base58 хэш, обеспечивая в то же время, что каждая сделка имеет свой собственный уникальный адрес. Протокол работает с использованием доверенного 3 участника, который действует как всегда-на реле точки от имени пользователя, похожего на сервер электронной почты. Полезная нагрузка (деньги / закрытые ключи) не находится под управлением сервером, только список громкого и их отображение в дружный адрес. Конфиденциальность внимание людей, которые не хотят раскрывать даже список транзакций на 3-й партии может провести свой собственный сервер ретрансляции.

Концептуальный рабочий процесс будет идти-то вроде этого:

• Алиса создает большое количество закрытых ключей и сохраняет их в автономном режиме, сохраняя только публичные соответствующие публичные адреса; для экономии места закрытых ключей могут быть сформированы на основе одного семени, которое легко хранить
• Алиса создает учетную запись на сервере ретрансляции, устанавливает маркер аутентификации, и присваивает себе дружественный адрес: alice@example.com
• Используя свой маркер аутентификации, клиент Алисы периодически связывается с сервером реле и запросы на недавнюю деятельность, связанную с ее счетами ("Мероприятия" будут определены ниже); если base58 пул адресов будет исчерпан, например, на первое подключении, клиент будет загружать новые ключи, генерируемые на стадии 1
• Алиса публикует ее дружеское обращение к друзьям, семье, деловых партнеров, Боб и Мэллори
• Когда Боб хочет произвести оплату Алисе, он входит в дружественном адрес Алисы в его клиенте, сумма для отправки, некоторые описания и любых других данных конкретного приложения
• клиент Боба проверяет его бумажник и обнаруживает его может соответствовать введенной сумме Боба точно потратив три закрытых ключей в его собственность
• клиент Боба анализирует адрес в сервере и пользовательской части, контакты сервера ретрансляции через DNS / HTTP и отправляет запрос на сделку. Например, почтовый адрес и данные могут пойти что-то вроде этого:

• Сервер реле извлекает три base58 хэш Алисы из пула доступные хэши, записывает их в базу данных б хэши наряду с информацией, размещенной на Бобе, и возвращают адреса для клиента Боба
  
• клиент Боба совершает сделки, как обычно, к адресам, полученным, и публикует их в blockchain
• На следующем обновлении, клиент Алисы будет связаться с сервером и найти то, что адрес, где используется, и связанный с ними плательщиком метаинформацией; если сделки существует в blockchain, то Алиса сможет увидеть удобный вход в нее входящий журнал, который отображает все 3 посылает к одному входу и показывает соответствующий плательщик адр и метаинформации, так же, как обычный электронный кошелек

Для обеспечения максимальной совместимости и легкого развертывания, сервер работает поверх DNS и HTTP, но он может быть также развернут над Namecoin / Tor. Он также монета агностика и может быть реализован для любой другой валюты, кроме Bitcoin. Если Боб не хочет раскрывать свой IP-адрес сервера ретрансляции Алисы, он может разрешить ее дружественное имя через Tor. Это также является необязательным для Боба раскрывать или нет свой дружеский адрес под "плательщик" POST поле.

Система имеет то преимущество, что Мэллори не может найти что-либо по queering сервера ретрансляции. Она получит уникальную и случайную строку, которая никогда не используется в blockchain и не раскрывает никакой информации о Алисе. Единственный способ, чтобы узнать больше, чтобы отправить деньги Алисе и транс их дальше. Но если Алиса использует тот же протокол, когда тратить деньги, полученные от Мэллори, то Mallory не может найти что-нибудь о других партнерах Алисы.

Протокол предлагает удобство системы, такие как PayPal, не спамить в blockchain с метаданными (платежные реквизиты); метаданные приватные, известный только Боб, Алиса и сервер, и она также может быть зашифрована, чтобы исключить сервер. Это позволяет легко возврат, если плательщик выбрал раскрыть обратный адрес; без дружественного адреса плательщика, возврат в течение base58 адреса плохой ideea, так как нет никакой гарантии, что отправитель сохранил соответствующий закрытый ключ.

Я не обязательно стремится иметь дружественные адреса, отформатированные как адрес электронной почты, особенно с тех пор этот адрес не будет иметь возможности электронной почты; Дружелюбный синтаксис адреса еще не определен, и существует множество альтернатив: алиса $ example.com, алиса ^ example.c, BTC: example.com ~ алиса и т.д. Я также скользил детали низкого уровня для сервера связи так как это слишком рано, чтобы сложить детали реализации. Кроме того, DoS при опорожнении пула доступных хэш должны быть предотвращен.


Позже редактировать, 3 апреля 2012:
Наивная схема представлены выше, является очень уязвимой для человека-в-середины атаки. Алиса должна доверять релейный серверу, системе DNS и поставщика SSL на example.com; они могли бы сговорились, чтобы раздать поддельные ключи, которые не принадлежит Алисе, захватить все средства Алисы, и регистрировать все платежные реквизиты.

Но отправитель и получатель уже неподделен канал в их распоряжении: в blockchain. Почему бы не использовать этот канал, чтобы установить доверенный открытый ключ, таким образом, широко уменьшая середину человека (сервер ретрансляции) маневрирование возможности?

Это может пойти что-то вроде этого:
- Алиса хочет дружественное имя alice@example.com, и владельцы example.com позволяют ей зарегистрировать
- Алиса хэш понятного имени с ripemd160 и создает глобально уникальный, unspendable Bitcoin адрес: base58 (ripemd160 ("alice@example.com") + Контрольная сумма),
- Адрес unspendable, так как это не хэш открытого ключа; только Алиса и друзья знают это, и это не может быть обнаружено
- Алиса создает ECDSA ключи, и использует его, чтобы подписать передачу несколько bitcents в unspendable адрес
- Элис только что опубликовали собственность из "alice@example.com" дружественное имя, ни с кем из участников Bitcoin видящих ничего, кроме обычной сделки Bitcoin
- Боб хочет послать Алисе несколько монет; он повторяет ripmend160 хэширования и попадает в unspendable адрес
- Боб просматривает его blockchain для затрачивает на этот адрес; он ожидает, что blockchain правильно индексироваться для таких сканирований быть дешевым
- Он считает, что единственными неизрасходованные сделки, сделанной Алисой, таким образом, получает ее открытый ключ
- Он контакты реле сервер @ example.com, и использует открытый ключ ECDSA Алисы, чтобы вырезать средний человек из цикла:
   - Метаданные транзакции передаются на сервер ретрансляции как блобы, шифруются для частного ключа с использованием ECIES Алисеса игровых
   - Каждый адрес ранее загруженный Алиса на сервер ретрансляции подписан, поэтому Боб может иметь полную уверенность Алиса получает деньги

Используя эту схему, Алиса поддерживает хорошую частную жизнь (она выпускает версию хешированной ее адрес), и не должна доверять релейный серверу с нее деньгами или персональными данные.

Что произойдет, если Мэллори находит дружественный адрес Алисы, и передает ее собственную транзакцию base58 (ripemd160 ("alice@example.com") + Контрольная сумма), с ее собственным открытым ключом? Боб должен принять только первую действующую сделку, и игнорировать более поздние. Это имеет тот недостаток, что если Алиса теряет свои первоначальные ключи, "alice@example.com" непригодна для вечности. Более сложная схема может быть разработана, где обновление, аннулирует и повторное использование может быть включено.

Как насчет адреса colisions? Ripemd160 80 бит сопротивления столкновения должны предложить достаточную защиту от случайных столкновений; за преднамеренные столкновения, мы точно в предыдущих ситуациях, и протокол должен предотвратить его.

Там, как представляется, по крайней мере, два аналогичных, но несовместимые схемы делать то, что я предложил выше как "наивный подход", Здесь я думал, я оригинален:

• https://en.bitcoin.it/wiki/BIP_0015
• http://ecdsa.org/bitcoin_URIs.html

Судя по обсуждение в списке рассылки, BIP15 было отложено, потому что не было четкого способа проверки подлинности сервера ретрансляции (псевдоним). HTTPS не достаточно.
Электрума предложение пытается сделать некоторую проверку подлинности, используя неопределенный "доверенный", Не очень полезно.
Если мы можем определить хороший способ публикации Публичных Алисы в blockchain и использовать его в дальнейшем для аутентификации и шифрования обмена, мы делаем прогресс на пути к рабочему протоколу. разрушение монет и спамить должны быть сведены к минимуму или нулю.