В документе « О положениях о конфиденциальности фильтров Блума в облегченных биткойн-клиентах » говорится о фильтрах Блума в SPV:
...Действительно, в текущих реализациях клиентов SPV [BitcoinJ] как адреса, так и их открытые ключи вставляются в аутсорсинговый фильтр Блума. Таким образом, если злоумышленник знает и адрес, и его открытый ключ, то он может тривиально проверить, является ли адрес истинным положительным результатом фильтра, проверив, вставлены ли в фильтр и адрес, и его открытый ключ. Если нет, то велика вероятность, что адрес является ложным срабатыванием фильтра. Мы считаем, что включение как адреса, так и его открытого ключа в фильтр Блума является серьезным недостатком в текущих реализациях клиента SPV, и его можно легко устранить.; таким образом, мы не используем этот недостаток в нашем анализе. Фактически, более 99% всех биткойн-транзакций состоят из платежей на биткойн-адреса (или хеш открытого ключа); более того, только 4587 из 33 миллионов адресов в системе получили транзакции, предназначенные как для их открытых ключей, так и для их хэшей открытых ключей. Это означает, что для подавляющего большинства биткойн-клиентов нет необходимости включать в фильтры Блума как открытые ключи, так и их хэши (т. е. биткойн-адреса); вставки одного или другого будет достаточно (более чем в 99% случаев). [мой акцент]
Идея этой атаки была повторена в статье « Конфиденциальность в BitcoinJ» :
Уязвимость заключается в том, что если публичный ключ действительно находится в фильтре, то запрос и pubkey, и pubkeyhash должен вернуть true. Поскольку pubkeyhash — это просто еще одна почти равномерно случайная строка, вероятность ложного срабатывания для злоумышленника составляет fp' = fp^2 = 0,0000000021555. Я получил около 56 миллионов публичных ключей из блокчейна (середина января), что теоретически дает 56 миллионов * fp' = 1,29 ожидаемых ложных срабатываний при сканировании блокчейна.
Другими словами, достаточно простой атаки, чтобы выбрать все открытые ключи из фильтра BitcoinJ Bloom.
Добавляет ли текущая версия BitcoinJ открытый ключ и его хеш-значение в фильтры Блума? Если нет, какой выпуск предотвратил это?
Кроме того, почему в первую очередь были добавлены как открытые ключи, так и хэши?
Добавляет ли текущая версия BitcoinJ открытый ключ и его хеш-значение в фильтры Блума? Если нет, какой выпуск предотвратил это?
Да. Следующий код реализует это:
/** Inserts the given key and equivalent hashed form (for the address). */
public synchronized void insert(ECKey key) {
insert(key.getPubKey());
insert(key.getPubKeyHash());
}
Кроме того, почему в первую очередь были добавлены как открытые ключи, так и хэши?
Я не тот парень, который это написал (Майк Хирн). Тем не менее, я предполагаю, что трудно сказать, будут ли депозиты на адрес в форме P2PKH или P2PK. Плата за открытый ключ действительно редкость, но это законно. Имея выбор между пропажей части денег его клиентов по загадочным причинам или ограничением их конфиденциальности, он выбрал последнее.
Теперь, если вы спросите, почему filterloadбы просто не взять HASH160 ключа, прежде чем сравнивать его с фильтром Блума, чтобы тонкий клиент мог одновременно искать и хэш, и ключ, я не знаю. Похоже, это решило бы проблему, упомянутую в этой статье, за довольно разумное количество процессорного времени. Я бы обвинил автора BIP37 , но это написал тот же парень.
Если клиент SPV хочет отслеживать баланс своего кошелька, он должен отслеживать как входящие средства — транзакции с выходами, содержащими хэш открытого ключа кошелька (биткойн-адрес), так и исходящие средства — транзакции со входами, имеющими открытый ключ кошелька в их фирменный сценарий. (Конечно, клиент SPV должен отслеживать все публичные ключи/адреса, сгенерированные кошельком.)
Можно сказать, что отслеживание исходящих средств дублирует функцию автоматического обновления фильтра Блума, но я предполагаю, что здесь используется синхронизация SPV с произвольной высотой блока.