Atomic Swap ล้มเหลว: คู่มือขอ Refund XMR/BTC ปี 2026

Atomic Swap ล้มเหลว: คู่มือขอ Refund XMR/BTC ปี 2026

ในช่วงครึ่งแรกของปี 2026 ผู้ใช้ Monero ในไทยจำนวนไม่น้อยรายงานปัญหา atomic swap ระหว่าง XMR กับ BTC ที่ "ค้างอยู่กลางทาง" — เงินไม่เข้ากระเป๋าปลายทาง แต่ก็ดึงคืนไม่ได้ทันที โดยเฉพาะหลังจากที่ Bitcoin Core 27 ปรับลด default mempool size และ monero-wallet-cli 0.18.4.x เปลี่ยนพฤติกรรมการสแกน output ทำให้ผู้ใช้บางส่วนต้องรอเกินกว่า 24 ชั่วโมงเพื่อให้ timelock ใน HTLC หมดอายุ บทความนี้เป็นคู่มือเชิงปฏิบัติสำหรับนักลงทุนชาวไทยที่ใช้บริการ swap แบบไม่ผ่านศูนย์กลาง (non-custodial) ผ่านเครื่องมืออย่าง COMIT xmr-btc-swap, UnstoppableSwap, หรือบริการ swap ฝั่ง MoneroSwapper เนื้อหาจะสอนวิธีตรวจสอบสาเหตุที่ swap ล้มเหลว ใช้คำสั่ง refund อย่างถูกต้อง และสิ่งที่ต้องเตรียมก่อนติดต่อทีมพัฒนาเพื่อกู้คืนเหรียญ การเข้าใจกลไก timelock และความหมายของ state file (.swap-state.toml) เป็นสิ่งสำคัญที่จะแยกระหว่าง "swap ที่ค้างชั่วคราว" กับ "swap ที่ต้อง refund จริง" — เพราะสับสนตรงนี้คือสาเหตุหลักของการสูญเงินถาวรในไทยตลอดสองปีที่ผ่านมา

ทำไม Atomic Swap ระหว่าง XMR กับ BTC ถึงล้มเหลว

Atomic swap ระหว่าง Monero กับ Bitcoin ไม่ใช่ swap แบบสองทางที่สมมาตร เพราะ Monero ไม่รองรับ smart contract แบบ Bitcoin จึงต้องอาศัยรูปแบบที่เรียกว่า cross-chain adaptor signatures ซึ่งโปรโตคอลที่ใช้กันมากที่สุดคือ COMIT xmr-btc-swap ของ CoBloX และ fork ของมันอย่าง UnstoppableSwap ปัญหาที่เกิดขึ้นจริงในไทยมาจากหลายชั้น ตั้งแต่เรื่องเครือข่ายไปจนถึงพฤติกรรมของคู่ค้า maker

• Maker หายไประหว่างทาง: เมื่อคุณ (taker) เริ่ม swap maker จะต้อง online เพื่อ broadcast คีย์ adaptor signature หาก maker ดับเครื่อง หรือ libp2p connection หลุดในช่วงสำคัญ swap จะค้างทันที
• ค่าธรรมเนียมต่ำเกินจน Bitcoin transaction ค้าง mempool: หลายผู้ใช้ในกรุงเทพฯ ตั้ง fee rate ตามค่าเฉลี่ย mempool.space ตอนตี 3 ซึ่งต่ำมาก แต่พอตื่นเช้ามาค่าธรรมเนียมพุ่ง 8 เท่า ทำให้ TX ติด mempool นานพอที่ timelock จะใกล้หมด
• Block reorg ฝั่ง Bitcoin: แม้จะเกิดน้อย แต่ช่วงปลายปี 2025 มี reorg ลึก 2 บล็อกซึ่งทำให้ swap state ของบางผู้ใช้ในไทยเปลี่ยนจาก BtcLocked เป็น Started อีกครั้ง
• Tor relay ที่ใช้ถูกบล็อก: ผู้ใช้บางรายในไทยใช้ Tor บริดจ์ obfs4 ที่ ISP บล็อกในช่วงเวลาเฉพาะ ทำให้การติดต่อ rendezvous point ของ maker ขาดหาย
• State file เสียหายจาก crash: ถ้าโน้ตบุ๊กที่รัน swap-cli ปิดเครื่องผิดวิธีระหว่าง state กำลังเขียน lock file ที่ ~/.local/share/xmr-btc-swap/ อาจ corrupt จนต้อง restore manual
• ความแตกต่างของเวอร์ชัน: taker ใช้ swap-cli 1.0 ขณะ maker ยังรัน 0.13 ทำให้ negotiation phase ล้มเหลวก่อน BTC จะถูก lock ด้วยซ้ำ

สิ่งที่ต้องเข้าใจคือ "swap ล้มเหลว" ในบริบทนี้ไม่ได้แปลว่าเงินหาย โปรโตคอลถูกออกแบบให้เงินอยู่ในสถานะใดสถานะหนึ่งเสมอ ไม่ฝั่งคุณ ก็ฝั่ง maker หรือบางครั้งล็อกไว้ในเอาต์พุต HTLC ที่รอ timelock หมดอายุ ดังนั้นก่อนตื่นตระหนกหรือไปร้องเรียน สำนักงาน ก.ล.ต. (กลต.) ให้ตรวจสอบ state ของ swap ก่อนเสมอ

กลไก Refund: HTLC, Timelock และ Cancel Transaction ทำงานอย่างไร

ในโปรโตคอล xmr-btc-swap การปกป้องเงินของ taker (ผู้ที่จ่าย BTC เพื่อรับ XMR) อยู่บนพื้นฐานของ Bitcoin script ที่เรียกว่า tx_lock ซึ่งมีสองทางออก: spend path สำหรับให้ maker แลกเอาไป กับ refund path สำหรับให้ taker กู้คืน BTC หาก maker ไม่ส่ง XMR ทันเวลา ทุก swap จะมี timelock สามชั้นที่ทำงานต่อกัน

1. tx_cancel (cancel_timelock)

ค่าเริ่มต้นที่ใช้กันบนเครือข่ายหลักคือประมาณ 72 บล็อก (ราว 12 ชั่วโมง) นับจาก tx_lock confirm ถ้าหลังเวลานี้ maker ยังไม่ redeem BTC ออกไป taker สามารถ broadcast tx_cancel เพื่อย้ายเอาต์พุตไปยัง script ที่อนุญาตให้ refund ในขั้นถัดไป

2. tx_refund (punish_timelock)

หลังจาก tx_cancel ติด blockchain แล้ว ต้องรออีก 72 บล็อก (รวมกว่า 24 ชั่วโมง) เพื่อให้ taker สามารถ broadcast tx_refund ดึง BTC คืนเข้า refund_address ที่ตั้งไว้ตอนเริ่ม swap ระยะนี้ถูกออกแบบให้เป็นกันชน หาก maker เห็น tx_cancel ก็จะมีโอกาส broadcast tx_punish เพื่อยึด BTC ทั้งหมดเป็นบทลงโทษหาก taker ทุจริต

3. tx_punish (เฉพาะกรณีพฤติกรรมผิดปกติ)

หาก taker เปิดเผยคีย์ลับให้ maker แล้วแต่กลับพยายามใช้ refund path นี่คือพฤติกรรมที่โปรโตคอลถือว่าโกง maker จะ broadcast tx_punish ภายในช่วง punish window และยึด BTC ทั้งหมดได้ ดังนั้นการ refund ต้องทำในช่วงเวลาที่ถูกต้องเท่านั้น — กดเร็วไปหรือช้าไปอาจเสียเงิน

ข้อควรระวัง: หาก swap ของคุณอยู่ในสถานะ XmrLocked แล้ว ห้าม refund เด็ดขาด เพราะแปลว่า Monero ถูก lock เรียบร้อย คุณต้อง redeem ออกมา ไม่ใช่ cancel

state สำคัญที่คุณจะเห็นใน swap-cli history มีดังนี้ Started (เริ่ม negotiation), BtcLocked (BTC ของคุณติด lock script แล้ว), XmrLocked (maker ส่ง XMR เข้า lock address แล้ว — เป็นจุดที่ปลอดภัยที่สุดสำหรับการ redeem), EncSigSent (คุณส่ง encrypted signature ให้ maker), BtcRedeemed (maker เอา BTC ของคุณไปแล้ว), CancelTimelockExpired (พร้อม cancel), BtcCancelled (cancel transaction ขึ้น chain แล้ว) และ BtcRefunded (เสร็จสมบูรณ์ คุณได้เงินคืน) การเข้าใจลำดับนี้คือกุญแจของการ refund อย่างถูกต้อง

ขั้นตอนกู้คืนเงินจาก Swap ที่ค้าง

คู่มือนี้ใช้กับ swap-cli ของโปรเจกต์ comit-network/xmr-btc-swap และ UnstoppableSwap ซึ่งเป็น GUI ที่อิงโปรโตคอลเดียวกัน หากคุณใช้บริการที่ห่อ UI ไว้อีกชั้น เช่นผ่าน MoneroSwapper เครื่องมือเหล่านี้ก็จะเปิดเผย swap_id ให้คุณนำมา refund ได้เสมอ

1. ระบุ swap_id ของรายการที่มีปัญหา: รันคำสั่ง swap history เพื่อดูรายการ swap ทั้งหมด หา UUID ที่อยู่ในสถานะ BtcLocked, XmrLockProofReceived หรือ CancelTimelockExpired ที่ตรงกับเวลาที่คุณ swap จริง บันทึก UUID นี้ไว้เพราะคำสั่งทุกอย่างต่อจากนี้จะอ้างถึงมัน
2. ตรวจสอบเวลา timelock ที่เหลือ: ใช้คำสั่ง swap --json refund --swap-id <UUID> --print-only (ในเวอร์ชันใหม่) หรือดูจาก log เพื่อยืนยันว่า cancel_timelock หมดอายุแล้ว ถ้ายังไม่หมด แปลว่าต้องรอ อย่ารีบส่งคำสั่งใด ๆ ที่ขัดกับ state
3. ตรวจสอบ Bitcoin node และค่าธรรมเนียม: ตั้ง fee rate ผ่าน --bitcoin-target-block 1 เพื่อให้ tx_cancel/tx_refund เข้า block ถัดไปทันเวลา ในไทยแนะนำให้รันบน Bitcoin Core เต็มตัวจาก Synology NAS หรือ Umbrel ที่ผู้ใช้หลายคนนิยมตั้งที่บ้าน หากใช้ public Electrum server ของ blockstream.info ระวังการเชื่อมต่อหลุด
4. รันคำสั่ง cancel ก่อน refund: หลัง cancel_timelock หมดอายุให้รัน swap cancel --swap-id <UUID> รอจน tx_cancel ติด 1 confirmation บน chain (mempool.space เช็คด้วยมือเองได้)
5. รอ punish_timelock แล้ว refund: เมื่อ tx_cancel มี 72 confirmations รัน swap refund --swap-id <UUID> โปรแกรมจะ build และ broadcast tx_refund อัตโนมัติ คุณจะเห็น BTC กลับเข้า refund_address ที่ระบุไว้ตอน config wallet ครั้งแรก
6. ตรวจสอบใน wallet ปลายทาง: เปิด Sparrow Wallet หรือ Electrum ที่ผูกกับ xpub เดียวกัน ค้นหา TXID ของ tx_refund ตรวจว่าจำนวน BTC ที่ได้คืนตรงกับยอดเดิมหักค่าธรรมเนียม fee rate ที่ใช้
7. ลบ state file หลังกู้คืนสำเร็จ: เพื่อความสะอาด รัน swap history ใหม่อีกครั้งและยืนยันสถานะเป็น BtcRefunded จากนั้นจึง backup file ที่ ~/.local/share/xmr-btc-swap/sqlite ก่อนลบ swap เก่า

หาก step 4 หรือ 5 ไม่สำเร็จเพราะ daemon ของ Monero ไม่ sync หรือ Bitcoin node ขาดการเชื่อมต่อ ห้ามรันซ้ำหลายรอบจนกว่าจะแก้ปัญหาต้นทาง การ broadcast ซ้ำของคำสั่งเดียวกันไม่เสียเงิน แต่การข้าม step โดยพยายามใช้ key ตรง ๆ จาก state file อาจเป็นเหตุให้ถูกตีความว่า "punish-eligible" ได้

เปรียบเทียบเครื่องมือ XMR-BTC Swap และความสามารถในการ Refund

ตลาดไทยมีตัวเลือกหลักสามถึงสี่ตัว แต่ละตัวมีจุดแข็งที่แตกต่างกันโดยเฉพาะเรื่องการกู้คืนเหรียญหลังจาก swap ล้มเหลว

ข้อแตกต่างที่สำคัญที่สุดคือบริการที่อิงโปรโตคอล atomic swap แท้ ๆ จะไม่สามารถ "เร่ง" refund ได้ เพราะโปรโตคอลถูก enforce โดย Bitcoin blockchain ตรง ๆ ไม่ใช่โดยฝ่ายบริการ ดังนั้นถ้ามีใครอ้างว่าจะ refund ให้ภายใน 1 ชั่วโมงโดยไม่ต้องรอ timelock ให้ระวัง — อาจเป็นการหลอกลวงที่เรียกข้อมูล private key ของคุณไป

กรณีศึกษาในไทย: เมื่อ Swap ค้างหลายวันต้องทำอย่างไร

กลางเดือนกุมภาพันธ์ 2026 ผู้ใช้รายหนึ่งในเชียงใหม่รายงานปัญหา swap 0.04 BTC เป็น XMR ผ่าน UnstoppableSwap ค้างที่สถานะ BtcLocked นานกว่า 36 ชั่วโมง สิ่งที่เขาทำผิดในตอนแรกคือเปิด VPN ที่เปลี่ยน IP บ่อย ทำให้ libp2p ของ swap-cli reconnect ไม่ติดและเข้าใจว่าตัว maker หายไป จึงรีบไปขอความช่วยเหลือในกลุ่ม Facebook ของชุมชน Bitcoin ไทยและพยายามลบ wallet เพื่อ "เริ่มใหม่" ซึ่งเกือบทำให้สูญเงิน

การกู้คืนที่ถูกต้องคือเก็บ swap-cli ปิดไว้ก่อน นำไฟล์ ~/.local/share/xmr-btc-swap ทั้งโฟลเดอร์ไป copy สำรอง จากนั้นรันใหม่บน VPS ที่ IP คงที่ (ในกรณีนี้คือ VPS ที่ Vultr สิงคโปร์) เพื่อให้ libp2p เชื่อมต่อ maker ใหม่ ผลปรากฏว่าสถานะอัปเดตเป็น CancelTimelockExpired ทันทีที่ sync เสร็จ ผู้ใช้รันคำสั่ง cancel ตามด้วย refund และได้ BTC คืนเต็มจำนวนหักเพียงค่า miner fee สองรายการ (รวมประมาณ 4,500 sat) ภายในเย็นวันถัดมา

บทเรียนหลักจากเคสนี้สำหรับผู้ใช้ในไทยมีสามข้อ หนึ่งคือควรรัน swap-cli บนสภาพแวดล้อมที่ IP เสถียรเสมอ เช่น VPS ที่เป็น public IPv4 ถาวร ไม่ใช่ Wi-Fi บ้านที่ใช้ CGNAT ของ True หรือ AIS Fibre ซึ่งทำให้การ punch hole ของ libp2p ลำบาก สองคืออย่าตื่นตระหนกลบไฟล์ wallet หรือ state ก่อนเข้าใจสถานะ — สิ่งที่หายไปไม่ใช่เงิน แต่คือ key material ที่จำเป็นต่อการ refund และสามคือควรเก็บที่อยู่ refund_address ไว้ใน hardware wallet เช่น Trezor หรือ Coldcard ที่หาซื้อได้จากผู้นำเข้าในไทยอย่างร้านเล็ก ๆ ในย่านอโศก ไม่ใช่ที่ exchange ที่อาจถูกอายัด

ในด้านกฎหมาย ผู้ใช้ในไทยที่เผชิญ swap ล้มเหลวควรทราบว่า สำนักงาน ก.ล.ต. ของไทยไม่ได้กำกับโปรโตคอล atomic swap โดยตรง เพราะถือเป็นการแลกเปลี่ยนแบบ peer-to-peer ที่ไม่มีตัวกลาง อย่างไรก็ตาม หากเกิดความเสียหายจากการที่ผู้ให้บริการห่อ UI หลอกลวง (เช่น เก็บ private key ของผู้ใช้) สามารถแจ้งต่อ กองบังคับการปราบปรามอาชญากรรมทางเทคโนโลยี (บก.ปอท.) และยื่นเรื่องผ่านระบบ ThaiPoliceOnline ได้ และในกรณีที่สงสัยว่าเงินถูกฟอกผ่าน mixing service ที่เกี่ยวข้อง สำนักงาน ปปง. มีอำนาจสอบสวน ดังนั้นการเก็บหลักฐานการ swap เช่น TXID ของ tx_lock และ swap_id จึงสำคัญสำหรับการดำเนินคดี

FAQ

ถ้า maker หายไปก่อน lock XMR เลย ฉันจะเสีย BTC หรือไม่?

ไม่ ในกรณีที่ maker หายไปหลัง tx_lock ของ BTC ขึ้น chain แต่ก่อนที่ XMR จะถูก lock โปรโตคอลจะให้คุณรอ cancel_timelock หมดอายุ จากนั้น cancel ตามด้วย refund คุณจะได้ BTC คืนเต็มจำนวนหักเพียงค่าธรรมเนียม miner สองรายการเท่านั้น เหรียญไม่หายไปไหน เพียงแค่ต้องรอ blockchain confirm ตามจังหวะของโปรโตคอล

ใช้เวลานานสุดเท่าไรกว่าจะได้เงินคืน?

โดยทั่วไป cancel_timelock อยู่ที่ประมาณ 12 ชั่วโมง และ punish_timelock อีกประมาณ 12 ชั่วโมง รวมเป็นประมาณ 24 ชั่วโมงนับจากเวลาที่ swap หยุดทำงาน บวกกับเวลาที่ใช้ในการ broadcast cancel และ refund transaction อีกเล็กน้อย ช่วงที่ mempool ของ Bitcoin หนาแน่นมาก คาดเวลารวม 30–36 ชั่วโมงเป็นค่าปลอดภัย

หากลบ swap-cli ทิ้งไปแล้ว ยังขอ refund ได้หรือไม่?

ได้ ถ้าคุณยังมี backup ของโฟลเดอร์ state (~/.local/share/xmr-btc-swap หรือ %APPDATA%\xmr-btc-swap บน Windows) นำไฟล์ sqlite และ wallet กลับมาวางที่เดิม ติดตั้ง swap-cli เวอร์ชันเดียวกับที่ใช้ตอน swap แล้วรัน history เพื่อตรวจสถานะ หากไม่มี backup เลย ต้องติดต่อ maker โดยตรงและพิสูจน์ความเป็นเจ้าของซึ่งทำได้ยาก

การ refund มีค่าใช้จ่ายเท่าไร?

ค่าใช้จ่ายหลักคือ Bitcoin miner fee สองรายการ ได้แก่ tx_cancel และ tx_refund รวมประมาณ 3,000–10,000 sat ขึ้นกับสภาพ mempool ในเวลาที่ broadcast หาก fee rate ที่ตั้งไว้ตอนต้นเพียงพอ ระบบจะหักจาก output ของ tx_lock โดยตรง ผู้ใช้ไม่ต้องเติม BTC เพิ่ม แต่ถ้า fee rate ต่ำเกินจน TX ค้าง อาจต้องใช้ replace-by-fee (RBF) ซึ่งซับซ้อนกว่า

ใช้ exchange ไทยเช่น Bitkub แทนได้ไหม?

Bitkub และ exchange ที่จดทะเบียนกับ ก.ล.ต. ของไทยปัจจุบันไม่รองรับ Monero โดยตรงเพราะข้อจำกัดด้าน AML ที่ สำนักงาน ปปง. และมาตรฐาน FATF Travel Rule กำหนด ผู้ใช้ในไทยที่ต้องการ XMR จึงต้องไป atomic swap หรือ peer-to-peer ผ่านบริการเฉพาะทาง ข้อดีของ atomic swap คือไม่ต้อง KYC แต่แลกมากับความรับผิดชอบในการจัดการ state เอง

มีทางป้องกัน swap ล้มเหลวล่วงหน้าได้ไหม?

มีหลายวิธี เลือก maker ที่มี uptime ดีบน list สาธารณะของ comit-network/maker-registry ตรวจ ping ก่อนเริ่ม swap ใช้ fee rate ที่สูงกว่าค่าเฉลี่ย mempool 30–50% รัน swap-cli บน VPS ที่ IP คงที่ และที่สำคัญที่สุดคืออย่าปิดเครื่องระหว่าง swap กำลังดำเนินอยู่จนกว่าสถานะจะเป็น BtcRedeemed หรือ XmrRedeemed

สรุป

Atomic swap ที่ล้มเหลวระหว่าง XMR กับ BTC แทบทุกกรณีสามารถ refund ได้ ตราบใดที่คุณรักษา state file ไว้และเข้าใจลำดับ timelock หัวใจของการกู้คืนคือความอดทน รอให้ cancel_timelock และ punish_timelock หมดอายุตามจังหวะของโปรโตคอล แล้วใช้คำสั่ง cancel ตามด้วย refund อย่างเป็นลำดับ ห้ามข้ามขั้นหรือพยายาม "เร่ง" ด้วยการแก้ไข key ตรง ๆ หากต้องการเรียนรู้เพิ่มเติมหรือซื้อ XMR แบบเก็บความเป็นส่วนตัวสูงสุดในไทย เริ่มที่หน้า ซื้อ Monero แบบไม่ระบุตัวตน ของ MoneroSwapper ที่รองรับวิธีการชำระเงินที่เหมาะกับผู้ใช้ในประเทศไทย