Engineering The Unhappy Path: Understanding BitVM2 Architecture Part Four: Withdrawals as a User Flow Withdrawals are where the standard design becomes operator-centric: fixed peg-in UTXOs, pre-signed graphs, and timelocks leak into the user experience. This is why GOAT BitVM2 separates “user gets BTC” from “operator gets reimbursed”. 1) User withdrawal = atomic swap (simple, arbitrary amount) A withdrawal is defined as Atomic Swap + Peg-Out. In the basic flow: • User locks PegBTC on L2 in an HTLC (hash-locked). • Operator locks BTC on L1 in a matching HTLC. • User claims BTC and reveals the preimage. • Operator uses that preimage to claim the PegBTC. This gives the user an “amount X” withdrawal without needing them to participate in the BitVM2 transaction graph mechanics. The spec also notes UX improvements (e.g. using Bitcoin SPV) to avoid the user manually handling a preimage. 2) Operator reimbursement = peg-out, proven against canonical L2 state After the swap, the operator exits via the peg-out path and is reimbursed based on L2 state-transition proofs, rather than relying on user-level coordination. Operationally, the operator role explicitly includes “exchanges PegBTC for native BTC with users” and then runs the proof/reimbursement workflow. The net effect: • Users get an arbitrary-amount withdraw path that doesn’t require “operator behavior”....