Las claves públicas de ECDSA parecen comenzar siempre con 0x02/ 0x03/ 0x04/ 0x05 1 , seguido de 32 bytes o 64 bytes.
Sin embargo, encuentro algunas claves públicas con el prefijo 0x00.
Por ejemplo, la salida de origen de la transacción 5c7c65bb950d3605cc67bd02c29e84cc14dfaa80626ef6a575132c7ce7979d2f contiene dos claves públicas:
037953dbf08030f67352134992643d033417eaa6fcfb770c038f364ff40d761588
0014fa6851313844da08b6a539aff5e74e705b7465fad0fc5ceeccae707995b846
Cuando se incorpora a EC_KEY_oct2keyla función de OpenSSL 1.1.1, la segunda clave pública falla directamente.
Otro ejemplo es la transacción f0020466ca75caa648cdc8364f297bda7bb06329bec5305ffb59ea2ea348ac39 , que usa una salida que enumera una clave pública como esta:
0029a38fa2eaf8e67481c47eeeaeb625e6d426eb78f3b9e0728a4679370ce5ac96
Estas 0x00claves públicas parecen venir siempre OP_CHECKMULTISIGy nunca bloquean la validación porque alguna otra clave pública sería válida.
¿Qué son estas claves y qué debe hacer un cliente con ellas?
Estas no son claves, son datos arbitrarios.
Hasta Bitcoin 0.16, se permitía una clave pública inválida en el multisig desnudo , siempre que fuera del tamaño correcto. Con la próxima versión 0.17, esto ya no es posible y las transacciones como las que vinculó se considerarán no estándar (tenga en cuenta que esto no impide que se incluyan en un bloque y seguirán siendo válidas si se incluyen).
La gente a menudo ha usado tales trucos para incrustar datos en la cadena de bloques. Por ejemplo, proporcionar 1 clave válida y 1 no válida en un multisig 1 de 2 le permite a alguien incrustar 33 bytes de datos, sin sacrificar el BTC encerrado en la billetera.
Un ejemplo más extremo de esto está en tx fc200f9cef8faf8f76756b5d02081061a1fd22ec1d580f778c12373e12a56016 , que contiene "claves" como 100000000000000000000000000000000000000000000000000000000000000000.
(ejemplo de tx de este problema )
andreas blaesus
0x02o0x03?Raghav Sood