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

Я обнаружил, что существует (бета) библиотека называется XPIR которые могут быть в состоянии улучшить это. Он использует гомоморфное шифрование, чтобы позволить сервер, чтобы иметь базу данных, какие клиенты могут запросить, но без сервера или любых слушателей, зная, какие записи в базе данных клиент запрашивает / прием. Таким образом, клиенты могут запросить сервер (в зашифрованном виде), "пожалуйста, дайте мне все операции, связанные с адресом ____", И сервер будет в состоянии предоставить эти данные, не зная ничего о запросе клиента. Это позволит значительно улучшить личную жизнь.

Запуск сервера будет довольно ресурсоемким, так что это не то, что каждый полный узел будет делать. Тем не менее, было бы целесообразно для серверов Электрум, сайты, как GreenAddress и т.д.

На самом деле я не пробовал программное обеспечение, но глядя на бумага, вот как я думаю, было бы работать на техническом уровне:

 - База данных, которая запрашиваться должна быть структурирована индекс -> стоимость, где индексы должны быть последовательными целыми числами, начиная с 0, и клиенты могут запросить только для определенных показателей. Таким образом, первый шаг для сервера, чтобы опубликовать отображение между всеми возможными запросами scriptPubKey и их indicies. Это может быть сделано путем хэширования каждого scriptPubKey видел в блоке цепи (возможно, с групповыми символами для обработки дел, как стелс-адреса), сортировки хэш, и давая каждый из них последовательного индекса. Все клиенты должны загрузить это первоначальное отображение. Если хэш составляет 128 бит, а индекс составляет 64 бит (оба из них может быть сокращены, возможно), в настоящее время отображение будет около 10,3 МБ с сегодняшними 429K уникальных адресов. Каждый получает то же самое отображение, так что нет никакой необходимости, чтобы загрузить его в каком-либо специальных анонимно.
 - Эффективность базы данных снижается с количеством записей. Вот, "записи" это число возможных запросов scriptPubKey. Таким образом, каждый сервер должен фактически иметь несколько баз данных XPIR, каждый из которых будет содержать, возможно, около 100000 возможных scriptPubKeys. Информация о том, какие scriptPubKey диапазоны относятся к какой базе данных также должны быть загружены клиентами, но это незначительное количество данных. Каждая база данных должна начать свои индексы 0, поэтому клиент должен будет регулировать глобальный индекс вниз в соответствии с которым база данных это запрос. Разделение на scriptPubKeys как это позволяет серверу знать, что клиент имеет некоторые адрес в этом диапазоне, но есть достаточное количество адресов, чтобы сделать это не-очень-полезными. Клиент также может послать фиктивные запросы сорвать даже это.
 - Клиент просто послать один запрос для каждого адреса в своем бумажнике. Для каждого из них, они получают все сделки по адресу наряду с его Merkle ветви связывая его с блочной цепи. Из стр.14 бумаги XPIR, это выглядит, как вы можете очень грубо ожидать, чтобы загрузить данные транзакций на 12,5 Кб / с, с задержкой между первым запросом и исходными данными транзакционных 10-500 секунд, в зависимости главным образом от скорости загрузки клиента. Эти скорости кажутся ОК.
- Если клиенты заинтересованы только в адресах, которые в настоящее время имеют BTC, вы можете значительно уменьшить размер базы данных, и, следовательно, повысить эффективность. Кроме того, размер базы данных может быть уменьшен для клиентов, которые были онлайн на некоторое время, и поэтому они заинтересованы только в новых / последних блоках.
 - Я не уверен, сколько клиентов разумный сервер мог удобно обрабатывать. Если это не очень много, то серверы, возможно, придется взимать плату за это. Может быть, они могли бы иметь свободные очереди, а затем возможность оплаты без очереди. Они могут использовать маркеры ослеплен принимать микроплатежи анонимно. В настоящее время библиотека XPIR, кажется, не очень оптимизирован, особенно для нескольких одновременных клиентов, поэтому повышение производительности, вероятно, возможно.

Мысли?