Rupix v0.6.9

Rupix v0.6.9 — Reproducibilidad contra un sistema declarado

Sin cambio de consenso. Mismo código de consenso que v0.6.7 (checkpoint #3 compartido con el nodo #2, confirmación externa del #2, verificar corregido). Usa esta; v0.6.7 y v0.6.8 están marcadas «no usar».

• v0.6.7: los binarios del CI no coincidían con los compilados desde el código, porque el compilador de C del runner de GitHub cambió. v0.6.8 intentó quitar C del todo y no compiló: las firmas (secp256k1) y muhash son código C. Las dos quedan documentadas tal cual en CHANGELOG.
• v0.6.9: la reproducibilidad se declara contra un sistema concreto y fijo: Linux se compila en Ubuntu 24.04 con Go 1.26.6 y su gcc 13.x, y tools/verificar-binarios.sh exige ese mismo sistema antes de comparar. Windows y Mac también en versiones fijas, nunca latest.
• Checkpoint #3 (blue 1,987,200), caducidad de la lista en DAA 3,900,000. Actualiza antes del DAA 2,600,000 (~25-oct).

Verifica tu descarga con SHA256SUMS-<os>.txt o con rupixwallet --testnet verificar.

---

Rupix v0.6.9 — Reproducibility against a declared system

No consensus change. Same consensus code as v0.6.7 (checkpoint #3 shared with node #2, external confirmation of #2, verificar fixed). Use this one; v0.6.7 and v0.6.8 are marked "do not use".

• v0.6.7: CI binaries did not match the ones built from source, because GitHub's runner changed its C compiler. v0.6.8 tried to remove C entirely and did not compile: signatures (secp256k1) and muhash are C code. Both are documented as they happened in CHANGELOG.
• v0.6.9: reproducibility is declared against a concrete, pinned system: Linux is built on Ubuntu 24.04 with Go 1.26.6 and its gcc 13.x, and tools/verificar-binarios.sh requires that same system before comparing. Windows and Mac on pinned versions too, never latest.
• Checkpoint #3 (blue 1,987,200), list expiry at DAA 3,900,000. Update before DAA 2,600,000 (~Oct 25).

Verify your download with SHA256SUMS-<os>.txt or with rupixwallet --testnet verificar.

No confíes, verifica. ER y Claude · Don't trust, verify. ER and Claude

Rupix v0.6.8

No usar: no compiló en el CI (CGO_ENABLED=0 imposible: secp256k1 y muhash son C). Usa v0.6.9. / Do not use: did not build in CI. Use v0.6.9.

Rupix v0.6.7

No usar: binarios no reproducibles (4/4 DIFIERE). Usa v0.6.8, mismo código compilado en Go puro. / Do not use: binaries not reproducible. Use v0.6.8, same code built in pure Go.

Rupix v0.6.6

Rupix v0.6.6 — Gemas vivas exactas y forge --count

Sin cambio de consenso. Mismas claves, mismos datos; solo cambia el binario.

• Gemas vivas exactas. El nodo ya no usa una caché de 30 s para contar gemas vivas: cuenta una vez y desde ahí suma y resta en cada bloque. GetGemsInfo, rupixwallet verificar y el explorador dan "creados" y "vivos" del mismo instante, así que "quemados" ya no miente durante la ventana de la caché.
• rupixwallet forge --count N. N gemas seguidas con una sola contraseña. Entre una y otra la wallet espera a ver la gema nueva; si la red rechaza algo, se detiene y dice cuántas salieron.
• rupixwallet gems empieza con tu Gold (disponible y llegando).
• Explorador: la escalera completa por nivel: creados / tope · por crear · quemados · vivos.
• tools/escalera-hasta-king.sh: forja gema a gema hasta un King en red viva (prueba de la escalera completa).

Verifica tu descarga con SHA256SUMS-<os>.txt o con rupixwallet --testnet verificar.

---

Rupix v0.6.6 — Exact live gem counts and forge --count

No consensus change. Same keys, same data; only the binary changes.

• Exact live gem counts. The node no longer uses a 30-second cache to count live gems: it counts once and from then on adds and subtracts on every block. GetGemsInfo, rupixwallet verificar and the explorer report "created" and "alive" from the same instant, so "burned" no longer lies during the cache window.
• rupixwallet forge --count N. N gems in a row with a single password. Between one and the next the wallet waits to see the new gem; if the network rejects anything it stops and tells you how many were made.
• rupixwallet gems starts with your Gold (available and arriving).
• Explorer: the full ladder per level: created / cap · left to create · burned · alive.
• tools/escalera-hasta-king.sh: forges gem by gem up to a King on the live network (full-ladder test).

Verify your download with SHA256SUMS-<os>.txt or with rupixwallet --testnet verificar.

No confíes, verifica. ER y Claude · Don't trust, verify. ER and Claude

v0.6.5 — Red cerrada por tipo de conexión, escalera por RPC y verificar

v0.6.5 — La red se cierra por tipo de conexión, la escalera por RPC y rupixwallet verificar / Connection-type whitelist, the ladder over RPC, and rupixwallet verificar

🇲🇽 Sin cambio de consenso. Mismas claves, mismos datos; solo cambia el binario.

• Lista blanca por tipo de conexión (pedido del auditor tras el fallo de los 9 bytes de v0.6.3): una conexión P2P rechaza, antes de convertir nada, cualquier mensaje que no sea del protocolo entre nodos, y una conexión RPC rechaza los que no son RPC. La superficie que un peer puede tocar baja de ~150 conversores a ~40.
• FuzzKaspadMessage: el fuzzer del tipo de wire completo. En su primera corrida encontró un mensaje heredado de kaspad que se podía recibir pero no mandar (StopNotifyingPruningPointUTXOSetOverrideResponse); arreglado.
• RPC GetGemsInfo: gemas nacidas (el conteo sellado en cada encabezado), vivas (índice de UTXOs) y topes. rupixctl --testnet GetGemsInfo. Requiere --utxoindex.
• rupixwallet --testnet verificar: una pantalla, sin contraseña: si tu binario es exactamente el de esta release (compara su sha256 con SHA256SUMS-<os>.txt, nuevo en los assets), si tu nodo responde y en qué red y bloque va, si tiene los checkpoints publicados, y el estado de la escalera. Cada línea OK / AVISO / FALLO; lo que no se pudo comprobar se dice.
• Especificación: la fila del Diamante corregida (la quema de 10 RUPIX es exacta y cubre la quema por transacción), sección 7 con cuatro cosas más que un 51 % sí puede hacer, dos pendientes cerrados con test, hueco #8 (TestMaxSompi) rastreado, versión en inglés. OPERACIONES: receta del segundo seed.

🇬🇧 No consensus change. Same keys, same data; only the binary changes.

• Whitelist by connection type (reviewer's request after v0.6.3's 9-byte bug): a P2P connection rejects, before converting anything, any message that is not part of the node-to-node protocol, and an RPC connection rejects non-RPC ones. The surface a peer can touch drops from ~150 converters to ~40.
• FuzzKaspadMessage: the fuzzer for the whole wire type. On its first run it found a kaspad-inherited message that could be received but not sent (StopNotifyingPruningPointUTXOSetOverrideResponse); fixed.
• RPC GetGemsInfo: gems born (the count sealed in every header), alive (UTXO index) and caps. rupixctl --testnet GetGemsInfo. Needs --utxoindex.
• rupixwallet --testnet verificar: one screen, no password: whether your binary is exactly the one in this release (compares its sha256 with SHA256SUMS-<os>.txt, new among the assets), whether your node answers and which network and block it is on, whether it has the published checkpoints, and the state of the ladder. Every line OK / AVISO / FALLO; whatever could not be verified is said.
• Specification: the Diamante row corrected (the 10 RUPIX burn is exact and covers the per-transaction burn), section 7 with four more things a 51 % can do, two pending items closed with tests, gap #8 (TestMaxSompi) tracked, English version. OPERACIONES: second-seed recipe.

Binarios reproducibles / reproducible binaries: sh tools/verificar-binarios.sh v0.6.5. No confíes, verifica.

v0.6.4 — Checkpoint #2 de la testnet

v0.6.4 — Checkpoint #2 de la testnet / Testnet checkpoint #2

🇲🇽 Actualiza antes del DAA 1,700,000 (~15 de octubre). El checkpoint #1 caducaba en DAA 2,000,000 y la regla de CHECKPOINTS.md es que nunca haya hueco entre checkpoints. Sin cambio de consenso más allá de la lista: misma wallet, mismas claves, mismos datos; solo cambia el binario.

• Checkpoint #2: blue score 691,200, hash ef79c0b3382489f8d4859608a86fe05411e60978e30fa9f3350272f26f8b9669 (el punto de poda del seed el 7-oct, con 269,575 bloques encima). La lista entera caduca ahora en DAA 2,600,000; el #3 se publica antes del DAA 2,300,000.
• Confirmación externa: pendiente. El día de publicarlo no había ningún nodo ajeno encendido. Si corres un nodo, mándanos tu pruningPointHash (rupixctl --testnet GetBlockDagInfo) y lo anotamos en CHECKPOINTS.md con fecha.
• Desde v0.6.3 (no publicado hasta hoy): ESPECIFICACION.md sección 7 (qué puede y qué no puede hacer un 51 %), FuzzCheckLevelRules (sexto objetivo de fuzzing, la escalera contra un oráculo independiente), tools/checkpoint-propuesto.sh, SUCESION.md, y el README dice cómo se construye Rupix.

🇬🇧 Update before DAA 1,700,000 (~October 15). Checkpoint #1 expired at DAA 2,000,000 and the CHECKPOINTS.md rule is that there is never a gap between checkpoints. No consensus change beyond the list: same wallet, same keys, same data; only the binary changes.

• Checkpoint #2: blue score 691,200, hash ef79c0b3382489f8d4859608a86fe05411e60978e30fa9f3350272f26f8b9669 (the seed's pruning point on 7-Oct, 269,575 blocks on top). The whole list now expires at DAA 2,600,000; #3 is published before DAA 2,300,000.
• External confirmation: pending. No external node was online on publication day. If you run a node, send us your pruningPointHash (rupixctl --testnet GetBlockDagInfo) and we record it in CHECKPOINTS.md, dated.
• Since v0.6.3 (unpublished until today): ESPECIFICACION.md section 7 (what a 51% attacker can and cannot do), FuzzCheckLevelRules (sixth fuzz target, the ladder against an independent oracle), tools/checkpoint-propuesto.sh, SUCESION.md, and the README says how Rupix is built.

Binarios reproducibles / reproducible binaries: sh tools/verificar-binarios.sh v0.6.4. No confíes, verifica.

Rupix v0.6.3 — release de seguridad

Rupix v0.6.3 — Release de seguridad: un paquete de 9 bytes podía apagar un nodo

Actualiza en cuanto puedas. Hasta v0.6.2, cualquier peer podía apagar tu nodo enviándole un mensaje de red malformado de 9 bytes. Lo encontró nuestro propio fuzzing la primera noche que corrió (3-oct-2026): un conversor heredado de kaspad leía un campo opcional sin comprobar que existiera, el bucle de recepción convierte cualquier mensaje antes de saber qué es, y el único atrapa-pánicos del proceso lo apaga. Sin cambio de consenso. Misma wallet, mismas claves, mismos datos: solo cambia el binario.

Seguridad

• Raíz: RpcFeeEstimate.toAppMessage comprueba sus campos; un mensaje malformado es un error limpio, no un pánico.
• Red de seguridad: si cualquier otro conversor entra en pánico por un mensaje que el fuzzing aún no encontró, se cierra esa conexión y queda en el log; el nodo sigue.
• Tests: TestMensajeDe9BytesNoTiraElNodo (los 9 bytes exactos), TestConversionDeRedNoTiraElNodo; el caso vive en testdata/fuzz/. Se avisa en privado a los mantenedores de kaspad.

Fuzzing (hueco #6 de ESPECIFICACION.md)

Cinco objetivos con go test -fuzz: topes, sello de gemas, RupixHeavyHash, rango de la matriz y mensajes de red; tools/fuzz-noche.sh los corre en serie. Primera noche: cuatro aguantaron 2 h cada uno; el quinto encontró lo de arriba.

Wallet

• Ya no existe --password en ningún comando: la contraseña se pide siempre en pantalla.
• dump-unencrypted-data (muestra la frase semilla): sin --yes; aviso, confirmación explícita y recordatorio de limpiar la pantalla, en español o inglés.
• Pistas con la red correcta (rupixctl --testnet …); textos de ayuda corregidos.

Verificación

• govulncheck ./... en cada push del CI. Herencia de Kaspa apartada a retirados/.
• Suite completa en verde (65 paquetes). Binarios reproducibles: tools/verificar-binarios.sh v0.6.3 (Go 1.26.6).

Detalle completo en CHANGELOG.md. No confíes, verifica.

Rupix v0.6.2

Rupix v0.6.2 — el tope no mata bloques; el nodo nuevo valida sus puntos de poda; wallet para principiantes

Cambio de consenso (el primero desde que hay checkpoints). Revisado por el auditor externo el 30-sep-2026: visto bueno explícito a la regla nueva del tope. Actualiza tu nodo: en la testnet ningún tope es alcanzable, así que v0.6.1 y v0.6.2 siguen de acuerdo en la práctica, pero el candado para nodos que sincronizan desde cero solo existe en v0.6.2. Misma wallet, mismas claves, mismos datos: solo cambia el binario.

Consenso

• El tope de gemas se aplica al aceptar la transacción, no al insertar el bloque (hueco #7). Antes, un bloque con una forja sobre el tope se rechazaba entero y un atacante podía "envenenar" la punta: los bloques honestos que lo mergearan caían con él. Ahora el bloque entra y la forja que excede el tope, sola, no se acepta: el Gold sigue vivo, el sello no cambia, nadie más pierde. Dos nodos independientes coinciden en cuál de dos hermanos con la última gema se la lleva. Tests: TestVenenoDeTopeNoMataAlHonesto, TestDosHermanosUltimaGema, TestForjaSobreTopeEnMempool, TestTopeDeDiamantesEnBloqueReal.
• Nodo nuevo contra peer hostil (hueco #2, lo prometido en v0.6.1). Antes de importar el punto de poda que le sirve un peer, cada checkpoint activo por debajo tiene que estar en la lista recibida o ser un ancestro conocido; si no, ErrCheckpointMismatch y no se importa. Test: TestNodoNuevoContraPeerHostil (cinco configuraciones, cuatro redes).

Wallet (para principiantes)

• forge revisa antes de mandar (gemas y Gold contra lo que pide la escalera, nivel abierto o no) y muestra un resumen que hay que confirmar; send y transfer-gem confirman.
• Español o inglés: rupixwallet language, --lang, RUPIX_LANG.
• Al crear la wallet se verifican dos palabras al azar de la frase semilla (no se puede saltar). Errores del nodo y del daemon explicados en palabras.

Verificación

• ESPECIFICACION.md: seis de siete huecos cerrados con test (queda el fuzzing). TestPOW vuelve a correr.
• Suite completa en verde (62 paquetes). Binarios reproducibles: tools/verificar-binarios.sh v0.6.2 (requiere Go 1.26.6).

Detalle completo en CHANGELOG.md. No confíes, verifica.

Rupix v0.6.1 — checkpoints para DAG, wallet usable, primer checkpoint publicado

Cuatro ramas revisadas y aprobadas por el auditor externo el 29-sep, mergeadas sin conflictos sobre 1e38bace. Sin cambios de consenso salvo la regla de checkpoints (que hasta hoy no tenia efecto: la lista estaba vacia) y el primer checkpoint de la testnet.

• Primer checkpoint publicado (testnet #4): blue score 86,400, hash 7e2ece393c7d991c86e7ba915276cd85b5fc19e8647d5d197fa26bf116604fad (DAA 86,399), caduca en DAA 2,000,000. Es el punto de poda que el seed y el nodo de JC ya compartian. TestCheckpointsPublicados obliga a que el codigo y CHECKPOINTS.md digan lo mismo.
• Emision: TestTotalSupply afirma la emision por calendario (41,999,994.96) y documenta el exceso acotado en cada frontera de halving (medido: 0.5 RUPIX en el halving 2). MaxRupia es tope por transaccion, no de emision. Ver MEMORIA.
• Guias ES/EN: la forja ya no lleva --password en la linea; la frase semilla se anota en papel al crear la wallet.
• Envio grande probado en la red publica (29-sep, wallet de la rama wallet-envios-grandes, daemon de prueba): 1,000 RUPIX en 24 transacciones / 8.6 s; 10,000 RUPIX en 232 transacciones / 46.1 s, desde una wallet de minero de ~78k pedazos. Antes 1,000 se cortaba a los 120 s.
• Arreglo del envio grande (rama wallet-envios-grandes, para v0.6.1): la seleccion de pedazos estima la comision en tiempo lineal y la exacta se calcula una sola vez al final. Medido en el seed, misma wallet de 78k pedazos: 100 RUPIX 1.6s -> 0.10s; 300: 16s -> 0.24s; 600: 65s -> 0.47s; 1,000: cortado a 120s -> 0.82s.
• Checkpoints para DAG (rama checkpoint-dag, para v0.6.1): la regla pasa a "todo bloque con blue score >= X + MergeDepth debe tener al bloque canonico H en su pasado". Un hermano tardio de H ya no rompe nada; una historia alterna sin H se rechaza. TestCheckpointDAG lo prueba, y se verifico que la prueba FALLA si la regla se apaga.
• Mempool (rama mempool-niveles, para v0.6.1): prueba automatica de que una forja de un nivel cerrado se rechaza al entrar al mempool y la misma transaccion entra pasado su halving (H-1 nivel A).
• .gitignore: los binarios quedan anclados a la raiz; la linea rupixwallet tapaba la carpeta cmd/rupixwallet y hacia fallar git add ahi.
• tools/verificar-emision.py: compara el Gold que existe en tu nodo con la regla de emision (enteros exactos) y alerta si alguna vez hay mas del permitido.
• Wallet (encontrado el 28-sep, se arregla en v0.6.1): enviar mucho Gold desde una wallet de minero se corta a los 2 minutos porque la seleccion de pedazos recalcula la comision rearmando toda la transaccion (costo al cuadrado; medido en el seed). parse imprime "KAS".
• Web: pagina matematica.html (emision, escalera, costo de mover, calculadora) en espanol e ingles.
• gofmt en todo el repo (251 archivos): solo formato. Los unicos cambios que no son espacios son imports reordenados (el renombre kaspa->rupix cambio su orden alfabetico). Compila igual.
• Explorer: la copia de la pagina en el repo estaba vieja (halving de testnet en 10,000; el real es 100,000). Sincronizada con la viva, y el tiempo al proximo halving ahora se muestra en minutos, horas o dias.
• govulncheck (27-sep): 0 vulnerabilidades que afecten al codigo; 3 en modulos requeridos que el codigo no llama.
• SECURITY.md: como reportar una vulnerabilidad en privado (pestana Security de GitHub), con tiempos de respuesta.
• Builds de release con -trimpath -buildvcs=false -buildid=: primer paso hacia builds reproducibles. Falta comprobar que dos builds den el mismo hash.
• params.go: el comentario del halving de mainnet decia "~decadas"; son ~16 meses (42M bloques a 1/seg). Hallazgo del auditor. Al revisarlo aparecio constants.BlocksPerHalving = 150, una constante sin uso cuyo comentario decia que definia la emision: eliminada. El consenso usa el valor de cada red.
• Alarma v2.1: sigue la rotacion del log del nodo (guarda inode + posicion; si el archivo viejo no aparece, ERROR). Pedido del auditor al revisar la v2.
• go.mod: minimo de Go de 1.26.6 a 1.25.0 (la minima real del arbol de dependencias). Un revisor con Go 1.25 ya puede compilar y correr la suite. Los binarios de release se siguen compilando con 1.26.6.
• Residuos del fork: el daemon de rupixwallet escribe su log en ~/.rupixwallet (antes ~/.kaspawallet); el minero dice "Rupixd is not synced" (antes "Kaspad").
• Alarma de bloques descalificados corregida. La v1 (25-sep, pedida por el auditor el 23-sep) caminaba hacia atras por la cadena seleccionada y, por construccion, nunca podia ver un bloque descalificado: dijo "OK" 134 veces sin poder sonar. La v2 lee la decision del propio nodo en su log (solo lo nuevo desde la revision anterior) y dice ERROR si el log no crece. Probada con un log falso: suena. Falta probarla provocando un bloque descalificado en devnet.
• Nodo: resolve_block_status.go registra cada bloque descalificado en nivel Warn (BLOQUE DESCALIFICADO <hash>: <motivo>); antes era Debug y no se veia. Cambio de log, no de consenso: no requiere relanzamiento.
• README (es/en): seccion "Como minar Rupix".
• changelog.txt renombrado a CHANGELOG-kaspad-upstream.txt para no confundirlo con este archivo.

Verificación: cada .zip trae su .sha256, generado por el CI de GitHub. Descarga, compara, y confirma que nadie lo alteró. Guías: GUIA-TESTNET.md / TESTNET-GUIDE.md, GUIA-FORJA.md / FORGE-GUIDE.md. No confíes, verifica.

Rupix v0.6.0 — RupixHeavyHash, rango determinista, y el fix del King

Tres cambios de consenso, integrados y probados juntos. Version INCOMPATIBLE: la testnet se relanzo (testnet #4, genesis nuevo). Los nodos existentes deben borrar su cadena y sincronizar desde cero.

1. Dominio keccak propio (RupixHeavyHash). El algoritmo de minado ya no comparte el dominio de hash de Kaspa. Separacion criptografica adicional del silicio de Kaspa.

2. Rango de la matriz con aritmetica entera (mod 2^61-1). Antes usaba float64 con un epsilon: dos CPUs (x86 vs ARM) podian redondear distinto y partir la cadena en silencio. Ahora es entero: identico en toda arquitectura. Verificado contra 5000 matrices reales.

3. Fix del conteo de gemas en el minero. Un test end-to-end nuevo (mina con el codigo real, valida con el codigo real) cazo que el minero contaba las forjas del bloque que construia, mientras el validador cuenta lo aceptado por el mergeset. Doble conteo: todo bloque con forja minado por produccion quedaba descalificado. En la testnet anterior el bug estuvo activo diez dias, enmascarado porque GHOSTDAG rescataba la transaccion via el bloque hermano. El primer King real habria sido rechazado. Corregido; el test falla si se revierte.

Suite completa en verde sobre el binario integrado. Genesis no requirio re-minado (el nonce cumple el PoW nuevo). Politica del cambio y evidencia on-chain en el repo.

We publish our bugs. Don't trust, verify.