Bitcoin es una innovadora red de pagos y una nueva clase de dinero.
Bitcoin usa tecnología peer-to-peer o entre pares para operar sin una autoridad central o bancos; la gestión de las transacciones y la emisión de bitcoins es llevada a cabo de forma colectiva por la red. Bitcoin es de código abierto; su diseño es público, nadie es dueño o controla Bitcoin y todo el mundo puede participar. Por medio de sus muchas propiedades únicas, Bitcoin permite usos interesantes no contemplados por ningún sistema de pagos anterior.
Que novedades incluye la versión 22.0 See changelog
Released
- Se agregó soporte para ejecutar Bitcoin Core como un servicio I2P (Proyecto de Internet invisible) y conectarse a dichos servicios. Consulte i2p.md para obtener más detalles.
- Esta versión elimina el soporte para los servicios ocultos de Tor versión 2 a favor de Tor v3 solamente, ya que la red Tor dejó de ser compatible con Tor v2 con el lanzamiento de la versión 0.4.6 de Tor. De ahora en adelante, Bitcoin Core ignora las direcciones Tor v2; ni los rumores a través de la red a otros pares, ni los almacena en la memoria o en peers.dat.
- Se agregó soporte para mapeo de puertos NAT-PMP a través de libnatpmp.
- Debido a la implementación de BIP 350, el comportamiento de todas las RPC que aceptan direcciones cambia cuando se pasa una versión de testigo nativo 1 (o superior). Estos ahora requieren una codificación Bech32m en lugar de una Bech32, y la codificación Bech32m también se utilizará para dichas direcciones en la salida RPC. No se deben crear direcciones de la versión 1 para mainnet hasta que se adopten reglas de consenso que les den significado (como sucederá con BIP 341). Una vez que eso suceda, se espera que Bech32m se use para ellos, por lo que esto no debería afectar a ningún sistema de producción, pero se puede observar en otras redes donde dichas direcciones ya tienen significado (como signet). (# 20861)
- El RPC getpeerinfo devuelve dos nuevos campos booleanos, bip152_hb_to y bip152_hb_from, que indican respectivamente si seleccionamos a un par para estar en el modo de ancho de banda alto de bloques compactos o si un par nos seleccionó como par de bloques compactos de ancho de banda alto. Los pares de alto ancho de banda envían nuevos anuncios de bloque a través de un mensaje cmpctblock en lugar de los anuncios habituales de inv / encabezados. Consulte BIP 152 para obtener más detalles. (# 19776)
- getpeerinfo ya no devuelve los siguientes campos: addnode, banscore y whitelisted, que anteriormente estaban en desuso en 0.21. En lugar de addnode, el campo connection_type devuelve manual. En lugar de estar en la lista blanca, el campo de permisos indica si el par tiene privilegios especiales. El campo de banscore simplemente se ha eliminado. (# 20755)
- Los siguientes RPC: gettxout, getrawtransaction, decoderawtransaction, decodescript, gettransaction y puntos finales REST: / rest / tx, / rest / getutxos, / rest / block desaprobaron los siguientes campos (que ya no se devuelven en las respuestas de forma predeterminada): direcciones , reqSigs. La marca -deprecatedrpc = direcciones debe pasarse para que estos campos se incluyan en la respuesta RPC. Esta marca / opción estará disponible solo para esta versión principal, después de la cual la obsolescencia se eliminará por completo. Tenga en cuenta que estos campos son atributos del objeto scriptPubKey devuelto en la respuesta RPC. Sin embargo, en la respuesta de decodescript, estos campos son atributos de nivel superior y se incluyen nuevamente como atributos del objeto scriptPubKey. (# 20286)
- Al crear una transacción bitcoin con codificación hexadecimal utilizando la utilidad bitcoin-tx con la opción -json establecida, los siguientes campos: direcciones, reqSigs ya no se devuelven en la salida tx de la respuesta. (# 20286)
- El RPC con lista prohibida ahora devuelve dos nuevos campos numéricos: ban_duration y time_remaining. Respectivamente, estos nuevos campos indican la duración de una prohibición y el tiempo que queda hasta que expira, ambos en segundos. Además, el campo ban_created se reposiciona para que aparezca antes de banned_until. (# 21602)
- El setban RPC puede volver a prohibir las direcciones de cebolla. Esto corrige una regresión introducida en la versión 0.21.0. (# 20852)
- El RPC getnodeaddresses ahora devuelve un campo de "red" que indica el tipo de red (ipv4, ipv6, cebolla o i2p) para cada dirección. (# 21594)
- getnodeaddresses ahora también acepta un argumento de "red" (ipv4, ipv6, onion o i2p) para devolver solo direcciones de la red especificada.
- El testmempoolaccept RPC ahora acepta múltiples transacciones (aún experimental en este momento, la API puede ser inestable). Está destinado a probar paquetes de transacciones con relaciones de dependencia; no se recomienda para la validación de transacciones independientes por lotes. Además de la política de mempool, se aplican políticas de paquete: la lista no puede contener más de 25 transacciones o tener un tamaño total que exceda los 101K bytes virtuales, y no puede entrar en conflicto con (gastar las mismas entradas que) entre sí o con el mempool, incluso si fuera un BIP125 válido reemplazado por tarifa. Existen algunas limitaciones conocidas para la precisión de la aceptación de prueba: es posible que testmempoolaccept devuelva "permitido" = Verdadero para un grupo de transacciones, pero "cadena-mempool demasiado larga" si realmente se envían. (# 20833)
- addmultisigaddress y createmultisig ahora admiten hasta 20 claves para direcciones Segwit. (# 20867