transaction Bitcoin ที่ติดคือยังไง?
ทุก unconfirmed Bitcoin transaction แข่งกันเพื่อพื้นที่ block ที่จำกัด แต่ละ block รองรับข้อมูล transaction ประมาณ 1-4 MB (ขึ้นกับประเภท transaction) และ miner เลือก transaction ที่ include ตาม fee rate — sats per virtual byte (sat/vB) — ที่แต่ละอันเสนอ เมื่อคุณ broadcast transaction ด้วย fee rate ที่กลายเป็นต่ำเกินไป มันนั่งใน mempool รอ miner เลือก
สิ่งนี้เกิดบ่อยที่สุดในช่วง fee spike คุณส่ง transaction ที่ 5 sat/vB ในช่วงบ่ายเงียบ และเมื่อ miner ดู mempool ขั้นต่ำที่เข้า block ถัดไปคือ 25 sat/vB transaction ของคุณอยู่ใกล้ก้นคิว และอาจอยู่ที่นั่นหลายชั่วโมง หลายวัน หรือจน congestion คลาย
เงินไม่หาย แช่แข็งในสภาพคลุมเครือ: ผู้ส่งใช้จ่าย input เหล่านั้นไม่ได้ (เขา “ถูกล็อก” ด้วย transaction ยังไม่ confirmed) และผู้รับเห็นการจ่ายเงินขาเข้าที่ไม่ confirmed ตลอด สำหรับการจ่ายเงินที่เร่งด่วน — จ่ายผู้ให้บริการ Lightning ปิด escrow พบ deadline — นี่เป็นปัญหาจริง
มี 2 ทางแก้หลัก: Replace-by-Fee (RBF) และ Child-Pays-for-Parent (CPFP)
RBF: Replace-by-Fee
RBF ระบุใน BIP 125 อนุญาตให้ผู้ส่ง transaction broadcast version ใหม่ของ transaction เดียวกัน — ใช้ input เดียวกัน จ่าย output เดียวกัน — แต่ค่าธรรมเนียมสูงกว่า miner จะชอบ replacement ค่าธรรมเนียมสูงกว่า และเมื่อ confirm transaction เดิมหายไป
RBF ทำงาน transaction เดิมต้อง ส่งสัญญาณ RBF ด้วยการตั้ง sequence number ของ input อย่างน้อย 1 ตัวให้ต่ำกว่า 0xFFFFFFFE กระเป๋าสมัยใหม่ส่วนใหญ่ทำอัตโนมัติ:
- Sparrow Wallet — ส่งสัญญาณ RBF ทุก transaction โดย default; มีปุ่ม “Increase Fee” ชัด
- Bitcoin Core — RBF เป็น default; ใช้
bumpfeeใน console หรือตัวเลือก GUI - Electrum — รองรับ RBF; คลิกขวา pending transaction เพื่อ bump
- mempool.space Accelerator — สำหรับ transaction ที่ RBF ไม่ได้ mempool.space มีบริการ accelerate แบบ CPFP
ถ้า transaction เดิมไม่ส่งสัญญาณ RBF ใช้วิธีนี้ไม่ได้ ตัวเลือกคือ CPFP (ถ้าคุณเป็นผู้รับ) หรือรอ
กฎการแทนที่ BIP 125 ละเอียด
BIP 125 นิยาม 5 เงื่อนไขที่ replacement transaction ต้องตรงทั้งหมด 2 อันที่เกี่ยวข้องที่สุดสำหรับการ bump ค่าธรรมเนียม:
ค่าธรรมเนียมสัมบูรณ์สูงกว่า: replacement ต้องจ่ายค่าธรรมเนียมรวมใน satoshi สูงกว่าเดิมอย่างเข้มงวด การจ่าย fee rate สูงกว่าไม่พอ — ถ้า replacement transaction เล็กกว่า (bytes น้อย) ค่าธรรมเนียมรวมอาจต่ำกว่าแม้ rate สูงกว่า สิ่งนี้ไม่ค่อยสำคัญในทางปฏิบัติเพราะการ bump ค่าธรรมเนียมมักเก็บรูปทรง transaction เดียวกัน
พื้นของ Relay fee increment: ค่าธรรมเนียม replacement ต้องอย่างน้อยเท่ากับค่าธรรมเนียมเดิมบวก 1 sat/vB × vbytes_of_replacement สิ่งนี้ป้องกัน attacker spam replacement ด้วยค่าธรรมเนียมสูงขึ้นเล็กน้อย พื้น BIP 125 คือสิ่งที่ calculator นี้คำนวณและบังคับใช้ — ถ้า rate ใหม่ที่คุณเลือกต่ำกว่านี้ replacement จะถูก reject โดย relay node
BIP 125 ยังกำหนดว่า replacement ไม่เพิ่ม unconfirmed input ใหม่ และจำนวน transaction ที่ conflict และ evict ต้องไม่เกิน 100
CPFP: Child-Pays-for-Parent
Child-Pays-for-Parent (CPFP) เป็นกลไกเสริม ทำงานเมื่อ:
- คุณเป็น ผู้รับ ของ transaction ที่ติด (ไม่ใช่ผู้ส่ง คุณจึงไม่มี key ผู้ส่ง)
- กระเป๋าผู้ส่งไม่ส่งสัญญาณ RBF
- คุณต้องการเร่งโดยไม่ invalidate หรือเปลี่ยน transaction เดิม
ใน CPFP คุณสร้าง child transaction ที่ใช้ output ที่ยังไม่ confirmed (เงินที่คุณรับ) ตั้งค่าธรรมเนียม child สูงพอที่ fee rate รวมของแพ็คเกจพ่อ + ลูกเกิน mempool ขั้นต่ำปัจจุบัน miner ประเมินแพ็คเกจเป็นหน่วย ดังนั้น child ที่ใจกว้างพอสามารถลาก parent ที่ติดเข้า block ถัดไปได้
CPFP มีข้อเสีย: คุณจ่ายค่าธรรมเนียม 2 transaction (parent ที่คุณไม่ได้ส่ง และ child ที่คุณสร้าง) สำหรับจำนวนเล็ก สิ่งนี้ไม่เหตุผลเชิงเศรษฐกิจ — คุณจ่ายค่าธรรมเนียม accelerate มากกว่ามูลค่า transaction RBF ปกติถูกกว่าเมื่อมี เพราะผู้ส่งจ่ายค่าธรรมเนียมเดียว ไม่ใช่ 2
เมื่อไรใช้ RBF vs CPFP
| สถานการณ์ | ใช้ |
|---|---|
| คุณส่ง transaction; กระเป๋าส่งสัญญาณ RBF | RBF — ถูกสุด สะอาดสุด |
| คุณส่ง transaction; ไม่ส่งสัญญาณ RBF | CPFP (สร้าง tx ใหม่ใช้ output ทอน) |
| คุณเป็นผู้รับ; transaction ติด | CPFP (ใช้ output ขาเข้าด้วยค่าธรรมเนียมสูง) |
| Exchange หรือบุคคลที่สามส่งเงินคุณ | ติดต่อผู้ส่งให้ RBF หรือ CPFP ถ้าคุณมี output ใช้ |
วิธี bump ผ่านกระเป๋ายอดนิยม
Sparrow Wallet: เปิด transaction ใน tab Transactions ถ้ายังไม่ confirmed และเปิด RBF คุณจะเห็นปุ่ม “Increase Fee” คลิก ตั้ง target fee rate และ Sparrow สร้างและ broadcast replacement อัตโนมัติ
Electrum: ใน History tab คลิกขวา pending transaction และเลือก “Increase fee” Electrum แสดงค่าธรรมเนียมปัจจุบันและให้ตั้ง fee rate ใหม่ ลงนามและ broadcast
Bitcoin Core (GUI): คลิกขวา pending transaction ใน Transactions tab และเลือก “Bump fee” GUI prompt ถาม fee rate ใหม่และจัดการที่เหลือ
Bitcoin Core (console): bumpfee <txid> — optional ส่ง {"fee_rate": N} เป็น argument ที่ 2
mempool.space: ถ้า transaction ของคุณไม่เข้าเงื่อนไข RBF mempool.space ให้บริการ accelerate แบบ CPFP paste txid และจ่ายค่าธรรมเนียมให้เขา package-mine
คำเตือนและข้อควรระวัง
ต้องส่งสัญญาณ RBF: ถ้า sequence number ของ transaction เดิมไม่ส่งสัญญาณ RBF node Bitcoin จะไม่ propagate replacement เช็ค setting กระเป๋าก่อนสมมติว่า bump ได้เสมอ
ผู้รับอาจเห็นเดิมเป็นการจ่ายเงิน unconfirmed: บางกระเป๋าและร้านค้าแสดง transaction รับ unconfirmed ทันที การ bump RBF ทางเทคนิค invalidate transaction เดิม — ผู้รับจะเห็นมันหายและ transaction ใหม่ปรากฏด้วยจำนวนเดียวกันแต่ txid ต่างกัน สื่อสารสิ่งนี้กับผู้รับหลีกเลี่ยงสับสน
ความเสี่ยง double-spend สำหรับผู้รับ: เพราะ RBF อนุญาตผู้ส่ง broadcast transaction ขัดแย้ง ผู้ส่งไม่ซื่อสัตย์อาจทางทฤษฎีใช้ RBF พยายาม double-spend โดยแทนที่ transaction ไปร้าน A ด้วย transaction ไปร้าน A ที่จำนวนต่ำกว่า — หรือแม้ไปที่อยู่ทอนที่เขาควบคุม ร้านค้าที่รับการจ่ายเงิน zero-confirmation Lightning หรือ on-chain ควรตระหนัก สำหรับจำนวนใหญ่ รอ confirmation 1 ครั้งหรือมากกว่าปลอดภัยกว่าเสมอ
ไม่ใช่ทุกกระเป๋าเท่าเทียม: บางกระเป๋าเก่าหรือกระเป๋า exchange ไม่ส่งสัญญาณ RBF โดย default ถ้าคุณใช้กระเป๋าแบบนี้ คุณอาจ bump ไม่ได้เลยโดยไม่มีความร่วมมือจากฝั่งรับ
FAQ
ทำไมพื้น BIP 125 สำคัญ?
ไม่มี relay floor attacker spam mempool ด้วย 1-sat incremental replacement ไม่รู้จบได้ บังคับ node ให้ validate และ propagate transaction ไม่จำกัด ข้อกำหนด 1 sat/vB increment หมายความว่าแต่ละ replacement ต้องจ่าย relay node เชิงเศรษฐกิจ ทำให้การโจมตี fee-spam แพงพอจนไม่ practical
เกิดอะไรขึ้นกับ transaction เดิมหลัง RBF สำเร็จ?
หายไป เมื่อ replacement confirm transaction เดิม invalid — ใช้ input เดียวกันที่ถูกบริโภคโดย replacement ที่ confirm ผู้รับที่เห็นเดิมยังไม่ confirm จะเห็นมันหายจากกระเป๋าและ replacement (อาจ txid ต่างกัน) confirm แทน
RBF transaction ที่รับได้ไหม?
ไม่ RBF ต้องการใช้ input เดียวกันกับ transaction เดิม ซึ่งหมายความว่าต้องมี private key ที่ลงนาม input เดิม ในฐานะผู้รับ คุณใช้ได้แค่ CPFP
รู้ได้ยังไงว่ากระเป๋าส่งสัญญาณ RBF?
เช็ค Settings หรือ Preferences ในกระเป๋า Sparrow, Bitcoin Core, และ Electrum ทั้งหมดมี setting RBF ถ้าไม่แน่ใจ หา transaction เดิมบน block explorer: transaction ส่งสัญญาณ RBF ถ้า input มี sequence number ต่ำกว่า 0xFFFFFFFE (4294967294) mempool.space แสดงชัด
Sources:
- BIP 125 (Replace-by-Fee signaling): github.com/bitcoin/bips/blob/master/bip-0125.mediawiki
- mempool.space live fee rates: mempool.space
- Sparrow Wallet RBF: sparrowwallet.com