Sr.Elemento
Madmaxista
- Desde
- 30 Mar 2011
- Mensajes
- 16.093
- Fruta
- 48.502
Bien, vamos a darle una vuelta de tuerca más al asunto.
Como seguro ya sabéis, Bitcoin permite programar y liquidar en su sistema (no tan)sencillas aplicaciones. Estas aplicaciones son lo que comunmente los usuarios llamamos (erróneamente) "transacciones".
Las transacciones están compuestas por unos "inputs", que hacen referencia a transacciones que existieron con anterioridad, y unos "outputs" que son las nuevas direcciones donde van a ser enviados los bitcoins de los inputs, junto con las "condiciones" que los propietarios de las nuevas direcciones deberán cumplir para poder gastarlos.
Esa definición es la definición clásica de transacción en el mundillo.
Pero con el nuevo enfoque del hilo vamos a cambiarla. Ya hemos dicho que las transacciones ya no son transacciones, son aplicaciones. Y los bitcoins no son "dinero", sino derechos transferibles para tener el privilegio de poder programar y liquidar una futura transacción en el sistema.
Visto de este modo, la explicación de qué es una "transacción" cambia notablemente. Ahora, los inputs que introduces en una transacción son los "derechos" de escritura que te fueron otorgados previamente, los outputs son los derechos de escritura que tú decides otorgar en el futuro (junto con las condiciones que deberá cumplir escrupulosamente aquel que quiera ejercer dichos "derechos") y la demostración matemática de que tú mismo cumples con los requisitos y condiciones que se te exigieron previamente en los inputs para poder estar programando y ejecutando esta aplicación (=transacción) en la red de Bitcoin.
Así pues, tenemos inputs, outputs, condiciones que te fueron exigidas y condiciones que exiges tú para el futuro.
Esas "condiciones" son los scripts que os he linkeado en posts anteriores y pueden contener instrucciones (OP_CODES) bastante variadas y que dan mucho juego para poder emplear a Bitcoin en aplicaciones no monetarias. Aquí teneis el link de nuevo:
Pero hay algo más que tenemos que saber para salirnos fuera del terreno "standar" de Bitcoin. Os he dicho que hay inputs, outputs y condiciones. Y que esas condiciones aceptan muchas y variadas posibles instrucciones. Bien, además de eso, se puede diferenciar en la programación sobre qué inputs y outputs deben actuar esas condiciones,. ¿Cómo? A través de las 6 opciones que nos ofrecen las "Signature Hash Types".
Son estas seis opciones:
SIGHASH_ALL: la que solemos utilizar por defecto. Firma todos los inputs y todos los outputs de la transacción, protegiéndola a toda ella frente a posibles modificaciones.
SIGHASH_NONE: firma todos los inputs, pero ninguno de los outputs, permitiendo a cualquiera el cambiar dónde van dirigidos los bitcoins, simpre y cuando no existan otras "Signature hash types" en la transacción que firmen los outputs, protegiéndolos.
SIGHASH_SINGLE: el único output que se firma es el correspondiente a este input, asegurando que nadie pueda cambiar tu parte de la transacción (este input y su correspondiente output), pero permitiendo a los demás participantes el cambiar su parte de la transacción.
SIGHASH_ALL/ANYONECANPAY: firma todos los outputs, pero sólamente este input, permitiendo a cualquiera añadir o quitar los demás inputs, de forma que cualquiera puede contribuir añadiendo bitcoins a la transacción pero sin poder cambiar, ni dónde van dirigidos, ni en qué cantidad.
SIGHASH_NONE/ANYONECANPAY: firma únicamente este input y permite a cualquiera el añadir o quitar tanto inputs, como outputs, así que cualqiera que tenga esta transacción podrá gastarla como quiera.
SIGHASH_SINGLE/ANYONECANPAY: firma este input y su correspondiente output. Permite a cualquiera añadir o quitar otros inputs.
Es importante conocer qué diferencias ofrecen estos seis tipos de "Signature Hash Types" porque son buena parte de la sal y la pimienta en la programación de aplicaciones no monetarias en Bitcoin. Seguiremos hablando de ellas en el futuro.
Como seguro ya sabéis, Bitcoin permite programar y liquidar en su sistema (no tan)sencillas aplicaciones. Estas aplicaciones son lo que comunmente los usuarios llamamos (erróneamente) "transacciones".
Las transacciones están compuestas por unos "inputs", que hacen referencia a transacciones que existieron con anterioridad, y unos "outputs" que son las nuevas direcciones donde van a ser enviados los bitcoins de los inputs, junto con las "condiciones" que los propietarios de las nuevas direcciones deberán cumplir para poder gastarlos.
Esa definición es la definición clásica de transacción en el mundillo.
Pero con el nuevo enfoque del hilo vamos a cambiarla. Ya hemos dicho que las transacciones ya no son transacciones, son aplicaciones. Y los bitcoins no son "dinero", sino derechos transferibles para tener el privilegio de poder programar y liquidar una futura transacción en el sistema.
Visto de este modo, la explicación de qué es una "transacción" cambia notablemente. Ahora, los inputs que introduces en una transacción son los "derechos" de escritura que te fueron otorgados previamente, los outputs son los derechos de escritura que tú decides otorgar en el futuro (junto con las condiciones que deberá cumplir escrupulosamente aquel que quiera ejercer dichos "derechos") y la demostración matemática de que tú mismo cumples con los requisitos y condiciones que se te exigieron previamente en los inputs para poder estar programando y ejecutando esta aplicación (=transacción) en la red de Bitcoin.
Así pues, tenemos inputs, outputs, condiciones que te fueron exigidas y condiciones que exiges tú para el futuro.
Esas "condiciones" son los scripts que os he linkeado en posts anteriores y pueden contener instrucciones (OP_CODES) bastante variadas y que dan mucho juego para poder emplear a Bitcoin en aplicaciones no monetarias. Aquí teneis el link de nuevo:
Tienes que estar registrado para ver este contenido
Pero hay algo más que tenemos que saber para salirnos fuera del terreno "standar" de Bitcoin. Os he dicho que hay inputs, outputs y condiciones. Y que esas condiciones aceptan muchas y variadas posibles instrucciones. Bien, además de eso, se puede diferenciar en la programación sobre qué inputs y outputs deben actuar esas condiciones,. ¿Cómo? A través de las 6 opciones que nos ofrecen las "Signature Hash Types".
Tienes que estar registrado para ver este contenido
Son estas seis opciones:
SIGHASH_ALL: la que solemos utilizar por defecto. Firma todos los inputs y todos los outputs de la transacción, protegiéndola a toda ella frente a posibles modificaciones.
SIGHASH_NONE: firma todos los inputs, pero ninguno de los outputs, permitiendo a cualquiera el cambiar dónde van dirigidos los bitcoins, simpre y cuando no existan otras "Signature hash types" en la transacción que firmen los outputs, protegiéndolos.
SIGHASH_SINGLE: el único output que se firma es el correspondiente a este input, asegurando que nadie pueda cambiar tu parte de la transacción (este input y su correspondiente output), pero permitiendo a los demás participantes el cambiar su parte de la transacción.
SIGHASH_ALL/ANYONECANPAY: firma todos los outputs, pero sólamente este input, permitiendo a cualquiera añadir o quitar los demás inputs, de forma que cualquiera puede contribuir añadiendo bitcoins a la transacción pero sin poder cambiar, ni dónde van dirigidos, ni en qué cantidad.
SIGHASH_NONE/ANYONECANPAY: firma únicamente este input y permite a cualquiera el añadir o quitar tanto inputs, como outputs, así que cualqiera que tenga esta transacción podrá gastarla como quiera.
SIGHASH_SINGLE/ANYONECANPAY: firma este input y su correspondiente output. Permite a cualquiera añadir o quitar otros inputs.
Es importante conocer qué diferencias ofrecen estos seis tipos de "Signature Hash Types" porque son buena parte de la sal y la pimienta en la programación de aplicaciones no monetarias en Bitcoin. Seguiremos hablando de ellas en el futuro.
Última edición: