¿Debería la billetera Bitcoin Core (o cualquier billetera) evitar que los usuarios envíen fondos a una dirección Taproot antes de la activación?

TL;DR: Las billeteras DEBERÍAN permitir el envío a todas las direcciones bech32m en este punto, pero las billeteras NO DEBEN solicitar salidas P2TR antes de que se apliquen las reglas de gasto de Taproot en la red¹.

---

El diseño de segwit anticipó el largo proceso que es la adopción de características opcionales. Por ejemplo, segwit se activó en agosto de 2017, pero Blockchain.com, un proveedor de servicios de billetera que facilita una parte importante de todas las transacciones de Bitcoin, agregó soporte de envío para direcciones bech32 solo en junio de 2021.

Segwit hizo la concesión de las direcciones envueltas en P2SH compatibles con versiones posteriores para que las ventajas de los tipos de salida de segwit estén rápidamente disponibles para el ecosistema (por ejemplo, para Lightning), y sentó las bases para una implementación más fluida de los tipos de salida de segwit nativos posteriores: BIP173 especificado que todas las versiones futuras de las salidas nativas de segwit deben considerarse direcciones válidas de forma predeterminada. Por lo tanto, las implementaciones de Bech32 que cumplen con BIP173 habrían tenido soporte de envío listo para usar para todos los futuros tipos de salida de segwit nativos. ( Se adoptó el mismo enfoque para bech32m.)

Permitir el envío a direcciones aparentemente indefinidas es seguro bajo las siguientes dos premisas.

1. Especificar bajo qué condiciones un receptor acepta un pago es el trabajo y la prerrogativa del receptor. Entre la factura y el registro en cadena, un remitente puede probar que cumplió con las instrucciones del receptor. Un receptor honesto solo proporcionará una dirección desde la que pueda gastar fondos de manera segura. En la interpretación más caritativa, una billetera del remitente que hace una verificación de la cordura de las instrucciones del receptor equivaldría, en el mejor de los casos, a una cortesía.
2. Un atacante no tiene ningún beneficio al proporcionar una dirección que envía fondos a una salida que cualquiera puede gastar en lugar de reclamar los fondos para sí mismo, y si por alguna razón inexplicable solo quisiera hacer que los fondos no se puedan gastar, simplemente podría crear una dirección que no t posee la clave privada para.

A cambio de hacer la concesión natural de confiar en el receptor para elegir un tipo de salida razonable, el ecosistema obtiene la gran ventaja de hacer que el despliegue de todos los nuevos tipos de salida previsibles sea instantáneo.

---

¹ _{Obviamente, esto debe evaluarse por red y es perfectamente razonable generar direcciones P2TR en redes de prueba, especialmente donde las reglas de Taproot ya se aplican, como por ejemplo, Signet.}

Para que un remitente envíe a una dirección P2TR antes de la activación, debe haber recibido esa dirección P2TR del receptor y, por lo tanto, sería una salvaguardia indirecta para proteger al receptor de haber dado direcciones P2TR prematuramente. Que los fondos del destinatario sean vulnerables a ser robados antes de la activación no es una preocupación directa del remitente.

Ya existen salvaguardas en la preactivación de Bitcoin Core, como la no generación de direcciones Taproot de la red principal (generalmente se recomienda que cualquier billetera evite que se generen direcciones Taproot de la red principal antes de la activación) y los gastos de Taproot de la red principal no se retransmiten (no se imponen tales restricciones a regtest, signet donde Taproot ya se ha activado). Esta restricción en el sendtoaddressRPC lo condicionaría a la altura del bloque actual o, alternativamente, el usuario tendría que actualizar a la última versión para poder enviar a una activación posterior de la dirección P2TR. Tal como está, una billetera no necesita actualizarse Taproot o ser consciente de Taproot para poder enviar a una dirección P2TR.

La introducción de las direcciones SegWit v0 tuvo este problema en el que muy pocas personas usaban las billeteras SegWit v0 después de la activación de SegWit porque ninguna billetera podía pagar a dichas direcciones. Además, los servicios no tenían ningún incentivo para actualizarse a SegWit v0 porque no había demanda para pagar a dichas direcciones.

Gracias a varias personas que respondieron esto en IRC y Murch por su edición sugerida. Cualquier error es mío.