BIP110: เมื่อ Bitcoin อยากจะบล็อก Ordinals ด้วย Soft Fork ที่ไม่มีใครอยากเซ็นชื่อให้

สรุปสั้น: BIP110 หรือ “Reduced Data Temporary Softfork” คือข้อเสนอ soft fork ชั่วคราว ~1 ปีที่ต้องการ block การฝังข้อมูลขนาดใหญ่ใน Bitcoin transactions ด้วย 7 กฎ consensus ใหม่ — โจมตีตรงๆ ที่ Ordinals, BRC-20, และ Runes มันเป็น User-Activated Soft Fork (UASF) ที่ต้องการ miner signaling แค่ 55% (ต่ำกว่ามาตรฐาน 95%) และมี mandatory signaling window เริ่มช่วง ~8 สิงหาคม 2026 — แต่ปัจจุบัน (สิงหาคม 2026) มี miner สนับสนุนเพียง ~2.6% activation จึงแทบเป็นไปไม่ได้ อย่างไรก็ตาม บทเรียนเรื่อง Bitcoin governance, ข้อถกเถียงเรื่อง “Bitcoin คืออะไร”, และความล้มเหลวที่น่าสนใจของ UASF นี้ ทิ้งคำถามสำคัญไว้ให้ชุมชนต้องตอบ

สารบัญ

ภาพรวม — ทำไม BIP110 ถึงมีอยู่
ทำไม Bitcoin ถึงมีปัญหากับ Ordinals
Technical Specification: 7 กฎที่ทำให้ทุกคนทะเลาะกัน
Activation Mechanism: Modified BIP9 + UASF
Timeline
ใครหนุน ใครต้าน — และทำไม
ผลกระทบ
บทเรียนด้าน Bitcoin Governance
อ้างอิง

ภาพรวม — ทำไม BIP110 ถึงมีอยู่

ปี 2022 เป็นจุดเริ่มต้นของยุค “Inscription” บน Bitcoin เมื่อโปรโตคอล Ordinals ทำให้คนสามารถฝังข้อมูลสุ่มลงในชั้น witness ของ Bitcoin transaction ได้ ตามมาด้วย BRC-20 token standard และ Runes protocol — ทั้งหมดอาศัยช่องว่างของ Taproot (BIP341) และการที่ Bitcoin ไม่มีกฎ consensus ที่ห้ามฝังข้อมูล

ปัญหาที่กลุ่ม “Bitcoin บริสุทธิ์” มองเห็นคือ:

UTXO set bloat — ข้อมูลที่ฝังอยู่ใน transaction ทำให้ node operators ต้องแบกรับขนาด UTXO set ที่ใหญ่ขึ้น ต้นทุนเพิ่ม decentralization ลด
Fee market distortion — Inscriptions แย่งพื้นที่ block กับ financial transactions จริงๆ ทำให้ค่า fee ของคนอยากโอนเงินพุ่งสูง
Development resource diversion — ทีม Bitcoin Core ต้องมาจัดการ edge cases และปัญหาที่เกิดจาก use case ที่ไม่ได้ตั้งใจออกแบบไว้

แล้ว Bitcoin Core v30 ก็เทน้ำมันเข้ากองไฟ ด้วยการเอาจำกัด 83 bytes ออกจาก OP_RETURN outputs — เปิดประตูให้ฝังข้อมูลขนาดใหญ่ได้ง่ายขึ้นอีก

BIP110 คือคำตอบของกลุ่มที่เชื่อว่า Bitcoin ควรเป็นแค่ “เงิน” ไม่ใช่ระบบเก็บข้อมูล — พวกเขาตัดสินใจเอาเรื่องนี้ขึ้นสู่ระดับ consensus โดยเสนอ soft fork ชั่วคราว 1 ปีที่จะทำให้ transaction เหล่านั้น invalid ในระดับกฎหมายของ network

ทำไม Bitcoin ถึงมีปัญหากับ Ordinals

ฉบับขำๆ — ถนนหลวงกับรถขนของ

ลองนึกภาพถนนสี่เลน (Bitcoin blockchain) ที่สร้างขึ้นมาเพื่อรถบรรทุกสินค้า (financial transactions) ทุกคันมีใบเบิกทาง มีปลายทางชัดเจน และแต่ละเที่ยวทำให้ระบบเศรษฐกิจขับเคลื่อน

แล้วก็มีกลุ่มคนที่เริ่มใช้ถนนนี้ขนเฟอร์นิเจอร์ทั้งบ้าน (Ordinals) — โต๊ะ, ตู้เย็น, เก้าอี้ — ถูกกฎหมายทุกอย่าง เพราะ “ถนนหลวงไม่มีกฎห้ามขนเฟอร์นิเจอร์” แต่รถเหล่านี้ช้า, ใหญ่, และทำให้รถสินค้าจริงๆ ต้องรอคิวนานขึ้นพร้อมจ่ายค่าผ่านทางแพงขึ้น

BIP110 คือ กฎหมายชั่วคราว 1 ปี ที่บอกว่า “ถ้าของที่คุณขนหนักเกิน 256 กิโล ต้องใช้รถประเภทพิเศษ” — มันไม่ได้ห้ามขนเฟอร์นิเจอร์โดยสิ้นเชิง แต่ทำให้การขนแบบเดิม invalid ตามกฎ consensus

ฝ่ายต้านบอกว่า: ถ้าเริ่มบอกว่า “ของประเภทนี้ขนไม่ได้” วันนี้ พรุ่งนี้คุณจะบอกว่า Lightning channel ขนไม่ได้ หรือ mixer ขนไม่ได้ด้วยหรือเปล่า?

ทำไม Ordinals ถึง “ได้ผล” ด้านเทคนิค

Ordinals ทำงานโดยอาศัย Segregated Witness (SegWit) ที่ฝัง arbitrary data ลงใน scriptSig witness field ของ transaction โดยใช้ pattern แบบนี้:

OP_FALSE
OP_IF
  OP_PUSH "ord"
  OP_PUSH 1
  OP_PUSH "image/png"
  OP_PUSH 0
  OP_PUSH <binary data chunk 1>  ← อาจใหญ่กว่า 256 bytes
  OP_PUSH <binary data chunk 2>
  ...
OP_ENDIF

Block OP_FALSE ทำให้ code path นี้ไม่ถูก execute จริง — มันแค่ฝังข้อมูลไว้โดยไม่มีผลต่อ logic ของ transaction แต่ข้อมูลก็ยังถูกบันทึกลง blockchain ตลอดไป

BIP110 ตีจุดนี้ 3 ทาง: Rule 2 (จำกัด OP_PUSHDATA ≤ 256 bytes), Rule 7 (ห้าม OP_IF ใน Tapscript), และ Rule 5 (จำกัด Taproot control block depth)

Technical Specification: 7 กฎที่ทำให้ทุกคนทะเลาะกัน

BIP110 เพิ่ม 7 กฎ consensus ใหม่ โดยมีข้อยกเว้นสำคัญคือ UTXO Grandfathering: UTXO ที่ถูกสร้างขึ้น ก่อน activation height จะได้รับการยกเว้นจากทุกกฎ — เงินที่มีอยู่แล้วปลอดภัย ไม่มีการ confiscate

กฎ	ข้อจำกัด	เป้าหมายจริง
Rule 1	scriptPubKey ≤ 34 bytes (OP_RETURN ≤ 83 bytes)	บล็อก non-standard output script ที่ใช้ฝังข้อมูล
Rule 2	OP_PUSHDATA payloads และ witness items ≤ 256 bytes	บล็อก inscription payload ขนาดใหญ่ใน witness data
Rule 3	Spending undefined witness versions = invalid	ป้องกัน trick ใช้ witness version ที่ยังไม่ถูกนิยาม
Rule 4	Taproot annex = invalid	บล็อก annex-based data embedding
Rule 5	Control block ≤ 257 bytes (รองรับ ≤ 128 taptree leaves)	บล็อก deep taptree inscription methods
Rule 6	OP_SUCCESS* ใน Tapscript = invalid	บล็อกการใช้ “no-op” opcode ที่ยังไม่ถูกกำหนดความหมาย
Rule 7	OP_IF / OP_NOTIF ใน Tapscript = invalid	ตัด conditional-branch encoding ที่ Ordinals ใช้ฝังข้อมูล

ความเสียหายข้างเคียง (Collateral Damage)

กฎเหล่านี้ไม่ได้โจมตีแค่ inscription — มันกระทบของดีด้วย:

BitVM — โปรโตคอลที่พยายาม emulate smart contract บน Bitcoin ใช้ deep taptrees มากกว่า 7 levels จะ break ทันทีจาก Rule 5
Advanced multisig / covenant schemes — บางรูปแบบที่ใช้ OP_IF ซับซ้อนจะกระทบจาก Rule 7
Pre-signed transactions — ถ้า UTXO ถูกสร้างหลัง activation height และ transaction ที่ pre-sign ไว้ใช้ feature ที่ถูกห้าม — อาจกลายเป็น unspendable ถ้าไม่มี alternative spending path

ตัว Coinkite เอง (ผู้ทำ Coldcard) ต้องออกมาเตือน user ให้ระวังเรื่องนี้ด้วย

ตัวอย่าง: Inscription ที่ละเมิด Rule 2

# Transaction witness data ของ Ordinals inscription ทั่วไป
witness:
  - <signature>
  - <script>:
      OP_FALSE
      OP_IF
        OP_PUSH "ord"
        OP_PUSH 1
        OP_PUSH "image/png"
        OP_PUSH 0
        OP_PUSH <4,096 bytes of PNG data>  ← ละเมิด Rule 2 (> 256 bytes)
      OP_ENDIF
  - <control block>

หลัง BIP110 activate — node ที่รัน BIP110 software จะ reject transaction นี้ว่า invalid

Peter Todd แย้งว่า: คุณสามารถ split ข้อมูลเป็นหลาย OP_PUSH ≤ 256 bytes แต่ละอัน แล้วฝัง BIP110 text ทั้งหมดลงไปได้สบายๆ โดยไม่ละเมิดกฎเลย — พิสูจน์ว่า technical restriction นี้ circumventable

Activation Mechanism: Modified BIP9 + UASF

BIP110 ใช้ BIP9 (block version signaling) เป็น base แต่เปลี่ยนพารามิเตอร์หลัก 5 จุดเพื่อให้เหมาะกับ soft fork ชั่วคราว:

การเปลี่ยนแปลงจาก BIP9 มาตรฐาน

พารามิเตอร์	BIP9 มาตรฐาน	BIP110
Signaling threshold	95% (1,916/2,016 blocks)	55% (1,109/2,016 blocks)
Expiration	Time-based (Unix timestamp)	Height-based (block 965,664)
Final state	ACTIVE (permanent)	EXPIRED (auto-expires หลัง ~1 ปี)
Mandatory signaling	ไม่มี	มี (blocks 961,632–963,647)
Signaling bit	ตาม BIP9 ปกติ	Bit 4

State Machine

DEFINED → STARTED → [55% threshold reached?]
                        YES → LOCKED_IN → ACTIVE → EXPIRED (หลัง 52,416 blocks)
                        NO  → [ถึง block 965,664?]
                                YES → EXPIRED (ไม่เคย active)
                                NO  → ต่อไป...

[Mandatory signaling window: blocks 961,632–963,647]
  ถ้า BIP110 node เห็น block ที่ไม่ signal bit 4 ใน window นี้ → reject block นั้น

ฉบับขำๆ — ประตูที่ล็อคเองได้

นึกภาพกฎหมายจราจรที่บอกว่า “ห้ามรถขนาดใหญ่ใน CBD ในชั่วโมงเร่งด่วน เป็นเวลา 1 ปี” — ไม่ใช่กฎถาวร แค่ชั่วคราว เพื่อแก้ปัญหาเฉพาะหน้า แล้วก็ “หมดอายุ” เองโดยอัตโนมัติ

BIP110 ออกแบบมาแบบนี้ — กฎ activate เองแล้วก็ “ปลดล็อคเอง” หลัง ~1 ปี เพื่อไม่ให้ permanent restrictions ไปขัดขวาง future Bitcoin upgrades ที่อาจต้องการ feature เหล่านั้นกลับมา

ปัญหา: UASF หมายความว่า node ที่รัน BIP110 software จะ reject block ของ miner ที่ไม่ signal — ถ้า miner ส่วนใหญ่ไม่ signal มันไม่ใช่ “Bitcoin” ที่ถูก upgrade แต่ BIP110 nodes จะ fork ตัวเองออกไปเป็น minority chain ขนาดเล็กแทน

Timeline

วันที่ / บล็อก	เหตุการณ์
2022	Ordinals protocol เริ่มปรากฏขึ้น, inscription แรกๆ ถูกฝังลง Bitcoin
2023-02	Peak spam event — mempool ระเบิด, ค่า fee พุ่งสูง, node operators บ่น
2023 ต่อมา	BRC-20 tokens และ Runes protocol ตามมา, ปัญหา UTXO bloat ทวีคูณ
2025-10	Dathon Ohm เผยแพร่ draft BIP110 เป็น response ต่อ BIP-444
2025-12-01	Signaling period เริ่มต้น (bit 4) ตาม spec
2025-12-03	Bitcoin BIPs repository assign BIP number 110 อย่างเป็นทางการ
2026-03	OCEAN Mining pool เป็นผู้ขุด block แรกที่ signal support — pool เดียวที่ทำ
2026-06	BGeometrics เปิดตัว BIP110 signaling tracker — support ยังต่ำกว่า 3%
2026-07-12	CoinDesk รายงาน miner support ยังอยู่ที่ 0% อย่างเป็นทางการ ก่อน deadline
~2026-08-09	Mandatory signaling window เริ่ม (block 961,632) — BIP110 nodes เริ่ม reject blocks ที่ไม่ signal
~2026-08-23	Lock-in deadline (block 963,647) — ต้องมี 55% (1,109/2,016 blocks) ถึงจะ lock-in
~2026-09-06	Max activation height (block 965,664) — ถ้าไม่ถึง threshold = EXPIRED โดยไม่เคย active

ใครหนุน ใครต้าน — และทำไม

ฝ่ายสนับสนุน

ชื่อ / องค์กร	จุดยืน
Dathon Ohm (author)	Bitcoin ต้องเป็น sound money — ไม่ใช่ “neutral protocol” สำหรับทุกอย่าง
Luke Dashjr (credited advisor)	ผู้เขียน Bitcoin Knots, มองว่า inscription เป็น “spam” ที่ต้องถูก filter
Bitcoin Knots	Node implementation แรกที่รองรับ BIP110
Start9, Umbrel, myNode	Node platforms ที่เปิดใช้ BIP110 support
OCEAN Mining	Mining pool เดียวที่ signal — ผู้นำด้านนโยบาย transaction filtering
hodlonaut	ผู้สร้าง CAPTURE analysis series สนับสนุน BIP110

ฝ่ายคัดค้าน (และน้ำหนักของพวกเขา)

Michael Saylor (Strategy, ถือ Bitcoin มูลค่าหลักหมื่นล้านดอลลาร์):

“there are 110 things more dangerous to Bitcoin than spam”

เขาเตือนว่าการแก้ “spam” ด้วย consensus change สร้าง precedent ที่อันตรายกว่าปัญหา spam เอง — เมื่อมันทำให้ใครก็ตามสามารถ lobby ให้เปลี่ยน consensus rules เพื่อ “จุดประสงค์ที่ดี” ได้

Adam Back (Blockstream, ผู้คิด Hashcash ที่เป็น foundation ของ Bitcoin mining):

“respectfully says no — fork away, but bitcoin won’t be joining it”

ชัดเจนที่สุด — Bitcoin ไม่ไปด้วย ถ้าอยากทำก็ fork ออกไป

Greg Maxwell (อดีต Bitcoin Core developer): อ้างว่า Ocean Mining เป็นผู้เขียน BIP110 จริงๆ แล้วใช้ Dathon Ohm เป็นหน้าฉาก โดยมีแรงจูงใจเรื่อง transaction filtering policy ที่ Ocean ทำอยู่แล้ว — Dathon Ohm ปฏิเสธข้อกล่าวหานี้

Peter Todd (Bitcoin Core contributor): ทดสอบจริงแล้วพิสูจน์ว่า inscription ยังทำได้ภายใต้ BIP110 โดยฝัง text ของ BIP110 เองลงในธุรกรรมที่ compliant 100% — ชี้ให้เห็นว่า technical restriction นี้ไม่ effective จริงๆ

Bitcoin Core developers ส่วนใหญ่: ไม่มีใครออกมา endorse BIP110 อย่างเป็นทางการ

เหตุผลทางเทคนิคที่คัดค้าน

Chain split risk — 55% threshold ต่ำกว่า 95% ที่ soft fork ปกติใช้ ถ้า miner ส่วนใหญ่ไม่เห็นด้วย อาจเกิด network split ชั่วคราว
BitVM พัง — protocol ที่กำลัง unlock smart contracts บน Bitcoin จะถูก disable ทันที
Pre-signed transactions กลายเป็น unspendable — scenario ที่ Coinkite, Blockstream และ Miniscript developers เตือน
Censorship precedent — ถ้าวันนี้ห้าม data > 256 bytes พรุ่งนี้จะห้ามอะไรอีก?

ผลกระทบ

ถ้า BIP110 Activate (ความเป็นไปได้น้อยมาก)

Ordinals / Runes / BRC-20: protocols เหล่านี้จะถูก handicap ชั่วคราว ~1 ปี — inscription ไม่ invalid ทั้งหมด แต่ขนาดและ encoding method ถูกจำกัด
BitVM: development disrupted ทั้งหมดตลอดช่วง active period
Wallet software: ต้องอัปเดตก่อน activation — Miniscript compilers ต้องหลีกเลี่ยง Rule 7
Node operators: BIP110 nodes จะ fork ออกจาก majority chain ถ้า miner ส่วนใหญ่ยังขุด “Bitcoin เดิม”

ถ้า BIP110 ไม่ Activate (likely)

BIP110 nodes ที่รัน software จะ fork ออกไปเป็น minority chain ขนาดเล็ก — แทบไม่มีมูลค่าทางเศรษฐกิจ
ตลาดไม่ได้แสดงความสนใจ — prediction market ให้โอกาส activation ต่ำมาก
BIP110 EXPIRED ที่ block 965,664 (~6 กันยายน 2026) โดยไม่เคยมีผลบังคับใช้

Impact ที่สำคัญกว่า: Bitcoin Governance

ไม่ว่า BIP110 จะ activate หรือไม่ — มันบังคับให้ชุมชน Bitcoin ต้องตอบคำถามที่หลีกเลี่ยงไม่ได้:

“Bitcoin เป็นแค่ money หรือเป็น neutral protocol สำหรับทุกอย่าง?”

ถ้าตอบว่า “แค่ money” — ต้องยอมรับว่า consensus rules สามารถถูกเปลี่ยนเพื่อ enforce นิยามนั้นได้
ถ้าตอบว่า “neutral protocol” — ต้องยอมรับ Ordinals, BRC-20, Runes และทุกอย่างที่จะตามมา

BIP110 ไม่ได้แค่ต่อสู้กับ Ordinals — มันต่อสู้กับ philosophical foundation ของ Bitcoin เอง

บทเรียนด้าน Bitcoin Governance

1. UASF คือ Double-Edged Sword

ในปี 2017 BIP-148 (UASF สำหรับ SegWit) สำเร็จเพราะมี economic majority อยู่เบื้องหลัง — exchanges, wallets, users จำนวนมากพร้อมที่จะ enforce กฎ ทำให้ miner ต้องยอม

BIP110 ขาดสิ่งนั้น ถ้าไม่มี economic majority support UASF ก็แค่ fork ตัวเองออกไปเงียบๆ โดยไม่มีใครสนใจ

2. Lowering Threshold ไม่ใช่ทางออก

55% ฟังดูสมเหตุสมผลสำหรับ “temporary soft fork” — แต่เส้นแบ่งระหว่าง “temporary และ permanent” เบลอมากในระดับ consensus ถ้า lower ได้ถึง 55% วันนี้ พรุ่งนี้จะมีใครเสนอ 40% สำหรับ “emergency” อะไรบางอย่างหรือเปล่า?

3. Peter Todd’s Lesson: Technical Rules ≠ Economic Enforcement

การพิสูจน์ว่า BIP110 text สามารถฝังลง Bitcoin ได้แม้ภายใต้กฎของ BIP110 เอง เป็น demonstration ที่ชัดเจนว่า: ถ้า economic incentive ยังมีอยู่ (คนยังอยากทำ inscription) คนจะหาทางอ้อม technical restriction เสมอ

4. Authorship ที่ไม่โปร่งใส = Credibility ถูก Undermine ตั้งแต่ต้น

การใช้ pseudonym “Dathon Ohm” บน GitHub account ที่เพิ่งสร้างใหม่ โดยมีข้อกล่าวหาจาก Greg Maxwell ว่า Ocean Mining อยู่เบื้องหลัง — ทำให้ technical merit ของ BIP110 ถูก dismiss ด้วยเหตุผล political แทนที่จะถูก evaluate จาก spec จริงๆ

Bitcoin upgrade proposals ต้องการความน่าเชื่อถือ — และ pseudonymous authorship ที่มีแรงจูงใจซ่อนเร้น ทำลายสิ่งนั้นได้ง่าย

5. สรุป: เมื่อ Protocol Meeting Philosophy

ประเด็น	บทเรียน
UASF ต้องการ economic majority	Signaling ต่ำ = fork ออกไปเงียบๆ ไม่มีผลกระทบ
Threshold ต่ำ = precedent อันตราย	55% อาจดูสมเหตุสมผล แต่เบลอเส้นแบ่ง “consensus”
Technical restriction ≠ economic incentive	คนหาทางอ้อมเสมอถ้า incentive ยังอยู่
Authorship credibility สำคัญ	Anonymous origin ทำให้ spec ถูก politicize
“Bitcoin is money” vs “neutral protocol”	คำถามนี้ไม่มีคำตอบที่ถูกหรือผิด — แต่ต้องตอบ

อ้างอิง

BIP 110 Official Spec — bips.dev/110
Bitcoin/bips GitHub — bip-0110.mediawiki
Jameson Lopp — A Layman’s Guide to BIP-110
The Bitcoin Manual — What Is BIP-110?
Simple Mining Insights — BIP-110: Bitcoin’s Data-Limit Proposal and the Fork Debate
CoinDesk — Bitcoin’s BIP 110 fork deadline nears with miner support at zero (July 2026)
Bitcoin.com — BIP-110 Pushes Bitcoin Toward August Fork Deadline With Only 5 EH/s Signaling
CryptoBriefing — BIP-110 proposal struggles with 2-3% miner support ahead of August activation deadline
BIP110.org — Official Support Site
BGeometrics — BIP110 Signaling Has Begun: Track It Daily
BIP110 Monitor — Bitcoin Signaling Monitor
Bitcoincore-dev — bitcoin-bip110 Official Activation Client
Strategy — 110 Reasons BIP 110 Is a Bad Idea
Bitaroo — BIP-110 in August: What Might Happen and How to Prepare
AbundantMines — BIP-110: A Debate Worth Consideration

เอกสารนี้รวบรวมจากรายงานสาธารณะหลายแหล่งเพื่อวัตถุประสงค์ทางการศึกษา ข้อมูลสถานะ activation อาจเปลี่ยนแปลงได้ตามสถานการณ์จริง กรุณาตรวจสอบ BIP110 Monitor และแหล่งข้อมูลต้นฉบับก่อนตัดสินใจใดๆ เกี่ยวกับการ upgrade node ของท่าน