EL LIBRO DE SATOSHI Primero: me pone un poco nervioso que bitcoin tenga un lenguaje de scripting, aunque es un lenguaje de scripting realmente simple (no hay bucles, no hay punteros, nada excepto matemáticas y criptografía) Me pone nervioso porque es más complicado y la complicación es la enemiga de la seguridad. También hace más difícil crear una segunda implementación compatible. Pero creo que lo puedo asumir. Repasando el código, las nuevas transacciones se verifica poniendo la firma y la clave pública sobre la pila del intérprete y ejecutando el script TxOut (¿lo he entendido bien?). ¿Podría escribir código para crear transacciones con cualquier script válido en el TxOut? Por ejemplo, ¿podría crear una TxOut con un script de: OP_2DROP OP_ TRUE. . . para crear una moneda que cualquiera pudiera gastar? Y, ¿es esta flexibilidad en los tipos de monedas creadas la razón de estar programado de esta manera? _____________________________________________________________ La naturaleza de Bitcoin es tal, que una vez publicada la versión 0.1, el diseño base estará escrito en piedra para el resto de su vida. Por esta razón quise diseñarlo de tal manera que soportara cualquier tipo de transacción que pudiera pensar. El problema era que, cada una requería campos de datos y código específico así se utilizara o no, y sólo cubría un caso especial cada vez. Hubiera sido una explosión de casos especiales. La solución fue el script, que generaliza el problema de tal manera que las partes involucradas en la transacción pueden describir su transacción como un predicado que los nodos evalúan. Los nodos sólo tienen que entender la transacción hasta el punto de evaluar si las condiciones del emisor se cumplen. El script es de hecho, un predicado. Es sólo una ecuación que devuelve verdadero o falso. Predicado es una palabra larga y poco común así que lo llamé script. El receptor del pago comprueba el script con una plantilla. Por ahora el receptor sólo acepta dos plantillas: pago directo y dirección bitcoin. Futuras versiones podrán añadir más plantillas para más tipos de transacciones y los nodos que ejecuten esas versiones o superiores podrán recibirlas. Todas las versiones de los nodos de la red pueden verificar y 147

SOBRE UNA VARIEDAD DE TIPOS DE TRANSACCIONES añadir cualquier nueva transacción a un bloque, aunque no sepan interpretarlas. El diseño admite una tremenda variedad de posibles tipos de transacciones que diseñé hace años. Operaciones de depósito en garantía, contratos en condiciones de servidumbre, arbitraje de terceros, firma multipartita, etc. Si Bitcoin evoluciona a lo grande, estas son cosas que querremos explorar en el futuro, pero todas han tenido que diseñarse al principio para asegurarse de que sean posibles de usar más tarde. No creo que, una segunda implementación compatible de Bitcoin sea una buena idea. Gran parte del diseño depende de que todos los nodos obtengan exactamente los mismos resultados así que una segunda implementación sería una amenaza para la red. La licencia de MIT es compatible con todas las demás licencias y usos comerciales, por lo que no es necesario volver a escribirla desde el punto de vista del licenciamiento. Una segunda versión sería un gran problema de desarrollo y mantenimiento para mí. Ya es bastante difícil mantener la compatibilidad con versiones anteriores mientras se actualiza la red sin una segunda versión. Si la segunda versión fallara, la experiencia del usuario se reflejaría negativamente en ambas, aunque al menos reforzaría a los usuarios la importancia de permanecer con la versión oficial . Si alguien estuviera preparándose para bifurcarse a una segunda versión, tendría que advertir sobre los muchos riesgos de usar una versión minoritaria. Este es un diseño donde la versión mayoritaria gana si hay desacuerdo, y eso puede ser bastante feo para la versión minoritaria y prefiero no entrar en eso, y no tengo que hacerlo siempre que haya una sola versión. Lo sé, a muchos desarrolladores no les gusta que bifurquen su software, pero en este caso tengo reales razones técnicas. _______________________________________________________________ Cita de: gavinandresen, 17 de junio 2010, 07:58:14 PM Admiro la flexibilidad del esquema de scripts en una transacción, pero mi pequeña y malvada mente inmediatamente comienza a pensar en maneras de abusar de ello. Podía codificar todo tipo de información interesante en el script TxOut, y si los clientes no pirateados validaban y luego ignoraban esas transacciones, sería un canal de comunicación 148