Тонкий клиент и OP_RETURN

Я хотел бы лучше понять, как работает легкий клиент. Насколько мне известно, легкий клиент хранит локально только заголовки блоков (каждый по 80 байт) и получает новый заголовок блока в среднем каждые 10 минут.

У меня по сути два вопроса:

1) Как легкий клиент может получить транзакцию по ее хэшу? Я хотел бы вернуть полную транзакцию, чтобы прочитать данные после кода OP_RETURN.

2) Как легкий клиент может быть уверен, что полученная транзакция действительно является транзакцией в самой длинной цепочке блоков? Он просто проверяет, есть ли уже подтвержденные 5 блоков после блока транзакции?

Большое спасибо

Ответы (1)

1) Самый простой способ в рамках протокола, вероятно, состоит в том, чтобы добавить этот хэш транзакции в фильтр Блума, отправить фильтр Блума на удаленный узел filterloadи запросить каждый отфильтрованный блок. Это отправит вам только интересующую вас транзакцию. (Также будет отправлено несколько дополнительных транзакций, которые соответствуют фильтру Блума, поскольку они являются ложными срабатываниями.) См. BIP37 для получения более подробной информации о том, как работает эта функция. Вот как легкие клиенты на основе BitcoinJ находят транзакции, соответствующие им.

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

2) Нет. Они получают заголовки блоков для всей лучшей цепочки. Это идет от блока генезиса до текущей вершины. (В настоящее время это 450000*80=36MB) Затем они проверяют, что соответствующий блок находится где-то в этой цепочке.

Спасибо вам за разъяснение! Могу я также спросить вас, каковы минимальные требования к тонкому клиенту с точки зрения оперативной памяти и процессора?
Почти ничего. Строго говоря, вам даже не нужно сохранять все заголовки блоков после того, как вы проверили, что они связаны с блоком генезиса. Вы можете оставить только верхушку цепочки и те, которые вас интересуют. Основная проблема с тонкими клиентами заключается не в ресурсах, которые они используют, а в их неспособности проверить, действителен ли блокчейн.
Хорошо, теперь я понял. Чтобы убедиться, что блокчейн действителен, нам нужны полные блоки со всеми транзакциями, так что полный узел, верно?
Верно. Вам нужны все блоки для обеспечения соблюдения правил, таких как запрет на использование одного и того же вывода дважды.
Привет, @nick, если я тонкий клиент (bitcoinj) и знаю как , так tx_hashи block_number, какое сообщение мне нужно отправить своим сверстникам, чтобы вернуть полную транзакцию?
@ gatb27 Как только вы узнаете block_hashи tx_hash, вы отправляете фильтр Блума с расширением filterload. Затем вы отправляете getdataс типом запроса MSG_FILTERED_BLOCKи хэшем блока. Это документирует детали низкого уровня. en.bitcoin.it/wiki/Protocol_documentation#Inventory_Vectors Позвольте мне посмотреть, смогу ли я разработать для вас пример кода.
Я только что изучил различные типы сообщений в руководстве для разработчиков :) Я хотел бы попросить последнюю услугу: меня интересует фрагмент кода на питоне (jython для биткойнj), который с учетом tx_hashи block_numberвозвращает шестнадцатеричный код после OP_RETURN в выводе tx_hash. Где я могу найти руководство по обучению, как это сделать? :)
Тонкий клиент и OP_RETURN
СпросиСетьПолитика конфиденциальности1y, 0v