pr-35793
Implement BIP 54 (Consensus Cleanup) without mainnet activation
- Pregunta 1¿Qué problema resuelve limitar los sigops legacy por transacción, si ya existe MAX_BLOCK_SIGOPS_COST? ¿Sobre qué scripts cuenta sigops CheckSigopsBIP54, y cuáles de ellos no entran en el conteo por bloque?
- Pregunta 2En el commit “chainparams: add versionbits deployment for BIP 54” se añade el despliegue
versionbits. ¿Por qué está NEVER_ACTIVE en todas las redes menos regtest? ¿Y por quégbt_optional_rulees false aquí y true en testdummy? - Pregunta 3En el commit “moveonly: move CheckSigopsBIP54 from policy to consensus”,
CheckSigopsBIP54sumascriptSig.GetSigOpCount(true)yscriptPubKey.GetSigOpCount(scriptSig). En un input P2SH elredeemScriptva dentro delscriptSig: ¿se cuenta dos veces? ¿Cuántos sigops suma entonces un input P2SH-P2WPKH? - Pregunta 4En el commit “validation: make BIP54 sigops check consensus-critical”,
CheckTxInputsrecibe unbool enforce_bip54. De sus tres llamantes fuera de los tests, dos siempre le pasan true y el tercero le pasa un valor calculado. ¿Cuál es cuál y por qué? Ese mismo commit cambia el resultado de validación deTX_INPUTS_NOT_STANDARDaTX_CONSENSUS: ¿cambia algo más que el mensaje de error que devuelve la RPC? - Pregunta 5En el commit “validation: prevent timewarp attacks with a 2h grace period”, el límite de timewarp se elige con
if (enforce_BIP94) ... else if (DeploymentActiveAfter(...)). ¿Por qué unelse ify no aplicar los dos casos? ¿Qué documenta elstatic_assert? - Pregunta 6En el commit “validation: prevent negative difficulty adjustment intervals” se compara el bloque en
nHeight % dai == dai - 1con el denHeight - dai + 1. ¿Son esos los mismos dos bloques que usaGetNextWorkRequiredpara medir la duración del periodo? ¿Por qué no basta con el arreglo del timewarp? - Pregunta 7El commit “miner: update a timewarp comment to refer specifically to BIP 54” dice que aplicar BIP 94 en todas las redes hace más segura la activación de BIP 54, pero
GetMinimumTime()solo contempla el primer bloque del periodo de retarget, no el último. ¿Puede entoncesgetblocktemplatefallar en un nodo honesto? ¿Y qué pasaría contest_block_validitydesactivado? - Pregunta 8En el commit “validation: enforce coinbase timelocked to block height” se exige que el coinbase tenga
nLockTime == nHeight - 1(además de unnSequenceno final). ¿Por qué el - 1 y por qué hacen falta las dos condiciones? ¿Qué tiene que ver esto con BIP 30, y por quéfeature_block.pytiene que reiniciar el nodo antes de sus tests de BIP 30? - Pregunta 9En el commit “validation: make 64-byte transactions invalid” se invalidan las transacciones de exactamente 64 bytes, no las de 64 o menos. ¿Por qué exactamente 64? ¿Por qué
MIN_STANDARD_TX_NONWITNESS_SIZEse queda en 65?
¿Aplica también al coinbase? - Pregunta 10La regla de sigops se invoca desde
ConnectBlock, mientras que las otras cuatro reglas viven enContextualCheckBlockHeaderyContextualCheckBlock, con unNOTEde queConnectBlockno las invoca y de que-reindex-chainstatese las salta. ¿Por qué esa asimetría? ¿Qué escenario de actualización preocupa a ese comentario?