Ingeniería del Camino Desafortunado: Entendiendo la Arquitectura de BitVM2 Parte Cuatro: Retiros como un Flujo de Usuario Los retiros son donde el diseño estándar se vuelve centrado en el operador: UTXOs de peg-in fijos, gráficos pre-firmados y timelocks se filtran en la experiencia del usuario. Por eso el GOAT BitVM2 separa "el usuario recibe BTC" de "el operador es reembolsado". 1) Retiro del usuario = intercambio atómico (sencillo, cantidad arbitraria) Un retiro se define como Intercambio Atómico + Peg-Out. En el flujo básico: • El usuario bloquea PegBTC en L2 en un HTLC (bloqueado por hash). • El operador bloquea BTC en L1 en un HTLC coincidente. • El usuario reclama BTC y revela la preimagen. • El operador utiliza esa preimagen para reclamar el PegBTC. Esto le da al usuario un retiro de "cantidad X" sin necesidad de que participe en la mecánica del gráfico de transacciones de BitVM2. La especificación también menciona mejoras en la experiencia del usuario (por ejemplo, usando Bitcoin SPV) para evitar que el usuario maneje manualmente una preimagen. 2) Reembolso del operador = peg-out, probado contra el estado canónico de L2 Después del intercambio, el operador sale a través del camino de peg-out y es reembolsado basado en pruebas de transición de estado de L2, en lugar de depender de la coordinación a nivel de usuario. Operativamente, el rol del operador incluye explícitamente "intercambiar PegBTC por BTC nativo con los usuarios" y luego ejecutar el flujo de trabajo de prueba/reembolso. El efecto neto: • Los usuarios obtienen un camino de retiro de cantidad arbitraria que no requiere "comportamiento del operador"....