Transacciones multisig después de taproot
Jithin Zachariah
Antes de taproot, cuando teníamos una transacción multisig, el vout tenía una matriz de direcciones (Imagen 1). Ahora, esta transacción multisig en Bitcoin core v22.0 se representa solo como un tipo multisig sin el campo de dirección (Imagen 2). Desde mi comprensión básica, taproot mejora la forma en que se firman las transacciones multisig con la firma de Schnorr. ¿Cómo se representan las direcciones en vout? ¿Se abstraen de la misma manera (ocultando el campo de dirección) como se hace para las transacciones multisig pre-taroot? Gracias de antemano.
Imagen 1:
Imagen 2:
Respuestas (1)
pieter wuille
Esto no está relacionado con la raíz principal.
El campo de "direcciones" en la salida RPC de Bitcoin Core era un legado histórico que, en el mejor de los casos, estaba desactualizado y, en el peor, era confuso. Desde la versión 22.0, el campo ha quedado obsoleto por completo, para todos los tipos de salidas de transacciones. Se puede volver a habilitar (temporalmente) usando -deprecatedrpc=addresses, pero en 23.0 desaparecerá por completo. Mi sugerencia es que no lo uses, porque incluso cuando funciona, probablemente no signifique lo que crees que significa.
En la interpretación moderna, una "dirección" es una notación abreviada legible por humanos para un "script de bloqueo" específico (scriptPubKey) que se puede colocar en los resultados de las transacciones. Incluso cuando la salida codifica una política multisig, solo hay una secuencia de comandos de bloqueo y, por lo tanto, solo una dirección.
La interpretación histórica (antes de la introducción de BIP16 en 2012, pero duró mucho más) era que una dirección es un identificador de una clave pública. Esta interpretación es lo que llevó a tener un campo de "direcciones" en la salida de RPC; siempre que haya una secuencia de comandos de bloqueo con varias claves públicas, el identificador de "dirección" de cada una se informará en ese campo RPC.
Esta interpretación histórica no tiene sentido ahora, y lo ha sido durante mucho tiempo. La razón es que las salidas multisig hoy en día no colocan varias claves en scriptPubKey. En su lugar, usan P2SH (BIP16) o P2WSH (BIP141) para colocar solo un hash del script que incluye todas las claves públicas en scriptPubKey. Esto es más barato, más simple y algo más privado. A partir de dichas salidas, a pesar de ser una política multisig, la salida de RPC no puede inferir las claves públicas individuales, porque solo las revela el gastador al pasar el tiempo, y para tales salidas, la RPC aún solo informaría 1 dirección.
No es diferente para las salidas P2TR (taroot). No hay claves públicas individuales que se puedan aprender de scriptPubKey y, por lo tanto, la salida de RPC solo informaría una sola "dirección" (la dirección P2TR).
¿Existe un esquema de firma múltiple que no necesite copias de seguridad de xpub?
¿Hay alguna manera de crear una billetera mulstisig con bloqueo de tiempo desde bitcoin-cli? [duplicar]
Dado que OP_VER nunca se usó, está deshabilitado y no se considera útil, ¿se puede quitar su significado y convertirlo en OP_SUCCESS?
Si retraso la actualización a la última versión de Bitcoin Core después de la activación de Taproot, ¿mi nodo alguna vez verifica los gastos iniciales de Taproot?
Taproot y grandes multisigs
Compatibilidad con descriptores multigrado taproot
¿Qué impide que un gasto de Taproot siga las antiguas reglas de Taproot (inicialmente tratadas como cualquiera puede gastar) preactivación creando una activación posterior a la reorganización?
¿Podemos experimentar en Signet con múltiples bifurcaciones blandas propuestas mientras mantenemos la capacidad de los nodos completos para validar la cadena de Signet?
¿Se podría usar CHECKSIGADD en nuevas firmas múltiples ECDSA en lugar de CHECKMULTISIG?
Lista de bloques huérfanos (no referenciados)