Pregunta 4

Pregunta 4 -> En el commit “validation: make BIP54 sigops check consensus-critical”, CheckTxInputs recibe un bool 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 de TX_INPUTS_NOT_STANDARD a TX_CONSENSUS: ¿cambia algo más que el mensaje de error que devuelve la RPC?

Puede ser connect block? primero comprubea si esta marcado como activado o no y pasa ese valor a la función check inputs

Nos puedes decir el motivo de porque conect block lo hace asi? @arejula27

Es la función que añade el bloque a la blockchain local, así que entiendo que primero comprueba si el nodo tiene activado bip54 y en ese caso ejecuta unas reglas u otras

y porque las otras funciones lo tienen a true fijo?

Ahí me pillas 😅

jeje

devuelve bad-txns-legacy-sigops?

no hemos llegado ahi aun

De hecho solo he visto fuera de los test otra más, así que una se me escapó por qué no la encuentro

Leí mal lo ultimo, tal vez porque en regtest si estará activo?

Puede ser la memoool la otra? Igual para aceptar todas en bloques pero no por política

nope

casi

txmempool.cpp y validation.cpp

Pero eso no es un poco hacer trampas?

no esta activado a medias

Aaaa

Okay este es el momento de activación

hay mas preguntas aqui?

Por mi pasamos a la siguiente 😀

ah bueno falta la parte del mensaje

Sí, un par de cosas no?
La tx ya no se puede minar: antes el test la metía con generateblock y pasaba, ahora el bloque entero es inválido. Y en txdownloadman_impl.cpp había una rama especial para TX_INPUTS_NOT_STANDARD que metía también el txid en el reject filter (no solo el wtxid). Con TX_CONSENSUS ya no entra ahí, así que se pierde esa optimización de relay. Ojo, puedo estar mal yo jaja

De nuevo, puedo estar mal yo jeje

noooo, confia en ti un poco 😛