De niño, en casa teníamos una radio antigua. El mando de volumen era también el interruptor de encendido. Si querías ponerla más bajita, lo girabas hasta el final y se apagaba. Un solo mando controlaba dos cosas a la vez, así que no podías ajustar una sin que la otra cambiara.
El TBV @BabylonLabs_io me recuerda a esa radio.
Los retos, salidas y transacciones de rescate del TBV requieren bloqueos relativos de tiempo: después de la confirmación de la transacción anterior, se espera a que transcurran N bloques para ejecutar. En Bitcoin, los campos para lograrlo se llaman nSequence (definido en BIP-68). Pero el mismo campo también cumple otra función: la señal RBF de BIP-125. Mientras nSequence sea menor que 0xFFFFFFFE, el nodo interpreta que la transacción está opt-in a Replace-by-Fee.
Un solo campo, dos significados. Al habilitar CSV, se activa automáticamente el opt-in RBF. Evitarlo no es posible: el opt-out RBF exige que nSequence sea 0xFFFFFFFF, y ese valor hace que el bloqueo relativo deje de funcionar. En la misma “rueda” se han puesto BIP-68 y BIP-125, definiendo dos posiciones que no pueden coexistir.
¿Qué implica esto en TBV? El opt-in RBF permite que el mempool acepte versiones sustitutas. Para transacciones prefirmadas, el re-firmado por terceros es imposible: no tienen tus claves privadas. Pero en un monedero multisig, si los firmantes mayoritarios conspiraran, podrían transmitir una versión alternativa con una comisión más alta, expulsando la transacción original del mempool. Las firmas siguen siendo válidas, pero esa transacción queda para siempre en un estado “reemplazable”.
Bitcoin Optech, al interpretar BIP-68, dijo esto: nSequence es un campo cargado en capas a lo largo de la historia, y cualquier protocolo que dependa de él debe pagar por los conflictos semánticos.
Entonces, ¿se puede sortear con un bloqueo absoluto usando nLockTime? Sí, pero solo puede bloquear hasta una altura concreta; no puede expresar “después de que ocurra un evento, espera N bloques”. La ventana de reto en TBV es, en esencia, relativa: el bloqueo absoluto no sirve.
Así que la pregunta se vuelve muy concreta: en TBV, la salida prefirmada y la transacción de reto, ¿con qué valor exacto se configura nSequence? Si es opt-in RBF, ¿quién está vigilando el mempool para detener un reemplazo colusorio?
$BABY #baby
El TBV @BabylonLabs_io me recuerda a esa radio.
Los retos, salidas y transacciones de rescate del TBV requieren bloqueos relativos de tiempo: después de la confirmación de la transacción anterior, se espera a que transcurran N bloques para ejecutar. En Bitcoin, los campos para lograrlo se llaman nSequence (definido en BIP-68). Pero el mismo campo también cumple otra función: la señal RBF de BIP-125. Mientras nSequence sea menor que 0xFFFFFFFE, el nodo interpreta que la transacción está opt-in a Replace-by-Fee.
Un solo campo, dos significados. Al habilitar CSV, se activa automáticamente el opt-in RBF. Evitarlo no es posible: el opt-out RBF exige que nSequence sea 0xFFFFFFFF, y ese valor hace que el bloqueo relativo deje de funcionar. En la misma “rueda” se han puesto BIP-68 y BIP-125, definiendo dos posiciones que no pueden coexistir.
¿Qué implica esto en TBV? El opt-in RBF permite que el mempool acepte versiones sustitutas. Para transacciones prefirmadas, el re-firmado por terceros es imposible: no tienen tus claves privadas. Pero en un monedero multisig, si los firmantes mayoritarios conspiraran, podrían transmitir una versión alternativa con una comisión más alta, expulsando la transacción original del mempool. Las firmas siguen siendo válidas, pero esa transacción queda para siempre en un estado “reemplazable”.
Bitcoin Optech, al interpretar BIP-68, dijo esto: nSequence es un campo cargado en capas a lo largo de la historia, y cualquier protocolo que dependa de él debe pagar por los conflictos semánticos.
Entonces, ¿se puede sortear con un bloqueo absoluto usando nLockTime? Sí, pero solo puede bloquear hasta una altura concreta; no puede expresar “después de que ocurra un evento, espera N bloques”. La ventana de reto en TBV es, en esencia, relativa: el bloqueo absoluto no sirve.
Así que la pregunta se vuelve muy concreta: en TBV, la salida prefirmada y la transacción de reto, ¿con qué valor exacto se configura nSequence? Si es opt-in RBF, ¿quién está vigilando el mempool para detener un reemplazo colusorio?
$BABY #baby