У меня была идея о том, как увеличить сделки секретность с чем-то я звонил "Перечисленные адреса."  Примерно через неделю после того, как у меня была первоначальная идея, это была размещена: .  Я также нашел а также  http://bitslog.wordpress.com/2012/08/06/destination-address-anonymization-in-bitcoin/ также. Все, которые по существу содержит мою идею, в той или иной форме, и все они гораздо более конкретизированы.

Несмотря на то, другие имели идею первых, я полагаю, суммируя свою мысль здесь все еще стоит пост.

Первоначальный импульс пришел, когда читал газету Сатоши. В статье рассказывается, как адреса могут стать связаны друг с другом: "Некоторое сшивание еще неизбежное с несколькими входами операциями, которые обязательно показывают, что их входы принадлежали одному владельцу."  То есть, если все мои адреса имеют меньше монет, чем мне нужно отправить, мне нужно будет объединить несколько адресов в поле ввода. В общем, это очень сильный индикатор, что входные адреса были принадлежат одному человеку.

Мы могли бы вместо того, чтобы отправить монеты в отдельных операциях. Однако, если мы не хотим, адреса, связанный друг с другом, сделки должны быть распределены во время. В противном случае было бы последовательность операций, направленных на тот же адрес примерно в то же время - достаточно, чтобы снова связать отправки адреса. (Хотя и не так сильно.)

Если каждый вход может использовать другой выходной адрес, мы не должны были бы распространяться операциями во время. Таким образом, нам нужно каким-то образом для получателя, чтобы отправить список адресов. Оказывается, что мы можем использовать свойство открытых и закрытых ключи в ECDSA, чтобы создать этот список связанных, или пронумерованные, ключи.

Все адреса Bitcoin основаны на ECDSA над эллиптической кривой secp256k1. Мы будем называть образующую группы, связанной с этой кривой «Г.» Закрытый ключ формируется путем выбора 256-разрядное целое число, «а», и открытый ключ, затем строится как «сания - генератор добавил к себе«а»раз. Оказывается, что при «а», легко вычислить Гаврилович ', но когда дано "сания трудно вычислить«а». Это несоответствие сложности является то, что позволяет нам определить криптографии с открытым ключом на этой группе.

Если у нас есть открытый ключ Гаврилович ', мы можем определить коллекцию "Перечисленные ключи," {(А + п) G: п = 1, 2, ..., M}, просто добавив 'G' открытого ключа для каждого нового адреса необходим. Добавление «G» для открытого ключа соответствует добавлению «1» к закрытому ключу. Более того, зная, что Гаврилович (а + 1) G, ..., и (а + M) G 'все действительные открытые ключи не помогают в поиске «а» - нет, даже если мы приведены действительные подписи каждый ключ. Таким образом, получатель платеж не должен предоставлять несколько адресов, он только должен обеспечить один. Когда транзакции будут отправлены, они не отправляется по известному адресу получателя платежа, а к перечисленным адресам. Получатель просто проверяет «(а + 1) G„(а + 2) G, ..., (а + M) G“, пока он не найдет адрес без каких-либо средств, отправленных ему в этот момент он знает, что он перечислил все адреса. 

К сожалению, до тех пор, как этот метод является открытым, аналитик может также вычислить ключи '(а + 1) G, (а + 2) G, ... и, таким образом, по-прежнему связывают входные адреса друг с другом. Таким образом, простое перечисление не работает.

Вместо этого, если бы мы использовали какое-то шпоночный генератор псевдослучайных чисел, ключи могут быть перечислены только если вы знали тайну. Например, если общий секрет, можно взять выход в HMAC в качестве следующего открытого ключа. То есть, допустим, у нас есть общий секрет, "пароль", Форма 256-битное число «с (п) = SHA256 ("пароль" || "N" || SHA256 ("пароль" || "N"))»И построить открытый ключ как '(A + S (N)) G'. (Это на самом деле не какая HMAC для, но это будет работать.) Таким образом, несколько адресов могут быть образованы из одного адреса, и до тех пор, как общий секрет остается секретом, что нет никакого способа угадать "перечисленных" ключи.

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

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

Я реализую проверку концепции в стандартном клиенте для этого, если кто-либо заинтересованы.