پروپوزال (BIP-110) BIP-444 که توسط Luke Dashjr و Dathon Ohm برای مقابله با «اسپم» و داده‌های دلخواه روی بلاکچین مثل Inscriptions/Ordinals پیشنهاد شده عملاً قصد دارد استفاده از Bare Multisig را برای ذخیره داده غیرممکن کند.

۱. سافت‌فورک BIP-444 چگونه جلوی Bare Multisig را می‌گیرد؟

تا پیش از این، محدودیت‌های Bare Multisig بیشتر در سطح «پالیسی» (Policy) بود، نه «اجماع» (Consensus). اما BIP-444 یک سافت‌فورک موقت (با انقضای یک ساله) است که قوانین سخت‌گیرانه‌ای را بر خروجی‌های تراکنش اعمال می‌کند.

مکانیزم مسدودسازی:

BIP-444 با محدود کردن سایز scriptPubKey (اسکریپت قفل‌کننده خروجی) جلوی Bare Multisig را می‌گیرد.

• محدودیت جدید: طبق این پروپوزال، سایز scriptPubKey برای اکثر تایپ‌های خروجی به ۳۴ بایت محدود می‌شود (مگر اینکه OP_RETURN باشد که تا ۸۳ بایت مجاز است).
• اثر روی Bare Multisig: یک اسکریپت Bare Multisig (حتی مدل ۳ کلیدی استاندارد) بسیار بزرگتر از ۳۴ بایت است.
  • فرمول سایز: 1 byte (OP_M) + N * (33 or 65 bytes key) + 1 byte (OP_N) + 1 byte (OP_CHECKMULTISIG)
  • حتی یک Multisig ساده‌ی 1-of-2 با کلیدهای فشرده حدود ۷۰ بایت فضا می‌گیرد.
  • بنابراین، با اعمال BIP-444، هر تراکنشی که حاوی خروجی Bare Multisig باشد، توسط نودها نامعتبر (Invalid) شناخته شده و ریجکت می‌شود.

۲. وضعیت Bare Multisig؛ از منسوخ شدن تا «پالیسی» نودها

روش Bare Multisig از نظر فنی هیچ‌گاه به طور کامل از پروتکل بیت‌کوین «حذف» نشده بود، اما سال‌هاست که Deprecated (منسوخ شده) محسوب می‌شود.

• سال ۲۰۱۲ (BIP-16 – P2SH): با معرفی P2SH (آدرس‌های شروع شده با 3)، توصیه شد که اسکریپت‌های پیچیده مثل Multisig درون یک هش قرار بگیرند و مستقیم در خروجی (UTXO set) نباشند. این اولین گام برای منسوخ کردن Bare Multisig بود.
• قوانین استاندارد (Standardness Rules): توسعه‌دهندگان Bitcoin برای جلوگیری از سنگین شدن UTXO Set، در کد نودها (بخش IsStandard) محدودیتی اعمال کردند که Bare Multisig را فقط تا ۳ کلید مجاز می‌دانست. هر چیزی بیشتر از آن (مثلاً ۲۰ کلید) اگرچه از نظر اجماع معتبر بود، اما توسط نودها Relay (بازنشر) نمی‌شد.

۳. دیتا روی Bare Multisig؛ ظرفیت‌ها و تکنیک‌ها

استفاده از Bare Multisig برای دیتا (مثل کاری که پروتکل‌های اولیه Counterparty یا برخی اینسکریپشن‌های مدرن انجام می‌دهند) به این صورت است که به جای کلید عمومی واقعی، «دیتا» قرار می‌دهند.

حداکثر دیتای قابل ذخیره‌سازی:

• روش استاندارد (Standard Relay):
  • سقف مجاز در این حالت ۳ کلید است. اگر از کلیدهای ۶۵ بایتی (غیرفشرده) استفاده کنید، ظرفیتی حدود ۱۹۵ بایت به دست می‌آورید (البته مقداری از این فضا صرفِ سربار اسکریپت می‌شود).
• روش ماینری (Non-Standard / Miner Coordinated):
  • اگر بتوانید با یک ماینر هماهنگ کنید که تراکنش شما را مستقیماً در بلاک بگنجاند (چون این نوع تراکنش‌ها توسط نودهای معمولی در شبکه پخش نمی‌شوند)، قادر خواهید بود از سقف محدودیت‌های اجماع (Consensus) استفاده کنید. از آنجا که OP_CHECKMULTISIG در لایه اجماع تا ۲۰ کلید را می‌پذیرد، می‌توان به ظرفیتی حدود ۱۳۰۰ بایت (۲۰ کلید ۶۵ بایتی) در هر خروجی دست یافت. البته توجه داشته باشید که این روش بسیار گران است و به ندرت استفاده می‌شود.

فرمت کلیدها (۳۳ بایتی vs ۶۵ بایتی):

در Bare Multisig شما می‌توانید فرمت کلید را انتخاب کنید:

1. ۳۳ بایتی (Compressed): با 02 یا 03 شروع می‌شود. دیتای کمتری جا می‌گیرد اما ارزان‌تر است.
2. ۶۵ بایتی (Uncompressed): با 04 شروع می‌شود. این فرمت برای ذخیره دیتا محبوب‌تر است چون در هر اسلات کلید، دیتای خام بیشتری (۶۴ بایت پی‌لود خالص) جا می‌شود.

۴. تکنیک «فیک پابلیک‌کی» (Fake PubKey) چیست؟

شما نمی‌توانید هر دیتایی را دقیقاً به جای کلید بگذارید.Fake PubKey رشته‌ای از بایت‌هاست که داده‌ی دلخواه را حمل می‌کند، و با تکنیک‌هایی مثل grinding طوری تنظیم شده که معادله secp256k1 را برآورده کرده و به‌عنوان یک نقطه معتبر روی منحنی شناخته شود.

چرا باید معتبر باشد؟

حتی اگر قرار نیست آن خروجی خرج شود، قوانین بیت‌کوین چک می‌کنند که آیا کلیدها فرمت معتبری دارند یا خیر. اگر دیتای شما دقیقاً روی منحنی صدق نکند، اسکریپت خطا می‌دهد.

نحوه ساخت (Grinding):

برای اینکه دیتای دلخواه (مثلاً متن “Hello World”) را به یک کلید تبدیل کنند، از روشی به نام Grinding استفاده می‌شود:

1. دیتا را برمی‌دارند.
2. یک شمارنده (Nonce) یا مقداری پدینگ (Padding) به آن اضافه می‌کنند.
3. چک می‌کنند آیا این رشته بایت، فرمول y^2 = x^3 + 7 را ارضا می‌کند؟
4. اگر نه، شمارنده را تغییر می‌دهند و دوباره چک می‌کنند.
5. این کار میلیون‌ها بار تکرار می‌شود تا بالاخره ترکیبی پیدا شود که هم دیتای شما را داشته باشد و هم از نظر ریاضی یک “Public Key” معتبر باشد.

نکته: کسی که این کلید را می‌سازد، Private Key متناظر با آن را ندارد. بنابراین پول‌هایی که به این اسکریپت ارسال می‌شوند عملاً سوزانده (Burn) می‌شوند، مگر اینکه کلیدهای دیگر در Multisig واقعی باشند.

این متن بازنویسی شده با ساختاری منسجم‌تر، لحنی روان‌تر و دسته‌بندی دقیق‌تر است تا تفاوت میان Policy (قوانین سلیقه‌ای نودها) و Consensus (قوانین اجماع شبکه) کاملاً شفاف شود.

۵. تفاوت محدودیت ۳ کلید در برابر ۲۰ کلید (Policy vs. Consensus)

سوال اصلی اینجاست: آیا در نهایت می‌توانیم فقط ۳ کلید داشته باشیم یا ۲۰ تا؟ پاسخ در درک تفاوت میان قوانین Policy و Consensus نهفته است.

در کد نودهای بیت‌کوین، تابعی به نام IsStandard() وجود دارد که نقش یک فیلتر اولیه را بازی می‌کند. این تابع یک قانون سخت‌گیرانه برای اسکریپت‌های نوع Bare Multisig (که مستقیماً از OP_CHECKMULTISIG استفاده می‌کنند) دارد: اگر اسکریپت از نوع Bare Multisig باشد (یعنی مستقیم OP_CHECKMULTISIG باشد)، تعداد کلیدها نباید بیشتر از ۳ باشد.

بدین ترتیب اگر شما یک تراکنش با ۱۹ یا ۲۰ کلید بسازید و به شبکه بفرستید، نودها آن را به عنوان “Non-Standard” دور می‌ریزند و به همسایگان خود نمی‌فرستند.

محدودیت ۳ کلید فقط یک قانون Policy بین نودهاست، نه یک قانونِ Consensus غیرقابل‌نقضِ شبکه.

اگر شما بتوانید تراکنش ۲۰ کلیدی خود را (بدون پخش در شبکه) مستقیماً به یک ماینر یا استخر استخراج (مثل F2Pool) برسانید، آن‌ها تراکنش را مستقیماً در بلاک خود قرار می‌دهند. وقتی این بلاک ساخته و به شبکه ارسال شود، سایر نودها مجبورند آن را بپذیرند.

چون در سطح «اجماع» (Consensus)، محدودیت قدیمی تا ۲۰ کلید (Legacy Limit) مجاز است. نودها حق دارند این تراکنش را در Mempool خود نگه ندارند، اما اگر درون یک بلاک معتبر قرار گیرد، طبق قوانین اجماع باید آن را تایید کنند.

این محدودیت به ساختار دستوری OP_CHECKMULTISIG در کدهای قدیمی بیت‌کوین برمی‌گردد. محدودیت فنی دستورات در آن زمان اجازه بررسی بیش از ۲۰ امضا (Signature) را نمی‌داد؛ بنابراین سقف اجماع روی ۲۰ تنظیم شده بود، هرچند نودها برای جلوگیری از اسپم، فیلتر سخت‌گیرانه‌تری (همان ۳ کلید) را در ورودی خود اعمال کردند.

۶. STAMPS؛ دلیل اصلی جنگ علیه Bare Multisig

در Bitcoin Stamps (SRC-20) برخلاف Ordinals که دیتا را در بخش Witness ذخیره می‌کند، استمپ‌ها دیتا را در UTXO Set (غیرقابل هرس) ذخیره می‌کنند که باعث پر شدن RAM نودها می‌شود.

مکانیزم استمپ‌ها از یک ساختار 1-of-3 در Bare Multisig استفاده می‌کنند:

1. کلید اول: کلید واقعی برای انتقال مالکیت.
2. کلید دوم و سوم: فیک پابلیک‌کی‌هایی که حاوی دیتای تصویر هستند.

نتیجه‌گیری: سافت‌فورک BIP-444 پایان قطعی بازی موش و گربه بین بیت‌کوینرها و کسانی است که می‌خواهند دیتا روی لایه یک ذخیره کنند. با تصویب این طرح Bare Multisig برای همیشه به تاریخ می‌پیوندد.

منابع:

• BIP-444 (BIP-110):
  • https://bip444.github.io
• Bare Multisig:
  • https://medium.com/@bitaps.com/exploring-bitcoin-signing-bare-multisig-input-bf0771384893
• P2SH multisig Vs Bare multisig:
  • https://www.reddit.com/r/Bitcoin/comments/32zcpl/difference_between_p2sh_multisig_and_bare
• Bare Multisig deprecated:
  • https://x.com/Ali2kCom/status/1998868565311762586