TL;DR : где в этом коде клиент SV выясняет, что он не обрабатывает блокчейн ABC?
Это изображение вызвало мой вопрос.
Существует несколько различных несовместимых друг с другом ( во всяком случае, я предполагаю ) реализаций клиентского программного обеспечения для криптовалюты Bitcoin Cash...
Мой вопрос предполагает, что каждая реализация обрабатывает свои соответствующие транзакции, используя схожие, но несовместимые друг с другом правила обработки блокчейна.
Нормально ли запускать реализацию клиента Bitcoin Cash SV в сети Bitcoin Cash ABC? И наоборот? Как же тогда одна реализация узнает, что сеть, в которой она работает, совместима с ее конкретными правилами обработки?
Ни один из клиентов конкретно не проверяет, находится ли он в неправильной цепочке: у BCH и BSV было нечистое разделение.
Ни сетевая магия, ни формат транзакций не изменились, поэтому их узлы продолжали обмениваться данными, а транзакции можно было воспроизводить из одной сети в другую. Как упоминает MCCCS , две сети начали следовать различным лучшим цепочкам, когда каждая сторона включала транзакции, которые были недействительны для другой сети. На тот момент полные узлы все еще были подключены к смеси узлов обоих протоколов. Они получали объявления о блоках любой цепочки. Когда они загружают первый блок с новыми кодами операций, которые были разрешены только для того или иного протокола ( OP_MULиOP_DATASIGVERIFY), узлы попытаются проверить блок и сочтут блок другого протокола недействительным. В этот момент они заблокируют узел, предложивший недопустимый блок, и заменят одноранговое соединение другим соединением. Я думаю, что тогда они, по крайней мере, отключат или полностью забанят любой новый пир, который также следует (с точки зрения этого узла) недопустимой цепочке, когда они подключаются. Это, по-видимому, вызвало обмен одноранговыми узлами с обеих сторон, пока каждый узел в конечном итоге не установил достаточное количество соединений с узлами, использующими тот же протокол, что и они сами.
Скриншот, на который вы ссылаетесь, был опубликован примерно через десять дней после разделения, поэтому реорганизация топологии, возможно, все еще продолжалась на тот момент (или скриншот был создан за несколько дней до того, как он был (повторно) опубликован). В частности, сервисы, отслеживающие заполнение узлов, также могли запускать специальные узлы-сканеры, которые на самом деле не работали с полным программным обеспечением узла и, следовательно, не объявляли блоки, поэтому они, возможно, отставали, замечая разделение топологии.
Они не делают.
У них разные, но иногда общие правила консенсуса. Есть два конкурирующих блока fork с разными правилами упорядочения транзакций и некоторые транзакции с одним OP_MULили OP_DATASIGVERIFY. Один из блоков действителен для этого клиента, за ним следует множество действительных блоков. Иногда они обрабатывают транзакции обеих сетей, поскольку защита от повторного воспроизведения не является обязательной. Они просто обрабатывают, если что-то действительно, или нет, если это не так.
алгоголик
MCCCS