*Tema mítico* : Hilo oficial de Bitcoin-XIII

No seáis así


Hombre, Ninfireblade, no seas así con los que quieren saber; no le obligues a leerse todo el tocho, y encima en inglés...

Explico a grandes rasgos el procedimiento del Lightning (sin entrar en el tema del enrutamiento):

- Lo primero que hay que hacer es crear una dirección segwit y cargarla con una cierta cantidad de BTC. Lógicamente, se requiere una operación on-chain para esto.

- Una vez creada y cargada la dirección podemos crear los canales bidireccionales que deseemos, cada uno con la dirección del destinatario y el importe correspondiente. Hay un límite, claro, que es el importe con que se cargó previamente la dirección. La creación de canales no se graba en la cadena de bloques (que me corrija Bmbnct si me equivoco).

- El envío y recepción de fondos a través de los canales abiertos es instantáneo (aunque para recibir debe estar el nodo encendido), el único límite es el importe asignado en origen a cada canal. La ventaja principal de LN es que estos intercambios de fondos no se graban en la cadena de bloques, solamente se realiza un intercambio criptográfico entre los corresponsales.

- Cada uno de los canales se cierra individualmente, por tiempo transcurrido o por acuerdo de los corresponsales. El cierre del canal es lo único que se graba en la cadena de bloques, con el estado final del balance de ambos extremos.

Creo que con esta explicación queda más claro cómo se implementa esta nueva funcionalidad de bitcoin. Espero que sirva para otros que tienen ganas de profundizar en este apasionante mundo de las criptos.

PD. Gracias, bmbnct, por compartir tu experiencia con la LN, agradecería tus comentarios sobre el procedimiento que acabo de exponer.

:D
 
La tengo bloqueada pero no veo motivo para que Twitter lo censure

Taptap
El motivo, supongo, es que cada vez que twittean algo de Bcash les lloverán los reportes de la comunidad Bitcoin. Y estarán estudiando el caso. Pero vamos, son suposiciones mías.

---------- Post added 07-mar-2018 at 10:17 ----------

¿Se podrá saber el resultado de esa subasta?
a ver qué precio se llega a pagar
Pues a no ser que se filtre, parece que no:

What information about the auction process or results will the USMS release?

The USMS will contact the winning and losing bidders directly. The USMS will not proactively release any information to the general public pertaining to the auction process or results, except for the number of registered bidders and the number of bids received.
 
+10 caracteres.............
 
Última edición:
Ademas tampoco es tan costoso encontrar una ruta, es un simple grafo con pesos, esta mas que estudiado eso.

A diferencia del enrutado IP donde el que envia un paquete no tiene que calcular la ruta hasta el destino sino que simplemente mira su tabla de enrutado y le pasa el paquete al gateway al que esta directamente conectado, en LN es diferente, el que envia calcula la ruta por cada nodo que tiene que pasar y esa ruta va añadida en el protocolo cifrado por capas, como una cebolla, de tal manera que cada nodo que va recibiendo el paquete solo sabe el nodo siguiente al que enviarselo.

Exactamente y ese es el gran problema porque obliga a que el nodo origen conozca en todo momento el estado completo de la red. Cosa posible en redes pequeñas, como la actual de prueba, pero imposible en una red distribuida de mayor tamaño ya que el trabajo requerido aumenta factorialmente a medida que aumenta el número de nodos..
Si a eso añadimos que es una red desestructurada, donde no sabes que dirección tienes que tomar, el resultado final es que el escalado del rutaje es en la practica inviable cosa que, muy probablemente, se buscaba desde el principio.

Como muy bien se resumía en reddit la solución es sencilla:

.-Todo el mundo solo abre canales con Blockstream
.-Todo el mundo paga los fee a Blockstream

Problema del routing arreglado.

P.S.
Para el que le interese de verdad este tema, nos encontramos con una variación de un problema básico en las ciencias de la computación conocido como "El problema del viajante" pero con dos añadidos que complican muchísimo mas el tema. Uno es que nos encontramos en un entorno descentralizado donde los nodos pueden desaparecer en cualquier momento por lo que el camino elegido deja de ser válido y el otro que hay que calcular que el camino elegido tiene suficientes fondos para completar la transacción cosa que puede variar en cualquier momento.
Básicamente es un problema de una enorme complejidad e irresoluble en la práctica, al menos en su diseño actual, en cuanto la red alcanza un cierto tamaño y cuya única solución es la centralización de todo el rutaje en unos pocos Hubs.
 
Hombre, Ninfireblade, no seas así con los que quieren saber; no le obligues a leerse todo el tocho, y encima en inglés...

Explico a grandes rasgos el procedimiento del Lightning (sin entrar en el tema del enrutamiento):

- Lo primero que hay que hacer es crear una dirección segwit y cargarla con una cierta cantidad de BTC. Lógicamente, se requiere una operación on-chain para esto.

- Una vez creada y cargada la dirección podemos crear los canales bidireccionales que deseemos, cada uno con la dirección del destinatario y el importe correspondiente. Hay un límite, claro, que es el importe con que se cargó previamente la dirección. La creación de canales no se graba en la cadena de bloques (que me corrija Bmbnct si me equivoco).

- El envío y recepción de fondos a través de los canales abiertos es instantáneo (aunque para recibir debe estar el nodo encendido), el único límite es el importe asignado en origen a cada canal. La ventaja principal de LN es que estos intercambios de fondos no se graban en la cadena de bloques, solamente se realiza un intercambio criptográfico entre los corresponsales.

- Cada uno de los canales se cierra individualmente, por tiempo transcurrido o por acuerdo de los corresponsales. El cierre del canal es lo único que se graba en la cadena de bloques, con el estado final del balance de ambos extremos.

Creo que con esta explicación queda más claro cómo se implementa esta nueva funcionalidad de bitcoin. Espero que sirva para otros que tienen ganas de profundizar en este apasionante mundo de las criptos.

PD. Gracias, bmbnct, por compartir tu experiencia con la LN, agradecería tus comentarios sobre el procedimiento que acabo de exponer.

:D

Te corrijo algunas cosillas:

- "La creación de canales no se graba en la cadena de bloques"

Cuando se crea un canal se transfieren los fondos a una dirección multifirma que requiere de 2 confirmaciones para poder usarlo. Y cuando se cierra se vuelve a grabar onchain.

- "El envío y recepción de fondos a través de los canales abiertos es instantáneo (aunque para recibir debe estar el nodo encendido), el único límite es el importe asignado en origen a cada canal"

Es correcto pero el envío de fondos a través del canal no son gratis, tiene comisiones que se han de tener en cuenta.

- "Cada uno de los canales se cierra individualmente, por tiempo transcurrido o por acuerdo de los corresponsales. El cierre del canal es lo único que se graba en la cadena de bloques, con el estado final del balance de ambos extremos."

Con esto me has puesto en duda y he tenido que mirarlo. Los canales siempre se abren de forma indefinida, no hay "tiempo transcurrido". Por lo tanto las partes lo tienen que cerrar.

---------- Post added 07-mar-2018 at 12:04 ----------

Exactamente y ese es el gran problema porque obliga a que el nodo origen conozca en todo momento el estado completo de la red. Cosa posible en redes pequeñas, como la actual de prueba, pero imposible en una red distribuida de mayor tamaño ya que el trabajo requerido aumenta factorialmente a medida que aumenta el número de nodos..
Si a eso añadimos que es una red desestructurada, donde no sabes que dirección tienes que tomar, el resultado final es que el escalado del rutaje es en la practica inviable cosa que, muy probablemente, se buscaba desde el principio.

Como muy bien se resumía en reddit la solución es sencilla:

.-Todo el mundo solo abre canales con Blockstream
.-Todo el mundo paga los fee a Blockstream

Problema del routing arreglado.

P.S.
Para el que le interese de verdad este tema, nos encontramos con una variación de un problema básico en las ciencias de la computación conocido como "El problema del viajante" pero con dos añadidos que complican muchísimo mas el tema. Uno es que nos encontramos en un entorno descentralizado donde los nodos pueden desaparecer en cualquier momento por lo que el camino elegido deja de ser válido y el otro que hay que calcular que el camino elegido tiene suficientes fondos para completar la transacción cosa que puede variar en cualquier momento.
Básicamente es un problema de una enorme complejidad e irresoluble en la práctica, al menos en su diseño actual, en cuanto la red alcanza un cierto tamaño y cuya única solución es la centralización de todo el rutaje en unos pocos Hubs.
Supongo que hasta que la red Lightning Network crezca no se podrá comprobar como realmente funciona o si se veran hubs. Yo creo que cierta centralización en hubs se dará, pero seria centralización de la segunda capa, no de la red bitcoin. Ya veremos, hasta que crezca son todo hipótesis.

Mientras tanto, hay simuladores como este:

GitHub - dianerey/lnsim: Lightning Network Simulator

Y estudios como este realizados con 10 millones de usuarios en una red de mallado completo (una locura)

Simulating a Decentralized Lightning Network with 10 Million Users

Sí alguien quiere más información sobre el enrutamiento en LN, la puede encontrar en los BOLTs, en concreto el 4 y el7:

lightning-rfc/04-onion-routing.md at master · lightningnetwork/lightning-rfc · GitHub

lightning-rfc/07-routing-gossip.md at master · lightningnetwork/lightning-rfc · GitHub

Este es el índice:

https://github.com/lightningnetwork/lightning-rfc/blob/master/00-introduction.md
 
Una puntalizacion sobre lo que he comentado de que cierta centralización se dará....

Si en el hipotético caso se diera una centralización en forma de hubs, no sería comparable a la centralización de la minería por ejemplo; por un matiz muy importante, en la minería la centralización seria de la confianza, mientras en LN, seria centralización operativa porque en LN no existe parámetro confianza ya que los fondos los maneja un Smart contract.
 
Gracias por tus aclaraciones y por la info aportada.

2 últimas dudas, si me permites:

- ¿Existe la posibilidad de establecer un sólo canal entre más de 2 corresponsales? ¿hay algún límite en el número de firmas de la dirección multifirma?

- A la hora de cerrar el canal: ¿basta con que una de las partes lo cierre para que se grabe en la cadena de bloques? o tienen que estar los 2 de acuerdo.

Me va quedando claro que habrá que ir definiendo los casos de uso de esta nueva tecnología, aunque aún quedan bastantes aspectos por concretar. En todo caso, es un placer estar viendo en directo la gestación de las nuevas funcionalidades de capa 2 de bitcoin.

Estamos viviendo tiempos interesantes :baba:


Te corrijo algunas cosillas:

- "La creación de canales no se graba en la cadena de bloques"

Cuando se crea un canal se transfieren los fondos a una dirección multifirma que requiere de 2 confirmaciones para poder usarlo. Y cuando se cierra se vuelve a grabar onchain.

- "El envío y recepción de fondos a través de los canales abiertos es instantáneo (aunque para recibir debe estar el nodo encendido), el único límite es el importe asignado en origen a cada canal"

Es correcto pero el envío de fondos a través del canal no son gratis, tiene comisiones que se han de tener en cuenta.

- "Cada uno de los canales se cierra individualmente, por tiempo transcurrido o por acuerdo de los corresponsales. El cierre del canal es lo único que se graba en la cadena de bloques, con el estado final del balance de ambos extremos."

Con esto me has puesto en duda y he tenido que mirarlo. Los canales siempre se abren de forma indefinida, no hay "tiempo transcurrido". Por lo tanto las partes lo tienen que cerrar.

---------- Post added 07-mar-2018 at 12:04 ----------

Supongo que hasta que la red Lightning Network crezca no se podrá comprobar como realmente funciona o si se veran hubs. Yo creo que cierta centralización en hubs se dará, pero seria centralización de la segunda capa, no de la red bitcoin. Ya veremos, hasta que crezca son todo hipótesis.

Mientras tanto, hay simuladores como este:

GitHub - dianerey/lnsim: Lightning Network Simulator

Y estudios como este realizados con 10 millones de usuarios en una red de mallado completo (una locura)

Simulating a Decentralized Lightning Network with 10 Million Users

Sí alguien quiere más información sobre el enrutamiento en LN, la puede encontrar en los BOLTs, en concreto el 4 y el7:

lightning-rfc/04-onion-routing.md at master · lightningnetwork/lightning-rfc · GitHub

lightning-rfc/07-routing-gossip.md at master · lightningnetwork/lightning-rfc · GitHub

Este es el índice:

lightning-rfc/00-introduction.md at master · lightningnetwork/lightning-rfc · GitHub
 
Gracias por tus aclaraciones y por la info aportada.

2 últimas dudas, si me permites:

- ¿Existe la posibilidad de establecer un sólo canal entre más de 2 corresponsales? ¿hay algún límite en el número de firmas de la dirección multifirma?

- A la hora de cerrar el canal: ¿basta con que una de las partes lo cierre para que se grabe en la cadena de bloques? o tienen que estar los 2 de acuerdo.

Me va quedando claro que habrá que ir definiendo los casos de uso de esta nueva tecnología, aunque aún quedan bastantes aspectos por concretar. En todo caso, es un placer estar viendo en directo la gestación de las nuevas funcionalidades de capa 2 de bitcoin.

Estamos viviendo tiempos interesantes :baba:

Si, coincido, para el que le guste la tecnología son tiempos interesantes; pero no me dan las horas del día para ver, oir y leer todo lo que hay :ouch:

Sobre las dudas:

- ¿Existe la posibilidad de establecer un solo canal entre más de 2 corresponsales? ¿hay algún límite en el número de firmas de la dirección multifirma?

No, el canal unicamente es entre dos peers y el saldo final es el que esta firmado por los dos en la ultima transacción realizada en el canal.

- A la hora de cerrar el canal: ¿basta con que una de las partes lo cierre para que se grabe en la cadena de bloques? o tienen que estar los 2 de acuerdo.

Se puede cerrar unilateralmente; el saldo resultante onchain sería el de la ultima transacción firmada por los dos, menos las comisiones para el minero.

---------- Post added 07-mar-2018 at 16:37 ----------

En el crash del 2011 de BTC estuvo involucrado Mtgox, en el de 2014 también y en este último... parece que también (aunque parece que la venta se realizo OTC); el fideicomiso de MTGox vendió 35841 Bitcoins por $362 millones y 34008 BCH por $45 millones.

Curiosas las fechas de los movimientos, coinciden con la brusca caída de Bitcoin desde su ultimo pico o justo un día antes de la bajada a 6000$ (6 de Febrero) se vendieron 18000 bitcoins. Que coincidencias!

2017-12-18 03:28 Bitcoin Block Explorer - Blockchain 2000 BTC -> 1MLGpEQfzd44vPuiihuazPL9tW7qzew1J5
2017-12-22 03:18 Bitcoin Block Explorer - Blockchain 6000 BTC -> 1MLGpEQfzd44vPuiihuazPL9tW7qzew1J5
2018-01-17 03:28 Bitcoin Block Explorer - Blockchain 8000 BTC -> 1MLGpEQfzd44vPuiihuazPL9tW7qzew1J5
2018-01-31 02:57 Bitcoin Block Explorer - Blockchain 6000 BTC -> 14LuAvrRzAmeikgaafs7H5695xs5dVXqA5
2018-02-05 06:31 Bitcoin Block Explorer - Blockchain 6000 BTC -> 14LuAvrRzAmeikgaafs7H5695xs5dVXqA5
2018-02-05 06:31 https://blockchain.info/tx/d833bd0e7bed0f09748a0cb04611ced5fc9210f95b40b0c02cd65b3ce326f67a: 6000 BTC -> 14LuAvrRzAmeikgaafs7H5695xs5dVXqA5
2018-02-05 06:31 https://blockchain.info/tx/fa824de460a4048fdc404b041bfad6ae5c689ec196721f1eb7ae6c439961df86: 6000 BTC -> 14LuAvrRzAmeikgaafs7H5695xs5dVXqA5

El articulo: https://www.trustnodes.com/2018/03/...lf-billion-dollars-worth-bitcoin-bitcoin-cash
 
Última edición:
jorobar, vaya bajada... miré la cotización hace un ratito estaba 1,000 $ arriba...
 
Las ventas que he comentado antes puestas en el gráfico:
48a07f007a45ee7521a4698adcecb4b0.jpg


---------- Post added 07-mar-2018 at 21:41 ----------

Bitcoin Cypherpunk hardware list :

- Trezor Model-T and/or LedgerBlue
- Raspberry PI Bitcoin and LN node
- DargonMint T1 miner
- CryptoSteel mnemonic backup
- OpenDime
- Airgapped laptop running Tails OS
- GeoSAT + blockstream satellite node


Twitter

---------- Post added 07-mar-2018 at 22:00 ----------

Halong Mining el primer fabricante de equipos de minería en implementar AsicBoost abierto.

Pego parte que me ha llamado la atención:

"BtcDrak, the pseudonymous Bitcoin developer behind Halong Mining, also proposed a Bitcoin Improvement Proposal (BIP) on the Bitcoin development mailing list referencing AsicBoost. The proposal itself is more generic, however, as it creates a future-proof space for mining optimizations that miners may come up with in the future.

While overt use of AsicBoost does not require a Bitcoin protocol change, it may interfere with the established soft fork activation process. More specifically, AsicBoost interferes with how some software clients interpret potential soft fork activation on the network, which could result in false positives. To mitigate this risk, software clients might need to be updated to allow for fewer soft fork upgrades simultaneously.

“I apologise for the inconvenience in advance, but this is the unfortunate result of restraints while negotiating to get the patent opened and licensed defensively in the first place,” BtcDrak wrote.

El artículo completo:

Halong Mining Is the First Bitcoin Mining Hardware Producer to Implement Overt AsicBoost

---------- Post added 07-mar-2018 at 22:34 ----------

- Bot malicioso en Binance realiza venta masiva de criptomonedas sin consentimiento de usuarios

Bot malicioso en Binance realiza venta masiva de criptomonedas sin consentimiento de usuarios | CriptoNoticias - Bitcoin, Blockchain y criptomonedas

- Administrador de Mt. Gox vende criptomonedas de la casa de cambio para indemnizar a sus clientes

Administrador de Mt. Gox vende criptomonedas de la casa de cambio para indemnizar a sus clientes | CriptoNoticias - Bitcoin, Blockchain y criptomonedas
 
Última edición:
¿Existe algún gráfico fiable del consumo real de electricidad que se destina a la minería y su impacto en el precio final de la factura eléctrica? Si no existe ¿Hay algún modo de calcularlo?

Sería interesante comprobar cómo ha ido subiendo el consumo de luz en el tiempo para minar monedas y su impacto concreto en el precio que al final se paga por la luz.

 
¿Existe algún gráfico fiable del consumo real de electricidad que se destina a la minería y su impacto en el precio final de la factura eléctrica? Si no existe ¿Hay algún modo de calcularlo?

Sería interesante comprobar cómo ha ido subiendo el consumo de luz en el tiempo para minar monedas y su impacto concreto en el precio que al final se paga por la luz.
los que se quejan del consumo energético no entienden el valor que aporta el pow.
bitcoin consume su pero aporta un valor que supera el precio de la energía.

cuanto consume por ejemplo el ejercito español? que valor aporta?
cuanto cuesta el futbol energèticamente?
Que valor aporta?
En los dos casos últimos, yo no entiendo el valor que aportan, por lo tanto me cuestiono el gasto que comportan.

Enviado desde mi Redmi 3 mediante Tapatalk
 
Volver