Calculadoras y modelos
con supuestos explicados.

Usa punto o coma como separador decimal; separa los miles con un espacio.

DCA, o Dollar-cost averaging, significa comprar por un importe fijo de moneda local a intervalos regulares, en lugar de buscar un único momento ideal. Reduce la necesidad de decidir cuándo comprar y puede moderar las operaciones emocionales, pero no garantiza ganancias, no evita pérdidas ni resuelve la custodia.

En cada compra modelada dividimos la cantidad por el precio histórico. La suma de esas fracciones da el total de BTC, valorado al último precio de la serie. Las aportaciones son cantidad por número de compras; la variación porcentual es (valor / aportaciones − 1) × 100. No es una rentabilidad anualizada.

Un año equivale aquí a 365 días. La primera compra usa el primer dato disponible. El modelo semanal elige el siguiente dato al menos siete días después de la compra anterior; el mensual, el primer dato de cada mes UTC, incluidos los meses parciales de los extremos. Por ello, el número puede diferir de 52 o 12 al año.

Usamos CoinGecko y, como alternativa, Yahoo Finance. Para monedas distintas del USD, el modelo de Yahoo puede combinar BTC/USD con el último cambio USD de esa moneda fechado como máximo en el momento del dato, de hasta siete días de antigüedad. Puede haber caché. La serie debe empezar y terminar a no más de siete días de los límites solicitados y no tener huecos mayores de ocho días; de lo contrario no hay resultado. Mostramos las fechas extremas reales y la fuente.

El modelo excluye spread, comisiones, impuestos y costes de custodia. Calcula fracciones matemáticas de BTC; la presentación se redondea y las compras reales en satoshis enteros pueden diferir. Es un cálculo histórico, no una previsión ni una instrucción de compra.

DCA reparte las compras en el tiempo, pero no convierte bitcoin en una inversión sin riesgo ni garantiza rentabilidad.

Usa punto o coma como separador decimal; separa los miles con un espacio.

Introduce un número entero de entradas de 1–500 y tarifas de 0–1 000 000 sat/vB. Los campos vacíos o inválidos ocultan el resultado.

Diferencia neta = comisión sin consolidar − suma de ambas comisiones con consolidación. Positivo indica ahorro modelado; negativo, mayor coste. Con una sola entrada no se combinan entradas.

Ambos escenarios suponen gastar todos los UTXO seleccionados juntos en una transacción posterior. La consolidación los une hoy en una salida. Cada transacción modelada tiene exactamente una salida del mismo tipo que las entradas; no se añade una salida de cambio.

El tamaño virtual es el peso de toda la transacción dividido por 4, redondeado hacia arriba. Incluye contadores CompactSize y witness marker/flag. Cada comisión es el tamaño en vB por la tarifa correspondiente, redondeado hacia arriba a un satoshi entero.

Suponemos claves públicas comprimidas y firmas ECDSA de 72 bytes incluido sighash. P2SH solo significa P2SH-P2WPKH aquí. Taproot usa key path, firma de 64 bytes con sighash predeterminado y sin annex; el modelo excluye script path y multisig.

Las tarifas las introduces tú; no son estimaciones en vivo ni garantías de confirmación. Cero y el máximo son límites del modelo, no reglas de red. Se desconocen los valores UTXO: no se comprueban fondos, dust ni aceptación del monedero. Las firmas y la construcción reales pueden cambiar el tamaño.

Combinar entradas puede vincular su propiedad ante un observador y reducir la privacidad. Una diferencia positiva de comisiones no basta para recomendar la consolidación.

El cálculo se ejecuta en el navegador sin solicitar datos de red. La herramienta no crea ni transmite transacciones y no necesita direcciones ni claves.

Usa punto o coma como separador decimal; separa los miles con un espacio.

Introduce una altura entera de 0–6 930 000. Un campo vacío o inválido oculta el resultado.

Cargando…

Fuente de la altura cargada: —

Hora de preparación de la respuesta de red (UTC): —

Última respuesta (UTC): —

La oferta de Bitcoin es limitada porque un bloque válido solo puede crear unidades nuevas conforme a un calendario decreciente de subsidios de bloque. Cada nodo que valida por completo comprueba esta regla por sí mismo. Los conocidos 21 millones son el resultado redondeado de ese calendario, no una cifra almacenada en la base de datos de una empresa.

Un minero puede incluir una transacción coinbase en un bloque válido. La suma de sus salidas no puede superar el subsidio de emisión permitido a esa altura más las comisiones de transacción. Las comisiones transfieren bitcoin existente; solo el subsidio crea unidades nuevas. Un bloque con una recompensa coinbase excesiva es inválido.

En la red principal el subsidio comienza en 50 BTC y se reduce a la mitad cada 210 000 bloques, truncado a satoshi enteros. El último bloque con subsidio positivo es 6 929 999; desde 6 930 000 es cero. Lo pendiente se calcula sobre el total teórico exacto, no sobre los 21 millones redondeados.

La suma incluye cada subsidio permitido desde la altura 0 hasta el bloque elegido. No es oferta circulante ni gastable: incluye los 50 BTC no gastables del bloque génesis y no resta subsidios no reclamados ni monedas perdidas. Las comisiones no son nueva emisión.

Solo estimamos una fecha para la altura cargada: hora de preparación de la respuesta más bloques restantes por 10 minutos. No es la hora de minado ni un plazo fijo. Los datos de mempool.space o del respaldo Blockchain.com pueden estar en caché; los intervalos reales varían.

Usa punto o coma como separador decimal; separa los miles con un espacio.

Introduce cantidades enteras: entradas 1–500, salidas 1–50; tarifa 0–1 000 000 sat/vB. Los campos vacíos o inválidos ocultan resultados.

Tipo de referencia por 1 BTC: Cargando…

Fuente no indicada · Última respuesta: —

Todas las entradas y salidas usan el tipo elegido. Incluye destinatarios y cambio en el número de salidas; la herramienta no añade salidas automáticamente. Los tipos mixtos y otros scripts quedan fuera del modelo.

El tamaño virtual es el peso de toda la transacción dividido por 4, redondeado hacia arriba. Incluye contadores CompactSize y witness marker/flag. Cada comisión es el tamaño en vB por la tarifa correspondiente, redondeado hacia arriba a un satoshi entero.

Suponemos claves públicas comprimidas y firmas ECDSA de 72 bytes incluido sighash. P2SH solo significa P2SH-P2WPKH aquí. Taproot usa key path, firma de 64 bytes con sighash predeterminado y sin annex; el modelo excluye script path y multisig.

Las tarifas las introduces tú; no son estimaciones en vivo ni garantías de confirmación. Cero y el máximo son límites del modelo, no reglas de red. Se desconocen los valores UTXO: no se comprueban fondos, dust ni aceptación del monedero. Las firmas y la construcción reales pueden cambiar el tamaño.

Valor de la comisión en moneda = comisión en satoshi / 100 000 000 × precio de referencia por BTC. El precio de mercado no cambia la tarifa sat/vB introducida ni la comisión en satoshi.

La conversión monetaria es orientativa: el tipo puede estar en caché y no incluye spread, comisiones ni precio de ejecución real. Mostramos los decimales de cada moneda; ese redondeo no sustituye una liquidación precisa. Usa el botón para recargar el tipo. La hora indica la recepción de la respuesta, no la medición del precio.

Usa punto o coma como separador decimal; separa los miles con un espacio.

Introduce números finitos no negativos; comisión del pool 0–100 %. El hashrate del equipo no puede superar el de red cargado. Los valores inválidos ocultan el resultado; electricidad en blanco no significa coste cero.

El precio eléctrico inicial es solo un dato del modelo. Se conserva en la moneda de su última edición manual y se convierte a otras con tipos de referencia disponibles. Sin tipos, el campo queda vacío hasta introducir un precio. No es una oferta del proveedor.

Cargando…

Hashrate estimado de la red: —

Altura de bloque cargada: —

Subsidio por bloque utilizado: —

Tipo de referencia por 1 BTC: — · Fuente no indicada

Última respuesta: —

1 TH/s = 10¹² H/s. La proporción del hashrate del equipo se multiplica por 144 bloques diarios, el subsidio cargado y (1 − comisión del pool / 100). Energía = W / 1 000 × 24 horas. Diferencia = valor de BTC esperado − electricidad; 30 días son treinta veces el mismo día.

Suponemos operación continua, 10 minutos por bloque de media y datos constantes. Excluimos ingresos por comisiones de transacción, equipos, depreciación, refrigeración adicional, impuestos y paradas. Los pagos y su variación dependen del pool; una expectativa matemática no promete pagos ni es beneficio neto completo. Se redondea la visualización y puede haber fracciones de satoshi.

El hashrate de red se infiere de bloques, no de medir todos los equipos. Puede venir de mempool.space o Blockchain.com con ventanas distintas; la fuente de altura se muestra aparte. Datos y precios pueden estar en caché. La hora de respuesta no es la medición de cada dato.

La conversión monetaria es orientativa: el tipo puede estar en caché y no incluye spread, comisiones ni precio de ejecución real. Mostramos los decimales de cada moneda; ese redondeo no sustituye una liquidación precisa. Usa el botón para recargar el tipo. La hora indica la recepción de la respuesta, no la medición del precio.

El minero busca un hash de cabecera que no supere el objetivo. Una prueba de trabajo válida no basta si el resto del bloque incumple las reglas. El creador de la plantilla selecciona las transacciones. En un pool suele hacerlo el operador; el propietario del equipo de cómputo puede no controlar la selección. La minería consume electricidad y equipos. La recompensa incluye emisión nueva y comisiones; los ingresos no son beneficios y los pagos del pool dependen de sus condiciones.

Controles: n de 2 a 7, m de 1 a n y L de 0 a n. Al reducir n, m y L se reducen a n si es necesario. Son límites del simulador, no un límite general de Bitcoin; m = 1 muestra un umbral de una firma.

Claves disponibles A = n − L. Se alcanza el umbral si A ≥ m; el margen adicional es max(0, A − m) y el déficit max(0, m − A). Se presuponen claves distintas y titulares disponibles dispuestos y capaces de firmar. Otra copia de seguridad de la misma clave no añade una firma independiente.

Ejemplo 2 de 3: sin pérdidas queda un margen de 1 clave; con 1 clave no disponible se alcanza el umbral, pero el margen es 0; con 2 claves no disponibles falta 1 firma. La indisponibilidad puede ser temporal; no implica automáticamente una pérdida permanente de fondos.

La recuperación también requiere la configuración correcta de la cartera: umbral, claves públicas de todos los participantes, su orden o regla de ordenación, tipo de script y posibles rutas de derivación. Un Output Descriptor puede registrar estos datos. Tener suficientes claves privadas puede no bastar para restaurar las direcciones; la configuración pública no sustituye las firmas.

El modelo excluye claves robadas, puntos de fallo compartidos, otras condiciones del script y compatibilidad entre carteras. Disponer de firmas no implica protección contra el robo. No se introducen claves reales; el simulador no crea carteras, no firma ni transmite transacciones y no necesita datos en vivo.