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 24.0 See changelog
Released
P2P y cambios en la red
- Para hacer frente a una posible denegación de servicio, se ha modificado la lógica para descargar las cabeceras de los pares. Esto es especialmente importante para los nodos que se ponen en marcha por primera vez (o para los nodos que se ponen en marcha después de haber estado desconectados durante mucho tiempo).
- Siempre que se reciban cabeceras de un peer que tengan un trabajo total en la cadena que sea menor que el valor -mínimo de la cadena del nodo o que esté suficientemente por debajo del trabajo en la punta del nodo, se iniciará una fase de "presincronización", en la que el nodo descargará las cabeceras del peer y verificará el trabajo acumulado en la cadena del peer, antes de almacenar esas cabeceras permanentemente. Una vez que se verifique que el trabajo acumulado es lo suficientemente alto, las cabeceras se volverán a descargar de ese par y se validarán y almacenarán completamente.
- Esto puede dar lugar a que la sincronización inicial de las cabeceras tarde más tiempo para los nuevos nodos que se ponen en marcha por primera vez, tanto porque las cabeceras se descargarán dos veces, como porque el efecto de la desconexión de un peer durante la fase de pre-sincronización (o mientras la mejor cadena de cabeceras del nodo tiene menos de -minimumchainwork), hará que el nodo tenga que utilizar el mecanismo de pre-sincronización de cabeceras con el siguiente peer también (descargando las cabeceras dos veces, de nuevo).
- Con las conexiones I2P, se utiliza una nueva dirección transitoria para cada conexión saliente si -i2pacceptincoming=0.
RPCs actualizados
Se ha eliminado la opción de configuración -deprecatedrpc=softforks. El RPC getblockchaininfo ya no devuelve el campo softforks, que anteriormente estaba obsoleto en 23.0. (#23508) La información sobre el estado de los softforks ahora sólo está disponible a través del RPC getdeploymentinfo.
Se ha eliminado la opción de configuración deprecatedrpc=exclude_coinbase. Los RPCs de receivedby (listreceivedbyaddress, listreceivedbylabel, getreceivedbyaddress y getreceivedbylabel) ahora siempre devuelven resultados que contabilizan las monedas recibidas de las salidas de coinbase, sin una opción para cambiar ese comportamiento. La exclusión de las bases de monedas estaba previamente obsoleta en 23.0.
Se ha eliminado la opción de configuración deprecatedrpc=fees. Los campos de tarifa de nivel superior fee, modifiedfee, ancestorfees y descendantfees ya no son devueltos por los RPC getmempoolentry, getrawmempool(verbose=true), getmempoolancestors(verbose=true) y getmempooldescendants(verbose=true). Se puede acceder a los mismos campos de tarifas a través del objeto fees en el resultado. Los campos de honorarios de nivel superior estaban previamente obsoletos en 23.0.
El RPC getpeerinfo ha sido actualizado con un nuevo campo presynced_headers, que indica el progreso en la fase de presincronización mencionada en la sección "P2P y cambios en la red".
Los cambios en los RPCs relacionados con el monedero se pueden encontrar en la sección de monedero más abajo.
Nuevos RPCs
- El RPC sendall envía UTXOs específicos a uno o más destinatarios sin crear cambios. Por defecto, el RPC sendall gastará todos los UTXO de la cartera. sendall es útil para vaciar carteras o para crear un pago sin cambio a partir de UTXOs seleccionados. Cuando se crea un pago a partir de una cantidad específica por la que el destinatario incurre en la tasa de transacción, se sigue utilizando la opción subtractfeefromamount a través de los RPCs send, sendtoaddress, o sendmany.
- Se ha añadido un nuevo RPC gettxspendingprevout, que escanea el mempool para encontrar transacciones que gasten alguno de los puntos de salida dados.
- El RPC simulaterawtransaction itera sobre las entradas y salidas de las transacciones dadas, y cuenta el cambio de balance para la cartera dada. Esto puede ser útil, por ejemplo, cuando se verifica que una transacción tipo coin join no contiene entradas inesperadas que el monedero firmará involuntariamente.
APIs REST actualizadas
- Los puntos finales /headers/ y /blockfilterheaders/ se han actualizado para utilizar un parámetro de consulta en lugar del parámetro de ruta para especificar el recuento de resultados. El parámetro de recuento es ahora opcional, y por defecto es 5 para ambos puntos finales. Los antiguos puntos finales siguen siendo funcionales, y no tienen ningún cambio de comportamiento documentado.
- Para /headers, utilice GET /rest/headers/<BLOCK-HASH>.<bin|hex|json>?count=<COUNT=5> en lugar de GET /rest/headers/<COUNT>/<BLOCK-HASH>.<bin|hex|json> (obsoleto)
- Para /blockfilterheaders/, utilice GET /rest/blockfilterheaders/<FILTERTYPE>/<BLOCK-HASH>.<bin|hex|json>?count=<COUNT=5> en lugar de GET /rest/blockfilterheaders/<FILTERTYPE>/<COUNT>/<BLOCK-HASH>.<bin|hex|json> (obsoleto)