¿Podemos construir una UTXO que solo se pueda gastar a través de la prueba de trabajo?

¿Los códigos de operación actuales de Bitcoin y el límite de tamaño de transacción permiten construir un UTXO que solo se puede gastar si se ha realizado una cantidad específica de trabajo?

Entonces, el gastador proporcionaría un nonce como entrada al script. Luego, la secuencia de comandos esencialmente realizaría una versión muy simplificada de cómo se verifican los encabezados de bloque de bitcoin (el nonce se combina con algunos otros datos, se procesa y el hash se compara con un "objetivo").

Sin OP_CAT y con la aritmética limitada a entradas de 4 bytes, ¿entiendo bien que lo anterior sería imposible? ¿O hay alguna solución?

Puede agregar un retorno de operación a su tx con los primeros 200 bits de la clave privada. Un gastador tendría que moler los últimos 56 bits hasta encontrar la clave privada correcta para firmar. ¡Combínalo con multisig o Schnorr tweak para apuntar a un solo destinatario!
@cabeza de alfiler gracias! Esa es una forma inteligente de hacerlo. De hecho, se requeriría una prueba de trabajo para descubrir la clave. Sin embargo, en este caso, se garantizaría que todos terminarían esencialmente con el mismo "nonce" (que es solo la clave privada completa), entonces, ¿no podría un minero de la cadena principal robar la recompensa? O, dicho de otra manera, ¿puede aclarar qué quiere decir con usar, por ejemplo, multisig para que se dirija a un solo destinatario? Es decir, quien hizo el trabajo, pero también de manera que la UTXO original no necesitaba saber quién es el conjunto de trabajadores potenciales. ¿Tiene esto sentido?
Mmm eso es dificil Los mineros pueden robar cualquier cosa que no esté firmada. Pensé que podría enviar a un multisig 2of2 donde una clave es un destinatario conocido y la otra clave debe ser forzada (por ese destinatario) Un minero no podría robar eso.
De nuevo, muchas gracias por tu respuesta. Esto es extremadamente útil. Entonces, el desafío que tengo con esa construcción (el método 2 de 2 que propusiste) es que necesitaría saber la clave del destinatario con anticipación, que no es lo que quiero. ¿Hay alguna manera de que podamos encadenar una serie de este tipo de transacciones para lograrlo?
¿Cuál es la aplicación de esto? Tengo curiosidad por saber lo que estás tratando de lograr
hola @chytrik, gracias por tu interés. Hay un par de aplicaciones que se me ocurren. Sin embargo, el principal en el que estoy más interesado se elude en mi otra pregunta aquí bitcoin.stackexchange.com/questions/91069/… Básicamente, quiero determinar si hay alguna forma en que Bitcoin tal como está podría verificar incluso un solo encabezado de bloque de una cadena lateral puramente de prueba de trabajo (a diferencia de federada). La pregunta aquí entonces es solo una forma reducida de esa pregunta.

Respuestas (1)

La respuesta depende de lo que esté tratando de lograr con esta construcción. Tengo tres conjeturas al respecto:

  • un conjunto de destinatarios determinados puede gastar si realizan el PoW: puede tener una transacción que se puede gastar si alguien proporciona: un valor cuyo hash es menor que una cantidad específica (que determina la dificultad) Y una firma que describe el conjunto de permitido entidades (potencialmente cualquier multisig).
  • cualquiera que realice la prueba de trabajo puede gastar (Y puede gastar sin PoW): esto es más complicado ya que un PoW simple basado en hash no funcionaría, un minero puede simplemente cambiar la dirección de destino de la transacción de gasto a una bajo su control. Debe demostrar que conoce un secreto (el resultado del PoW) sin incluirlo en el tx para que los mineros no puedan tomar el dinero sin repetir el PoW: esto es lo que logran las firmas digitales. Como se sugiere en los comentarios, puede construir un utxo que se puede gastar firmando con cierta clave privada que solo usted conoce y que contiene parte de ella bajo unop_return. Entonces, uno tiene que probar cualquier clave privada en el conjunto de las permitidas hasta que pueda producir una firma válida. Esto no filtra la clave privada en sí, por lo que el minero no puede firmar el mismo tx con una dirección de destino diferente.
  • cualquiera que realice la prueba de trabajo puede gastar (Y NO puede gastar sin PoW): pensé en esto por un tiempo y no puedo encontrar una construcción fácil para esto, podría ser difícil incluso con capacidades de secuencias de comandos más fuertes que las de bitcoin. Mi mejor suposición es que tiene una clave pública probablemente aleatoria (por ejemplo, usando un VDF en el nonce del último bloque) y todos tienen que forzar la clave privada para gastar. Veo dos problemas principales: los mineros pueden tener alguna ventaja al seleccionar nonces para influir en la aleatoriedad del PK y es difícil ajustar la dificultad, necesita un esquema de firma personalizado que tenga el nivel de seguridad que desea y eso no es trivial con el script de bitcoin.

Esta NO es una lista completa, son solo las primeras ideas que me vinieron a la mente. Especialmente el segundo caso, que me parece más probable, se puede construir de varias maneras diferentes: por ejemplo, también podría publicar el hash de la clave privada en un ( op_returnpara que la clave privada no tenga que incluirse en la transacción ) y lo convertiría en un PoW basado en hash, ya que hash es mucho más rápido que firmar.

gracias por tu respuesta. Para el primer punto, menciona comparar si el hash es menor que cierto valor. Sin embargo, el hash es un número de 256 bits, pero las operaciones de comparación numérica en el script de bitcoin están limitadas a 32 bits. Entonces, ¿no estoy seguro de que esta opción funcione? Sin embargo, de sus escenarios, el tercero es el que estoy tratando de hacer: cualquiera realiza el trabajo Y no puedo gastar sin realizar también el trabajo. Hasta ahora estoy perplejo en él.
Había imaginado que el caso deseable es el tercero. No es una tarea fácil en absoluto. Me haces desprevenido en cuanto a la cuestión de la comparación numérica, pero a costa de escribir un guión increíblemente intrincado, supongo que puedes solucionarlo. Si tiene suficientes 32 bits de seguridad, puede tomar los últimos 4 bytes del hash y compararlos con el objetivo. De lo contrario, puede tomar los últimos dos bloques de 4 bytes y combinar dos comprobaciones.
Este es un enfoque interesante (aunque, como sugirió, parece que el guión puede terminar bastante inflado/intrincado). Sin embargo, creo que "tomar los últimos 4 bytes del hash" es donde puede fallar. Parece posible empujar 32 bytes (el hash) a la pila. Sin embargo, extraer 4 bytes a la vez y compararlos parece imposible, a menos que me equivoque. Nuevamente, gracias por sus pensamientos al respecto.
Definitivamente no soy un experto en secuencias de comandos de bitcoin, pero de un vistazo rápido parece que no es posible, no creo que pueda ayudar más. Podría ser más fácil con algo como un guión sin guión, pero realmente sé muy poco al respecto.
Sí, con las próximas actualizaciones (eventuales), algo como esto parece ser posible. Hasta entonces, yo tampoco estoy seguro. ¡Gracias por tus pensamientos hasta ahora!
Para construir la prueba de trabajo de una manera que también sea segura para los ataques de los mineros, aún puede hacer lo que se sugirió en el primer comentario. Puede agregar a un tx normal una salida que contenga parte de la clave privada. De esta manera, uno tiene que aplicar fuerza bruta a los bits restantes para poder producir una firma válida y los mineros no tienen una ventaja significativa. En este caso, el creador conoce la clave privada con seguridad, no hay forma de evitarlo. ¿Por qué no estás considerando esta dirección?
Perdón por el retraso. La razón principal por la que esa dirección es menos interesante para mí es precisamente porque el creador conocería la clave privada. Por lo tanto, no sería una 'competencia leal' entre aquellos que están tratando de completar el trabajo.
Si coloca claves privadas parciales en OP_RETURNs, ¿qué me impide "trolear" a todos al enviar transacciones similares con claves privadas parciales incorrectas ? "¡Jajaja, ustedes hicieron 2^56 trabajos gratis! ¡Imbéciles!"
Tal vez podría haber un hash de script de pago en el que el requisito para resolver la dificultad requiriera la extracción en el bloque producido más recientemente. Puede hacer que los mineros de la competencia hagan hash del bloque más reciente y necesiten encontrar un nonce que cree el nivel de dificultad compartida necesario para gastar la recompensa. De esa manera, solo podría haber un ganador después de cada bloque nuevo, la dificultad se puede ajustar por bloque y nadie podría "falsificar" una prueba de trabajo que cumpliera con estos requisitos. Si alguien proporciona una copia del último bloque con un nonce adicional adjunto que cumple con la dificultad de la competencia, devuelva verdadero.
Para elaborar, usar un bloque btc completo no es realista (¿a menos que tenga una versión comprimida?), Pero una prueba Merkle de los datos del bloque debería ser suficiente (que es básicamente una especie de suma de verificación comprimida). Aunque el tamaño de estos datos puede aumentar la dificultad de resolver una acción que debe tenerse en cuenta.
¿Podemos construir una UTXO que solo se pueda gastar a través de la prueba de trabajo?
RespuestasAquíPolítica de privacidad1y, 0v