Qué pasó
El 17 de agosto de 2026 se integró el
pull request #2253 en el repositorio de
propuestas de Bitcoin, corrigiendo el validador de referencia de
BIP-375, la especificación
en borrador para enviar
silent payments mediante
PSBTs. El validador venía
tratando cualquier script de salida cuyo primer byte cayera entre OP_2 y OP_16 como una
salida de SegWit versión 2 o posterior. La mayoría de los scripts que empiezan por esos bytes
no son nada de eso.
Qué cambia
Los silent payments permiten a quien recibe publicar una única dirección estática que nunca aparece en la cadena: quien envía deriva una salida nueva a partir de ella usando un secreto compartido calculado con los propios inputs de la transacción. Como el destinatario tiene que encontrar esos pagos escaneando, BIP-352 restringe qué transacciones entran en el alcance. Una de las condiciones es que la transacción "does not spend an output with SegWit version > 1", y la especificación es explícita sobre el motivo: saltarse los scripts de salida desconocidos "allows us to have a clean upgrade path for silent payments by avoiding the need to scan the same transaction multiple times with different rule sets."
El coste de equivocarse aquí lo paga quien recibe, que no tiene voto en el asunto. Si quien envía incluye un input que la regla excluye, produce un pago que la wallet del destinatario, o el servidor de índice del que depende, sencillamente no va a mirar nunca. BIP-375 lleva la restricción al flujo de firma para que falle temprano: "If any input is spending an output with script using Segwit version > 1, the Signer must fail."
Reconocer ese tipo de input es donde el validador se equivocaba. Preguntaba si el primer byte
del script era OP_2 o superior. Un
witness program no es un
byte, es una forma: un opcode de versión seguido de un único push directo de entre 2 y 40
bytes, y nada más detrás. El
reemplazo
comprueba la forma, exigiendo que la longitud total esté entre 4 y 42 bytes y que el segundo
byte sea igual a la longitud de lo que queda. Un OP_2 suelto es un script común que empuja
el número dos, y el pull request agrega un vector de prueba que dice justamente eso.
Qué no cambia
Esto es un validador de referencia de una especificación en borrador, no una regla de consenso ni una wallet publicada. Nada en la red se comportó distinto el 17 de agosto, y si alguna implementación en producción copió el mismo atajo es una pregunta que el pull request no responde.
La restricción en sí se mantiene, y es la parte con un coste real: unas monedas guardadas en una versión futura de witness no se pueden gastar hacia un silent payment con las reglas actuales, por diseño, y esa limitación la absorbe quien envía para que el escaneo de quien recibe siga siendo barato.
También conviene nombrar en qué dirección fallaba el error. La comprobación antigua rechazaba cosas que debía aceptar, no al revés. Un validador que rechaza por error un PSBT válido es un fallo; uno que acepta por error uno inválido es un fallo distinto y peor.
Contexto
Todo el software de Bitcoin tiene que decidir qué hacer con un script que no reconoce, porque el método mismo de un soft fork consiste en dar significado nuevo a patrones que el software antiguo trata como no restringidos. Escribir esa decisión como una comprobación de rango sobre el primer byte es el atajo que envejece mal, y lo hace justo cuando llega la actualización que anticipaba. El repositorio de propuestas lleva quince días movidos: es el mismo tramo en el que BIP-85 sumó una aplicación para Nostr y BIP-89 avanzó a Deployed.