No se puede hacer con la infraestructura actual. Podemos imaginar dos soluciones.

Primera solución: actualizaciones de Bitcoin

El script se vuelve progresivamente más poderoso con nuevos códigos de operación. En este caso, creo que en realidad tendría que haber un nuevo índice de conjunto UTXO (que los nodos ni siquiera calculan actualmente) para que el script pueda encontrar todos los pagos a una dirección en particular/con un marcador en particular y reflexionar sobre ellos. Luego, podría hacer que la gente invirtiera dinero en salidas con scripts que digan en pseudocódigo:

• Si ha pasado un cierto tiempo
• Haga la búsqueda de UTXO para encontrar todas las salidas etiquetadas como para la parte A
• Realice la misma búsqueda para la parte B
• Analícelos y súmelos para averiguar cuál ganó. El conjunto de instrucciones existente puede o no ser lo suficientemente bueno para esto, pero volver a habilitar los códigos de operación que fueron desactivados por pánico hace mucho tiempo no parece imposible: solo necesita buenas pruebas unitarias.
• Luego, utilizando el resultado de ese cálculo, solicite una firma originada por la dirección ganadora

Entonces, la arquitectura del script podría hacer esto, con una extensión y algunos de los códigos de operación deshabilitados que se vuelven a habilitar. Pero la verdadera pregunta es: ¿debería hacerlo?

La principal desventaja de permitir este tipo de cosas es que calcular los índices de la base de datos necesarios es computacionalmente intensivo y ralentizará los nodos, lo que los hará más costosos de ejecutar y perjudicará la escalabilidad de Bitcoin.

La ventaja es que esta construcción sería auditada y verificada por cada participante de la red, que es la mejor seguridad que puede tener en Bitcoin.

Para este caso de uso particular, probablemente sentiría que los costos superan los beneficios. La construcción es, en mi opinión, bastante extraña y poco convincente. Sin embargo, es posible que a alguien se le ocurra un caso de uso para OP_LOOKUP_OUTPUTS que realmente sea convincente, y hemos estado hablando siempre sobre hacer que los nodos calculen más índices sobre el conjunto UTXO. Si terminamos haciendo eso por otras razones de todos modos, en ese momento exponerlo a través de Script no parece un gran salto y hacer que esta construcción sea un contrato inteligente "puro" sería posible (fácil, incluso).

Segunda solución: red de Oracle

Desde que comenzó Bitcoin, ha habido un debate sobre el equilibrio entre la simplicidad y el poder en los contratos de secuencias de comandos. Bitcoin tiene un lenguaje de secuencias de comandos bastante restrictivo, en parte porque en los primeros días se descubrió que no estaba lo suficientemente bien probado y abierto a vulnerabilidades de seguridad, y reducir la energía no utilizada era una forma rápida de estabilizar el núcleo.

Ethereum es exactamente lo contrario, le da a los scripts un enorme poder y acceso a muchas capacidades costosas, como ranuras de almacenamiento de datos. Qué tan seguro es, qué tan resistente a los ataques DoS, etc., es actualmente una pregunta sin resolver, pero sabemos por amarga experiencia con Bitcoin, Java, Flash, HTML/JS, etc. que el código móvil de sandboxing es extremadamente difícil. Van a tener mucho trabajo por delante. Se ha descubierto que todos los sandboxes de código móvil que conozco tienen agujeros en algún momento, por lo que nadie ha logrado hacer lo que Ethereum quiere hacer sin exploits recurrentes. Es por eso que la comunidad de Bitcoin es tan conservadora con el aumento del poder de Script.

Sería ideal si de alguna manera pudiéramos crear dos sistemas de secuencias de comandos, uno simple/trivial que administre el movimiento de dinero en la red central y otro más poderoso en el que las brechas de seguridad solo afecten a las personas que usan esas funciones en lugar de a todos.

Hay un par de maneras en que podemos hacer esto en Bitcoin.

Una es tener una red p2p independiente de oráculos:

https://en.bitcoin.it/wiki/Contracts#Trust_minimization:_multiple_independent_oracles

En este caso cada oráculo tiene una identidad y la gente paga hasta un umbral de firma de oráculos preseleccionados. Cada oráculo ejecuta el programa de forma independiente y luego firma con su clave privada si el programa tiene éxito.

El problema aquí es que no tienes mucha agilidad. Los oráculos no pueden ir y venir de la misma manera que los mineros.

Otra es usar una cadena lateral, cuando dicha tecnología esté disponible. En este caso, la cadena lateral no contiene monedas y no es necesaria la vinculación bidireccional. Más bien, las "transacciones" de la cadena lateral simplemente afirman que se ejecutó un programa y se cumplió. Luego, los oráculos "minan" la cadena lateral, lo que demuestra que una mayoría de hashpower ejecutó el script y obtuvo el resultado esperado.

Una forma final es utilizar SNARK, cuando dicha tecnología esté disponible.

El atractivo de las cosas de sandboxing de esta manera es que si, por ejemplo, se encuentra un exploit de escape de sandbox en la implementación dominante de Oracle, resultaría en que las salidas bloqueadas de Oracle se vuelvan robables, pero no cualquier otra salida de Bitcoin, por lo que el riesgo está contenido.

El diseño de Ethereum, por el contrario, une las cosas con más fuerza. Un exploit en el motor de contratos de Ethereum podría resultar en la ruptura de todo el sistema.

No hay capacidad en el lenguaje de secuencias de comandos de Bitcoin para acceder a los datos relacionados con la cadena de bloques que no están incluidos en la transacción o en la secuencia de comandos de salida que la transacción está tratando de gastar. Básicamente, esto significa que no podrá calcular ni comparar el saldo total de direcciones en el script.

Necesitará un intermediario externo que pueda evaluar qué parte tiene más bitcoins en su cuenta.