Я знаю, эта нить старая, но я пришел к нему, а затем нашел пример хэша транзакции, находящийся в нескольких не-раздвоенных блоках в блоке-цепи. Блоки, которые содержат транзакции с хэш
d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599
являются 91812 и 91842. Пока предыдущие выходы сделки все были израсходованы, этот двойной хэш сделка считается действительной. Если какой-либо из адресов, полученных BTC от сделки в блоке номер 91812 не потратил свои монеты еще, это было бы недействительным.
Это известная ошибка в первые дни Bitcoin. Я не думаю, что можно больше, чтобы иметь 2 coinbase сделки с той же хэш транзакции.
Это была не ошибка, но первоначальный проект.
BerkeleyDB, который был использован в проекте тогда не было никаких проблем обработки записей без уникальных ключей.
После ухода Satoshi, ребята, которые взяли на себя разработку заменили BerkeleyDB с LevelDB. И LevelDB работает только с уникальными ключами.
Тот, кто принял решение тогда, видимо, не заботиться об обработке без уникальных идентификаторов больше (в действительности только coinbase может иметь не уникальные идентификаторы), так что они существенно изменили протокол блока цепи в этой точке. Что было хорошее решение, имхо, так как там были только 2 TXS, как это в то время как архитектурное усложнение сохраняя обратную совместимость не будет, а стоит это 100 BTC, для которых, скорее всего, никто не имеет ключа в любом случае.
Это не что первый раз, когда я прочитал дезинформацию об этом было быть предполагаемой ошибкой.
Вы, ребята, лучше получить ваши записи прямо, потому что на самом деле это была не ошибка - таков был первоначальный дизайн и оригинальная реализация не имела никаких проблем с обработкой же идентификаторы TX.
Затем в блоках версии 2 они начали требовать значения высоты блока внутри coinbase, что делает его теперь невозможно повторить предыдущую TXID, даже если шахтер действительно хотел.