BITCOIN: aplicaciones no monetarias

Excelente hilo y muy necesario.

Teniendo en cuenta que bitcoin reducido al mínimo es una hoja excel descentralizada y "automatizada", por decirlo mal y pronto, pues todos los usos que ahora tienen las bases de datos. Si además tenemos en cuenta que cualquier cosa o documento puede ser digitalizado y metido en una base de datos digital, pues salen más usos de los que uno pueda imaginar.

A bote pronto:

- Cámara de fotos que suba a la blockchain las fotos automáticamente. Muy útil en peritaciones. Por ejemplo, con fotos de antes y después de alquilar un coche o de antes de iniciar unas obras de metro en las viviendas circundantes. Sería como un notario dando fe, pero muchísimo más rápido e instantáneo.

- Fe notarial.

- Visados de colegios profesionales.

- Registro de la propiedad.

- Documento de identidad internacional con ADN. Esto da bastante miedo, pero por ejemplo se acabaría el cachondeito de los pagapensiones económicos sin papeles con canas en los bemoles diciendo que tienen 15 años.

- Seguros. Con los contratos inteligentes se puede meter todo el funcionamiento de una compañía de seguros en un software y poco más. Si acaso habría que digitalizar y estandarizar los certificados de defunciones, invalidez, accidente, robo, etc. Sin personal humano, sólo con contratos inteligentes.

- Banco con encaje del 100%. La función originaria y legítima de los bancos, no la que tienen ahora. Algo así como bitconnet pero sin estafa, en serio. Aunque no sé hasta qué punto es automatizable el análisis de riesgo. Se podría hacer como Air B'n'B supongo. Igual que los seguros, sin intervención de humanos, sólo con contratos inteligentes.

- Si se combina con la automatización de vehículos salen cosas alucinantes, además del taxi que dijo Antonopoulos, hay muchos más casos que ya entran casi en la ciencia ficción.
 
Última edición:
Hilo muy necesario, felicitaciones a elemento, voy leyendo y luego comento, el post inicial sencillamente magistral.

Congratulaciones
 
Hola elemento, muy interesante el hilo. ¿Qué pasa si la onza de oro la roba el mensajero y no puedes comprobar si era falsa o verdadera?
Por cierto, no funciona el enlace al hilo que comentas sobre este tema.

---------- Post added 18-ene-2018 at 23:56 ----------
FoSz2 dijo:
Excelente hilo y muy necesario.

Teniendo en cuenta que bitcoin reducido al mínimo es una hoja excel descentralizada y "automatizada", por decirlo mal y pronto, pues todos los usos que ahora tienen las bases de datos. Si además tenemos en cuenta que cualquier cosa o documento puede ser digitalizado y metido en una base de datos digital, pues salen más usos de los que uno pueda imaginar.

A bote pronto:

- Cámara de fotos que suba a la blockchain las fotos automáticamente. Muy útil en peritaciones. Por ejemplo, con fotos de antes y después de alquilar un coche o de antes de iniciar unas obras de metro en las viviendas circundantes. Sería como un notario dando fe, pero muchísimo más rápido e instantáneo.

- Fe notarial.

- Visados de colegios profesionales.

- Registro de la propiedad.

- Documento de identidad internacional con ADN. Esto da bastante miedo, pero por ejemplo se acabaría el cachondeito de los pagapensiones económicos sin papeles con canas en los bemoles diciendo que tienen 15 años.

- Seguros. Con los contratos inteligentes se puede meter todo el funcionamiento de una compañía de seguros en un software y poco más. Si acaso habría que digitalizar y estandarizar los certificados de defunciones, invalidez, accidente, robo, etc. Sin personal humano, sólo con contratos inteligentes.

- Banco con encaje del 100%. La función originaria y legítima de los bancos, no la que tienen ahora. Algo así como bitconnet pero sin estafa, en serio. Aunque no sé hasta qué punto es automatizable el análisis de riesgo. Se podría hacer como Air B'n'B supongo. Igual que los seguros, sin intervención de humanos, sólo con contratos inteligentes.

- Si se combina con la automatización de vehículos salen cosas alucinantes, además del taxi que dijo Antonopoulos, hay muchos más casos que ya entran casi en la ciencia ficción.
Hacer clic para expandir...
Aclarar que en la cadena de bloques no puedes subir documentos, sino un hash que demuestra que un documento existía en ese momento. Esto es necesario para no colapsar la cadena de bloques.

En cualquier caso, FoSz2, muy clara tu explicación.

Terminaré diciendo que, como supongo ya sabéis, Satoshi Nakamoto es Nick Szabo, quizá con la colaboración de Hal Finney. Sr. elemento, creo que Szabo sí que sabía que al fin había dado con la solución para crear una moneda digital distribuida, y por eso precisamente uso un seudónimo para proteger su identidad.
 
Última edición:
Muy buen hilo. Así a bote pronto:

-Compartir información incensurable y validada. Algo parecido a subir una película al Emule pero con la garantía de que no será rastreable y que nadie de los que la comparte altere o cambie el producto.

-Una conversación tipo walkie-talkie totalmente indescifrable (sólo con digitalizar y encriptar cada "cambio y corto").

-Libro de cuentas de una empresa u organismo grande con muchas sedes en diferentes sitios del mundo. Ello le posibilitaría tener información de sus cuentas, gastos y relaciones casi al segundo.

-Información varia subida a la blockchain en vez de a la Nube con muchísima más seguridad respecto a la perdurabilidad y privacidad de su contenido y su clave de acceso. Como si se suben secretos de Estado.

Todo sin salir de bitcoin. En sidechains, echándole un poco de imaginación, comprimiendo información a tope y con el tema bastante más evolucionado...

La verdad que da miedo. Por poder se puede hasta compartir material snuff horrendo sin ningún tipo de censura más que la aceptación de los nodos. La tecnología detrás de bitcoin tiene cualidades como para poner a prueba la humanidad. Es un poco como otra vuelta de tuerca de Internet.
 
Última edición:
Hasta que punto crees que es necesario que script pase a ser un lenguaje "Turing complete" para lograr cubrir el 100% de aplicaciones no monetarias?
 
djun dijo:
Este uso me parece muy interesante. Permite hacer intercambios o permutas entre particulares desconocidos en condiciones donde exista la mayor seguridad o confianza posible.


Pero no entiendo bien el concepto de cómo funciona. Es decir:

1. Por una parte, en una caja fuerte habéis depositado, digamos, una fianza o garantía (en Bitcoins), Tolomeo 1x y tú 2x.

2. Después él te envía 1 onza, tú la compruebas, la verificas. Y después le envías el pago por dicha onza (en bitcoins).

3. Si todo va bien se 'liberan' los bitcoins de la caja fuerte mediante una tras*acción en la que es necesaria la firma de los dos. (serán dos tras*acciónes de vuelta, supongo: 1x para Tolomeo, y 2x para tí).

Pero ¿qué sucede si recibes la onza, y no le pagas lo acordado a la otra parte? ¿La garantía que habíais depositado se pierde para ambas partes? ¿Esos bitcoins de la caja fuerte se quedan bloqueados? ¿Tolomeo, que te envió la onza, perdería también 1x depositado en la caja fuerte, mientras tú perderías 2x depositados en la caja fuerte?

De todos modos el sistema parece bueno y organizándolo a través de un árbitro, todo iría bien. O quien engañé se quedaría sin su garantía depositada, mientras que la otra parte la recuperaría.


Edito: El enlace que dejó elemento es éste (hay que eliminar "www."):
Economía: Hilo oficial del Bitcoin (VI) - Página 654
Hacer clic para expandir...

Vale, ya he arreglado lo del enlace.

Con respecto a lo de la "destrucción mutua asegurada", tal y como dice su nombre, si en algún momento alguna de las partes hace algo mal, perderán ambas partes irremediablemente. Voy a explicarlo con un ejemplo y paso a paso, para que lo veáis.

1.- Tú y yo acordamos hacer la compra-venta de una onza de oro por correo. Imagínate que eres tú el que me la quieres vender. Ni tú ni yo nos conocemos, vivimos muy lejos, no confiamos el uno en el otro, pero queremos utilizar la destrucción mutua asegurada para lograr que la tras*acción de la onza de oro llegue a buen término.

2.- Cualquiera de los dos puede programar la "caja fuerte" de Bitcoin, que no sería más que una dirección multifirma 2 de 2 Multisignature - Bitcoin Wiki formada por dos direcciones, una de las cuales estaría bajo tu control y la otra bajo el mío.

3.- ¿Cómo haríamos eso? Pues tú me darías a mi la clave una clave pública bajo tu control o yo te la daría a ti, es indiferente porque cualquiera de las dos partes puede construir la "caja fuerte". Una vez tienes las dos claves públicas, te vas a coinb.in=>new=>multisig address y allí insertas ambas claves públicas para construir una dirección multifirma que requiera necesariamente de ambas claves para poder gastar los bitcoins

4.- Una vez creada la "caja fuerte", vendría la parte crucial del intercambio: habría que construir una tras*acción que enviase allí A LA VEZ, unos bitcoins tuyos y los mios a razón de 1x para aquel que "envía primero" (bien la onza de oro o bien el pago, es indiferente) y 2x para aquel que "envía después".
Esta tras*acción se construye de la siguiente forma:

Cualquiera de las dos partes que intervienen en la tras*acción puede construirla. Una de las partes le pide a la otra que le comunique una dirección Bitcoin bajo su control (con acceso a las claves privadas) que tenga suficientes bitcoins como para realizar su parte del envío. Una vez tenga dicha dirección lo que haría es ir a coinb.in=>new=>tras*action y allí construiría una tras*acción con 2 inputs y 3 outputs.

Uno de los inputs sería su parte y el otro input sería la parte de la otra persona.

Los 3 outputs serían la caja fuerte (que, al ser multifirma, comenzaría por el número 3 en lugar del habitual 1), y después tu dirección de cambio y la mía (porque es muy posible que las direcciones de salida de bitcoins correspondientes a los inputs contengan bitcoins en exceso para la operación. Aquí habría que pagar comisiones a los mineros, así que habría que decidir previamente si las comisiones las paga una de las partes o se pagan a medias.

Una vez construida la tras*acción, el que la contruido firmaría su input y le haría llegar la tras*acción a la otra persona para que firmase el suyo y lo enviase a la red Bitcoin.

5.- Una vez enviados los bitcoins a la caja fuerte a modo de "garantía", aquel que ha tras*ferido la cantidad 1x enviaría primero. En el ejemplo de la tras*acción con Tolomeo, fue él el que puso 1x, así que él me envió la onza de oro por correo.

6.- Cuando me llegó la onza dos días después la comprobé y, una vez autentificada, le pregunté qué método de pago quería que yo emplease para pagársela. Él me inisitió en que quería bitcoins así que, en lugar de liberar los bitcoins de la caja fuerte en las mismas cantidades que depositamos inicialmente (1x él y 2x yo), los liberamos considerando ya el pago por la onza de oro (2x para él y 1x para mi).

7.- ¿Cómo realizamos esta tras*acción? Pues nos vamos a coinb.in=>new=>tras*action y construiríamos la tras*acción con inputs desde la dirección multifirma y con dos outputs. Uno de los dos output sería una dirección de mi propiedad y el otro output sería de la suya. Esta tras*acción tras*feriría los bitcoins ya teniendo en cuenta el pago de la onza de oro (1x para mi y 2x para él). Una vez construida, yo firmaría con mi clave privada y le haría llegar la tras*acción a Tolomeo para que él firmase con su clave privada y enviase la tras*acción a la red.


Bien ahora hagamos un análisis de qué ocurriría si algo hubiese salido mal durante la tras*acción.

Riesgos por cada fase:

- Envío de bitcoins a la caja fuerte:
Tolomeo 1x
elemento 2x

Si algo sale mal aquí, Tolomeo perdería 1x precio de la onza y yo perdería 2x

- Tolomeo me envía a mi la onza de oro:

Tolomeo 1x + onza de oro
Mojon 2x

Si algo sale mal en esta fase, Tolomeo pierde aproximadamente 2x (los 1x bitcoins más la onza de oro) y yo perdería 2x bitcoins.

- Recibo la onza de oro:

Tolomeo 1x + onza de oro
Mojon 2x - onza de oro (aquí l aonza de oro está en negativo porque, en caso de ser auténtica, yo la tendría en mi poder y se reduciría el riesgo al que estoy expuesto)

Si algo sale mal en esta fase, pueden ocurrir dos cosas. Si la onza de oro era auténtica pero se ha perdido por el camino, Tolomeo perdería 1x + la onza de oro y yo perdería 2x. Si la onza resultase ser una falsificación, él perdería 1x y yo perdería 2x.

- Yo realizo verifico la onza y realizo el pago:

Tolomeo 1x + onza de oro
Mojon 2x + pago de la onza de oro - onza de oro

Si algo sale mal en esta fase, pueden ocurrir dos cosas. Si el dinero que le he enviado a Tolomeo es auténtico yo perdería 2x + el dinero de la onza de oro - la onza de oro y él perdería 1x + la onza de oro. Si el dinero que le he enviado como pago fuera falso, él perdería 1x + la onza de oro y yo perdería 2x.

- Se liberan los bitcoins una vez finalizada la tras*acción:

Tolomeo 1x + onza de oro
Mojon 2x + pago de la onza de oro - onza de oro



Como vemos, en cualquier fase de la tras*acción, si algo saliese mal, perderían ambas partes SIEMPRE. Por eso mismo se llama "destrucción mutua asegurada".

Por cierto, cuando hablo de "perder" me refiero a que una de las partes se sentirá engañada y, por lo tanto, nunca firmará la liberación de los bitcoins que ambas partes depositaron en la caja fuerte a modo de garantía.

---------- Post added 19-ene-2018 at 10:04 ----------
MIP dijo:
Hasta que punto crees que es necesario que script pase a ser un lenguaje "Turing complete" para lograr cubrir el 100% de aplicaciones no monetarias?
Hacer clic para expandir...

Esto que nombras es casi, casi, lo que ofrece Ethereum. Digo casi, casi porque, si no recuerdo mal, Ethereum no llega a alcanzar un 100% de "Turing completeness", pero se queda cerca.

Sin embargo ¿cuál es el precio que tiene que pagar Ethereum para poder ofrecer eso? El enorme y continuo riesgo de que algo pueda salir mal en los contratos que se construyen y perder todo el dinero. Ya ocurrió en la DAO y, en mi opinión, jamás se debe revertir la cadena mediante un hardfork.

Bitcoin, sin llegar a alcanzar el grado de libertad en la programación que ofrece Ethereum, ya ofrece muchas y variadas posibilidades no monetarias. No creo que merezca la pena ampliar enormemente la ventana de posibles puntos de hackeo tal y como ha hecho Ethereum. Al menos no en la cadena de bloques de la capa 0. Soy de los que opina que hay que tener una capa 0 segura y descentralizada y luego ya, a partir de ahí, construir más capas que ofrezcan más posibilidades (y, desde luego, más riesgo).
 
Bien, vamos a darle una vuelta de tuerca más al asunto.

Como seguro ya sabéis, Bitcoin permite programar y ejecutar en su sistema (no tan)sencillas aplicaciones. Estas aplicaciones son lo que comunmente los usuarios llamamos (erróneamente) "tras*acciones".

Las tras*acciones están compuestas por unos "inputs", que hacen referencia a tras*acciones 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 tras*acción en el mundillo.

Pero con el nuevo enfoque del hilo vamos a cambiarla. Ya hemos dicho que las tras*acciones ya no son tras*acciones, son aplicaciones. Y los bitcoins no son "dinero", sino derechos tras*feribles para tener el privilegio de poder programar y ejecutar una futura tras*acción en el sistema.

Visto de este modo, la explicación de qué es una "tras*acción" cambia notablemente. Ahora, los inputs que introduces en una tras*acció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 (=tras*acció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:

Script - Bitcoin Wiki

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".

Developer Guide - Bitcoin

Son estas seis opciones:

SIGHASH_ALL: la que solemos utilizar por defecto. Firma todos los inputs y todos los outputs de la tras*acció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 tras*acció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 tras*acción (este input y su correspondiente output), pero permitiendo a los demás participantes el cambiar su parte de la tras*acció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 tras*acció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 tras*acció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:
La principal aplicación no monetaria es, IMHO, servir de prepago con trazabilidad de servicios ubicuos. Veamos un ejemplo:

Te montas en tu coche y quieres tener wifi y 4G triple B (bueno, bonito y barato). Tu consola te acepta la entrada de tokens INDE (qué pasa, yo tengo derecho también a tener un token a mi nombre) y esos tokens INDE tiene un valor variable en FIAT pero fija en GB de internete (fijas lo serían nominalmente, ya que si tienes 1GB nominal pero el proveedor te regala medio, elegirás ese proveedor), ya sea 4G o Wifi local. Esos tokens se irán gastando según consumas y podrías rechazar proveedores.

Las compañías venderán sus tokens marcados en el mercado y luego los usuarios podríamos navegar desde nuestros coches, estando en diferentes sitios con diferentes proveedores, todos aceptando los INDE como pago por el tráfico de datos, sin necesidad de tener contratos y pudiendo comprar tokens adicionales en cualquier momento.

Los proveedores locales y los troncales de alta capacidad liquidarían sus INDE entre ellos, ya que son trazables. Si en un sitio es más caro dar internete a cambio de tokens, el servicio sería asumido a pérdidas entre varias compañias, en base a un acuerdo de alcance de suministro que diluiría esa pérdida local entre varios.

Si una compañía pretende bajar precios del GB temerariamente, sus tokens INDE deberán ser aceptados en su salida a la venta por algún mecanismo de garantía, que posibilite que tenga que emitir tokens de reserva hasta, pongamos, un 50% sobre el valor de mercado de los que emita para cubrir los roaming entre proveedores, pudiendo liquidarlos según los precios se fueran acercando a lo normal o perderlos si resulta que no ha sabido hacer bien sus cálculos.

Si una compaia no da buen servicio, sus tokens precisarán mayores garantías. en base a un algoritmo sobre KYC, de manera que los proveedores menos demandados serán los que más caro tendrán emitir tokens, pues tendrían que inmovilizar más recursos en tokens como garantía.

Esto mismo se podría aplicar al gas, a los combustibles, a la electricidad, etc.. siempre buscando que productores, mayoristas, minoristas necesarios y consumidores pudieran acceder a todo el mercado a la vez simplificando la contratación, aumentando la disponibilidad de servicio y evitando monopolios.
 
indenaiks dijo:
La principal aplicación no monetaria es, IMHO, servir de prepago con trazabilidad de servicios ubicuos. Veamos un ejemplo:

Te montas en tu coche y quieres tener wifi y 4G triple B (bueno, bonito y barato). Tu consola te acepta la entrada de tokens INDE (qué pasa, yo tengo derecho también a tener un token a mi nombre) y esos tokens INDE tiene un valor variable en FIAT pero fija en GB de internete (fijas lo serían nominalmente, ya que si tienes 1GB nominal pero el proveedor te regala medio, elegirás ese proveedor), ya sea 4G o Wifi local. Esos tokens se irán gastando según consumas y podrías rechazar proveedores.

Las compañías venderán sus tokens marcados en el mercado y luego los usuarios podríamos navegar desde nuestros coches, estando en diferentes sitios con diferentes proveedores, todos aceptando los INDE como pago por el tráfico de datos, sin necesidad de tener contratos y pudiendo comprar tokens adicionales en cualquier momento.

Los proveedores locales y los troncales de alta capacidad liquidarían sus INDE entre ellos, ya que son trazables. Si en un sitio es más caro dar internete a cambio de tokens, el servicio sería asumido a pérdidas entre varias compañias, en base a un acuerdo de alcance de suministro que diluiría esa pérdida local entre varios.

Si una compañía pretende bajar precios del GB temerariamente, sus tokens INDE deberán ser aceptados en su salida a la venta por algún mecanismo de garantía, que posibilite que tenga que emitir tokens de reserva hasta, pongamos, un 50% sobre el valor de mercado de los que emita para cubrir los roaming entre proveedores, pudiendo liquidarlos según los precios se fueran acercando a lo normal o perderlos si resulta que no ha sabido hacer bien sus cálculos.

Si una compaia no da buen servicio, sus tokens precisarán mayores garantías. en base a un algoritmo sobre KYC, de manera que los proveedores menos demandados serán los que más caro tendrán emitir tokens, pues tendrían que inmovilizar más recursos en tokens como garantía.

Esto mismo se podría aplicar al gas, a los combustibles, a la electricidad, etc.. siempre buscando que productores, mayoristas, minoristas necesarios y consumidores pudieran acceder a todo el mercado a la vez simplificando la contratación, aumentando la disponibilidad de servicio y evitando monopolios.
Hacer clic para expandir...

Algo parecido leí sobre "fidelity bonds" y tokenización a partir de sacrificios de bitcoins. A lo mejor esto te interesa:

Fidelity bonds - Bitcoin Wiki

La parte que a lo mejor te puede interesar es la última del artículo, en la que se realiza un "sacrificio temporal" de bitcoins al bloquearlos en una tras*acción con nLocktime, de manera que, a cambio del token o bono, sacrificarías el coste de oportunidad de poder disponer de esos bitcoins "bloqueados" durante el tiempo de duración del "contrato".

---------- Post added 19-ene-2018 at 14:20 ----------

Y ya vamos terminando con el nLocktime, que es parámetro que permite condicionar una tras*acción a que sólamente pueda ser incorporado a un bloque de la cadena a partir de un momento futuro, bien en forma de fecha (en formato Unix time Unix time - Wikipedia ) o de un determinado bloque.

Más info aquí:

Developer Guide - Bitcoin


Ya están terminados los tochazos descriptivos, a partir de ahora ya hay suficiente información en el hilo como para montar cositas guapas, guapas.
 
Última edición:
Ahora voy a explicar cómo podría utilizarse Bitcoin para estampillar un contenido digital, un documento o un texto, de manera que en cualquier momento del futuro se puede demostrar matemáticamente que documento, contenido digital o texto existían ANTES de la fecha del estampillado.

Por si no lo sabéis, las direcciones Bitcoin se generan así:

Technical background of version 1 Bitcoin addresses - Bitcoin Wiki

Así que nosotros podemos tomar nuestro documento, contenido digital, foto, texto, etc., calcular el SHA256 y emplear el resultado como semilla para generar el par de clavez pública/privada de Bitcoin y su correspondiente dirección.

Una vez creada la dirección, se envía allí una cantidad testimonial de bitcoin, se gastan los que allí queden y en cualquier momento del futuro podrás demostrar que, desde el hash SHA256 del documento, texto, archivo, foto, puedes derivar el par de claves y también la dirección Bitcoin. Y como esa dirección Bitcoin existía en la fecha del estampillado (porque la tras*acción así lo hace constar en la cadena de bloques), pues estás demostrando matemáticamente y de forma infalsificable que el archivo, documento, texto, foto o lo que sea que has estampillado, existían ya antes de dicha fecha.

Sirva esto como ejemplo. Si tomamos el texto del post que da origen a este hilo:

Código: 
Bueno, pues estrenando nuevo subforo y, al hilo de los acontecimientos de los últimos días en el mundillo de Bitcoin con respecto a la cotización, pues veo la oportunidad de iniciar un hilo que llevo mucho tiempo queriendo abrir y que creo que es muy necesario:

EL HILO DE LAS APLICACIONES NO MONETARIAS DE BITCOIN.

Como muchos ya sabéis porque lo he repetido en este foro alguna vez, mi visión particular sobre Bitcoin es que no se trata de dinero y que Satoshi, como muchos inventores a lo largo de la historia, no tenía realmente ni idea de lo que estaba inventando en realidad y, ni mucho menos, tenía idea de las repercusiones que iba a conllevar.

Sí, ya sé que algunos de vosotros ya habréis leído el paper de Satoshi o que muchos, al menos, habréis leído el título del famoso paper:

Bitcoin: a peer-to-peer electronic cash system.

y seguro que os estaréis planteando "ya está elemento tocando los huevones, cuando el título del paper de Bitcoin es muy claro". Pero la evidencia es la evidencia, y tengo que decir que Satoshi nos estaba engañado a todos. Satoshi no inventó un método electrónico de pago. Ni siquiera estaba inventando un método electrónico de pago descentralizado. Satoshi estaba inventando, en realidad, la primera Corporación Descentralizada Autónoma de la historia.

Y ahora, definiendo cada una de las palabras, entenderemos realmente la repercusión del inventito de marras:

CORPORACIÓN: Sí, Bitcoin es una corporación. ¿Por qué?. Pues porque tiene una estructura de funciones internas bien establecida, tiene un ánimo de lucro bastante evidente, tiene unos férreos estatutos internos que rigen el funcionamiento de todo el sistema con precisión de relojero (el código), tiene un cuerpo de accionistas que sostienen económicamente a la corporación (los poseedores de bitcoins), tiene usuarios, que son todos aquellos que pujan por el producto que ofrece y, también, tiene unos OBJETIVOS. Aunque de los objetivos no hablaré ahora, sino que lo haré después.

AUTÓNOMA: El funcionamiento de Bitcoin es autónomo y esto enlaza con los OBJETIVOS de los que he hablado en el punto anterior. Bitcoin está diseñado para mantener un poderoso equilibrio de intereses que se encarga de velar para que, a ninguno de los colectivos que participan del sistema (mineros, nodos, usuarios, desarrolladores y comercios), le sea rentable actuar en contra de los intereses del resto de colectivos. Y esto garantiza que, aplicando energía al sistema mediante el mecanismo de la "minería", el funcionamiento de la corporación hacia la búsqueda su objetivo, sea verdaderamente autónomo.

DESCENTRALIZADA: Esta corporación, y el ambicioso objetivo con el que fué diseñada, únicamente puede lograr el éxito desde la descentralización. Es por ello por lo que Satoshi logró resolver el famoso problema de computación de los generales bizantinos. Gracias a su solución, un número indeterminado de nodos de una red puede alcanzar un consenso periódicamente a través de un canal de comunicación inseguro. Ahora mismo la red Bitcoin está formada por miles de nodos repartidos por todos los continentes (incluido el espacio) y la minería, que se encarga de aportar energía al sistema y protegerlo, puede desarrollar su actividad en cualquier parte del planeta con acceso a energía a bajo coste.

Y ahora hablemos del OBJETIVO de esta CORPORACIÓN. ¿Cuál es el objetivo de Bitcoin?. Bien... Bitcoin no es lo que muchos pensáis. Tampoco es lo que los intoxicadores, los Gobernadores de Bancos Centrales, los políticos o los usuarios de otras shitcoins, van cacareando por ahí. Ni siquiera el objetivo de Bitcoin es aquello con lo que Satoshi os confundió en el título de su paper. Bitcoin no es "a peer-to-peer" electronic cash system.

El objetivo de esta corporación (=el objetivo de Bitcoin) es poder mantener indefinidamente en el tiempo, y de forma segura, un entorno de reglas e instrucciones en el que puedan ejecutarse unas (en principio) sencillas aplicaciones (=tras*acciones).

Sí señores, el objetivo real de Bitcoin es el de mantener de forma autónoma, descentralizada, segura y con una certidumbre medible, un sistema operativo que nos va a permitir programar y ejecutar sobre él unas aplicaciones.

¿Por qué digo esto? sencillamente, porque tengo ojos y, al igual que cualquiera de vosotros, puedo consultar el código. Si nos vamos a la parte de "scripts" de las tras*acciones que podemos ejecutar en Bitcoin, podemos observar la cantidad de códigos OP que tenemos a nuestra disposición para poder programar esas tras*acciones (=aplicaciones) y lograr variadísimos resultados. Aquí tenéis un link:

Script - Bitcoin Wiki

Por lo tanto, combinando esas instrucciones y programándolas adecuadamente para que se ejecuten en un sistema operativo autónomo como es Bitcoin, empezamos a hacernos una ligera idea de qué es realmente Bitcoin. Si programamos una de esas sencillas aplicaciones (=tras*acción) para que adquiera cualidades parecidas a las del dinero, estaríamos utilizando Bitcoin como si fuera dinero. Pero como ya os habéis podido imaginar, esas instrucciones con las que podemos programar las tras*acciones dan para mucho, mucho más. Así que Bitcoin puede ser otras muchas cosas "no monetarias".

Así que es por este motivo por el que doy comienzo oficial al hilo de las "aplicaciones no monetarias de Bitcoin", en el que vamos a ir poniendo ejemplos y hablar de todas las tras*acciones que podemos programar en Bitcoin y que nos permiten hacer "algo más" de aquello a lo que ya nos hemos acostumbrado en este sistema.

Como comienzo, os recomiendo una billetera muy sencilla y polivalente con la que podremos hacer "algo más" que con las billeteras que utilizamos habitualmente:

Bitcoin Wallet by Coinb.in

(SU GITHUB): GitHub - OutCast3k/coinbin: Javascript Bitcoin Wallet. Supports Multisig, Stealth, HD, Time Locked Addresses, RBF and more!
No utilicéis la wallet desde la web, utilizad el software de su github. Ya os podéis imaginar el por qué (seguridad y esas cosas)


Y aquí os pongo un explorador de información relacionada con Bitcoin (tras*acciones, bloques, scripts, claves, etc) que muestra la información de forma muy intuitiva y gráfica:

Blockchain reader


Ni qué decir tiene que espero que este hilo sea bastante más complicado y "avanzado" que el hilo oficial de Bitcoin porque, al fin y al cabo, nos vamos a ir metiendo poco a poco en las verdaderas tripas de Bitcoin y vamos a empezar a hacer cosillas "no standar".

Y lo introducimos en algún calculador online de hashes SHA256, (como este SHA-256 hash calculator. Online SHA-256 hash generator. Mining Bitcoin ) nos da el siguiente hash:

Código: 
b2fdaea396a52bb783f5e52b7cea359b4df67c798d01eb67b984d496a899a1f9

Y si ese hash lo utilizamos como semilla para generar un par de claves pública/privada y su correspondiente dirección Bitcoin con esta aplicación (dentro de la opción "Brain Wallet):

bitaddress.org

(no uséis la aplicación web, descargaros la aplicación desde el github y ejecutadlo en local)

Pues obtendríamos:

- Bitcoin Address:
Código: 
13uFD1m7dJHBZXZTusmeZGDHQmZNXAcGCx
- Private Key (Wallet Import Format):
Código: 
5JbSASoe2L61qSrekmoNLFY9UF4BxFCBdJ7yFWHdwgKmJXHFZSv

Así que nosotros sencillamente enviaríamos una cantidad testimonial de bitcoins a esa dirección y, una vez la tras*acción hubiese sido incluida en la cadena de bloques, en cualquier momento del futuro podríamos demostrar que ese texto que hemos utilizado como semilla ya existía ANTES del estampillado. El precio a pagar de esto sería el de las comisiones que nos cobraría la red por hacer funcionar una aplicación (=realizar una tras*acción) en el sistema Bitcoin.

---------- Post added 19-ene-2018 at 18:06 ----------

Como curiosidad, si alguien se pregunta cómo consiguió Julian Assange el construir direcciones Bitcoin que comenzasen por las letras que aél le interesaba para construir el escueto mensaje en el que tranquilizaba sobre su situación

2-8.jpg


lo hizo con la aplicación vanitygen, que va probando por fuerza bruta claves privadas hasta que encuentra aquella que puede derivar en una dirección Bitcoin que contiene la secuencia de caracteres que nos interesa. Podéis encontrar la aplicación aquí:

GitHub - samr7/vanitygen

Es con esa aplicación con la que yo me he creado la dirección "Mojon" :XX:

Código: 
1MojonoqXYAZpeeg2FBU8WUMVb636idCrE
 
Última edición:
Herencias.

Imaginad que tenéis 70 años y queréis utilizar Bitcoin para programar una herencia. Vuestra intención es la siguiente:

Tenéis un hijo y queréis que, en el caso de que fallezcáis, herede vuestros bitcoins en un plazo razonable de tiempo, pero también queréis que, en el caso de que no fallezcais y tengáis que utilizar esos bitcoins, podáis hacerlo. Incluso queréis tener la opción de "desheredar" a vuestro hijo o modificar la herencia en cualquier momento, "por si las moscas". ¿Cómo lo haríais?

Bien, vamos a considerar como "plazo razonable" para heredar, como máximo un año. Esto es, que si yo fallezco el 1 de enero de 2018, mi heredero pueda tardar en recibir los bitcoin de herencia en, como máximo, un año.

El procedimiento sería:

- Construís con coinb.in una nueva tras*acción con el importe correspondiente a las cantidades que queréis enviar a cada hijo (en este caso un único hijo) y, en las "opciones avanzadas", ponéis en nLocktime el tiempo en Unix Unix time - Wikipedia correspondiente al día futuro en que consideréis que la herencia debería ejecutarse. Podéis calcular el tiempo Unix aquí: Unix Time Stamp - Epoch Converter
En mi caso de ejemplo, será el 31 de diciembre de 2018 a las 23h:59m:59s. (Tiempo Unix =1546300799). Yo la tras*acción la he construido sin comisiones, cosa que explicaré en el siguiente punto.

- Una vez construida la tras*acción, se lleva al menú de "Firmar" y ahí la firmaremos con nuestra clave privada. Pero hay algo MUY IMPORTANTE. Como sabéis, al haber programado la tras*acción con nLocktime, lo que estamos haciendo es dejar muy claro que esta tras*acción nunca podrá ser incluida en un bloque cuya fecha sea anterior al tiempo Unix que hemos especificado (31 de diciembre de 2018) a las 23h:59m:59s.

Pero hay un problema. Ni tú, ni yo, ni nadie en realidad sabe qué comisiones estará exigiendo la red Bitcoin en ese momento para poder ejecutar nuestras aplicaciones (=tras*acciones) allí, así que es de vital importancia (y por eso os he soltado el rollo antes de las "Signature Hash Types" en unos posts más atrás, que firmemos la tras*acción con la opción SIGHASH_SINGLE/ANYONECANPAY

De este modo, será el interesado el que tendrá que incluir un input de su propiedad en dicha tras*acción (y firmarlo) con una cantidad de bitcoins suficientes como para hacer frente a las comisiones que la red pueda estar exigiéndonos por utilizarla.

Si queréis ver un ejemplo, esta es la tras*acción que he construido:

Código: 
0100000001e2a7bb30e778667b67ac77df5ee48c94c90e8d8ce351e0c39890276a6fe3d47d010000008a473044022022e3ac16fe11deed22cd6e96cc1a423cd8d2bc75c0895732aa1f17aea3ef4d3302203acdda8186dec4b2409c08ff03d90808309e1d97462e6bc1906e86fd8434669d8341045972af48b049d8e1410f5294d209e110b6ad9494151beccb90d03636651db0daa54b49497e00eea505624db6e2546bd1d62ed3921aad22ef6703d3e0241bd4420000000001404b4c00000000001976a9147bb768a0fd9fe61a6cd0d6f94037a0250f5ebdb488ac7fad2a5c

ha4v6FW.jpg


Aquí podéis verle bien las tripas a la tras*acción:

tras*action explorer

Si yo falleciese durante el tras*curso de 2018, mi heredero, propietario de la dirección
Código: 
1CH9q4DdZr2HRzpEVdLx3dFkTFX8RApsg7
podría recibir la herencia siempre que le añadiese un input con suficientes bitcoins como para pagar las comisiones de la red.

Ahora el siguiente punto: ¿Y si quisiese desheredar a mi heredero durante este año? Pues tan sencillo como construir otra tras*acción que gaste los bitcoins de la dirección de salida
Código: 
1MojonoqXYAZpeeg2FBU8WUMVb636idCrE
antes de que llegue el día del nLocktime (31 de diciembre de 2018).
 
Última edición:
Iniciar sesión o registrarte para responder aquí.
Volver