No se encontraron resultados

La página solicitada no pudo encontrarse. Trate de perfeccionar su búsqueda o utilice la navegación para localizar la entrada.

Boletín Bitcoin Optech #260

Boletín Bitcoin Optech #260

BITCOIN OPTECH (19 de Julio, 2023). Bitcoin Optech Newsletter #260 | Traducción al español de Conociendo Cripto   Boletín Bitcoin Optech #260 19 de julio de 2023 El boletín de esta semana incluye la entrada final de nuestra serie semanal limitada sobre la política de...

Boletín Bitcoin Optech #259

Boletín Bitcoin Optech #259

BITCOIN OPTECH (28 de Junio, 2023). Bitcoin Optech Newsletter #259 | Traducción al español de IT4Bitcoin   Boletín Bitcoin Optech #259 12 de julio de 2023 Esta semana en el boletín se describe una propuesta para eliminar detalles de la especificación de LN que ya no...

Boletín Bitcoin Optech #257

Boletín Bitcoin Optech #257

BITCOIN OPTECH (28 de Junio, 2023). Bitcoin Optech Newsletter #257 | Traducción al español de IT4Bitcoin   Boletín Bitcoin Optech #257 28 de junio de 2023 El boletín de esta semana resume una idea para evitar el anclaje de transacciones coinjoin y describe una...

Boletín Bitcoin Optech #256

Boletín Bitcoin Optech #256

BITCOIN OPTECH (21 de Junio, 2023). Bitcoin Optech Newsletter #256 | Traducción al español de ConociendoCripto   Boletín Bitcoin Optech #256 junio 21, 2023 El boletín de esta semana resume una discusión sobre la ampliación de las facturas BOLT11 para solicitar dos...

Boletín Bitcoin Optech #255

Boletín Bitcoin Optech #255

BITCOIN OPTECH (01 de Junio, 2022). Bitcoin Optech Newsletter #255 | Traducción al español de IT4Bitcoin   Boletín Bitcoin Optech #255 junio 15, 2023 En el boletín de esta semana se resume una discusión sobre permitir el reenvío de transacciones que contienen datos en...

No se encontraron resultados

La página solicitada no pudo encontrarse. Trate de perfeccionar su búsqueda o utilice la navegación para localizar la entrada.

Hardware Post 7

Hardware Post 7

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in...

Hardware Post 7

Hardware Post 5

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in...

Nuestras impresiones de The Bitcoin Collective Conference

Nuestras impresiones de The Bitcoin Collective Conference

Esta fue la primera edición de The Bitcoin Collective, la conferencia de Bitcoin más grande del Reino Unido hasta el momento. Transcurrida durante el fin de semana que fue del Viernes 21 de octubre hasta el sábado (22 de octubre) en la capital de Escocia, Edimburgo....

Bitcoin y Pasaportes

Bitcoin y Pasaportes

EXE GUERRA (09 de agosto, 2022). Bitcoin y Pasaportes Desde sus inicios como Libertario pasando por la ONG Bitcoin Argentina y la creación de Espacio Bitcoin hasta la paternidad y su migración a Europa, Franco nos lleva por un viaje cuyo lema actual es: Bitcoin y...

Bitcoin, Bear Market y actualidad con Nico Bourbon

Bitcoin, Bear Market y actualidad con Nico Bourbon

EXE GUERRA (04 de julio, 2022). Bitcoin, Bear Market y actualidad con Nico Bourbon En esta Sesión Exe conversa con Nico Bourbon referente histórico del ecosistema Bitcoin y cripto en Argentina. Desde sus inicios hasta el Bear Market actual, Nico nos comparte qué lo...

Feliz Bitcoin Pizza Day – ¿Mis 10.000 BTC no valen nada?

Feliz Bitcoin Pizza Day – ¿Mis 10.000 BTC no valen nada?

Conociendo Cripto (22 de mayo, 2022). Feliz Bitcoin Pizza Day – ¿Mis 10.000 BTC no valen nada? Con una pizza mitad mozzarella, rúcula y tomates cherry y otra mitad de 4 quesos sumado a cerveza artesanal, el equipo de solobitcoin.info festejó los 12 años de la primera...

Recomendaciones para usuarios de LN

Recomendaciones para usuarios de LN

Darthcoin (25 de mayo, 2022). Recomendaciones para usuarios de LN Una simple advertencia sobre el uso de Lightning Network en el estado actual Este artículo está dedicado a todos los nuevos usuarios que comienzan ahora o quieren comenzar ahora a correr un nodo BTC/LN....

Qué es y como funciona Lnp2pbot❓

Qué es y como funciona Lnp2pbot❓

JUAN RODRIGUEZ (29 de abril, 2022). Qué es y como funciona Lnp2pbot En el video explico como funciona Lnp2pbot para comprar y vender #bitcoin de forma anónima, sin KYC y de forma inmediata.

Comparación Lightning Wallets

Comparación Lightning Wallets

Comparación Lightning Wallets DarthCoin ₿⚡️February 27, 2022 Introducción Bien, incorporamos nuevos usuarios a Bitcoin. Pero muchos de ellos están confundidos por la gran cantidad de tipos de wallets y no saben exactamente con cuál deberían comenzar o si es adecuado...


BITCOIN OPTECH (05 de Julio, 2023). Bitcoin Optech Newsletter #258 | Traducción al español de IT4Bitcoin

 CriptoNoticias Logo

Boletín Bitcoin Optech #258

05 de julio de 2023

Este boletín semanal incluye otro artículo de nuestra serie limitada sobre la política de la mempool, además de nuestras secciones regulares que anuncian nuevos lanzamientos y candidatos a lanzamiento, y describen cambios destacados en el software de infraestructura popular de Bitcoin.

Noticias

Esta semana no se encontraron noticias significativas en las listas de correo de Bitcoin-Dev y Lightning-Dev.

Esperando confirmación #8: Política como una interfaz

Una serie limitada semanal sobre la transmisión de transacciones, la inclusión en la mempool y la selección de transacciones para la minería, incluyendo por qué Bitcoin Core tiene una política más restrictiva que la permitida por el consenso y cómo las carteras pueden utilizar esa política de manera más efectiva.

Hasta ahora, en esta serie, hemos explorado las motivaciones y desafíos asociados con la transmisión descentralizada de transacciones, lo que ha llevado a la necesidad de reglas de validación de transacciones más restrictivas a nivel local y global que el consenso. Dado que los cambios en la política de transmisión de transacciones en Bitcoin Core pueden afectar si las transacciones de una aplicación se transmiten, requieren ser socializados con la comunidad de Bitcoin más amplia antes de ser considerados. Del mismo modo, las aplicaciones y los protocolos de segunda capa que utilizan la transmisión de transacciones deben ser diseñados teniendo en cuenta las reglas de política para evitar la creación de transacciones que sean rechazadas.

Los protocolos de contratación dependen aún más de las políticas relacionadas con la priorización, ya que la aplicabilidad en la cadena depende de poder confirmar rápidamente las transacciones. En entornos adversos, las contrapartes malintencionadas pueden tener interés en retrasar la confirmación de una transacción, por lo que también debemos pensar en cómo se pueden aprovechar las peculiaridades de la interfaz de política de transacciones en contra de un usuario.

Las transacciones de la Lightning Network cumplen con las reglas de estandarización mencionadas en publicaciones anteriores. Por ejemplo, el protocolo peer-to-peer especifica un «dust_limit_satoshis» en su mensaje «open_channel» para especificar un umbral de «dust» (cambio insignificante). Dado que una transacción que contiene una salida con un valor menor que el umbral de «dust» no se transmitirá debido a los límites de «dust» de los nodos, esos pagos se consideran «no exigibles en la cadena» y se eliminan de las transacciones de compromiso.

 Los protocolos de contratación a menudo utilizan rutas de gasto con bloqueo temporal para dar a cada participante la oportunidad de impugnar el estado publicado en la cadena. Si el usuario afectado no puede confirmar una transacción dentro de ese período de tiempo, puede sufrir una pérdida de fondos. Esto hace que las tarifas sean extremadamente importantes como mecanismo principal para aumentar la prioridad de confirmación, pero también más desafiantes. La estimación de la tasa de comisión se complica por el hecho de que las transacciones se transmitirán en algún momento desconocido posterior, los nodos a menudo operan como clientes ligeros y algunas opciones de aumento de tarifas no están disponibles. Por ejemplo, si un participante de un canal de LN se desconecta, la otra parte puede transmitir unilateralmente una transacción de compromiso prefirmada para liquidar la distribución de sus fondos compartidos en la cadena. Ninguna de las partes puede gastar unilateralmente el UTXO compartido, por lo que cuando una de las partes está desconectada, no es posible firmar una transacción de reemplazo para aumentar la tarifa de la transacción de compromiso. En su lugar, las transacciones de compromiso de LN pueden incluir salidas ancla para que los participantes del canal puedan adjuntar un hijo que aumente la tarifa en el momento de la transmisión.

Sin embargo, este método de aumento de tarifas también tiene limitaciones. Como se mencionó en una publicación anterior, agregar una transacción CPFP no es efectivo si las tarifas mínimas de la mempool aumentan por encima de la tarifa de la transacción de compromiso, por lo que aún deben firmarse con una tarifa ligeramente sobreestimada en caso de que las tarifas mínimas de la mempool aumenten en el futuro. Además, el desarrollo de las salidas ancla incluyó varias consideraciones debido a que una de las partes puede tener interés en retrasar la confirmación. Por ejemplo, una parte (Alice) puede transmitir su propia transacción de compromiso a la red antes de desconectarse. Si la tarifa de esta transacción de compromiso es demasiado baja para una confirmación inmediata y si la contraparte de Alice (Bob) no recibe su transacción, puede haber confusión cuando las transmisiones de su versión de la transacción de compromiso no se transmitan con éxito. Cada transacción de compromiso tiene dos salidas ancla para que cualquiera de las partes pueda usar CPFP en cualquiera de las transacciones de compromiso, por ejemplo, Bob puede intentar transmitir ciegamente un aumento de tarifa CPFP de la versión de Alice de la transacción de compromiso, incluso si no está seguro de que ella haya transmitido previamente su versión. Cada salida ancla se asigna un valor pequeño por encima del umbral de «dust» y puede ser reclamada por cualquiera después de cierto tiempo para evitar inflar el conjunto de UTXO.

Garantizar la capacidad de CPFP de cada parte en una transacción es más complicado que simplemente proporcionarles una salida ancla. Como se mencionó en una publicación anterior, Bitcoin Core limita la cantidad y el tamaño total de las transacciones descendientes que se pueden adjuntar a una transacción no confirmada como protección contra ataques de denegación de servicio. Dado que cada contraparte tiene la capacidad de adjuntar transacciones descendientes a la transacción compartida, uno podría bloquear la transacción CPFP del otro impidiendo que se transmita agotando esos límites. La presencia de estas transacciones descendientes «ancla» a la transacción de compromiso y la mantiene en una posición de baja prioridad en las mempools.

Para mitigar este posible ataque, la propuesta de salidas ancla de la LN bloquea todas las salidas que no son anclas con un bloqueo de tiempo relativo, evitando que se gasten mientras la transacción no está confirmada, y la política de límite de descendientes de Bitcoin Core se modificó para permitir un descendiente adicional cuando este nuevo descendiente era pequeño y no tenía otros ancestros. Esta combinación de cambios en ambos protocolos aseguró que al menos dos participantes en una transacción compartida pudieran ajustar la tarifa en el momento de la transmisión, sin aumentar significativamente la superficie de ataque DoS en la transmisión de transacciones.

La prevención de CPFP a través del dominio del límite de descendientes es un ejemplo de un ataque de «pining». Los ataques de «pining» aprovechan las limitaciones en la política de la mempool para evitar que las transacciones compatibles con los incentivos entren en las mempools o se confirmen. En este caso, la política de la mempool ha hecho un equilibrio entre la resistencia a los ataques DoS y la compatibilidad de incentivos. Se debe hacer un equilibrio: un nodo debe considerar las aumentos de tarifas, pero no puede procesar un número infinito de descendientes. La excepción de CPFP refina este equilibrio para un caso de uso específico.

Además de agotar el límite de descendientes, existen otros ataques de «pining» que impiden el uso de RBF, hacen que RBF sea prohibitivamente costoso o aprovechan RBF para retrasar la confirmación de una transacción de ANYONECANPAY. El «pining» solo es un problema en escenarios en los que múltiples partes colaboran en la creación de una transacción o cuando hay espacio para que una parte no confiable interactúe con la transacción. Minimizar la exposición de una transacción a partes no confiables es generalmente una buena manera de evitar el «pining».

Estos puntos de fricción resaltan no solo la importancia de la política como una interfaz para aplicaciones y protocolos en el ecosistema de Bitcoin, sino también dónde necesita mejorar. En la publicación de la próxima semana se discutirán propuestas de política y preguntas abiertas.

Lanzamientos y candidatos a lanzamientos

 ● Core Lightning 23.05.2 es una versión de mantenimiento de este software de nodo LN que contiene varias correcciones de errores que pueden afectar a los usuarios en producción. Se recomienda considerar la actualización a esta nueva versión para aprovechar las mejoras y correcciones implementadas. También se anima a los usuarios a ayudar en la prueba de las versiones candidatas para garantizar la estabilidad y el rendimiento del software.

Cambios destacados en el código y la documentación

 

● Bitcoin Core #24914 carga los registros de la base de datos de la billetera en orden por tipo en lugar de recorrer toda la base de datos dos veces para detectar dependencias. Algunas billeteras con registros corruptos pueden dejar de cargarse después de este cambio, pero se pueden cargar con una versión anterior de Bitcoin Core y transferirse a una nueva billetera.

● Bitcoin Core #27896 elimina la función experimental de sandbox para llamadas al sistema (syscall) (ver Newsletter #170). Un problema relacionado y los comentarios posteriores señalan las desventajas de la función, incluida la mantenibilidad (tanto de la lista blanca de syscalls como del soporte del sistema operativo), alternativas mejor soportadas y consideraciones sobre si el sandboxing de syscall debería ser responsabilidad de Bitcoin Core.

● Core Lightning #6334 actualiza y expande el soporte experimental de CLN para salidas de anclaje (ver Newsletter #111 para la implementación inicial de CLN). Algunas de las actualizaciones en esta solicitud de extracción incluyen habilitar el soporte experimental para anclajes HTLC sin comisiones y agregar controles configurables para garantizar que el nodo tenga al menos la cantidad mínima de fondos de emergencia necesarios para operar un canal de anclaje.

● BIPs #1452 actualiza la especificación BIP329 para un formato de exportación de etiquetas de billetera con una nueva etiqueta opcional gastable que indica si la salida asociada debe ser gastable por la billetera. Muchas billeteras implementan funciones de control de monedas que permiten al usuario indicar al algoritmo de selección de monedas que no gaste ciertas salidas, como salidas que podrían reducir la privacidad del usuario.

● BIPs #1354 agrega BIP389 para los descriptores de ruta de derivación múltiple descritos en el Newsletter #211. Permite que un solo descriptor especifique dos rutas de BIP32 relacionadas para la generación de claves HD: la primera ruta para pagos entrantes y la segunda ruta para pagos internos de la billetera (como el cambio).