No parece haber un consenso abrumador sobre el parámetro lockinontimeout (LOT) para el mecanismo de activación de Taproot BIP 8. Sé que algunos argumentarían firmemente en contra de hacer esto, pero ¿podría Bitcoin Core lanzar una versión en la que los usuarios se vean obligados a elegir entre establecer LOT en verdadero o falso antes de ejecutar el software? ¿Es esto técnicamente viable?
Matt Corallo y ZmnSCPxj respondieron esto en la lista de correo de desarrolladores de Bitcoin.
Matt Corallo declaró :
Bitcoin Core no tiene infraestructura para manejar las reglas de consenso de cambio con el mismo directorio de datos: después de ejecutarse con uasf=true durante algún tiempo, los bloques válidos se marcarán como no válidos y será necesario realizar un desarrollo adicional para habilitar el cambio a uasf=false. Este es un código complejo y crítico para hacerlo bien, y los ciclos de revisión y prueba necesarios parecen no valer la pena.
En cambio, la única forma práctica de enviar dicha opción sería tratarla como una cadena separada (de la misma manera que se tratan regtest, testnet y signet), incluido su propio directorio de datos separado y similares.
ZmnSCPxj agregó :
Sin implicar nada más, esto puede solucionarse si un usuario mantiene dos
datadirs y ejecuta dos clientes. Esto tendría un cliente "externo" que ejecuta LOT=X (donde X es lo que prefiera el usuario) y un cliente "interno" que es como máximo 0.21.0, que no impondrá ninguna regla LOT. A continuación, el cliente interno utilizaconnect=directiva para conectarse localmente al cliente externo y se conecta solo a ese cliente, usándolo como un firewall. El cliente externo se puede ejecutar podado para reducir el uso de recursos de espacio en disco (el cliente interno puede permanecer sin podar si el usuario lo necesita, por ejemplo, para la implementación de LN que necesita buscar ID de canal cortos arbitrarios). El uso del ancho de banda debe ser el mismo, ya que el cliente interno solo se conecta al cliente externo y el sistema operativo debe optimizar ese caso. Sin embargo, el uso de la CPU se duplica. (la idea general provino de gmax, solo para ser claros, aunque el uso a continuación es mío)Luego, el usuario puede seleccionar LOT=C o LOT=!C (donde C es lo que finalmente se envíe con Bitcoin Core) en el cliente externo según las preferencias del usuario.
Si Taproot no está activado por MASF y LOT=!U es lo que domina más tarde (donde U es lo que el usuario decida), el usuario puede decidir simplemente destruir el nodo externo y conectar el nodo interno directamente a la red (opcionalmente actualizando el nodo interno a LOT=!U) como una forma de "cambiar de opinión en vista de la economía". El nodo interno seguirá entonces la cadena dominante.