شرط خرج دقیقاً کجا نوشته میشود و گره چگونه آن را میخواند؟ از اجرای یک اسکریپت به دامنهٔ امضا و سپس تفاوت پیشنهاد، نرمافزار و قاعدهٔ فعال میرسیم.
مطالب مرتبط: دستهٔ ۳، دستهٔ ۶، دستهٔ ۸، دستهٔ ۹
مفاهیم این بخش: شرط خرج، چندامضایی، قفل زمانی مطلق و نسبی، تراکنش نیمهامضاشده، سگویت، شنور، تپروت، سافتفورک، هاردفورک، پیشنهاد بهبود، فعالسازی، اعتبارسنجی مستقل
هدف توضیح: تفکیک قابلیت کیف پول، قالب امضا، قاعدهٔ اجماع و پیشنهاد هنوز فعالنشده.
اسکریپت بیتکوین چه چیزی را کنترل میکند؟
خروجی تراکنش فقط مقدار بیتکوین ندارد؛ شرطی هم دارد که خرج بعدی باید آن را برآورده کند. اسکریپت زبان بیان و بررسی این شرطهاست. شرط ساده میتواند ارائهٔ امضای معتبر برای کلید مشخص باشد. شرط چندامضایی ممکن است دو امضا از مجموعهٔ سه کلید بخواهد؛ داشتن فقط یکی از آن کلیدها کافی نیست. گره، دادهٔ خرج را در برابر شرط خروجی ارزیابی میکند، نه در برابر نام، نیت یا توضیح شفاهی صاحب کیف پول. راهنمای شروط تراکنش
برای مثال، توافق سه نفر دربارهٔ «خرج مشترک» تا وقتی در ساختار واقعی کنترل وجه منعکس نشده باشد، قاعدهای قابلاجرا برای شبکه نیست. از سوی دیگر، اسکریپت قرارداد حقوقی یا داور کیفیت کالا نیست: معتبرشدن خرج، تحویل درست کالا را ثابت نمیکند. برای آشنایی با نام دستورها میتوان صفحهٔ اسکریپت در ویکی جامعه را خواند؛ این واژهنامهٔ مشارکتی جای مشخصات فنی و بررسی قواعد اجرایی را نمیگیرد.
قفل زمانی مطلق و نسبی چه تفاوتی دارند و آیا خودشان وجه را منتقل میکنند؟
قفل مطلق خرج را به رسیدن به یک آستانهٔ ارتفاع بلاک یا زمان وابسته میکند. شرطی مانند «پس از این آستانه، همراه با امضای معتبر» با دستور OP_CHECKLOCKTIMEVERIFY قابل بیان است. صرف تنظیم زمان روی یک تراکنش با قفلکردن همهٔ راههای خرج یک خروجی یکسان نیست؛ باید خود شرط خروجی نیز محدودیت موردنظر را الزام کند. مشخصات قفل مطلق
قفل نسبی مدت انتظار را نسبت به تأیید خروجیِ مورد استفاده میسنجد، نه یک تاریخ ثابت جهانی. BIP 68 معنای نسبیِ مشخصی برای فیلد توالی ورودی تعریف میکند. شمارش بلاک و سنجش زمان قواعد متفاوت دارند و ساعت تلفن معیار نهایی نیست. مشخصات قفل نسبی هیچیک از این قفلها «دستور پرداخت خودکار در سررسید» نیستند. پس از فراهمشدن شرط زمانی، هنوز تراکنش معتبر، امضاهای لازم، انتشار و تأیید نیاز است. مثال مفهومی، مسیر بازیابی با تأخیر است؛ طراحی عملی آن بدون بررسی دقیق میتواند وجه را برای همیشه غیرقابلخرج کند.
تراکنش نیمهامضاشده چیست و چرا برای امضای آفلاین مفید است؟
قالب PSBT ظرفی برای انتقال تراکنش و اطلاعات لازم میان سازنده، تکمیلکننده و امضاکننده است. همهٔ این نقشها لازم نیست در یک دستگاه باشند. رایانهٔ برخط میتواند پیشنهاد تراکنش را آماده کند و دستگاه دیگری پس از بررسی، امضای لازم را اضافه کند. در چندامضایی نیز امضاها میتوانند جداگانه گردآوری شوند و سپس تراکنش نهایی از بسته بیرون گرفته شود. «نیمهامضاشده» نام قالب است؛ فایل ممکن است هنوز هیچ امضایی نداشته باشد. تعریف و نقشهای قالب
این جداسازی، نیاز به اعتماد کورکورانه به پیشنهاد تراکنش را از بین نمیبرد. امضاکننده باید بتواند مقصد، مبلغ، کارمزد و خروجی برگشتی را درست بررسی کند. فایل ممکن است اطلاعات حساس دربارهٔ ورودیها و مسیرهای کلید داشته باشد و نباید صرفاً به دلیل نداشتن کلید خصوصی، عمومی تلقی شود. دریافت یک فایل از «پشتیبانی» نیز دلیل موجهی برای امضای آن نیست؛ امضا باید پیامد مشخص و فهمیدهشده داشته باشد. الزامات امضاکننده
سگویت چه چیزی را تغییر داد و چرا برای پروتکلهای خارج از زنجیره مهم است؟
سگویت دادهٔ شاهد، از جمله دادههای لازم برای اثبات مجازبودن خرج، را در ساختاری جدا قرار داد و راه تعهد بلاک به آن را تعریف کرد. این داده حذف نمیشود؛ برای اعتبارسنجی همچنان لازم است. تفاوت مهم، جداشدن دادهٔ شاهد از محاسبهٔ شناسهٔ متعارف تراکنش در قالب سگویت است. در شرایط تعریفشده، تغییر غیرارادی دادهٔ امضا دیگر شناسهای را که تراکنش بعدی به آن ارجاع میدهد عوض نمیکند. مشخصات سگویت
این موضوع برای ساخت زنجیرهای از تراکنشهای ازپیشآمادهشده، مانند سازوکارهای کانال، مهم است: ارجاع به خروجی قبلی باید پایدار بماند. سگویت همچنین محاسبهٔ وزن را تعریف کرد که دادهٔ پایه و شاهد را با وزن یکسان نمیشمارد. نباید از آن نتیجه گرفت هر پرداخت سگویت حتماً کارمزد کمتری دارد یا همهٔ انواع تغییرپذیری تراکنش ناپدید شدهاند. تعداد و نوع ورودیها، خروجیها و نرخ کارمزد همچنان مؤثرند؛ مزیت فنی را باید با شرایط آن بیان کرد. انگیزه و قواعد وزن
شنور و تپروت یک چیزند و آیا همهٔ پرداختها را خصوصی میکنند؟
شنور در BIP 340 طرح امضاست: روش دقیق ساخت و بررسی امضا با ویژگیهایی که ساخت پروتکلهای امضای مشترک را تسهیل میکند. این ویژگی به معنای ادغام خودکار همهٔ امضاهای هر تراکنش نیست؛ سازوکارهای بالاتر و پیادهسازی درست لازماند. مشخصات امضای شنور
تپروت در BIP 341 ساختار خرج خروجی را تعریف میکند. خرج میتواند از مسیر کلید انجام شود یا یکی از مسیرهای اسکریپت و مدرک مربوط به آن آشکار شود. در حالت همکاری مناسب، مسیر کلید میتواند جزئیات شرطهای استفادهنشده را پنهان نگه دارد؛ در خرج اسکریپتی نیز لازم نیست همهٔ شاخهها آشکار شوند. مشخصات تپروت بااینحال، این به معنای پنهانشدن مبلغ، ارتباط همهٔ تراکنشها یا هویت شبکهای کاربر نیست. شنور ابزار امضاست و تپروت سازوکار استفاده از کلید و شرطهای جایگزین؛ هیچکدام برچسب تضمین ناشناسی نیستند.
سافتفورک و هاردفورک چه تفاوتی با بهروزرسانی معمولی نرمافزار دارند؟
بهروزرسانی نرمافزار ممکن است فقط رابط یا عملکرد را اصلاح کند. تغییر اجماع به قواعد اعتبار بلاک مربوط است. سافتفورک محدودیت میافزاید: بلاکِ مطابق قواعد تازه با قواعد قدیمی سازگار است، ولی گره قدیمی الزام تازه را بررسی نمیکند. هاردفورک میتواند بلاکی را معتبر بداند که قواعد قدیمی رد میکنند. توضیح تغییر قواعد
مثال آموزشی: سختترکردن شرط پذیرش با مجازکردن امرِ پیشتر ممنوع جهت یکسانی ندارد. اما نام «سافت» بهتنهایی بیخطربودن را ثابت نمیکند و «هارد» نیز وقوع دو زنجیرهٔ ماندگار را تضمین نمیکند. برای خواندن خبر ارتقا، دو سؤال جدا بپرسید: دقیقاً کدام قاعده تغییر میکند و چه کسانی آن را اجرا میکنند؟ نام نسخه یا تعداد قابلیتهای رابط، پاسخ هیچکدام نیست.
داشتن شمارهٔ پیشنهاد بهبود بیتکوین چه چیزی را ثابت میکند؟
پیشنهاد بهبود بیتکوین، یا BIP، سندی برای بیان و بررسی ایده است. همهٔ پیشنهادها دربارهٔ اجماع نیستند؛ بعضی قالب کاربردی، رابط یا فرایند همکاری را شرح میدهند. شمارهگرفتن و انتشار در مخزن به معنای تصویب عمومی، توصیهٔ رسمی یا فعالشدن در شبکه نیست. فرایند مستندشده در BIP 3 میان پیشنهاد نویسنده، تکمیل مشخصات و شواهد استفاده تمایز میگذارد؛ دبیران مخزن مرجع تحمیل ارتقا به کاربران نیستند. فرایند پیشنهادها
برای ارزیابی ادعای «این قابلیت به بیتکوین اضافه شد»، فقط عنوان خبر را نخوانید. موضوع سند، وضعیت آن، پیادهسازی مربوط و در صورت تغییر اجماع، شواهد فعالسازی را جداگانه بررسی کنید. یک قابلیت ممکن است در نرمافزار آزمایشی وجود داشته باشد اما روی شبکهٔ اصلی قابل استفاده نباشد. همچنین فعالشدن یک قاعده به معنای پشتیبانی فوری همهٔ کیف پولها از رابط و امکانات آن نیست؛ اینها مراحل متفاوتاند.
چه کسی قواعد بیتکوین را تعیین میکند و چرا تعداد گرهها رأی نیست؟
هر گرهٔ کامل بلاکها را با قواعدی که اجرا میکند میسنجد و از میان زنجیرههای معتبر، زنجیره با کار انباشتهٔ بیشتر را دنبال میکند. بنابراین یک زنجیرهٔ نامعتبر صرفاً با زیادشدن تعداد فرستندگانش معتبر نمیشود. از همین سازوکار نتیجه میگیریم شمارش نشانیهای شبکه، صندوق رأیِ اجماع نیست؛ یک فرد میتواند چند گره داشته باشد و بخشی از گرهها نیز در شمارش عمومی دیده نشوند. اعتبارسنجی و انتخاب زنجیره
توسعهدهنده کد پیشنهاد میکند، نگهدارنده دربارهٔ مخزن تصمیم میگیرد، استخراجکننده بلاک میسازد و کاربر دربارهٔ نرمافزار و قواعد پذیرفتهشدهٔ خودش انتخاب میکند. هیچکدام از این نقشها بهتنهایی معادل کنترل بیقید شبکه نیست. فرایند پیشنهادها نیز هیئت مرکزی تصویب ندارد. حدود فرایند پیشنهادها البته تصمیمها اثر اقتصادی و هماهنگی متقابل دارند؛ امکان رد یک تغییر به معنای تضمین همراهی دیگران نیست. سیگنال استخراج نیز اگر در روش فعالسازی نقش داشته باشد، مجوز عمومی تغییر دلخواه قواعد نیست.
گره چگونه شرط خرج را اجرا میکند؟ یک اسکریپت را قدمبهقدم بخوانیم
پشته را مانند دستهای برگه تصور کنید: هر دادهٔ تازه روی آن مینشیند و هر دستور، عمل مشخصی روی بالای پشته انجام میدهد. این تشبیه برای دنبالکردن ترتیب است؛ در پیادهسازی، اقلام پشته رشتههای بایتاند. اسکریپت خروجیِ قبلی، scriptPubKey، شرط را تعیین میکند؛ اسکریپت ورودیِ خرج جدید، scriptSig، در نمونهٔ قدیمی P2PKH امضا و کلید عمومی را روی پشته میگذارد. این دو فیلد در دو جای متفاوتاند و هنگام بررسی، بهترتیب اجرا میشوند. اجرای شرط خرج
مثال فرضی: S دادهٔ امضا، K کلید عمومی و h هش کلیدی است که قبلاً در خروجی ثبت شده. این حروف دادهٔ قابلخرج نیستند. برنامهٔ خروجی چنین است: OP_DUP OP_HASH160 <h> OP_EQUALVERIFY OP_CHECKSIG. نامهای دستور، نمایش خوانا هستند؛ هر نام عیناً بهصورت حروف لاتین روی زنجیره ذخیره نمیشود. دستورها و قالب اسکریپت
در جدول، پشته از چپ به راست، از پایین به بالا نوشته شده و ترتیبش با جهت نثر فارسی عوض نمیشود. اجرای دستورهای جدول در بیتکوین کور
| گام | اثر | پشته پس از گام |
|---|---|---|
| دادههای ورودی | امضا، سپس کلید روی پشته قرار میگیرد | [S, K] |
| OP_DUP | بالاترین قلم را تکثیر میکند | [S, K, K] |
| OP_HASH160 | نسخهٔ بالاییِ کلید را هش میکند | [S, K, HASH160(K)] |
| قراردادن h | هش مقرر در شرط خرج را اضافه میکند | [S, K, HASH160(K), h] |
| OP_EQUALVERIFY | دو هش را برمیدارد؛ نابرابری اجرا را ناموفق میکند | اگر برابر باشند: [S, K] |
| OP_CHECKSIG | امضا را با کلید و پیام تراکنش بررسی میکند | در نمونهٔ موفق: «درست» |
اینجا HASH160 یعنی ابتدا SHA256 و سپس RIPEMD160. تکثیر کلید لازم است تا یک نسخه برای تطبیق هش مصرف شود و نسخهٔ دیگر برای بررسی امضا بماند. معنای دستورهای نمونه
دو دستکاری فرضی: اگر کسی کلید خودش را همراه امضای درستِ خودش بگذارد، تطبیق هش در شرط متعلق به کلید دیگر شکست میخورد. اگر همان کلید عمومیِ مورد انتظار را کپی کند ولی امضای سازگار نداشته باشد، از تطبیق هش میگذرد و در بررسی امضا شکست میخورد. دو آزمون دو کار دارند: یکی انتخاب کلید مقرر، دیگری بررسی اجازه برای پیام مشخص. برای مفهوم «پیام مشخص» به پرسش بعد بروید.
این ردگیری متعلق به P2PKH است. در خرج بومی P2WPKH، امضا و کلید در شاهد قرار دارند و scriptSig خالی است؛ بنابراین جدول را نباید نقشهٔ محل فیلدها در همهٔ انواع خرج دانست. قواعد خرج سگویت؛ جایگاه دادهٔ شاهد
امضا چگونه به یک پیام گره میخورد و چرا «امضای معتبر» برای هر تغییر تراکنش معتبر نمیماند؟
امضا کپیِ رمزشدهٔ کلید خصوصی نیست. برای دیدن سازوکار، اسکلت ریاضی شنور را بخوانیم: کلید عمومی P = dG است. امضاکننده از مقدار یکبارمصرف، نقطهٔ R = kG میسازد؛ چالش e از هشِ دادههای مربوط به R، کلید عمومی و پیام به دست میآید. رابطهٔ امضا s = k + ed mod n است و بررسیکننده رابطهٔ متناظر sG = R + eP را میسنجد. راز d برای این بررسی لازم نیست. ساخت و بررسی امضای شنور
این طرح مفهومی است، نه دستور پیادهسازی: BIP340 انتخاب مقدار یکبارمصرف، هش برچسبدار، نمایش مختصات، زوجبودن مختصات عمودی و کنترل محدودهها را دقیق مشخص میکند. همچنین این فرمول شنور است، نه الگوریتم ECDSA در نمونهٔ اسکریپت قبلی. جزئیات لازم الگوریتم
اگر پیام عوض شود، چالش هم عوض میشود و همان امضا عموماً دیگر رابطه را برقرار نمیکند. اما کدام بخش تراکنش وارد پیام میشود؟ «نوع هش امضا» این دامنه را تعیین میکند. در SIGHASH_ALL خروجیها متعهد میشوند؛ SIGHASH_NONE به خروجیها تعهد نمیدهد. گزینهٔ ANYONECANPAY نیز دامنهٔ تعهد به ورودیها را تغییر میدهد. این نامها نوع اجازه را مشخص میکنند، نه قدرت بیشتر یا کمتر الگوریتم امضا. دامنهٔ تعهد امضا
آزمایش فرضی: ورودیای با ارزش ۱۰٬۰۰۰ ساتوشی خرج میشود؛ خروجی دریافتکننده ۶٬۰۰۰ و خروجی باقیمانده ۳٬۰۰۰ ساتوشی است. برای همان ورودی، با SIGHASH_ALL و بدون ANYONECANPAY امضا ساختهایم. حالا سه تغییر را جدا امتحان کنیم:
| تغییر فرضی پس از امضا | نتیجه برای همان امضا |
|---|---|
| تغییر خروجی دریافتکننده به ۵٬۰۰۰ و باقیمانده به ۴٬۰۰۰ | دیگر با پیام امضاشده سازگار نیست؛ برابرماندن جمع کافی نیست |
| حفظ مبالغ و عوضکردن اسکریپت مقصد | سازگار نیست؛ تعهد خروجی هم مبلغ را پوشش میدهد، هم اسکریپت را |
| عوضکردن نام نمایشی دریافتکننده در دفترچهٔ محلی | اگر بایتهای متعهدشده تغییر نکنند، پیام امضا عوض نشده است |
در سگویت نسخهٔ صفر، پیام امضا طبق BIP143 از فیلدهای معین ساخته میشود؛ از جمله مبلغ خروجیِ خرجشونده و، در حالت این مثال، هش خروجیهای جدید. بررسیکننده همان پیام را بازسازی میکند. بنابراین نه تصویر صفحهٔ تأیید امضا میشود و نه نام مخاطب در دفترچه. دادههای پیام در سگویت نسخهٔ صفر
اگر فرض را به SIGHASH_NONE تغییر دهیم، تغییر خروجیها میتواند همان امضا را معتبر نگه دارد؛ البته امضاهای دیگر و قواعد تراکنش هم باید برقرار باشند. در تپروت، ساخت پیام قواعد جداگانه دارد و SIGHASH_DEFAULT دامنهای مانند SIGHASH_ALL دارد. پس برای فهم اجازهٔ یک امضا، هم نوع خرج و هم دامنهٔ تعهد آن را باید شناخت. دامنههای امضا؛ پیام امضای تپروت
مثال توضیحی: شمارهٔ یک پیشنهاد، شناسهٔ سند است و فعالشدن آن را نشان نمیدهد. همچنین گرهٔ قدیمی همهٔ الزامهای تازهٔ یک سافتفورک را مستقلاً نمیسنجد. این تفاوتها نشان میدهند سند، نرمافزار و قواعدی که یک گره واقعاً اجرا میکند سه چیز مرتبط اما متفاوتاند.