Discusión general sobre SIGHASH_NOINPUT, OP_CHECKSIGFROMSTACK, and OP_SECURETHEBAG
Oradores: Olaoluwa Osuntokun, Jeremy Rubin
Fecha: June 6, 2019
Transcripción De: Bryan Bishop
Traducción Por: Blue Moon
Tags: Sighash anyprevout, Op checksigfromstack, Op checktemplateverify
Categoría: Core dev tech
SIGHASH_NOINPUT, ANYPREVOUT, OP_CHECKSIGFROMSTACK, OP_CHECKOUTPUTSHASHVERIFY, and OP_SECURETHEBAG
https://twitter.com/kanzure/status/1136636856093876225
Al parecer, hay algunos mensajes políticos en torno a OP_SECURETHEBA y “asegurar la bolsa” podría ser una cosa de Andrew Yang
SIGHASH_NOINPUT
Muchos de nosotros estamos familiarizados con NOINPUT. ¿Alguien necesita una explicación? ¿Cuál es la diferencia entre el NOINPUT original y el nuevo? NOINPUT asusta al menos a algunas personas. Si sólo hacemos NOINPUT, ¿empezará a causar problemas en bitcoin? ¿Significa que los intercambios tienen que empezar a mirar el historial de transacciones y poner en la lista negra NOINPUT en el historial reciente hasta que esté profundamente enterrado? Si enviamos un NOINPUT a alguien, ¿somos responsables de que pierda dinero o algo así? ¿Hay algún otro comportamiento extraño que pueda causar miedo?
NOINPUT es diferente a como han funcionado las sighashes, porque permite que las firmas sean reproducidas contra diferentes UTXOs con el mismo script pero diferente valor. La propuesta de cdecker de hace un año para NOINPUT lo restringía para que la firma se comprometa con el valor del UTXO que se está gastando, así que eso lo restringe un poco. Aunque, si su intercambio le está enviando 200 BTC en dos lotes de 100 BTC entonces eso no es suficiente protección tal vez. Cuando lo gastas, ¿no se gastaría a las mismas salidas? ¿A una dirección de cambio se le paga dos veces? Tal vez usted quiere enviar 5 BTC a alguien y oops supongo que accidentalmente pagó dos veces por lo que 10 BTC.
Una preocupación inicial es que debido a que son indistinguibles como un tipo de salida, no podemos decir, es esta una dirección que … lo siento si me estoy saltando por delante, pero la manera de pensar en ello es, este tipo de firmas NOINPUT son sólo cosas que están dentro de alguna aplicación o dentro de algún protocolo que se negocia entre los participantes, pero no cruzan dominios independientes donde se ve una cartera o un protocolo como una especie de dominio. No puedes decir la diferencia, ¿es esta una dirección que puedo dar a alguien más o no? Todo son scripts, no hay direcciones reales. Hay tipos de salidas que son completamente inseguras incondicionalmente; hay cosas que están protegidas y puedo dárselas a cualquiera, no quieres reutilizarla, pero no hay ningún problema de seguridad por hacerlo. Esta es una clase adicional que es segura perfectamente, pero sólo cuando se utiliza de la manera correcta. Básicamente estamos optando por una funcionalidad adicional y debes ser consciente de las ventajas y desventajas cuando lo haces. Cuando luke-jr dijo que quería escribir una cartera que sólo utilizara SIGHASH\NOINPUT, eso fue motivo de preocupación. Algunas personas podrían querer utilizar SIGHASH_NOINPUT como una forma de abaratar o reducir la complejidad de hacer una implementación de monedero. SIGHASH_NOINPUT es desde un punto de vista puramente procedimental más fácil que hacer un SIGHASH_ALL, eso es todo lo que estoy diciendo. Así que estás haciendo menos hash. Es mucho más rápido. Esa preocupación me ha llamado la atención y es algo que puedo ver. ¿Queremos evitar que la gente sea estúpida y se dispare a sí misma y a sus clientes en el pie? ¿O tratamos esto como un caso especial en el que usted marca que somos conscientes de cómo se debe utilizar y sólo tratamos de conseguir que la conciencia fuera?
¿Qué peligros existen como receptor de NOINPUT? Si recibo un pago con una firma SIGHASH_NOINPUT, podría reproducirlo y cobrar dos veces… bueno, eso no es un riesgo, es una ventaja. Si recibo un pago de un UTXO y ese UTXO fue autorizado con una firma NOINPUT, entonces si hay un reorg o si eso estaba en el mempool o algo, entonces esa firma seguiría siendo válida si hubo maleabilidad en el pasado, pero mi pago no. Pero esto requiere una larga reorg o locura, por lo que podría no ser plausible. ¿Quizás haya algún otro ataque que sea así?
Hay salidas etiquetadas, o firmas de acompañantes como formas de reducir el alcance de las repeticiones. Esas son las dos únicas ideas que tenemos hoy en día. La firma chaperona es cada vez que dices que una firma ANYPREVOUT NOINPUT en una transacción no es válida a menos que veas un SIGHASH_ALL en la misma entrada, una segunda firma. Todo se convierte en multisig, 2-de-2. Se vincula esa dirección en particular en el momento del gasto. El problema con el chaperón es que ya no podemos hacer agregación de firmas con ellos porque ahora tienen diferentes sighashes. Tienen que ser dos claves diferentes, de lo contrario usarías el sighash normal en la firma única.
El hecho de que puedas producir la firma del chaperón implica que no necesitas NOINPUT con la misma clave porque esas personas van a estar conectadas a la hora de firmar. No hay ningún problema con ello, pero no tiene sentido. Y ahora tienes doble tamaño de firma para todo; sí, es más grande pero no peor que el multisig existente. Así que es sólo para escenarios no cooperativos en primer lugar.
What’s the argument against chaperone signatures? Well you could just make it so that anyone can sign for it, so what’s the point. It’s cheaper to circumvent it with half of g. That’s only true if you have OP_CAT and you’re doing magic, and we don’t have OP_CAT yet.
¿Cuál es el mayor argumento en contra de las salidas etiquetadas? La idea de las salidas etiquetadas es que no tenemos NOINPUT ANYPREVOUT soportado para salidas taproot v1, en su lugar tenemos un segwit version 16 v16 que soporta taproot. La razón de v16 es que redefinimos bech32 para no cubrir v16. No hay direcciones para este tipo de salida. Si eres un intercambio y recibes una dirección bech32, la declaras inválida. Lo haces menos amigable para el usuario aquí; y no debería haber una dirección de todos modos. Puede que quieras verla en un explorador de bloques, pero no quieres pasársela a nadie.
Parece que si estamos haciendo salidas etiquetadas las firmas de los chaperones no aportan nada. Es una de dos. Las chaperonas no añaden nada en absoluto; no tiene sentido. Hay argumentos razonables para no hacerlo así. La forma más sencilla de satisfacerlos es prescindir de ellos. Si te comprometes con la pubkey para las firmas de los chaperones antes de tiempo…. si todos los que quisieran usar NOINPUT estuvieran convencidos de que hay un problema, entonces elegirían lo correcto, pero está claro que la gente no lo está. No es un mecanismo de defensa a pie de calle porque es fácilmente eludible, y es más fácil eludirlo que utilizarlo. Mientras que para las salidas etiquetadas, es que si quieres cualquier NOINPUT entonces debes etiquetar.
¿Dónde está la etiqueta? La desventaja de la versión etiquetada es que de repente no es fungible, y se puede distinguir de la taproot. No creo que el argumento de la fungibilidad sea muy fuerte porque al menos en los casos de uso imaginados ahora, estas salidas sólo se crearían en un entorno no cooperativo. También serían muy temporales. Así que serían barridos inmediatamente. Si miras la blockchain, sabrás bien que fue un cierre no cooperativo. También tendemos a cotillear sobre estas cosas. Ni siquiera es necesario ir tan lejos como redefinir bech32 para eliminar estas direcciones v16… el miedo imaginario creo que es, algo malo sucede, la firma NOINPUT de alguna manera se utiliza, como MtGox versión 2 o algo así, y los grandes jugadores y dicen wow esta nueva cosa taproot es aparentemente aterradora no vamos a apoyar el envío a ella, o no apoyar la recepción a ella o lo que sea. Creo que eso sería mucho más perjudicial que la fungibilidad de tener una versión separada.
¿Si hay una versión separada entonces no podría usar taproot y NOINPUT juntos? No, se pueden usar juntos. Incluso podría ser un byte más largo diciendo v16 es sólo salidas no direccionables, y el primer byte 0 que sigue significa que es taproot, pero la versión no direccionable o algo así. Así que incluso si usted no va tan lejos como no hacer una nueva dirección, el riesgo es que estas direcciones que son reconocibles son de miedo, frente a todo taproot es.
Dejando de lado ese argumento por un momento, usted dijo que ya se podía decir acerca de estos cierres no cooperativos y eso es lo que está pasando. ¿Hay alguna idea acerca de si algunas personas tienen formas de hacer que los cierres no cooperativos sean más indistinguibles? Con firmas de adaptadores y números de secuencia, sí. Puedes decir por el número de secuencia y el tiempo de cierre que es eltoo. No creo que el argumento sea que ya es reconocible, sino que esas salidas ya sólo se crean en la configuración no cooperativa. Bueno, ya sabes que se creó en el ajuste NOINPUT y eso lo hace reconocible. Pues no, nos importa la fungibilidad para el caso cooperativo no para el caso no cooperativo. En el caso no cooperativo en taproot, se rompe la fungibilidad también porque revelas los scripts así que ya vas a decirle al mundo lo que estás haciendo. Si hubiera un uso para la firma tipo NOINPUT, para un caso cooperativo, simplemente no lo he visto todavía. Podría haber alguna. Podrías usar una firma adaptadora Schnorr… para cooperativa taproot necesitas estar online para hacer la ceremonia de firma musig y mantener la fungibilidad.
¿Las salidas etiquetadas resuelven completamente el riesgo de repetición? Hace más evidente que puede ser reproducido, en lugar de descubrirlo más tarde. Sabes qué ruta de firma es reproducible. El acto de usar una firma sin entrada retroactivamente..
¿Qué hay de comprometerse con todas las veces anteriores que usas NOINPUT para que estés seguro de que lo quieren? Bueno, eso es malo para la validación. Consenso podría funcionar. Bueno, usted podría utilizar nonces como ethereum hace…. la otra repetición tiene que incrementar un número de secuencia cada vez. Eso es más carga para la verificación también. También es cierto que evitarlo es más fácil que usarlo.
¿Qué hay de la opinión de las empresas del sector sobre las salidas etiquetadas para NOINPUT? Todavía no.
Aparte de eltoo, ¿hay algún otro protocolo que espere usar NOINPUT? Hay algunas cosas de cartera donde tienes pactos simples con SIGHASH_NOINPUT. Desafortunadamente Bob no esta aqui. Podrías poner la firma en la salida de la transacción que la está gastando, porque no depende del txid. Así que tienes dos transacciones, una está gastando la otra, y ya puedes asumir el hash de la transacción, puedes asumir el sighash de la transacción antes de que se cree, o ya creaste, porque no gasta nada que pueda cambiar más. Creas una salida que tiene una firma que cubriría la siguiente transacción para donde irían los fondos. La firma está en el script testigo. Sí. No puedes hacer mucho con ella, es bastante débil. Russell encontraría algo. Una vez que agreguemos OP_CAT…. si no te comprometes con el script, entonces podrías hacer firmas de claves privadas probadamente desconocidas. Eso es divertido. Aquí hay una firma, y puedo mostrar que conozco la preimagen de la clave pública.
¿Alguien piensa que NOINPUT es realmente una mala idea? gmaxwell parece… Él está muy preocupado por las repeticiones, como un fallo de intercambio o un montón de dinero se pierde. Ese es su principal temor creo. Como un mtgox v2. Hay tres campos–quien aqui piensa que seria mas simple, YOLO tu culpa eres un niño grande por usar un nuevo sighash. ¿Qué pasa con el campo de salida etiquetada? ¿Estamos votando por un soft-fork? ¿O tienes que incluir todo el blockchain en la firma? Vale, nadie. Parece 50-50 entre YOLO y salida etiquetada. Es una bandera sighash de “niño grande”. Greg dijo que teníamos que meditarlo en 2015; y llevamos como seis años.
Parece que no hay una gran oposición a la idea de NOINPUT, es sólo una cuestión de cómo restringido debe ser. “Lo que pensábamos que le faltaba a bitcoin eran ataques de repetición”… En realidad alguien de Bitcoin Cash quería usar NOINPUT como una solución a la maleabilidad, pero en realidad lo empeora. Fue entonces cuando empecé a poner marcas de tiempo en mis correos, porque quería pruebas de que les había hablado de ello. Bueno, recibí una respuesta citándome, así que le puse la marca de tiempo. ¿Lo firmaron con PGP? Vamos, ¿qué saben ellos de eso de las firmas? Ah, NOINPUT para PGP, inventado para CSW.
Con salidas etiquetadas, podrías hacer ANYPREVOUT a través de la ruta de la llave también. Esto significa que no podrías usar NOINPUT dentro de p2sh porque en p2sh no revelas la versión testigo en la salida lo que rompería la protección. ¿Entonces necesitamos hacer segwit nativo? No creo que a nadie que quiera usar NOINPUT le importe esto. Oh, p2sh anidado si. La gente todavía va a buscar cosas en los exploradores de bloques.
¿Qué pasó con webbtc? Sí se rompió hace unos años como en 2014.
OP_SECURETHEBAG
Es una manera de hacer pactos. Usted podría hacer pactos con como CHECKOUTPUTVERIFY donde coincidencia de patrón en las salidas de sí mismos. Otra forma de jl2012 es empujar los elementos en la pila y se puede empujar en como v-tamaño de salida o el número de otuputs o el valor. Una tercera es que en lugar de tener un DAG de ejecución de la transacción en la que usted hace un checkoutputhash y luego un hash particular, y usted dice que el gasto de salida debe tener un hash particular a sí mismo. Así que a medida que serializar todas las salidas, tiene el valor y la secuencia de comandos. Usted puede decir algo así como, la primera cosa que el gasto de este debe tener un tamaño de salida de como 5 o algo así.
La suposición subyacente es que actualmente se puede gastar inmediatamente después de un cierto número de confirmaciones. Pero aquí usted puede recibir la confirmación de los fondos, pero se puede retrasar cuando usted necesita para hacer el pago. El pago y la liquidación se pueden hacer en momentos diferentes. Yo recibiendo las monedas puede ser separado de cuando necesito gastarlo. Así que te comprometes a algún DAG de transacciones futuras, y esto es lo que valida la confirmación. Una vez que se confirman, entonces puedo gastarlas.
Cuando combinas esto con taproot, puedes tener múltiples rutas de ramificación dependiendo de lo que suceda. Jeremy presentó esto para control de digestión control de congestión para retiros de cambio. Son “dividendos de libertad”. El intercambio puede desenrollarlos y pagar a todos en la misma salida, o pagar a la gente de uno en uno. Cuando vi esa idea, era escéptico sobre su uso. En ese caso, estás usando más espacio en bloque del que usarías al final. Además, las tasas son súper jodidas ¿no? ¿Si tienes que pagarlas todas por adelantado? Hay una forma de añadir tasas más tarde; te comprometes con toda la estructura creada a partir de esto. No puedes añadir tasas a posteriori debido a los compromisos. Pero podrías cambiar la propuesta para permitirle añadir múltiples aportaciones. Usted podría tener un pago inicial que no es timelocked en absoluto, pero con honorarios bajos que nunca podría confirmar; entonces usted tiene otro que paga honorarios más altos y es timelocked a una semana más tarde y sólo reduce su cambio. Así que también puedes hacer cosas así.
Es el pacto más restrictivo que se te pueda ocurrir; el hash debe coincidir. Digamos que le das a un bitconner unos 5 BTC. Para cuando gaste 5 BTC, debe pagarme el 1% de ese valor o algo así. Es un caso de uso extraño. Es un caso interesante. También puedes definir bóvedas con esto; cuando gastas esto, digamos que hay CSV para esta cantidad en particular. Es como una ejecución pre-planificada en lugar de un tiempo de ejecución haciendo nada en ese momento. Puede ser un montón de caminos aumentados con taproot. Usted puede obtener profundidad finita también. Tienes que hacer el hash, así que no puedes tener desconocido o script o valor, todo debe ser premeditado.
Todos a los que envías dinero necesitan ver el script completo; o su subárbol. Puede que haya otro camino que no resulte en que les paguen. No necesitan saber las cosas por debajo de ellos en el otro lado. Podría ser la firma menos testigo también, que muestra el camino taproot actual y continúa allí.
Es pactos, pero muy simple, y todavía se puede hacer cosas interesantes. Usted puede controlar cómo se gastan las monedas, sin tener una infección viral cosa. No puede infectar todas las monedas del mundo indirectamente o algo así. Así que es finito. Tienes que calcular de antemano lo que va a suceder. Tal vez podrías usar una función hash segura y así no hacer ciclos.
Bóvedas es un gran problema para la seguridad. Así que eso sería realmente genial. Hubo bóvedas, control de digestión, y también usted podría tener un pago de un intercambio si usted es una ballena y usted no tiene que revelar lo que las salidas van a en el momento de la retirada y usted podría revelar más tarde en algunas cantidades discretas y usted no tiene que publicar que por adelantado. Es una ocultación de commit-reveal o UTXO. Esto es generalmente útil para cualquier tipo de, pactos sólo realmente volar la cantidad de cosas que usted cna hacer con bitcoin script. Usted puede tener una garantía de ciertas cosas.
Puedes tenerlo totalmente enumerado y dices, soy estos 20 puntos finales y ahora puedo crear nuevas firmas en esos puntos finales y anticipar dónde van a crear nuevos árboles.
OP_CHECKSIGFROMSTACK
¿Y si eliminamos la secuencia de revocación con OP_CHECKSIGFROMSTACK? Están algo relacionados. Si vamos a hacer pactos, ¿por qué no una versión más potente? Si los pactos genéricos son el objetivo del diseño, en lugar del objetivo de OP_SECURETHEBAG cumple, son objetivos distintos. Si el objetivo es pactos genéricos, entonces no quieres hacerlo con OP_CAT y OP_CHECKSIGFROMSTACK en realidad quieres opcodes adecuados para inspeccionar partes de tus transacciones. El hecho de que esto se pueda hacer con esta piratería masiva de hash, quiero decir, tener ciertas características puede animar a la gente a empezar a pensar en qué tipo de cosas son posibles, pero rara vez la forma en que se hace es como realmente quieres que suceda en la producción. Personalmente creo que las cosas puestas en script deberían ser utilizables en producción y podemos pensar en cosas como qué sería posible sin que estuvieran ahí. Prefiero el caso de uso donde sabemos cómo hacerlo eficientemente y cómo querrías hacerlo. El hashing también es bastante sencillo. La pregunta debería ser, ¿hay casos de uso para OP_CHECKSIGDATAFROMSTACK que sean distintos de los pactos genéricos.
CHECKSIGFROMSTACK es un opcode. Ahora mismo en bitcoin tienes verificación de firma. CHECKSIGFROMSTACK dice que usted va a empujar cosas en la pila, hash, y entonces usted puede verificar arbitraria pubkey privkey pares. Puedes hacer esto para la delegación. Puedes verificar una clave pública y un checksig regular en la transacción misma. Pide una pubkey, y puedes delegarla a alguien más; o cualquier tipo de datos de oráculo externo. Digamos que estamos apostando por el precio, y tenemos la clave de Bitstamp hardcoded en el script. También hay otras construcciones para pagos probabilísticos, donde firmo un hash y hago comparaciones sobre eso para pagar a individuos particulares. También puedes hacer esto para revocaciones en lightning. Es como un 2-de-2 multisig; firmamos el número de secuencia de ese mismo estado. Decimos, preséntame un dato de secuencia firmado mayor que lo que sea, entonces podemos seguir adelante y avanzar. Esto permite obtener revocaciones de una forma más sencilla con números de secuencia firmados que avanzan. Podría ser sólo Schnorr. El CHECKSIGFROMSTACk puede ser m-de-n multisig. Puedo tener datos externos, o delegación, o diferentes formas de tener algún tipo de orden en el script basado en valores firmados del mundo exterior. Usted podría hacer una cosa oráculo umbral con CHECKSIGFROMSTACKADD?
Todas esas construcciones; mucho trabajo de gente como Tadge y Poelstra para hablar de formas en que podemos hacer cosas que son complejas fuera de la cadena con firmas de adaptadores o algo así. Pero esto suena como lo contrario. Pero CHECKSIGFROMSTACK te permite hacer cosas más complejas fuera de la cadena también.
Para eltoo, puedes usar CHECKSIGFROMSTACK en lugar del locktime. Las transacciones ya no tienen CLTV y pueden ser bloqueadas por tiempo. Es otra firma, pero ahora el locktime esta libre para otras cosas posiblemente. Ya no estamos limitados a mil millones de revocaciones, y ahora podemos hacer un poco más, podemos hacer cuatro mil millones ¿verdad?
OP_CAT y OP_CHECKSIGFROMSTACK también proporciona algunas posibilidades de pacto, creo que es realmente genial. Pero cada vez que añades estas cosas, hay esta propiedad emergente de cosas que no habías visto de antemano.
Para los números de secuencia con signo, en realidad se podría hacer mejor con un anexo. ¿Cómo podrías añadir un locktime sin usar un hard-fork? Podrías usar el anexo; podrías añadir un locktime relativo o absoluto mediante el anexo. Entonces el anexo sería el valor del locktime. Tienes que definir la semántica para la codificación de los datos dentro del anexo. Puedes tener un prefijo de un byte que diga que este es el tipo del anexo. Los tiempos de bloqueo por entrada serían mucho más flexibles y útiles para la iluminación. Sí, el anexo, no había pensado en eso. Eso es interesante. Así que ahora tengo una solución a algo, genial gracias. Genial, evitó un futuro hard-fork. Estaba pensando, tienes que cambiar el formato de transacción no hay otra manera pero supongo que no es cierto. O añadir cosas adicionales bajo la firma, ese es el anexo.
El hecho de que este anexo sea posible es un accidente; es debido a p2wsh y p2wpkh que podemos razonar sobre el último byte de los elementos de la pila, y si hubiéramos elegido otro tipo de codificación esto no hubiera sido posible. El primer byte del testigo no puede ser un opcode inválido, o tiene que ser una clave pública, y empieza por 2, 3, 6 o 7. Así que hay un par de bytes disponibles. Por eso la versión de la hoja se escoge de uno de esos prefijos. Es menos necesario que la versión hoja tenga esta propiedad que el anexo.
Nunca he oído hablar de un uso para un tiempo de bloqueo absoluto por entrada. Usted podría hacer mejor agregación probablemente. Puedes comprometer el bloqueo de tiempo y no puedes agregarlos con SIGHASH_SINGLE, pero serías capaz de satisfacerlos, serías capaz de agregarlos. Ahora mismo tenemos HTLCs que tienen un tiempo de bloqueo y no podemos combinarlos, pero si fuera sólo en la entrada entonces podríamos agregarlos y ahorrar espacio en la cadena. Tampoco tenemos que confirmarlos en el script HTLC. Este es un ejemplo de uso. Típicamente, quieres agregar diferentes entradas, y tienes firmas pre-firmadas, y entonces quieres SINGLE|ANYONECANPAY.
¿Qué pasa con la versión 2 de entrada mientras estamos en ello? Bueno, tenemos que con tapscript y todas esas otras cosas. ¿Alguna otra pregunta sobre CHECKSIGFROMSTACK?
OP_SECURETHEBAG de nuevo
Jeremy dio una charla en 2016 sobre unos pactos más poderosos; pero eran las ideas generales para los pactos. Creo que en ese momento tenía una idea y meditó durante un tiempo. La respuesta fue “demasiado poderoso, demasiado aterrador”. Este es el primero en el que decimos “sí, con eso no veo cómo podéis dispararos en el pie”. También con tapscript tienes una hoja de posibles caminos. Idealmente tienes un lenguaje donde puedes generar lo que quieres que sea, compilar tus transacciones, firmarlo, y moverlo en cadena. ¿Tanglescript? Porque es un DAG.
Antes podías pre-firmar transacciones; y con SECURETHEBAG no necesitan estar en línea. Está en la cadena, va a suceder. Y la gente puede tener ramas particulares para las que están preparados. Puede que quieras que la gente esté en línea para verificar que sus ramas son correctas.
¿Hubo una propuesta de salida etiquetada más completa? Sí, se discutió en la lista de correo en enero o diciembre. Por ahí.