Software Mining de código abierto desarrollado en Rust por Braiins (antes Slush Pool) como alternativa más moderna a CGMiner. BOSminer está diseñado específicamente para ASICs. Integrado en el ecosistema BraiinsOS, permite una gestión avanzada de ASIC, con funciones como overclocking, supervisión detallada del rendimiento y compatibilidad con StratumV2.
Acrónimo de «Basis Of Lightning Technology» Se trata de una serie de especificaciones diseñadas para permitir la interoperabilidad de Lightning entre distintas implementaciones de este protocolo de segunda capa (LND, Core Lightning, Eclair…). Estas especificaciones detallan las reglas y normas que deben seguirse para que los nodos Lightning formen una única red.
Propuesta que permite a un nodo Bitcoin abrir información sobre su mempool, es decir, las transacciones que esperan confirmación. Gracias a esto, otros participantes pueden recibir datos en tiempo real sobre transacciones sin confirmar enviando un mensaje específico a un nodo. Antes de la adopción del BIP35, los nodos sólo podían acceder a información sobre … Leer más
La bifurcación suave se aplicó en marzo de 2013, a partir del bloque 227.930, que introdujo la versión 2 para los bloques de Bitcoin. Esta nueva versión exige que cada bloque incluya en el scriptSig de la transacción coinbase la altura del bloque que se está creando. Este cambio sirve para clarificar la forma en … Leer más
BIP32 introdujo el concepto de cartera jerárquica determinista (cartera HD). Esta propuesta permite generar una jerarquía de pares de claves a partir de una «semilla maestra» común, utilizando funciones de derivación unidireccionales. Cada par de claves generado puede a su vez ser el padre de otras claves hijas, formando así una estructura arborescente (jerárquica). La … Leer más
Propuesta destinada a mejorar los mecanismos de gestión de la red por parte de los nodos Bitcoin. Antes de BIP31, los nodos Bitcoin no tenían forma directa de saber si sus pares seguían conectados, operativos y no sobrecargados. BIP31 introdujo el uso de un mensaje pong, en respuesta a un mensaje ping, que permite una … Leer más
Propuesta de mejora que implica una bifurcación suave implementada el 15 de marzo de 2012, para resolver el problema de los identificadores de transacción duplicados. Antes del BIP30, era técnicamente posible tener dos transacciones diferentes con el mismo identificador de transacción (TXID) en la blockchain. Esto ocurría especialmente dos veces en las transacciones de coinbase: … Leer más
Este BIP es una extensión del BIP22, cuyo objetivo es fomentar su adopción por el software utilizado por los pools de minería, especialmente por el protocolo Getwork, predecesor de Stratum. Propuesta por Luke Dashjr, esta extensión pretende integrar el estándar BIP22 en Getwork por defecto, con el fin de facilitar su adopción por parte de … Leer más
BIP propuesto en 2012 por Luke Dashjr que introduce un método JSON-RPC estandarizado para interfaces de minería externas, llamado «getblocktemplate». Con el aumento de la dificultad de la minería, se ha desarrollado el uso de software externo especializado para producir pruebas de trabajo. Este BIP propone un estándar común de comunicación para la plantilla de … Leer más
Propuesta escrita por Nils Schneider y Matt Corallo, basada en el BIP20 escrito por Luke Dashjr, que a su vez procede de otro documento escrito por Nils Schneider. BIP21 define cómo las direcciones de recepción deben ser codificadas en URIs (Uniform Resource Identifier) para facilitar los pagos. Por ejemplo, un URI Bitcoin siguiendo BIP21 en … Leer más
Propuesta de Luke Dashjr que competía con BIP12 y BIP16. BIP17 introdujo un nuevo opcode, OP_CHECKHASHVERIFY, diseñado para permitir la verificación de un script presente en el scriptSig contra su hash presente en el scriptPubKey antes de desbloquear los fondos. La BIP16 (P2SH) fue finalmente preferida a la BIP17 (CHV) tras un periodo de intensos … Leer más
BIP16 introdujo el concepto de Pay-to-Script-Hash (P2SH), que se traduce como «pagar al hash del script». Propuesto inicialmente en 2012 y activado en 2013, BIP16 pretendía simplificar el uso de transacciones que requieren scripts complejos, como las transacciones multifirma, permitiendo a los usuarios pagar a un hash del script necesario para gastar esos bitcoins en … Leer más
Una propuesta introducida para permitir a los monederos ligeros (Verificación simplificada de pagos) filtrar transacciones sin tener que descargar toda la blockchain. Este método se basa en el concepto de filtros de Bloom, estructuras de datos probabilísticas utilizadas para comprobar la pertenencia a un conjunto. Estos filtros permiten a los clientes de SPV recibir únicamente … Leer más
Una propuesta de mejora de Bitcoin que introduce un mecanismo de cifrado para añadir protección adicional a las claves privadas mediante una frase de contraseña. BIP38 garantiza que incluso si un tercero obtiene físicamente la clave privada cifrada, no podrá utilizarla sin conocer su frase de contraseña. Esto añade una capa adicional de seguridad para … Leer más
Introdujo una estandarización del formato de firma en las transacciones. Este PIF se propuso en respuesta a una divergencia en la forma en que OpenSSL gestionaba la codificación de firmas en distintos sistemas. Esta heterogeneidad planteaba el riesgo de dividir la blockchain. El BIP66 estandarizó el formato de firma para todas las transacciones utilizando una … Leer más
Se ha introducido un nuevo opcode denominado OP_CHECKLOCKTIMEVERIFY que permite inutilizar un UTXO hasta un momento futuro especificado. La implementación de este BIP requirió una bifurcación suave, que se produjo el 14 de diciembre de 2015. También introdujo la versión 4 de los bloques.
BIP50 es un BIP informativo que informa de un error relacionado con la transición de Berkeley DB a Level DB, causando una división en la blockchain de Bitcoin y una reorganización importante de 24 bloques el 12 de marzo de 2013. Este BIP detalla el incidente y las acciones correctivas implementadas.
El BIP49 es un BIP informativo que introduce el método de derivación utilizado para generar direcciones SegWit anidadas en un monedero HD. La ruta de derivación propuesta sigue los estándares de BIP43 y BIP44, con el índice 49′ (derivación endurecida) en la profundidad de la meta. Por ejemplo, la primera dirección de una cuenta P2SH-P2WPKH … Leer más
Propuesto por Justus Ranvier en 2015, este protocolo pretende resolver el problema crítico de la reutilización de direcciones de Bitcoin, una práctica que compromete gravemente la privacidad de los usuarios en el sistema. Satoshi Nakamoto, en el Libro Blanco de Bitcoin, ya había destacado la importancia de utilizar pares de claves distintos para cada transacción … Leer más
Una propuesta de mejora que introduce una estructura de derivación jerárquica estándar para los monederos HD. BIP44 se basa en los principios establecidos por BIP32 para la derivación de claves y en BIP43 para el uso del campo «purpose». Introduce una estructura de derivación de cinco niveles: m / purpose’ / coin_type’ / account’ / … Leer más
