👋🏼 Hola hola

Por qué protocolos fuera de la red de Bitcoin 🤔?

1. Bitcoin es pésimo como experiencia de usuario: Si le quiero explicar a mis abuelos que puedo enviar dinero por internet usando Bitcoin no hace sentido mostrar cómo hago una transacción con un QR (misterioso 🧙🏽‍♂️), esperar 10 minutos (esperanza del siguiente bloque), y no tener la certeza de que va realmente llegar el dinero a la billetera que estoy mostrando. ¿Cómo le explicas que tienes que pagar un fee por la cantidad de espacio en el bloque a una persona 100% no técnica, que solo quiere pagar la subscripción al WoW?
2. Bitcoin tiene que ser sólido, debe inspirar confianza: A pesar de lo que digan ciertos críticos sobre que no hay mucho desarrollo o innovación en la red de Bitcoin (y ciertamente mentira), Bitcoin debe ser sumamente estable como red de traspaso y almacenaje de valor. En cierta medida el código es la ley, por lo que agregar nuevas características o funcionalidades es abrir más posibilidades a posibles errores de código o que existan escenarios no probados.

La visión de Mr. señor Satoshi 🥸

Satoshi tenía planeado que se podía hacer canales o formas de tener transacciones constantes entre distintas personas / entidades / grupos / etc. Para esto la primera implementación de Bitcoin venía incluido un nSequence que estaba pensando usarse de la siguiente forma:

Augusto y Bárbara (sí, los cambié, reclámenme gente de redes 😂), crean una transacción en conjunto usando inputs (por simplicidad 1). Cada input tiene un timelock que lo hace inválido hasta cierto tiempo en el futuro y colocan un nSequence 0. Los output tienen un valor acordado en un principio (lo mismo de los input?) para comenzar el canal. Esta transacción la envían al mempool, la cual no va ser considerada hasta que el timelock venza.

Luego Augusto y Bárbara pueden hacer transacciones entre ellos, pagar la cuota del asado entre ellos o comprar un libro que tanto quería Augusto. En cada transacción los output se modifican para aumentar el valor hacia un lado o hacia el otro, enviándolo al mempool con un nSequence 1, funcionando así como un contador de cuál transacción es la última.

 Nota 💡:  No voy a asumir que todos conocen técnicamente Bitcoin, por lo que un par de explicaciones no hacen mal.

• Mempool: Es la base de datos de transacciones no confirmadas o pendientes que mantienen los nodos de Bitcoin. Estas transacciones son compartidas entre ellos a través de mensajes. No todos los nodos tienen la misma base de datos y existen varios que si quieren no almacenan estos. Los mineros toman de estas transacciones para construir los bloques
• nSequencue: Es un atributo (o parte) de un input de una transacción de Bitcoin. En otras palabras son bits que representan un número en la transacción ya decodificada.
• Timelock: Bloqueo por tiempo para que la transacción sea confirmada válidamente, en otras palabras, que los mineros lo tomen del mempool (nLockTime) o también que los output de la transacción sean gastables (CLTV o CSV). Los timelocks pueden ser representados como unix epoch time o número de bloque.

1. Vas a un bar y prometes pagar cuando el bar cierre (Timelock, para ser exacto nLockTime)
2. Para tu primer trago haces una transacción pagándolo, colocando el nLockTime en el bloque que cierra el Bar y con nSequence 0
3. Para tu segundo trago, haces la misma transacción, con el output más grande al bartender ( o realmente el bar?) con nSequence 1
4. Eventualmente tienes que dejar de tomar, dejando dos posibilidades:
   • Tomas hasta que cierra el bar (guiño guiño varios amigos). Ahí nLockTime se cumple, se manda al mempool y el bartender te puede echar con la cuenta ya pagada, tranquilamente
   • Consideras meticulosamente la resaca del día siguiente y firmas la última transacción con el número más grande posibles, señalando al bartender puede obtener los fondos inmediatamente. En este caso en particular, el Timelock es ignorado por los mineros.

1. Eres muuuy amigo de Jihan Wu, quien tiene 51% del hashing power de la red. También eres muy amigo de Federico, muy bueno en redes que puede eclipsar fácilmente nodos 🥸
2. Invitas a los dos al bar y compran 150 tragos, 50 para cada uno con papa fritas para compartir y un par de Pepsi zero.
3. Al momento de cerrar al bar, se van tranquilamente. El bartender ve la última transacción en su nodo con todo lo que pidieron, está feliz, la propina es enorme. Mientras tanto Jihan Wu llama a para que minen la transacción con nSquence 0. La primera con solo un trago.
4. Llegan a sus casa tranquilamente, pensando en la resaca del día de siguiente
5. El bartender al ver que se minó primera transacción  y no la que veía en su nodo:

• Satoshi tenía una idea de canales de pagos
• Los mineros pueden saltarse cualquier regla que pongamos en el mempool
• Satoshi no pudo ser tan inteligente de achuntarle a todo. Hoy no usamos nSequence de esta forma

Nota 👀  Se puede lograr el mismo ataque con un eclipsado al nodo o teniendo mayor cantidad de Hash Power.  No obstante, no es necesario ninguna de las dos para que ocurra, ya que un minero pudo haber recibido la primera TX solamente y haber encontrado un bloque sin ver nada.

Simple Micropayment Channel (Canal de micro-pagos simple ? ) 🍃

Creado por Spilman en el 2013, es la versión mejorada de lo que pensó el Don señor Mr. Satoshi que podemos resumir en la definición: "Canales unidireccionales con tiempo limitado y compatible con incentivos". También un intento de forma para no hacer trampa a los bartender

Volviendo a nuestro ejemplo, antes de comenzar con los tragos se realiza el siguiente ritual:

1. Creas una transacción a una dirección con multifirmas 2-2 (se necesitan dos firmas de dos) entre el bartender y tú. No la envías al mempool
2. Creas una nueva transacción (backoff) que gasta la transacción inicial. Esta transacción tiene un nLockTime igual a la hora de cierre del bar + 1 bloque. La firmas y le das esta transacción ya firmada al bartender
3. El bartender firma el backoff y te lo devuelve. Ahora es válido porque los dos tienen la transacción
4. Transmites la primera transacción a la red. El bartender y tú esperan que esté muy bien confirmada (1 hora de no comer nada y mirarse fijamente) para comenzar a ordenar tragos.

1. Primer trago, creas una transacción que gasta de la primera ya confirmada con un output del valor del primer trago con la otra parte apuntando hacia una dirección tuya.
2. Firmas la transacción, se la pasas al bartender, quien te da la anhelada piscola
3. Para los siguientes tragos recreas los mismos dos pasos anteriores, agregando el precio y sumándolo con lo que ya estabas enviando.
4. Al final
   • Si el bar va a cerrar, el bartender firma la última transacción completando el 2-2
   • Si decides que te quieres ir antes a casa porque tu hígado ya no puede más, simplemente le dices al bartender que cierre el canal firmando la última transacción
   • Si no tomaste nada realmente - te quedaste mirando al infinito, contemplando la vida bitcoinizada - puedes reclamar tus fondos usando el backoff

• Bartender se rehúsa a atenderte, se ríe y se va a conversar con otras personas
• Tú enojado, te vas diciendo que simplemente transmites la transacción de backoff y que vas a publicar en todos lados el pésimo bar que es este
• El bartender te mira con desprecio y te pide que revises un explorador de bloques confiable, no la basura que estabas usando (en sus palabras). Enojado, taimado porque realmente estabas dispuesto a tener resaca, revisas la tx, y... el Id de la transacción es diferente! El bartender te mira con cara de superioridad porque sabe que recuperó la propina de la última vez.
• Tú, impresionado, le preguntas cómo  mierda  te cambió la firma, si tu private key la enterraste en los campos de hielo cerca de Cochrane, te demoras 10 días a pie para solo llegar donde los conquistadores que te pueden llevar a caballo al lugar recóndito, donde aún existen huemules y la caja sellada herméticamente que solo tú sabes la contraseña.
• Así, el bartender te explica que se pueden malear las firmas ya que son simplemente grandes números pero que afectan el id de transacción. Todos pueden hacer esto sin la llave privada. Se ríe en tu cara y te pide que le pagues el 99% de los fondos de la transacción inicial para que puedas recuperar el 1%.

• Sé bueno con los bartender
• Se pueden malear transacciones y es una de las grandes razones por las que se desarrolló SegWit.
• Incluir las firmas en lo que define el id de transacción fue otro pastel de Satoshi. Sip, se farreó varias pero lo dejamos pasar porque prácticamente inventó la moneda mágica del internet 🧙🏽‍♂️ 

Duplex micropayment Channel 🛣

1. Bárbara firma una nueva transacción con más output a Augusto con T=99
2. Augusto devuelve la transacción firmada 
3. Ambos quedan con el mismo estado "simétrico"
4. Augusto le paga la hierba mate que trajo de Argentina a Bárbara, firmando una nueva transacción con más output hacia Bárbara con T=98
5. Bárbara, incentivada a tener más dinero, devuelve la transacción firmada a Augusto

En este caso en particular, se debe utilizar expresamente SegWit para que no puedan malear las transacciones 🥷🏽 pero, por qué tenemos esos Timelocks?

Aquí lo más importante, debido a que ambos pueden pagarse mutuamente, es que se necesita una forma de invalidar el estado anterior al último pago. Si Augusto quiere hacer trampa a Bárbara y la transacción no tuviera timelocks, nada lo detendría a transmitir al mempool cualquier transacción que lo deje con más sats.
 


Lo "elegante"de la solución es que es sumamente sencillo entender que un T=45 va estar disponible antes de  un T=50, lo que significa que si mantenemos constante ojo 👀  a qué transacciones debo enviar al mempool, nadie me puede hacer trampa.

No todo es flores y rosas 🌹, el problema de estos canales de pagos es que son de tiempo finito. Cuando se libera uno de los timelock los incentivos están puestos a enviar la transacción al mempool y dejar de operar.
También existe una cantidad máxima de pagos entre canales.

Esos problemas no están presente en Lightning Network ⚡️ que veremos en un siguiente episodio de los 2 sats a la comunidad 🚀

Conclusiones

Links de interés (en inglés)