Madurez de la coinbase · toda la cadena
La regla de la cadena ya expiró, pero las billeteras siguen reteniendo 6,480 bloques las monedas recién minadas.
El bloque 979,920 ya pasó, así que la regla temporal de la cadena terminó. Pero la política de propagación que vino con ella no depende de esa ventana y sigue exigiendo 6,480 confirmaciones antes de poder gastar una recompensa. Eso es comportamiento del cliente, no una regla de este pool, y es un tema abierto río arriba.
Lo que hizo PyBLØCK. Nuestro nodo ya corre v29.4.3.knots20260508, desde el 2026-10-27. Dijimos que actualizaríamos en RC2 y lo hicimos.
Qué te cambia, en claro. Ya aplica, y no esperó al bloque 973,440: nuestro nodo dejó de propagar el gasto de cualquier recompensa con menos de 6,480 confirmaciones. Eso es sobre lo que nuestro nodo transmite, no sobre si la moneda es tuya: una recompensa minada antes del bloque 973,440 madura a las 100 confirmaciones de siempre y tu saldo la muestra como gastable, porque lo es. Tus monedas no están congeladas y no las tenemos nosotros. Son válidas, ya son tuyas en la cadena, y cualquier otra billetera o nodo las sigue transmitiendo: la mayor parte de la red no actualizó. Lo que cambia es nuestro nodo, no tu propiedad.
Por qué aquí esto es más llevadero que en otros lados. Tu recompensa se escribe directo en la coinbase del bloque, a tu dirección: ya es tuya en la cadena, y aquí no retenemos nada: no la podemos gastar y no cobramos primero. Un pool custodial, en cambio, se queda con toda la coinbase y te paga después desde su propio saldo; mientras esa coinbase está bloqueada, tiene que financiar cada pago con reservas. Nosotros no adelantamos nada, así que aquí no hay nada que se pueda acabar.
Por qué la fecha llega antes que los 45 días: la regla cuenta bloques, no tiempo. 6,480 bloques son unos 45 días al ritmo habitual de 10 minutos, pero esta cadena está yendo más rápido (~45 días al ritmo reciente), así que el desbloqueo cae antes. La altura del bloque es lo fijo; toda fecha de aquí es una estimación que se mueve con la cadena.
Hasta ahora una recompensa de bloque se podía mover después de 100 bloques, unas 16 horas. Esto es una regla del cliente Bitcoin BLAKE2b, no de este pool: aplica a toda coinbase de la cadena, la haya minado quien la haya minado, y no hay nada que podamos cambiar de nuestro lado. Lo que se te debe no cambia; solo cuánto tiempo queda quieto antes de moverse. Los pagos se siguen escribiendo directo en la coinbase del propio bloque, a tu dirección, sin que nosotros retengamos nada. Eso también significa que tu parte queda bloqueada igual que la nuestra: no cobramos primero.
Por qué esto empieza antes del bloque 973,440. La parte de billetera y de propagación de esta versión aplica la espera larga a toda recompensa, a propósito e independientemente de la regla de la cadena: la propuesta lo dice con todas las letras. Corrimos la versión en un nodo aislado nuestro para estar seguros: el corte queda exactamente en 6,480 confirmaciones sin importar cuándo se minó la recompensa, y ya aplica con la activación todavía en el futuro. O sea que no es algo que se arregle antes del día de la bandera: es lo que hace el cliente, y es comportamiento del cliente antes que una regla de este pool.
El mismo anuncio dice que quien mina sin correr su propio nodo y gateway no está minando de verdad y podría no cobrar nada en el futuro. Eso es una intención declarada en el cambio mismo: no es código, y hoy no existe ningún mecanismo para eso. No vamos a fingir que sabemos cómo se administraría. Te lo contamos porque mereces el cuadro completo. Si alguna vez se vuelve una regla real, lo vas a leer aquí primero.
Lo que te recomendamos, por lo que valga. Si igual vas a estar esperando una madurez más larga, es buen momento para correr tu propio nodo y gateway DATUM. No porque te libre de la espera: no lo hace, y quien te diga lo contrario se equivoca — la regla aplica a toda coinbase de la cadena, la haya armado quien la haya armado. Házlo porque simplemente te conviene. Tu nodo elige las transacciones, así que nunca vemos tu selección y no podríamos censurar ninguna aunque quisiéramos. Y te quedas con más, porque no hay corte de node-runner cuando el node-runner eres tú: 99% en CAROUSEL, contra 22% por nuestro stratum (CHIRP ya paga 100% por cualquier camino: corre 100% sobre DATUM). La espera es la misma de cualquier forma; lo que cambia es cuánto del bloque es tuyo cuando se libera, y quién decidió qué entró en él. Cómo montarlo →
Correr tu propio nodo y gateway es lo que WAVICLES ya hace, y ahora también está disponible para CAROUSEL y CHIRP: mira PATUM, el instalador de un clic.
Tu nodo arma el bloque. El pool sólo fija el reparto: todos los que tienen trabajo en la ventana, según su trabajo · comisión 0% con tu propio nodo, 0% a través del stratum de PyBLØCK · pagado en la coinbase. El pool no retiene ni un sat.
| Minero | Hashrate · 10 min | Parte de la ventana | Recibiría | Última share |
|---|---|---|---|---|
| Todavía no hay trabajo en la ventana — conecta un nodo y el reparto aparece acá. | ||||
| Bloque | Cuándo | Construido por | Pagado a mineros | Salida del pool | Mineros pagados |
|---|---|---|---|---|---|
| Todavía no hay bloques de WAVICLES — el primero aparece acá y en BLOQUES. | |||||
Desde el bloque 977,350, el trabajo que entra por los puertos SV1 públicos de PyBLØCK cede el 77 % de su parte a la pool. Minando por tu propio gateway DATUM (PATUM) no se paga.
| Gateway | Software | Shares | Trabajo | Conectado | Última share |
|---|---|---|---|---|---|
| No hay gateways conectados ahora mismo. | |||||
CONVOYMining/datum_gateway del 2026-09-02 en adelante (commit b9ea7dc+). Las versiones anteriores fallan después del handshake con "Invalid data structure in configuration" — pull, rebuild, reconectar; la configuración no cambia.| Síntoma en el log del gateway | Causa | Solución |
|---|---|---|
Invalid data structure in configuration → Waiting on DATUM server… 0 | versión de CONVOY anterior al 2026-09-02 | actualizar a master (≥ b9ea7dc), recompilar, reconectar |
decryption failed | pool_pubkey incorrecta o truncada | copia la clave completa de 128 hex (haz clic en el bloque de configuración), reinicia el gateway |
| Handshake OK pero 0 shares en el pool | los mineros apuntan al pool en vez de a tu gateway | los mineros van a IP-del-gateway:puerto-stratum, nunca a :28915 |
| los mineros trabajan contra tu gateway y siguen en 0 shares después de 30+ min | el piso de shares por defecto de DATUM, vardiff_min = 16384, es escala de ASIC SHA-256; una GPU o CPU en BLAKE2b no lo alcanza nunca | "stratum": {"vardiff_min": 1} (una potencia de dos; 1 es lo que corre el propio gateway GPU de PyBLØCK), reinicia el gateway |
| coinbase "sólo pool" en un bloque | la plantilla no dejó espacio para las salidas de pago | blockreservedweight=100000 en el bitcoin.conf de tu nodo |
| se conecta y se cae cada pocos minutos, con una clave de gateway nueva cada vez | el gateway se reinicia justo después del handshake: su nodo no devuelve trabajo BLAKE2b (RPC mal configurado, sin sincronizar, o le falta la regla blake2b) | lee el log del gateway después de "DATUM Pool MOTD"; en tu nodo ejecuta bitcoin-cli getblocktemplate '{"rules":["segwit","blake2b"]}' |
| tu identidad muestra trabajo pero el pago es 0 / "not payable" | el usuario del minero en tu gateway es un nombre de worker, no una dirección | los mineros entran con una dirección Bitcoin-BLAKE2b (bc1q… / 1…); un worker después de un punto está bien: bc1q….rig1 |
| pocas identidades pagadas en un bloque | un presupuesto de coinbase demasiado chico para la lista de pagos | corregido del lado del pool el 2026-09-14: ahora todos los gateways reciben la clase de 16 KB (~400 pagos), CONVOY de fábrica incluido. Nada que cambiar de tu lado. |
blockreservedweight=100000 en bitcoin.conf. El valor por defecto de Knots deja lugar para ~55 salidas de coinbase. El firmware de tus mineros decide cuántos pagos puede llevar una coinbase: el firmware moderno (Whatsminer, S21, ePIC) acepta coinbases grandes y paga toda la ventana; una coinbase de fábrica de ~730 bytes admite ~15, y entonces el reparto se prorratea entre los que entran — el pool nunca se lo queda. Con una ventana grande tu coinbase puede llevar cientos de salidas (cada pago bech32 = 124 WU); reserva peso para que nunca desplace transacciones. Las plantillas Bitcoin-BLAKE2b pesan hoy ~110 kWU, así que sobra lugar.mining.pool_address decide a quién se le paga si alguna vez minas sin el pool, y el gateway ni siquiera arranca sin una válida. En cada minero, como usuario de Stratum, decide a quién se le acredita en la ventana. Pon las dos. Después mira la tabla de Node runners de arriba: si las shares suben, funcionó.mining.pool_address. Es obligatoria. Con una inválida el gateway imprime Could not generate output script for pool addr y se cierra en menos de un segundo, así que si tu gateway está corriendo, este campo ya está bien. También es la dirección que cobra el 100% de cualquier bloque que encuentres mientras el pool esté inalcanzable, que es el caso de más abajo.x. Un nombre de worker después de un punto está bien: bc1q….rig1. Con la configuración que publicamos arriba (pool_pass_full_users: true) ese usuario es lo que acreditamos, así que cada minero de tu gateway cobra en la dirección con la que entra.pool_pass_full_users en false y todos los mineros de tu gateway se acreditan a mining.pool_address, escriban lo que escriban. Es lo correcto si los equipos son todos tuyos, y lo incorrecto si estás alojando a otro.bad-username, y esas shares no ganan nada. O sea que un error de tipeo te cuesta trabajo real, en silencio, hasta que mires. Vuelve a comprobar siempre después de cambiar un usuario: tu fila en la tabla de Node runners tiene que mostrar las shares subiendo y los rechazos planos.:28915, que es por donde tu gateway habla con nosotros y nunca a donde van los mineros; o son GPU o CPU y no alcanzan nunca el piso de shares por defecto, que está pensado para ASICs SHA-256. Para este último caso pon "stratum": {"vardiff_min": 1} y reinicia. La pestaña Clients de tu propio gateway es la forma más rápida de distinguir el primer caso de los demás: si está vacía, el problema está de tu lado del gateway, no entre nosotros.pooled_mining_only. Dejado en true, como lo publicamos, tu gateway desconecta a tus mineros antes que minar sin pool. En false, tu nodo sigue armando bloques por su cuenta y cualquier bloque que encuentre paga el 100% a mining.pool_address. Ninguna de las dos está mal. La primera evita que tu hashrate vaya a un lugar que no elegiste; la segunda lo mantiene ganando. Es también la segunda razón por la que ese campo tiene que ser una dirección que de verdad controles.7491a509 o posterior. Las anteriores cuentan mal los bytes de la coinbase BLAKE2b y truncan la lista de pagos, así que un bloque encontrado con una de ellas dejaría sin cobrar a casi toda la ventana. Las rechazamos en el handshake con un mensaje que lo dice, en vez de dejar que te enteres con un bloque. Ojo: un simple git pull de master no alcanza si master todavía arrastra el bug. Los forks de la línea OCEAN y los paquetes de StartOS también sirven.wavicles_api.php?mode=snapshot&hash=… y no puede cambiar una vez que el bloque existe.max_payees) == los pagados del snapshot, cada uno pagado on-chain.python3 tools/verify_wavicles_block.py --height H \ --conf bitcoin.conf --url https://b.pyblock.xyz/wavicles_api.php