На картошках как Чапай расскажу.

С самых первых версий Биткойн-клиента проверка ECDSA-подписей производилась просто и тупо: подключаем при сборке библиотеку OpenSSL (наверняка слышали про такую), вызываем оттедова функцию "sign" когда надо подписать и "verify" когда надо проверить подпись. Вернула функция true -- значит проверка прошла успешно, вернула false -- значит неуспешно.

Пока всё понятно? Никаких дурных предчувствий нет? Так и надо программировать?

Так нельзя. Нельзя полагаться на то, что авторы OpenSSL не изменят (из лучших своих побуждений) работу вызываемых нами методов и тем самым "случайно залетевший дятел не разрушит нашу цивилизацию". А в той библиотеке действительно есть что менять. Функции не проверяли (и скорее всего до сих пор не проверяют) валидность передаваемых им значений. Можно вызвать проверку подписи (а для этого мы в метод передаем три значения: сообщение, публичный ключ и саму подпись) и функция вернет либо true если подпись верна, либо false если подпись не верна.

Логично? Тогда в чем же подвох?

А если вместо публичного ключа туда засунуть что-то другое? Набор байтиков, которые никак не могут быть публичным ключом? Ни в мирное время, ни в военное?

Так вот, разработчики BitcoinCore решили, что такое недопустимо. И решили, что клиент будет сперва проверять, что публичный ключ -- это публичный ключ в международно-признанном формате (а не в том, про который вчера решила левая пятка коммиттера OpenSSL), а подпись -- это подпись, и никаких сусликов! И если скрипт предъявляет вместо пубкея мусор, то транзакция сразу считается невалидной, а не просто не прошла проверка одной подписи.

Ну заодно и сами переписали код из OpenSSL и вообще (к настоящему времени) избавились от этой библиотеки. Где кроме ECDSA ещё миллион тонн всякого ненужного биткойну говна. И тащить что-то опенсорсное в свой любимый клиент вообще говоря опасно. Мало ли что там на гитхабе выложили? Кто из вас код смотрел и бэкдоры искал? Поднимите руки! Я вижу лес поднятых рук!

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

Ну с тех пор это правило было внесено в консенсус, а мои несколько центов стали "технически экспроприированы".
Дальше показывать? Или сами найдете на mempool.space где в этом адресе дырка от бублика в том месте где должен находиться публичный ключ?