Transacciones fuera de línea

[sitwac]

El término "resistencia a la censura" no aparece en el White Paper de Satoshi Nakamoto para Bitcoin (BTC). Sin embargo, se ha convertido en una de las frases más citadas por los defensores de la tecnología Blockchain y las criptomonedas.

La capacidad de llevar a cabo transacciones en criptomonedas de forma offline o fuera de línea también crea otra vía para una adopción más amplia de la moneda digital. Las áreas con poca o ninguna cobertura de Internet pueden tener acceso a canales de pago descentralizados.

"En muchas partes del mundo rural y en desarrollo, la conectividad a Internet es costosa e intermitente. Más soluciones adaptadas a estas situaciones facilitarían sin duda el uso de criptomonedas en los lugares donde se necesita. Las transacciones de Bitcoin se pueden realizar a través de capas de transporte alternativas de bajo ancho de banda como radios de mesh y SMS".

La estructura no jerárquica de una meshnet tiene una clara semejanza con las primeras iteraciones de Internet. Este tipo de disposición también es similar a la Blockchain de Bitcoin con su topología de red plana.

Con los avances emergentes en la tecnología inalámbrica, ya no es necesario cablear las Meshnet. En cambio, los nodos de la red se comunican directamente entre sí si están dentro del alcance. Para la transferencia de información de largo alcance, los nodos actúan como relés para enviar flujos de datos a distancia.

https://es.cointelegraph.com/news/offline-transactions-the-final-frontier-for-global-crypto-adoption

Este es uno de los desarrollo que mas sigo en cuando al mundo de las criptomonedas ya que creo que este tipo de invenciones dejan que la red de Bitcoin se establezca de mejor forma a nivel mundial.

Actualmente uno de los proyectos que sigo de forma local de llama Locha Mesh, como se nota las personas bajo la premisa de la criptomonedas muestran una gran inventiva a la hora de tener una necesidad. Conoce algun proyecto de forma local que busque desplegar o desarrollar una red malla.

[seoincorporation]

El término "resistencia a la censura" no aparece en el White Paper de Satoshi Nakamoto para Bitcoin (BTC). Sin embargo, se ha convertido en una de las frases más citadas por los defensores de la tecnología Blockchain y las criptomonedas.

La capacidad de llevar a cabo transacciones en criptomonedas de forma offline o fuera de línea también crea otra vía para una adopción más amplia de la moneda digital. Las áreas con poca o ninguna cobertura de Internet pueden tener acceso a canales de pago descentralizados.

"En muchas partes del mundo rural y en desarrollo, la conectividad a Internet es costosa e intermitente. Más soluciones adaptadas a estas situaciones facilitarían sin duda el uso de criptomonedas en los lugares donde se necesita. Las transacciones de Bitcoin se pueden realizar a través de capas de transporte alternativas de bajo ancho de banda como radios de mesh y SMS".

La estructura no jerárquica de una meshnet tiene una clara semejanza con las primeras iteraciones de Internet. Este tipo de disposición también es similar a la Blockchain de Bitcoin con su topología de red plana.

Con los avances emergentes en la tecnología inalámbrica, ya no es necesario cablear las Meshnet. En cambio, los nodos de la red se comunican directamente entre sí si están dentro del alcance. Para la transferencia de información de largo alcance, los nodos actúan como relés para enviar flujos de datos a distancia.

https://es.cointelegraph.com/news/offline-transactions-the-final-frontier-for-global-crypto-adoption

Este es uno de los desarrollo que mas sigo en cuando al mundo de las criptomonedas ya que creo que este tipo de invenciones dejan que la red de Bitcoin se establezca de mejor forma a nivel mundial.

Actualmente uno de los proyectos que sigo de forma local de llama Locha Mesh, como se nota las personas bajo la premisa de la criptomonedas muestran una gran inventiva a la hora de tener una necesidad. Conoce algun proyecto de forma local que busque desplegar o desarrollar una red malla.

Las transacciones necesitan de internet para ser ser emitidas a la cadena de bloques, sin embargo es posible firmar una transacción y tener el codigo listo pera emitir dicha transacción en la cadena de bloques. Esto es como crear un cheque de bitcoin y cobrarlo en el momento que deseamos. El único problema sobre esto es que alguien podría gastarse ese dinero antes de que cobremos el cheque 

[DUPONDIUS]

El único problema sobre esto es que alguien podría gastarse ese dinero antes de que cobremos el cheque 

Un problemón.

[d5000]

Las transacciones necesitan de internet para ser ser emitidas a la cadena de bloques, sin embargo es posible firmar una transacción y tener el codigo listo pera emitir dicha transacción en la cadena de bloques. Esto es como crear un cheque de bitcoin y cobrarlo en el momento que deseamos. El único problema sobre esto es que alguien podría gastarse ese dinero antes de que cobremos el cheque  

Hace ya unos años me topé con una posible solución para una sub-clase de este problema (cuando hay una intención de llevar a cabo un a compraventa, pero el intercambio se realiza offline en una zona sin acceso a Internet. Un ejemplo: Una persona quiere vender un objeto, por ejemplo un caballo, en una zona rural, y se puede conectar a Internet solamente 1 vez por semana.). Está basada en la técnica de los "atomic swaps":

Using OP_CHECKLOCKTIMEVERIFY for offline transactions - possible?

Explicado de manera corta:

La persona que tiene la intención de comprar (A) crea una transacción y la confirma en la cadena de bloques. Esta transacción, sin embargo, tiene dos outputs: uno permite a A retomar el control del dinero después de un tiempo (por ejemplo, un mes) a través de OP_CHECKLOCKTIMEVERIFY (un llamado timelock) y el otro, permite a otra persona B (el vendedor) retirar el dinero pero solamente si esta provee un secreto S (el hash del secreto se incluye en la transacción, se trata de un hashlock).

B tiene que verificar primero que la transacción está debidamente confirmada. Ahora, cuando se realiza el intercambio, hay dos posibilidades:
1) Se realiza la compraventa. B entrega el bien a A, y A entrega el secreto S a B, y B, cuando tiene otra vez acceso a Internet, puede transferir el dinero a su propia dirección de Bitcoin. B puede verificar instantáneamente que el secreto es correcto ya que conoce el hash de S, que fue incluido en la transacción confirmada.
2) No se realiza. En este caso, el secreto S no se entrega a B. A puede recuperar el dinero después de que venza el "timelock".

Este tipo de transacción offline obviamente tiene limitaciones, ya que se tiene que conocer de antemano la dirección del vendedor, y tiene la gran desventaja de que hay que confirmar la transacción en la cadena, lo que significa que el fee se paga aún si el intercambio no se realiza. Pero para algunos intercambios en áreas rurales (por ejemplo, la venta de ganado o de herramientas como tractores) podría ser útil.

[th3nolo]

Las transacciones necesitan de internet para ser ser emitidas a la cadena de bloques, sin embargo es posible firmar una transacción y tener el codigo listo pera emitir dicha transacción en la cadena de bloques. Esto es como crear un cheque de bitcoin y cobrarlo en el momento que deseamos. El único problema sobre esto es que alguien podría gastarse ese dinero antes de que cobremos el cheque  

Hace ya unos años me topé con una posible solución para una sub-clase de este problema (cuando hay una intención de llevar a cabo un a compraventa, pero el intercambio se realiza offline en una zona sin acceso a Internet. Un ejemplo: Una persona quiere vender un objeto, por ejemplo un caballo, en una zona rural, y se puede conectar a Internet solamente 1 vez por semana.). Está basada en la técnica de los "atomic swaps":

Using OP_CHECKLOCKTIMEVERIFY for offline transactions - possible?

Explicado de manera corta:

La persona que tiene la intención de comprar (A) crea una transacción y la confirma en la cadena de bloques. Esta transacción, sin embargo, tiene dos outputs: uno permite a A retomar el control del dinero después de un tiempo (por ejemplo, un mes) a través de OP_CHECKLOCKTIMEVERIFY (un llamado timelock) y el otro, permite a otra persona B (el vendedor) retirar el dinero pero solamente si esta provee un secreto S (el hash del secreto se incluye en la transacción, se trata de un hashlock).

B tiene que verificar primero que la transacción está debidamente confirmada. Ahora, cuando se realiza el intercambio, hay dos posibilidades:
1) Se realiza la compraventa. B entrega el bien a A, y A entrega el secreto S a B, y B, cuando tiene otra vez acceso a Internet, puede transferir el dinero a su propia dirección de Bitcoin. B puede verificar instantáneamente que el secreto es correcto ya que conoce el hash de S, que fue incluido en la transacción confirmada.
2) No se realiza. En este caso, el secreto S no se entrega a B. A puede recuperar el dinero después de que venza el "timelock".

Este tipo de transacción offline obviamente tiene limitaciones, ya que se tiene que conocer de antemano la dirección del vendedor, y tiene la gran desventaja de que hay que confirmar la transacción en la cadena, lo que significa que el fee se paga aún si el intercambio no se realiza. Pero para algunos intercambios en áreas rurales (por ejemplo, la venta de ganado o de herramientas como tractores) podría ser útil.

No tenía idea de que con un timelock podías hacer eso, es demasiado útil sobre todo en Venezuela ya que el internet es intermitente.

Una pregunta cuando A nos da el hash Secreto S tenemos que confiar en que A será honesto y no gastará los fondos una vez que B haga la entrega de lo que estaba vendiendo?

[d5000]

No tenía idea de que con un timelock podías hacer eso, es demasiado útil sobre todo en Venezuela ya que el internet es intermitente.

Una pregunta cuando A nos da el hash Secreto S tenemos que confiar en que A será honesto y no gastará los fondos una vez que B haga la entrega de lo que estaba vendiendo?

No, es justo lo que previene el timelock B puede retirar inmediatamente después de conectarse a Internet, una vez que conoce el secreto, mientras que A debe esperar hasta el vencimiento del timelock.

La transacción que contiene el hash de S también contiene el "timelock", se encuentra confirmada en la blockchain antes del intercambio, y B lo puede comprobar. De esta manera, B puede, por ejemplo, decir "ah no, este timelock es demasiado corto", si ve un riesgo de no poder retirar el dinero antes de que éste se venza.

Ya que mencionas a Venezuela, puede ser que esta técnica también sea útil para la compra y venta de BTC por dinero fiat en efectivo, cuando hay mala conexión a Internet.

Lo que si, en el thread que he enlazado, me han dicho que el método puede ser que no sea considerado "estándar", es decir que algunos (o todos?) los mineros pueden rechazar a la transacción en cuestión. Esto habría que verlo bien antes de programar una aplicación práctica.

[th3nolo]

Entiendo entonces cuando pasa le tiempo del Timelock, tanto A como B pueden gastar la transaccion o A tiene un timelock mas largo que B para que en ese caso B pudiera utilizar el secreto S sin problemas?

Esas son mis dudas, pero si entiendo mas o menos como funciona la mecánica de hecho últimamente he estado revisando un poco el código de Bitcoin en la sección de desarrollo del foro y veo que no seria tan... complicado hacer una aplicación practica.

[d5000]

Entiendo entonces cuando pasa le tiempo del Timelock, tanto A como B pueden gastar la transaccion o A tiene un timelock mas largo que B para que en ese caso B pudiera utilizar el secreto S sin problemas?

El timelock solamente es válido para A. La transacción tendría dos opciones diferentes para gastar el monto:
- Una cuya condición es que con la clave de B se pueda gastar el monto en el momento que sea (sin timelock), solo conociendo además S.
- La otra, cuya condición es presentar la clave de A, pero solamente funciona después del timelock.

Sería un poco parecido a los hash/timelocks de Lightning, al final.

Me han señalado en el thread en inglés el siguiente ejemplo de código, que originalmente fue concebido para la venta de datos sin necesitar confianza entre comprador (buyer) y vendedor (publisher):

Code:

    IF
        HASH160 <Hash160(encryption key)> EQUALVERIFY
        <publisher pubkey> CHECKSIG
    ELSE
        <expiry time> CHECKLOCKTIMEVERIFY DROP
        <buyer pubkey> CHECKSIG
    ENDIF

Fuente: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki#trustless-payments-for-publishing-data

El segmento detrás de IF es la opción que chequea el secreto (del vendedor/B), el detrás de ELSE la que contiene el timelock (para A).

[rebelion_de_masas]

Wow, no sabía que era posible, de verdad es muy útil para aquí

[th3nolo]

Entiendo entonces cuando pasa le tiempo del Timelock, tanto A como B pueden gastar la transaccion o A tiene un timelock mas largo que B para que en ese caso B pudiera utilizar el secreto S sin problemas?

El timelock solamente es válido para A. La transacción tendría dos opciones diferentes para gastar el monto:
- Una cuya condición es que con la clave de B se pueda gastar el monto en el momento que sea (sin timelock), solo conociendo además S.
- La otra, cuya condición es presentar la clave de A, pero solamente funciona después del timelock.

Sería un poco parecido a los hash/timelocks de Lightning, al final.

Me han señalado en el thread en inglés el siguiente ejemplo de código, que originalmente fue concebido para la venta de datos sin necesitar confianza entre comprador (buyer) y vendedor (publisher):

Code:

    IF
        HASH160 <Hash160(encryption key)> EQUALVERIFY
        <publisher pubkey> CHECKSIG
    ELSE
        <expiry time> CHECKLOCKTIMEVERIFY DROP
        <buyer pubkey> CHECKSIG
    ENDIF

Fuente: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki#trustless-payments-for-publishing-data

El segmento detrás de IF es la opción que chequea el secreto (del vendedor/B), el detrás de ELSE la que contiene el timelock (para A).

Muchísimas gracias todas mis dudas quedaron aclaradas, creo que pediré que añadan una charla de timelocks para las próximas reuniones de Satoshi en Venezuela (Un amigo @criptobastardo es su promotor) este mecanismo sin duda es súper útil para la situación que estamos enfrentando con conexiones de muy baja calidad y servicios de luz intermitentes.

Creo que te mencionaste que el mecanismo es parecido al timelock de lightning, con eso te refieres a que puedes hacer lo mismo con Bitcoins enrutados en la LN?

Ayer pensando en la idea de timelock me quedé pensando en las posibilidades de algo así pero usado canales de LN ya que veo en ellos un potencial gigante para poder hacer micro transacciones y poder comprar bienes y  adquirir servicios en caso de que nuestro sistemas nacional bancario falle.

https://voce.com.ve/2019/04/03/401669/sudeban-busca-alternativas-para-no-depender-de-visa-y-mastercard/

[d5000]

Creo que te mencionaste que el mecanismo es parecido al timelock de lightning, con eso te refieres a que puedes hacer lo mismo con Bitcoins enrutados en la LN?

No estoy seguro, pero puede ser que sea posible algo parecido en un canal de pago al estilo Lightning. (No se puede hacer exactamente lo mismo, ya que el mecanismo que propuse requiere una transacción confirmada, y en LN justo se busca evitar eso.)

Cuando A y B tienen un canal de pago abierto, tengo entendido que entonces en cada pago cada parte firma una "commitment transaction". Esta asegura que se actualice el saldo de cada uno en el canal, y además posibilita a la otra parte sacar todos los fondos del canal como penalidad, en el caso que esta conozca un secreto que se publica siempre con el próximo pago.

Es decir, en el segundo pago se publica el secreto para el primer pago, y así sucesivamente (así nadie puede publicar una transacción anterior sin que el otro pueda quedarse con todos los fondos).

Ahora podríamos crear un pago "condicional": Antes del intercambio ambas partes también firmarían una "commitment transaction". Pero esta no solo requiere un secreto para la penalidad, sino que solamente si el vendedor B conoce un secreto adicional, entonces se actualiza el saldo a su favor. Sino, queda todo así como está (y la transacción no tendría valor alguno, es decir que se descarta).

En el intercambio, como en el concepto original, el comprador provee el secreto al vendedor si se realiza el intercambio. Este no tiene que crear ninguna transacción en la cadena, pero si "contarle" a la aplicación de LN que conoce el secreto (así este actualiza el saldo en el canal de pago), y guardar el secreto en un lugar seguro, porque en el caso de que A trate de publicar la transacción con el estado "anterior", entonces B puede crear una transacción que le provee también los fondos del intercambio realizado con A.

No estoy seguro de que funcione, sobre todo creo que esto complicaría a los nodos intermedios que "rutean" la transacción. Pero podría funcionar en un canal de pagos simple (no conectado a LN). Si funciona en LN sería un golazo, pero no lo creo ...

[th3nolo]

Yo no tengo muchas bases en LN, pero si puedo preguntar a mis amigos que son desarrolladores a ver qué opinan ellos y si tiene sentido tratar de implementar algo así.

d5000 conoces algunos recursos o páginas web donde uno pueda aprender más a fondo sobre LN y sus posibilidades?

[seoincorporation]

Yo no tengo muchas bases en LN, pero si puedo preguntar a mis amigos que son desarrolladores a ver qué opinan ellos y si tiene sentido tratar de implementar algo así.

d5000 conoces algunos recursos o páginas web donde uno pueda aprender más a fondo sobre LN y sus posibilidades?

Saludos Th3nolo, hay muchísima información en la red sobre red de rayos, pero te dejo un par de fuentes para que puedas entender la mas a fondo:

https://www.bitcoinlightning.com/what-is-bitcoin-lightning/
https://es.wikipedia.org/wiki/Lightning_(red)

Por lo que yo entiendo de la red de rayos es abrir un canal de pagos a través de una transacción. Supongamos que abrimos un canal con una transacción de 0.1 btc, de esta forma 100 usuarios pueden gastar en ese canal 0.001 cada uno de ellos, una vez que se completa la cantidad máxima entonces se cierra el canal con otra transacción. La ventaja de esto es que solo nos costó 2 transacciones en la red de bitcoin pero se movieron 100 transacciones de 0.001 a través de nuestro canal.

[th3nolo]

Saludos Th3nolo, hay muchísima información en la red sobre red de rayos, pero te dejo un par de fuentes para que puedas entender la mas a fondo:

https://www.bitcoinlightning.com/what-is-bitcoin-lightning/
https://es.wikipedia.org/wiki/Lightning_(red)

Por lo que yo entiendo de la red de rayos es abrir un canal de pagos a través de una transacción. Supongamos que abrimos un canal con una transacción de 0.1 btc, de esta forma 100 usuarios pueden gastar en ese canal 0.001 cada uno de ellos, una vez que se completa la cantidad máxima entonces se cierra el canal con otra transacción. La ventaja de esto es que solo nos costó 2 transacciones en la red de bitcoin pero se movieron 100 transacciones de 0.001 a través de nuestro canal.

Gracias SEO, voy a revisar los recursos y aprender un poco más al respecto.
Tenía una vaga idea de cómo funcionaba la LN pensé que simplemente era para hacer pagos entre pares de manera instantánea y dejar abierto el canal.

Por ejemplo, si abrías un canal de 0.01 podrías hacer 100 pagos de 0.001 pero si la otra persona del canal te hace pagos, podrías extender su durabilidad por lo que el límite es la creatividad y la forma en que enrutes los pagos.

Y si la ventaja es que puedes hacer transferencia P2P pero sin dejar registro de todas ellas en la blockchain necesariamente.

PD: hay algún tema tuyo o en el foro que hable de la LN para no desviarnos tanto del tema de d5000

[d5000]

Por lo que yo entiendo de la red de rayos es abrir un canal de pagos a través de una transacción. Supongamos que abrimos un canal con una transacción de 0.1 btc, de esta forma 100 usuarios pueden gastar en ese canal 0.001 cada uno de ellos, una vez que se completa la cantidad máxima entonces se cierra el canal con otra transacción. La ventaja de esto es que solo nos costó 2 transacciones en la red de bitcoin pero se movieron 100 transacciones de 0.001 a través de nuestro canal.

Es un poquito diferente. Yo tampoco soy el gran experto de LN, pero creo que entendí más o menos el principio básico. Pero es difícil explicarlo de manera sencilla ...

Lo básico es que un canal de pago es, normalmente, una dirección multisig del tipo "2 de 2" entre dos personas. Esto quiere decir que cualquier transacción que saca fondos de esta dirección debe ser firmada digitalmente por ambos.

Ahora lo que hacen ambas personas es intercambiar transacciones sin confirmarlas en la blockchain. El objetivo es que estas transacciones, cuando se publiquen en la cadena, reflejen fielmente el saldo de cada uno de los dos participantes.

Por ejemplo, podemos tener un canal de pago en el cual cada uno de los participantes tiene 1 BTC de saldo inicial. Entonces lo primero que crean ambos participantes, son dos transacciones (una firmada por A y la otra por B) que envían 1 BTC a la cuenta de A y 1 BTC a la cuenta de B. Si A quiere cerrar el canal, añade su firma a la transacción firmada por B, y vice versa. Estas transacciones solo se intercambian entre ambos, es decir no se publican para el resto de la red, por la cual ninguna gasta comisiones.

Ahora lo que hacen los participantes es que actualizan siempre el estado de su canal, enviandose, de la misma manera, transacciones con los montos actualizados.

Ejemplo: A paga 0.5 BTC a B, entonces el saldo de A queda en 0.5, y el de B en 1.5 BTC. Otra vez, ambos crean transacciones los cuales reflejan estos saldos, y que permiten retirar 0.5 BTC a A, y 1.5 BTC a B.

Si uno quiere cerrar el canal, por ejemplo porque la otra parte ya no responde o quiere vender todos los BTC, entonces simplemente firma la transacción que había firmado la contraparte y de esta manera se envia el monto de A a otra dirección controlada por A, y el monto de B a otra controlada por B (estas direcciones deben ser conocidas desde el principio).

A esto se añade el paso por otros nodos (que es lo mas complicado de todo, mejor vean lo en las fuentes que linkeó Seoincorporation) y la penalidad por publicar un estado antiguo.

La esencia es que dos personas pueden, de esta manera, realizar un número infinito de pagos entre si, y a otros nodos con los que están conectados. No hay un límite de (por ejemplo) 100 transacciones que se reemplazan por una. En un caso ideal puede ser un millón o mil millones sin que nada tenga que confirmarse en la cadena y por ende sin comisión. El único límite es que si el saldo de una parte queda en 0, no puede realizar más pagos, hasta que "rellene" su canal con una transacción "real" en la blockchain.

El tema de la "transacción fuera de línea" entraría en el punto en el que se actualizan los saldos. Esto quizá se puede hacer "condicional", es decir que para retirar el dinero adicional recibido por el comprador, el vendedor debe saber además un secreto.

[d5000]

Estuve preguntando en el foro inglés como se podían realizar transacciones fuera de línea a través de Lightning, y recibí respuestas de un usuario con más experiencia con LN.

En el caso de que entre comprador y vendedor haya un canal de pagos abierto, es fácil: En este caso, si no hay conexión a Internet, simplemente pueden crear, en el momento de intercambio, una red WiFi "ad hoc" entre sus dispositivos (notebooks, smartphones etc.). Es decir, que la transacción misma se puede realizar fuera de línea, pero con los dos aparatos conectados entre si. Obviamente, los canales hay que prepararlos y llenarlos cuando hay conexión a Internet.

Ahora en la mayoría de los casos no habrá un canal de pago directo sino que el pago se debe "rutear". Ss hay una suficiente cantidad de usuarios de LN en la zona (por ejemplo en un barrio de una ciudad) se pueden crear redes privadas del tipo "meshnet" (red en malla). Se usa Internet cuando está disponible, y cuando no lo es, se puede usar la meshnet para todos los pagos que se realizan entre los usuarios de esta red privada.

Se necesitaría un cambio en el software de LN para poder cambiar rápidamente entre Internet y la red mallada.

Faltaría un método para situaciones dónde no estén disponibles suficientes usuarios en la zona del intercambio. Quizá alguien todavía me puede responder si mi idea de un pago LN condicional (con un secreto adicional) que detallé arriba es viable.

[seoincorporation]

PD: hay algún tema tuyo o en el foro que hable de la LN para no desviarnos tanto del tema de d5000

Tenemos un hilo que empezó el colega VB1001 en enero con respecto a este tema, y fue el hilo que personalmente me despertó interés en el tema, espero que sea de tu ayuda y que con este puedas aclarar todas tus dudas.

https://bitcointalk.org/index.php?topic=5093387.0