Открытые ключи ECDSA всегда начинаются с 0x02/ 0x03/ 0x04/ 0x05 1 , за которыми следуют 32 байта или 64 байта.
Однако я сталкиваюсь с некоторыми открытыми ключами с префиксом 0x00.
Например, исходный вывод транзакции 5c7c65bb950d3605cc67bd02c29e84cc14dfaa80626ef6a575132c7ce7979d2f содержит два открытых ключа:
037953dbf08030f67352134992643d033417eaa6fcfb770c038f364ff40d761588
0014fa6851313844da08b6a539aff5e74e705b7465fad0fc5ceeccae707995b846
При вводе в EC_KEY_oct2keyфункцию из OpenSSL 1.1.1 второй открытый ключ напрямую дает сбой.
Другим примером является транзакция f0020466ca75caa648cdc8364f297bda7bb06329bec5305ffb59ea2ea348ac39 , в которой используется вывод, содержащий открытый ключ, подобный этому:
0029a38fa2eaf8e67481c47eeeaeb625e6d426eb78f3b9e0728a4679370ce5ac96
Эти 0x00открытые ключи, кажется, всегда поставляются с OP_CHECKMULTISIGпроверкой и никогда не блокируют ее, потому что какой-то другой открытый ключ будет действительным.
Что это за ключи и что с ними делать клиенту?
Это не ключи, это произвольные данные.
До версии Биткойн 0.16 недействительный открытый ключ допускался в голом multisig , если он имел правильный размер. С грядущим 0.17 это больше невозможно , и транзакции, подобные тем, на которые вы ссылались, будут считаться нестандартными (обратите внимание, что это не мешает их включению в блок, и они по-прежнему действительны, если включены).
Люди часто использовали такие уловки для встраивания данных в блокчейн. Например, предоставление 1 действительного и 1 недействительного ключа в мультиподписи 1 из 2 позволяет внедрить 33 байта данных, не жертвуя BTC, заблокированными в кошельке.
Более ярким примером этого является tx fc200f9cef8faf8f76756b5d02081061a1fd22ec1d580f778c12373e12a56016 , который содержит «ключи», такие как 100000000000000000000000000000000000000000000000000000000000000000.
(пример тх из этого выпуска )
Андреас Блесус
0x02или0x03?Рагхав Суд