я думал, что было бы неплохо иметь ненадежный способ смотреть балансы адреса без необходимости загружать весь blockchain. я прочитал в bip37, что существует проблема, когда злонамеренный удаленный узел может пропустить операции, и нет никакого способа для тонкого клиента, чтобы знать это произошло:
котировка
Таким образом, сообщение merkleblock является блок заголовок, плюс часть Merkle дерева, которое может быть использовано для извлечения идентификационной информации для операций, которые соответствовали фильтру и доказать, что данные согласования сделки действительно появляются в решаемой блоке. Клиенты могут использовать эти данные, чтобы убедиться, что удаленный узел не подавая им фальшивые сделки, которые никогда не появлялись в реальном блоке, хотя лежал через упущение все еще возможно.
В настоящее время я не знаю, если эта проблема была решена. я гугл за него и ничего не нашел, так что в течение оставшейся части этого поста я не буду предполагать ...
один способ обойти это может быть, чтобы найти адрес на blockchain.info или blockexplorer.com и проверить баланс, что один является правильным, а потому, что никакие операции отсутствуют в клиенте. Однако это не практично для большого сайта электронной коммерции, который генерирует много адресов автоматически. я предполагаю, что API вызовы могут быть использованы, но все же ... я не нравится идея доверять третьей стороне, когда деньги на карту.
и вы могли бы сказать, что веб-сайт электронной коммерции должны быть загрузив полную версию blockchain - что бы решить эту проблему. но как-то это кажется немного расточительно требование ко мне - особенно, если другие варианты.
У меня была идея, и я думал, что я буду видеть, что люди думают об этом. во-первых, безопасность имеет первостепенное значение, поэтому очень важно, чтобы blanaces быть подтверждено клиентом с помощью blockchain, а не какой-то "доверенный" третье лицо. поэтому я думаю, что если тонкий клиент хочет установить свой баланс, он должен загрузить соответствующие операции, отсеченную Merkle дерево для блока, и все заголовки блоков. я думаю, что это уже, как все тонкие клиенты не работают - так что никаких проблем там.
но проблема заключается в определении того, какие операции и обрезка дерева Меркла скачать - и, в частности, в обеспечении того, чтобы полный список этих данных обеспечиваются. так что мое мышление было то, что адресная книга может быть построена с использованием Merkle дерева адресов и их данные corrsponding поиска, а затем корня этого адресной книгой дерева может быть включено в blockchain где-то - скажут coinbase txin, в другом месте в заголовке Bitcoin или даже в слиянии добывал blockchain как namecoin (это позволит избежать изменений в протокол Bitcoin и клиенты могут легко загружать все заголовки namecoin в дополнении к Bitcoin заголовков, как это мало). так как это последний вариант - использование namecoin blockchain - является наиболее вероятным решением этих 3, я буду считать, это в течение оставшейся части этого поста.
полные узлы namecoin будет иметь возможность проверить это "адрес корневой книга Merkle" восстанавливая его для себя, и, возможно, это может быть даже частью протокола namecoin отклонять блоки, которые содержали неправильно "Bitcoin адрес корни книги Меркла", точные детали этого адресной книги мне неизвестны, но упрощенный пример будет выглядеть следующим образом:
Код:
{
Bitcoin address1: [Bitcoin blockhash11, Bitcoin blockhash12, Bitcoin blockhash13, ...],
Bitcoin address2: [Bitcoin blockhash21, Bitcoin blockhash22, Bitcoin blockhash23, ...],
...
}
таким образом, всякий раз, когда тонкий клиент хочет, чтобы загрузить сделки по конкретному адресу он может сделать запрос в адресной книгу (содержатся на многом namecoin полных узлов я предусматривающие), чтобы получить конкретные блоки, где его операция, а затем запросить указанные блоки регулярной путь через сеть. на самом деле только конкретные TXS в этом блоке не требуется, но для простоты предположим, его весь блок на данном этапе.
namecoin шахтеры могли вычислить корень Merkle всех адресов пути добавления адреса самого последние Bitcoin блока в дерево Merkle и держать столько адрес филиалов обрезки, как можно дальше от предыдущего экземпляра базы данных для уменьшения хеширования (поскольку список Bitcoin адресов огромен) ,
и для того, чтобы удаленные узлы не лежат бездействие, когда тонкие клиенты просят их список адресов, минимальные ветви проверки дерева адрес Merkle может быть поданы на тонкий клиент, так что он может вычислить адрес-Merkle-корень самого по себе и сравнить его со значением в заголовке блока.
дружественные комментарии приветствуются. может быть, эта проблема уже решена каким-либо другим образом, что я не в курсе, и выше низшая решение? дай мне знать...