مجوز خرج، اسکریپت و Taproot
فصلهای کتاب · ۹۹ پرسش
کلید، seed و عبارت بازیابی همهٔ مثالهای منتشرشده عمومیاند؛ هرگز برای پول واقعی استفاده نشوند. این مجموعه و کدهایش پیادهسازی تولیدی کیف پول یا مرجع مستقل اجماع نیستند.
اسکریپت بیتکوین چه چیزی را اثبات میکند؟
مجوز خرج و مدل اجرای Script
بررسی میکند دادههای ارائهشده، شروط خرج یک خروجی را در زمینه تراکنش برآورده میکنند یا نه. این نتیجه نه هویت حقوقی امضاکننده را ثابت میکند و نه بهتنهایی اعتبار کل تراکنش را.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:2–24ch07_authorization-authentication.adoc:25–58ch07_authorization-authentication.adoc:59–74ch07_authorization-authentication.adoc:75–89
چرا داشتن کلید خصوصی همیشه برای خرج کافی نیست؟
مجوز خرج و مدل اجرای Script
ممکن است خروجی چند امضا، گذشت زمان، افشای یک راز یا ترکیبی از آنها را بخواهد. کلید فقط یکی از شروط احتمالی مجوز خرج است.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:2–24ch07_authorization-authentication.adoc:25–58ch07_authorization-authentication.adoc:59–74ch07_authorization-authentication.adoc:75–89
چرا Script حلقه دلخواه ندارد؟
مجوز خرج و مدل اجرای Script
نبود حلقه نامحدود و وجود محدودیتهای اجرایی، هزینه اعتبارسنجی را قابلکنترل میکند؛ در غیر این صورت مهاجم میتوانست گرهها را گرفتار محاسبه پایانناپذیر کند.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:2–24ch07_authorization-authentication.adoc:25–58ch07_authorization-authentication.adoc:59–74ch07_authorization-authentication.adoc:75–89
آیا تورینگکامل نبودن یعنی قرارداد پیچیده نمیتوان ساخت؟
مجوز خرج و مدل اجرای Script
خیر. ترکیب امضا، هش، شرط و زمان برای بسیاری از سیاستهای مالی کافی است. محدودیت اصلی، محاسبه عمومی و دسترسی دلخواه به وضعیت است، نه نبود هر نوع منطق قراردادی.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:2–24ch07_authorization-authentication.adoc:25–58ch07_authorization-authentication.adoc:59–74ch07_authorization-authentication.adoc:75–89
«بیحالت بودن» Script چه معنایی دارد؟
مجوز خرج و مدل اجرای Script
اجرای یک اسکریپت، حافظه ماندگار خصوصی از اجراهای گذشته ندارد. وضعیت خرجشدن خروجیها را گره از مجموعه UTXO و زنجیره میگیرد؛ بیحالت بودن اسکریپت به معنای بیحالت بودن بیتکوین نیست.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:2–24ch07_authorization-authentication.adoc:25–58ch07_authorization-authentication.adoc:59–74ch07_authorization-authentication.adoc:75–89
آیا Script مستقیماً قیمت بازار یا نتیجه مسابقه را میداند؟
مجوز خرج و مدل اجرای Script
خیر. چنین واقعیتهایی در ورودیهای اجماع وجود ندارند. اتصال پرداخت به آنها به سازوکاری مانند امضای اوراکل نیاز دارد و اعتماد به منبع خبر را وارد طراحی میکند.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:2–24ch07_authorization-authentication.adoc:25–58ch07_authorization-authentication.adoc:59–74ch07_authorization-authentication.adoc:75–89
پشته در Script چگونه کار میکند؟
پشته، داده و نتیجه اجرا
دادهها روی پشته قرار میگیرند و معمولاً آخرین داده واردشده زودتر مصرف میشود. بنابراین ترتیب آرگومانها بخشی از معنای برنامه است، نه صرفاً شیوه نمایش آن.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:90–135ch07_authorization-authentication.adoc:136–157ch07_authorization-authentication.adoc:158–236ch07_authorization-authentication.adoc:237–259
تفاوت opcode با داده چیست؟
پشته، داده و نتیجه اجرا
opcode دستور اجراست؛ داده، بایتهایی است که دستورها مصرف میکنند. دستور push مشخص میکند بایتهای بعدی باید داده تلقی شوند، نه دستور مستقل.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:90–135ch07_authorization-authentication.adoc:136–157ch07_authorization-authentication.adoc:158–236ch07_authorization-authentication.adoc:237–259
چرا نمایش یک عدد در Script میتواند با نمایش همان عدد در تراکنش فرق کند؟
پشته، داده و نتیجه اجرا
فیلدهای تراکنش و اعداد پشته قالبهای جداگانه دارند. اعداد Script معمولاً با نمایش little-endian و علامت در بیت بالایی بایت آخر تفسیر میشوند؛ قالب را باید از زمینه تشخیص داد.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:90–135ch07_authorization-authentication.adoc:136–157ch07_authorization-authentication.adoc:158–236ch07_authorization-authentication.adoc:237–259
چه مقدارهایی در تبدیل بولی Script نادرست هستند؟
پشته، داده و نتیجه اجرا
بردار خالی، نمایشهای صفر و «صفر منفی» نادرستاند. در مقابل، برای ورودی شرط در Tapscript محدودیت سختگیرانهتری وجود دارد: فقط بردار خالی یا بایت
01پذیرفته میشود.منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:90–135ch07_authorization-authentication.adoc:136–157ch07_authorization-authentication.adoc:158–236ch07_authorization-authentication.adoc:237–259
چرا اسکریپت «۲ و ۳ را جمع کن و با ۵ مقایسه کن» حفاظت مالی ایجاد نمیکند؟
پشته، داده و نتیجه اجرا
چون هیچ راز یا اختیار انحصاری نمیخواهد؛ هر شخص میتواند همان محاسبه را انجام دهد. درستشدن یک عبارت با احراز اختیار خرج تفاوت دارد.
تصویر 0702اجرای پشتهای یک عبارت ساده نمونهٔ پشتهای برای فهم ترتیب عملیات است، نه یک قرارداد آمادهٔ استفاده.
Mastering Bitcoin, third edition; Andreas M. Antonopoulos and David A. Harding. Original image, unchanged.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:90–135ch07_authorization-authentication.adoc:136–157ch07_authorization-authentication.adoc:158–236ch07_authorization-authentication.adoc:237–259
آیا scriptSig و scriptPubKey واقعاً به یک برنامه واحد چسبانده میشوند؟
پشته، داده و نتیجه اجرا
این تصویر فقط توضیحی است. در خرج قدیمی، هرکدام جداگانه اجرا میشوند و پشته اصلی منتقل میشود؛ وضعیت اجرایی شرطها منتقل نمیشود. P2SH و witness نیز مراحل اعتبارسنجی اختصاصی دارند.
تصویر 0701ارتباط دادهٔ بازکردن قفل و شرط خرج تصویر ترکیب منطقی را آموزش میدهد؛ اجرای واقعی scriptSig و scriptPubKey زمینهها و قواعد جدا دارد.
Mastering Bitcoin, third edition; Andreas M. Antonopoulos and David A. Harding. Original image, unchanged.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:90–135ch07_authorization-authentication.adoc:136–157ch07_authorization-authentication.adoc:158–236ch07_authorization-authentication.adoc:237–259
آیا رسیدن بدون خطا به انتهای اسکریپت کافی است؟
پشته، داده و نتیجه اجرا
خیر. نتیجه نهایی باید شرایط صدق پشته را برآورده کند. در خرجهای witness معمولی، یک عنصر درست باید باقی بماند؛ صرف اجراشدن دستورها به معنای موفقیت نیست.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:90–135ch07_authorization-authentication.adoc:136–157ch07_authorization-authentication.adoc:158–236ch07_authorization-authentication.adoc:237–259
چرا باقیماندن داده اضافه روی پشته مهم است؟
پشته، داده و نتیجه اجرا
ممکن است نشان دهد برنامه آرگومانها را درست مصرف نکرده است. الزام clean stack در زمینههای مربوط، این ابهام را محدود میکند؛ اما حتی یک عنصر درست باقیمانده هم میتواند محصول یک منطق معیوب باشد.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:90–135ch07_authorization-authentication.adoc:136–157ch07_authorization-authentication.adoc:158–236ch07_authorization-authentication.adoc:237–259
مسیر بررسی P2PKH چیست؟
پرداخت به هش کلید عمومی
اسکریپت، کلید عمومی ارائهشده را کپی و هش میکند، تطابق آن با هش مقصد را الزام میکند و سپس امضا را با همان کلید بررسی میکند. بنابراین هم تطابق کلید و هم اجازه خرج لازم است.
تصویر 0703اجرای P2PKH، بخش نخست دادهٔ ورودی و شرط خروجی بهترتیب بررسی میشوند؛ مسیر تصویر مخصوص P2PKH است.
Mastering Bitcoin, third edition; Andreas M. Antonopoulos and David A. Harding. Original image, unchanged.
تصویر 0704اجرای P2PKH، بخش دوم درستبودن نتیجهٔ اسکریپت بهتنهایی کافی نیست؛ کل تراکنش باید دیگر قواعد اجماع را هم رعایت کند.
Mastering Bitcoin, third edition; Andreas M. Antonopoulos and David A. Harding. Original image, unchanged.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:260–313
چرا در P2PKH کلید عمومی نیز کنار امضا لازم است؟
پرداخت به هش کلید عمومی
خروجی فقط هش کلید را دارد. گره باید ابتدا کلید واقعی را ببیند تا هش آن را تطبیق دهد و سپس امضا را با آن بررسی کند.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:260–313
اگر هش کلید درست باشد ولی امضا غلط باشد چه میشود؟
پرداخت به هش کلید عمومی
خرج نامعتبر است. دانستن یک کلید عمومی، توان ساختن امضای معتبر را نمیدهد؛ تطابق هش فقط کلید مجاز را مشخص میکند.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:260–313
چرا OP_EQUALVERIFY با OP_EQUAL تفاوت امنیتی دارد؟
پرداخت به هش کلید عمومی
OP_EQUALنتیجه مقایسه را روی پشته میگذارد؛ ادامه برنامه ممکن است آن را نادیده بگیرد.OP_EQUALVERIFYدر صورت نابرابری فوراً اجرای اسکریپت را ناموفق میکند.منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:260–313
در چندامضایی ۲ از ۳ دقیقاً چه چیزی لازم است؟
چندامضایی قدیمی و دامهای آن
دو امضای معتبر متناظر با دو کلید از سه کلید مجاز لازم است. دو نسخه از امضای یک کلید مستقل، جای دو امضاکننده مجاز را نمیگیرد.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:314–384ch07_authorization-authentication.adoc:385–469
چرا ترتیب امضاها در CHECKMULTISIG اهمیت دارد؟
چندامضایی قدیمی و دامهای آن
تطبیق امضاها و کلیدها بهترتیب پیش میرود و کلیدهای ردشده دوباره بررسی نمیشوند. ترتیب ناسازگار میتواند مجموعهای از امضاهای جداگانه معتبر را در این اسکریپت نامعتبر کند.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:314–384ch07_authorization-authentication.adoc:385–469
حد ۲۰ کلید در CHECKMULTISIG چه تفاوتی با حد چندامضایی bare دارد؟
چندامضایی قدیمی و دامهای آن
اولی محدودیت اجرای opcode است؛ دومی محدودیت سیاست استاندارد بودن قالب bare در نسخههای مورد بحث است. سیاست معمول سه کلید bare را نباید حد عمومی اجماع برای تمام چندامضاییها دانست.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:314–384ch07_authorization-authentication.adoc:385–469
چرا CHECKMULTISIG یک عنصر اضافی از پشته میگیرد؟
چندامضایی قدیمی و دامهای آن
یک رفتار تاریخیِ خارج از شمارش صحیح آرگومانها در قواعد اجماع تثبیت شده است. خرجکننده باید عنصر dummy لازم را نیز فراهم کند؛ اصلاح ناسازگار این رفتار، خرجهای موجود را تغییر میداد.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:314–384ch07_authorization-authentication.adoc:385–469
عنصر dummy در CHECKMULTISIG چه مقداری باید داشته باشد؟
چندامضایی قدیمی و دامهای آن
طبق قاعده NULLDUMMY در زمینههای مربوط، باید بردار خالی باشد؛ معمولاً با
OP_0فراهم میشود. «یک مقدار بیاهمیت دلخواه» توصیف دقیقی از قاعده فعال نیست.اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:314–384ch07_authorization-authentication.adoc:385–469
چرا نمونه چندامضایی بدون dummy را نباید مستقیماً اجرا کرد؟
چندامضایی قدیمی و دامهای آن
ممکن است نمایش آموزشی، آرگومان تاریخی لازم را حذف کرده باشد. نمونه باید با قالب خرج، ترتیب پشته و قواعد فعال آزمایش شود؛ خوانا بودن نمودار، اعتبار اجرایی آن را ثابت نمیکند.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:314–384ch07_authorization-authentication.adoc:385–469
آیا چندامضایی لزوماً هویت یا تعداد افراد را اثبات میکند؟
چندامضایی قدیمی و دامهای آن
خیر. یک شخص ممکن است همه کلیدها را داشته باشد و یک کلید نیز ممکن است میان چند نفر به اشتراک گذاشته شده باشد. اسکریپت کلیدها را میبیند، نه ساختار سازمانی پشت آنها را.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:314–384ch07_authorization-authentication.adoc:385–469
P2SH چه هزینهای را از فرستنده به گیرنده منتقل میکند؟
P2SH و تعهد به سیاست خرج
فرستنده فقط به هش یک redeem script پرداخت میکند؛ خرجکننده بعداً خود اسکریپت و دادههای لازم را ارائه میدهد. پیچیدگی سیاست و بخش عمده داده خرج در زمان مصرف آشکار میشود.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:470–618ch07_authorization-authentication.adoc:619–641ch07_authorization-authentication.adoc:642–661ch07_authorization-authentication.adoc:662–688
چرا آدرس P2SH نوع دقیق قرارداد را آشکار نمیکند؟
P2SH و تعهد به سیاست خرج
آدرس هش اسکریپت را حمل میکند، نه متن آن را. پشت آن ممکن است چندامضایی، قفل زمانی یا برنامه witness تودرتو باشد؛ پیشوند بهتنهایی سیاست را مشخص نمیکند.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:470–618ch07_authorization-authentication.adoc:619–641ch07_authorization-authentication.adoc:642–661ch07_authorization-authentication.adoc:662–688
در خرج P2SH چه دو بررسی جداگانهای انجام میشود؟
P2SH و تعهد به سیاست خرج
ابتدا هش redeem script با تعهد خروجی تطبیق داده میشود؛ سپس همان اسکریپت با آرگومانهای ارائهشده اجرا میشود. دانستن متن اسکریپت بدون ارضای آن کافی نیست.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:470–618ch07_authorization-authentication.adoc:619–641ch07_authorization-authentication.adoc:642–661ch07_authorization-authentication.adoc:662–688
چرا scriptSig خرج P2SH باید push-only باشد؟
P2SH و تعهد به سیاست خرج
قواعد P2SH لازم میدانند scriptSig دادههای ورودی و redeem script را فراهم کند، نه برنامه اجرایی دلخواه را. این محدودیت بخشی از روش تفسیر امن و مشخصِ لایه دوم است.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:470–618ch07_authorization-authentication.adoc:619–641ch07_authorization-authentication.adoc:642–661ch07_authorization-authentication.adoc:662–688
آیا میتوان P2SH را با تودرتوکردن نامحدود هش اسکریپتها گسترش داد؟
P2SH و تعهد به سیاست خرج
خیر. بررسی ویژه P2SH یک قاعده مشخص است، نه فراخوانی بازگشتی خودکار برای هر هش مشابه. ظاهر شبیه P2SH درون یک اسکریپت، بهتنهایی مرحله ویژه دیگری ایجاد نمیکند.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:470–618ch07_authorization-authentication.adoc:619–641ch07_authorization-authentication.adoc:642–661ch07_authorization-authentication.adoc:662–688
چرا داشتن آدرس P2SH برای بازیابی کیف پول کافی نیست؟
P2SH و تعهد به سیاست خرج
هش، متن redeem script را قابلبازسازی نمیکند. کلیدها، ترتیب آنها و سیاست باید از بکاپ یا طرفهای قرارداد بازیابی شوند تا بتوان خروجی را خرج کرد.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:470–618ch07_authorization-authentication.adoc:619–641ch07_authorization-authentication.adoc:642–661ch07_authorization-authentication.adoc:662–688
چرا P2SH قدیمی معمولاً حداکثر ۱۵ کلید فشرده را در چندامضایی جا میدهد؟
P2SH و تعهد به سیاست خرج
redeem script هنگام خرج بهصورت یک عنصر پشته وارد میشود و سقف ۵۲۰ بایتی دارد. اسکریپت چندامضایی با ۱۶ کلید فشرده از این سقف عبور میکند، هرچند opcode در زمینههای دیگر تا ۲۰ کلید میپذیرد.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:470–618ch07_authorization-authentication.adoc:619–641ch07_authorization-authentication.adoc:642–661ch07_authorization-authentication.adoc:662–688
اگر به هش یک redeem script بیشازحد بزرگ پول بفرستیم چه خطری دارد؟
P2SH و تعهد به سیاست خرج
ساخت خروجی ممکن است ممکن باشد، اما ارائه آن اسکریپت در خرج P2SH از حد مجاز عبور کند. اعتبار خروجی در زمان دریافت تضمین نمیکند که سازنده سیاست، راه خرج قابلاستفادهای ساخته است.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:470–618ch07_authorization-authentication.adoc:619–641ch07_authorization-authentication.adoc:642–661ch07_authorization-authentication.adoc:662–688
چرا خروجی OP_RETURN معمولاً وارد مجموعه UTXO نمیشود؟
OP_RETURN و تعهد داده
اجرای آن آشکارا ناموفق است، پس خروجی قابلخرج نیست. گره میتواند آن را از وضعیت خرجنشده حذف کند، هرچند بایتهای تراکنش در تاریخچه بلاک باقی میمانند.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:689–759
آیا نوشتن یک هش در OP_RETURN یعنی خود فایل در بلاکچین ذخیره شده است؟
OP_RETURN و تعهد داده
خیر. هش فقط یک تعهد کوتاه به داده است. برای بررسی تطابق بعدی، اصل فایل باید جداگانه در دسترس باشد؛ از هش نمیتوان فایل را بازیابی کرد.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:689–759
آیا حد ۸۰ بایت OP_RETURN یک قانون همیشگی اجماع است؟
OP_RETURN و تعهد داده
خیر. این عدد به سیاست رله رایج در زمان کتاب مربوط است. برای مثال، Core 30.0 سیاست پیشفرض و امکان چند خروجی داده را تغییر داد؛ باید نسخه، تنظیم و تفاوت سیاست با اجماع مشخص شود.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:689–759
آیا بیتکوین فرستادهشده به خروجی غیرقابلخرج OP_RETURN قابلبازگشت است؟
OP_RETURN و تعهد داده
در چارچوب همان قواعد، خیر. مقدار آن همچنان بخشی از مجموع خروجیهاست و کارمزد محسوب نمیشود؛ اما شرطی برای خرج موفق آن وجود ندارد.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:689–759
چرا nLockTime بهتنهایی برای قفلکردن دریافتکننده کافی نیست؟
قفل زمانی مطلق در اسکریپت
nLockTime را سازنده تراکنش خرج انتخاب میکند. برای الزام تمام خرجها به رعایت حد زمانی، خود خروجی باید شرطی مانند CLTV داشته باشد تا خرجکننده نتواند آن را حذف کند.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:760–778ch07_authorization-authentication.adoc:779–893
CLTV دقیقاً چه چیزی را با چه چیزی مقایسه میکند؟
قفل زمانی مطلق در اسکریپت
آرگومان اسکریپت را با nLockTime تراکنش خرج مقایسه میکند، سازگاری نوع ارتفاع یا زمان را میخواهد و نهاییبودن sequence ورودی را نمیپذیرد. رسیدن زنجیره به حد زمانی نیز جداگانه بررسی میشود.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:760–778ch07_authorization-authentication.adoc:779–893
چرا بعد از CHECKLOCKTIMEVERIFY اغلب OP_DROP میآید؟
قفل زمانی مطلق در اسکریپت
CLTV در صورت موفقیت آرگومان زمان را از پشته حذف نمیکند. DROP آن را کنار میگذارد تا دستورهای بعدی آرگومان درست، مثلاً کلید و امضا، را مصرف کنند.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:760–778ch07_authorization-authentication.adoc:779–893
آیا CLTV میتواند زمان مبتنی بر ارتفاع را با timestamp مقایسه کند؟
قفل زمانی مطلق در اسکریپت
خیر. دو طرف باید از یک نوع باشند؛ مقادیر کمتر از ۵۰۰ میلیون ارتفاع و مقادیر بالاتر یا مساوی آن زمان تلقی میشوند. مقایسه صرفِ بزرگی عدد، جای تطابق نوع را نمیگیرد.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:760–778ch07_authorization-authentication.adoc:779–893
چرا sequence برابر 0xffffffff با الزام CLTV ناسازگار است؟
قفل زمانی مطلق در اسکریپت
چنین ورودیای نهایی محسوب میشود و میتواند اجرای قفل مطلق تراکنش را بیاثر کند. CLTV این راه دورزدن شرط زمانی خروجی را میبندد.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:760–778ch07_authorization-authentication.adoc:779–893
آیا خروجی با CLTV در زمان مقرر خودکار پرداخت میشود؟
قفل زمانی مطلق در اسکریپت
خیر. زمان فقط امکان معتبرشدن یک خرج را فراهم میکند. هنوز باید تراکنش ساخته، امضا، منتشر و در بلاک پذیرفته شود.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:760–778ch07_authorization-authentication.adoc:779–893
اگر nLockTime برابر ارتفاع H باشد، آیا درج در خود بلاک H مجاز است؟
قفل زمانی مطلق در اسکریپت
برای فعال بودن قفل، قاعده نهاییشدن مقایسه سختگیرانه دارد: nLockTime باید از ارتفاع بلاک کمتر باشد. بنابراین این حد در حالت ارتفاعی، اولین امکان را در H+1 ایجاد میکند؛ شرطهای دیگر هم باید برقرار باشند.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:760–778ch07_authorization-authentication.adoc:779–893
آیا شاخه «خرج پس از تاریخ X» بعداً منقضی میشود؟
قفل زمانی مطلق در اسکریپت
نه. این شرط معمولاً یک حد پایین زمانی است. پس از بازشدن مسیر، بدون شرط مستقل دیگری باز میماند؛ قفل زمانی را نباید تاریخ انقضای حق خرج فرض کرد.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:760–778ch07_authorization-authentication.adoc:779–893
تفاوت قفل نسبی با مطلق چیست؟
قفل نسبی و CHECKSEQUENCEVERIFY
قفل مطلق به یک ارتفاع یا زمان مشترک اشاره میکند؛ قفل نسبی از تأیید خروجی خرجشونده اندازهگیری میشود. به همین دلیل قفل نسبی برای «مهلت واکنش پس از انتشار این تراکنش» مناسبتر است.
اصلاحات و رفع ابهام
- مبدأ قفل نسبی زمانیE-013
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:894–927ch07_authorization-authentication.adoc:928–966
CSV چه رابطهای با BIP68 دارد؟
قفل نسبی و CHECKSEQUENCEVERIFY
CSV میخواهد sequence ورودی، تأخیری دستکم بهاندازه شرط اسکریپت داشته باشد. BIP68 سپس اثر آن sequence را نسبت به سن خروجی در زنجیره اعمال میکند؛ یکی شرط قرارداد است و دیگری قاعده نهاییشدن نسبی.
اصلاحات و رفع ابهام
- مبدأ قفل نسبی زمانیE-013
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:894–927ch07_authorization-authentication.adoc:928–966
چرا نسخه تراکنش و بیت غیرفعالسازی در CSV مهماند؟
قفل نسبی و CHECKSEQUENCEVERIFY
قفل نسبی معمول به نسخه حداقل ۲ و sequence فعال نیاز دارد. بررسی این شرایط مانع آن میشود که خرجکننده عدد ظاهراً کافی بگذارد اما سازوکار اعمال تأخیر را خاموش کند.
اصلاحات و رفع ابهام
- مبدأ قفل نسبی زمانیE-013
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:894–927ch07_authorization-authentication.adoc:928–966
آیا عدد CSV همیشه تعداد ثانیه است؟
قفل نسبی و CHECKSEQUENCEVERIFY
خیر. بیت نوع مشخص میکند تأخیر برحسب بلاک است یا واحدهای ۵۱۲ ثانیهای. مخلوطکردن نوع یا واردکردن مستقیم ثانیهها میتواند زمان واقعی قرارداد را کاملاً تغییر دهد.
اصلاحات و رفع ابهام
- مبدأ قفل نسبی زمانیE-013
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:894–927ch07_authorization-authentication.adoc:928–966
آیا CSV زمان را از زمان ساخت کیف پول یا امضا آغاز میکند؟
قفل نسبی و CHECKSEQUENCEVERIFY
خیر. مبدأ به تأیید خروجی مرتبط است؛ در نوع زمانی، محاسبه با MTPهای مشخصشده در BIP68 انجام میشود. ساعت دستگاه امضاکننده تعیینکننده نیست.
اصلاحات و رفع ابهام
- مبدأ قفل نسبی زمانیE-013
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:894–927ch07_authorization-authentication.adoc:928–966
آیا CSV آرگومان خود را از پشته حذف میکند؟
قفل نسبی و CHECKSEQUENCEVERIFY
خیر. مانند CLTV، بررسی میکند ولی آرگومان را باقی میگذارد؛ طراحی ادامه اسکریپت باید حذف یا استفاده درست از آن را لحاظ کند.
اصلاحات و رفع ابهام
- مبدأ قفل نسبی زمانیE-013
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:894–927ch07_authorization-authentication.adoc:928–966
OP_IF چگونه مسیر خرج را انتخاب میکند؟
شرطها، مسیر جایگزین و خطای منطقی
مقدار شرط را از بالای پشته برمیدارد و فقط شاخه متناظر را اجرا میکند. دادههای مربوط به امضا یا راز باید با ترتیب مصرف همان شاخه چیده شوند.
اصلاحات و رفع ابهام
- guard ناقص با OP_IFE-017
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:967–1028ch07_authorization-authentication.adoc:1029–1087ch07_authorization-authentication.adoc:1088–1169ch07_authorization-authentication.adoc:1170–1265
چرا شرط اشتباه همیشه به معنی شکست اسکریپت نیست؟
شرطها، مسیر جایگزین و خطای منطقی
مقدار false ممکن است فقط شاخه IF را رد کند؛ اگر شاخه دیگر یا پشته باقیمانده نتیجه درست ایجاد کند، اسکریپت موفق میشود. «اجرا نشدن بررسی» با «ردشدن خرج» یکسان نیست.
اصلاحات و رفع ابهام
- guard ناقص با OP_IFE-017
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:967–1028ch07_authorization-authentication.adoc:1029–1087ch07_authorization-authentication.adoc:1088–1169ch07_authorization-authentication.adoc:1170–1265
آیا «EQUAL سپس IF و CHECKSIG و ENDIF» با EQUALVERIFY و CHECKSIG معادل است؟
شرطها، مسیر جایگزین و خطای منطقی
خیر. در نمونه کتاب، عدم تطابق هش میتواند شاخه امضا را رد کند و یک داده درست روی پشته باقی بگذارد. شرط الزامآور باید شکست را صریح کند؛ مثلاً EQUALVERIFY یا شاخه شکست مناسب داشته باشد.
اصلاحات و رفع ابهام
- guard ناقص با OP_IFE-017
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:967–1028ch07_authorization-authentication.adoc:1029–1087ch07_authorization-authentication.adoc:1088–1169ch07_authorization-authentication.adoc:1170–1265
چگونه میتوان مسیر دورزدن guard ناقص کتاب را دید؟
شرطها، مسیر جایگزین و خطای منطقی
در الگوی هشمقایسه و IF بدون ELSE شکست، یک مقدار
01زیر پیشتصویر نادرست قرار دهید. مقایسه false میشود، IF آن را مصرف میکند و بررسی امضا اجرا نمیشود؛01باقیمانده نتیجه را درست میکند. این تحلیل یک خطای منطقی نمونه آموزشی است، نه دستور استفاده از آن برای نگهداری پول.اصلاحات و رفع ابهام
- guard ناقص با OP_IFE-017
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:967–1028ch07_authorization-authentication.adoc:1029–1087ch07_authorization-authentication.adoc:1088–1169ch07_authorization-authentication.adoc:1170–1265
آیا clean stack بهتنهایی خطای guard ناقص را میگیرد؟
شرطها، مسیر جایگزین و خطای منطقی
نه الزاماً. اگر فقط یک عنصر درست باقی بماند، شرط clean stack نیز برقرار است. حفاظت به معنای درست برنامه وابسته است، نه صرفاً تعداد عناصر نهایی.
اصلاحات و رفع ابهام
- guard ناقص با OP_IFE-017
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:967–1028ch07_authorization-authentication.adoc:1029–1087ch07_authorization-authentication.adoc:1088–1169ch07_authorization-authentication.adoc:1170–1265
چرا یک مسیر بازیابی جدید میتواند امنیت مسیر اصلی را تغییر دهد؟
شرطها، مسیر جایگزین و خطای منطقی
مهاجم کافی است آسانترین مسیر مجاز را برآورده کند. امنیت ترکیب OR را نباید با جمع قدرت تکتک شاخهها سنجید؛ یک شاخه ضعیف ممکن است سیاست اصلی را دور بزند.
اصلاحات و رفع ابهام
- guard ناقص با OP_IFE-017
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:967–1028ch07_authorization-authentication.adoc:1029–1087ch07_authorization-authentication.adoc:1088–1169ch07_authorization-authentication.adoc:1170–1265
در سیاست «دو نفر اکنون، یک نفر با وکیل پس از ۳۰ روز، وکیل پس از ۹۰ روز» چه اتفاقی برای مسیر اول میافتد؟
شرطها، مسیر جایگزین و خطای منطقی
مسیر اول معمولاً همچنان معتبر میماند. زمان، مسیرهای بیشتری را باز میکند؛ آنها را بهصورت خودکار جایگزین یا انحصاری نمیکند.
اصلاحات و رفع ابهام
- guard ناقص با OP_IFE-017
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:967–1028ch07_authorization-authentication.adoc:1029–1087ch07_authorization-authentication.adoc:1088–1169ch07_authorization-authentication.adoc:1170–1265
چرا «۳۰ روز» در شبهکد را نباید عدد آماده Script دانست؟
شرطها، مسیر جایگزین و خطای منطقی
باید معلوم شود منظور زمان مطلق است یا نسبی، واحد بلاک است یا زمان، و timestamp/MTP چگونه محاسبه میشود. برچسب انسانیِ نمودار، قالب اجرایی دقیق ندارد.
اصلاحات و رفع ابهام
- guard ناقص با OP_IFE-017
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:967–1028ch07_authorization-authentication.adoc:1029–1087ch07_authorization-authentication.adoc:1088–1169ch07_authorization-authentication.adoc:1170–1265
چرا آزمون اسکریپت باید مسیرهای شکست را نیز پوشش دهد؟
شرطها، مسیر جایگزین و خطای منطقی
آزمون موفق فقط نشان میدهد یک خرج مجاز ممکن است. برای امنیت باید اثبات عملی بیشتری جست: امضای کم، راز غلط، زمان زود، انتخابگر شاخه غلط و پشته اضافی نباید راه خرج ناخواسته باز کنند.
اصلاحات و رفع ابهام
- guard ناقص با OP_IFE-017
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:967–1028ch07_authorization-authentication.adoc:1029–1087ch07_authorization-authentication.adoc:1088–1169ch07_authorization-authentication.adoc:1170–1265
در خرج native P2WPKH امضا و کلید کجا قرار میگیرند؟
P2WPKH و جدایی witness
در witness ورودی؛ scriptSig باید خالی باشد. خروجی، نسخه صفر و برنامه ۲۰ بایتیِ هش کلید را دارد و قواعد witness معنای ویژه آن را اعمال میکنند.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1266–1276ch07_authorization-authentication.adoc:1277–1338ch07_authorization-authentication.adoc:1339–1364
چرا P2WPKH از نظر منطقی به P2PKH شبیه است ولی بایتهایش یکسان نیست؟
P2WPKH و جدایی witness
هر دو تطابق هش کلید و امضا را میخواهند، اما قالب خروجی، جای دادههای مجوز و الگوریتم تعهد امضا متفاوت است. شباهت سیاست به معنای یکسانبودن serialization نیست.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1266–1276ch07_authorization-authentication.adoc:1277–1338ch07_authorization-authentication.adoc:1339–1364
scriptCode در امضای P2WPKH چیست؟
P2WPKH و جدایی witness
قالب متناظر P2PKH برای همان هش کلید در پیام امضای BIP143 استفاده میشود. خود witness program کوتاه، جایگزین مستقیم این scriptCode در محاسبه پیام نیست.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1266–1276ch07_authorization-authentication.adoc:1277–1338ch07_authorization-authentication.adoc:1339–1364
چرا برنامه witness صفرِ ۲۰ بایتی با نوع ۳۲ بایتی فرق دارد؟
P2WPKH و جدایی witness
طول برنامه همراه نسخه معنای آن را تعیین میکند: ۲۰ بایت برای P2WPKH و ۳۲ بایت برای P2WSH است. تفسیر صرفاً با دیدن OP_0 کامل نمیشود.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1266–1276ch07_authorization-authentication.adoc:1277–1338ch07_authorization-authentication.adoc:1339–1364
آیا witness یک scriptSig دیگر با همان دستورهای push است؟
P2WPKH و جدایی witness
خیر. witness فهرستی از عناصر بایتی با شمارش و طولهای مشخص است. این فهرست به ماشین بررسی مربوط داده میشود، اما خودِ فهرست برنامه Script نیست.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1266–1276ch07_authorization-authentication.adoc:1277–1338ch07_authorization-authentication.adoc:1339–1364
در خرج P2WSH چه چیزی به هش خروجی متعهد شده است؟
P2WSH و اسکریپت شاهد
SHA256 کل witness script. آخرین عنصر witness باید آن اسکریپت باشد؛ عناصر قبلی ورودیهای اجرای آن هستند و هش اسکریپت باید با برنامه ۳۲ بایتی خروجی یکسان باشد.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1365–1439ch07_authorization-authentication.adoc:1440–1457
چرا P2WSH میتواند اسکریپتی بزرگتر از redeem script رایج P2SH داشته باشد؟
P2WSH و اسکریپت شاهد
witness script نهایی تابع سقف اختصاصی ۱۰هزار بایتی است و همان عنصر pushشده ۵۲۰ بایتی P2SH نیست. با این حال عناصر دادهای معمول پشته همچنان محدودیت دارند.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1365–1439ch07_authorization-authentication.adoc:1440–1457
آیا بزرگتر بودن سقف P2WSH به معنی حذف هزینه اجرای برنامه است؟
P2WSH و اسکریپت شاهد
خیر. وزن تراکنش، شمارش عملیات و امضاها و محدودیتهای پشته همچنان هزینه و سقف ایجاد میکنند. انتقال داده به witness آن را رایگان یا نامحدود نمیکند.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1365–1439ch07_authorization-authentication.adoc:1440–1457
چرا برای خرج P2WSH هم باید سیاست را پشتیبان گرفت؟
P2WSH و اسکریپت شاهد
خروجی فقط هش را ذخیره میکند. بدون witness script و کلیدها یا دادههای لازم، از روی هش بهتنهایی راه بازیابی عمومی وجود ندارد.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1365–1439ch07_authorization-authentication.adoc:1440–1457
چرا Segwit بهصورت soft fork قابلاعمال بود؟
مهاجرت و Segwit تودرتو
قالبهای قبلی که گره قدیمی محدودیت کامل جدیدشان را نمیدانست، برای گره ارتقایافته با قواعد محدودکنندهتر تفسیر شدند. سازگاری قدیمی به معنای اعتبارسنجی کامل witness توسط گره قدیمی نیست.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1458–1482ch07_authorization-authentication.adoc:1483–1500ch07_authorization-authentication.adoc:1501–1537ch07_authorization-authentication.adoc:1538–1591
P2SH-P2WPKH چه مشکلی را حل میکرد؟
مهاجرت و Segwit تودرتو
امکان دریافت خرج Segwit از فرستندههایی را فراهم میکرد که آدرس P2SH میشناختند ولی آدرس native Segwit را نه. سازگاری بیشتر در برابر سربار اضافه قالب تودرتو به دست میآمد.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1458–1482ch07_authorization-authentication.adoc:1483–1500ch07_authorization-authentication.adoc:1501–1537ch07_authorization-authentication.adoc:1538–1591
در Segwit تودرتو، scriptSig چه دارد؟
مهاجرت و Segwit تودرتو
فقط push برنامه witness بهعنوان redeem script را دارد؛ دادههای امضا در witness میمانند. افزودن داده دلخواه به scriptSig با قالب دقیق موردنیاز سازگار نیست.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1458–1482ch07_authorization-authentication.adoc:1483–1500ch07_authorization-authentication.adoc:1501–1537ch07_authorization-authentication.adoc:1538–1591
چرا P2SH-P2WPKH معمولاً از native P2WPKH گرانتر است؟
مهاجرت و Segwit تودرتو
لایه P2SH و ارائه redeem program بایتهای پایه اضافه میکنند که وزن بیشتری از بایت witness دارند. این هزینه برای سازگاری قالب قدیمی پرداخت میشود، نه برای امضای قویتر.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1458–1482ch07_authorization-authentication.adoc:1483–1500ch07_authorization-authentication.adoc:1501–1537ch07_authorization-authentication.adoc:1538–1591
در P2SH-P2WSH چند تعهد متفاوت وجود دارد؟
مهاجرت و Segwit تودرتو
خروجی به HASH160 برنامه witness متعهد است و آن برنامه به SHA256 اسکریپت واقعی. هر لایه باید با قالب و الگوریتم هش خودش بررسی شود؛ این دو هش قابلجایگزینی نیستند.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1458–1482ch07_authorization-authentication.adoc:1483–1500ch07_authorization-authentication.adoc:1501–1537ch07_authorization-authentication.adoc:1538–1591
آیا تغییر نوع آدرس، بیتکوینهای قدیمی را خودکار به Segwit منتقل میکند؟
مهاجرت و Segwit تودرتو
خیر. هر UTXO اسکریپت زمان ایجاد خودش را دارد. مهاجرت آن به قالب دیگر به یک تراکنش خرج معتبر و ایجاد خروجی جدید نیاز دارد.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1458–1482ch07_authorization-authentication.adoc:1483–1500ch07_authorization-authentication.adoc:1501–1537ch07_authorization-authentication.adoc:1538–1591
درخت اسکریپت چه مزیتی نسبت به افشای همه شاخهها دارد؟
درخت سیاست و افشای حداقلی
برای استفاده از یک شاخه میتوان خود آن و مسیر اثباتش را ارائه کرد، نه همه سیاست را. این کار هزینه و افشای جزئیات استفادهنشده را کاهش میدهد.
تصویر 0705درخت مرکلِ مسیرهای جایگزین خرج برچسب CHECKMULTISIG در این نمودار مفهومی، کد قابل اجرای Tapscript نیست؛ Tapscript برای چندامضایی قواعد دیگری دارد.
Mastering Bitcoin, third edition; Andreas M. Antonopoulos and David A. Harding. Original image, unchanged.
تصویر 0706افشای یک مسیر و اثبات عضویت آن این نمودار مفهومی همهٔ بایتهای control block و قواعد Tapscript را نشان نمیدهد؛ CHECKMULTISIG در Tapscript فعال نیست.
Mastering Bitcoin, third edition; Andreas M. Antonopoulos and David A. Harding. Original image, unchanged.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1592–1735
آیا افشای یک برگ، هیچ اطلاعاتی درباره سیاست باقیمانده نمیدهد؟
درخت سیاست و افشای حداقلی
خیر. طول مسیر، خود شاخه اجراشده، زمان خرج و سایر دادهها میتوانند سرنخ بدهند. پنهانبودن متن برگهای دیگر مساوی با ناشناسی کامل نیست.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1592–1735
چرا شاخه پرتکرار بهتر است در عمق کمتر باشد؟
درخت سیاست و افشای حداقلی
مسیر اثبات کوتاهتر، هشهای کمتری در witness میخواهد. طراحی درخت میتواند هزینه موردانتظار را با احتمال استفاده از شاخهها سازگار کند، نه اینکه همه شاخهها را همیشه همعمق کند.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1592–1735
آیا نمودارهای MAST کتاب مستقیماً کد قابلاجرای Tapscript هستند؟
درخت سیاست و افشای حداقلی
خیر. برخی نمودارها برای توضیح تجزیه سیاست از CHECKMULTISIG قدیمی استفاده میکنند. در Tapscript باید از منطق سازگار مانند CHECKSIGADD استفاده و کل ساختار دوباره بررسی شود.
تصویر 0707درخت نامتقارن برای مسیرهای با احتمال متفاوت مسیر پرکاربرد را میتوان کمعمقتر قرار داد؛ برچسبهای اسکریپت شکل، قرارداد Tapscript آمادهٔ اجرا نیستند.
Mastering Bitcoin, third edition; Andreas M. Antonopoulos and David A. Harding. Original image, unchanged.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1592–1735
Pay-to-contract چگونه داده را بدون نوشتن آشکار آن به پرداخت پیوند میدهد؟
تعهد در کلید و امضای چندطرفه
کلید عمومی پایه با یک tweak وابسته به داده تغییر میکند. کسی که داده و کلید پایه را دارد میتواند رابطه را بررسی کند، درحالیکه خروجی ممکن است مثل یک پرداخت کلیدی عادی دیده شود.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1736–1777ch07_authorization-authentication.adoc:1778–1856
آیا خرجکردن یک کلید tweaked بهتنهایی قبول آگاهانه متن قرارداد را اثبات میکند؟
تعهد در کلید و امضای چندطرفه
خیر. کنترل کلید، تعهد رمزنگاریشده به داده و پذیرش حقوقی یا فهم متن، سه ادعای متفاوتاند. معنای قراردادی به پروتکل ارتباطی و احراز طرفین هم وابسته است.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1736–1777ch07_authorization-authentication.adoc:1778–1856
چرا اصالت کلید پایه در Pay-to-contract مهم است؟
تعهد در کلید و امضای چندطرفه
اگر مهاجم بتواند کلید پایه را جایگزین کند، ممکن است پرداخت به کلیدی برود که او کنترل میکند. درستی محاسبه tweak، منبع اولیه کلید را احراز نمیکند.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1736–1777ch07_authorization-authentication.adoc:1778–1856
چندامضایی scriptless چه چیزی را از زنجیره پنهان میکند؟
تعهد در کلید و امضای چندطرفه
چند طرف با پروتکل امضای مناسب، یک کلید و امضای قابلبررسی عادی میسازند؛ گره لزوماً تعداد شرکتکنندگان یا مراحل داخلی را نمیبیند. هماهنگی خارج از زنجیره همچنان لازم است.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1736–1777ch07_authorization-authentication.adoc:1778–1856
آیا MuSig همان امضای آستانهای دلخواه t از n است؟
تعهد در کلید و امضای چندطرفه
خیر. MuSig معمولاً همکاری همه کلیدهای گروه را لازم دارد. امضای آستانهای t از n پروتکل دیگری برای توزیع سهمها و ساخت امضا با زیرمجموعه کافی میخواهد.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1736–1777ch07_authorization-authentication.adoc:1778–1856
خروجی Taproot به چه چیزی متعهد است؟
مسیر کلیدی و اسکریپتی Taproot
به یک کلید خروجی x-only که از کلید داخلی و، در صورت وجود، ریشه درخت اسکریپت با tweak دامنهبندیشده ساخته شده است. بنابراین یک خروجی میتواند هم مسیر کلیدی و هم مسیرهای اسکریپتی داشته باشد.
تصویر 0710تعهد Taproot به کلید داخلی و ریشهٔ درخت وجود مسیرهای اسکریپتی به معنی اجبار استفاده از آنها نیست؛ کسی که کلید لازم برای مسیر کلیدی را دارد میتواند از آن مسیر خرج کند.
Mastering Bitcoin, third edition; Andreas M. Antonopoulos and David A. Harding. Original image, unchanged.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1857–1957
در خرج key path Taproot چه چیزی آشکار میشود؟
مسیر کلیدی و اسکریپتی Taproot
امضای لازم برای کلید خروجی ارائه میشود، بدون آشکارکردن درخت اسکریپت. مشاهدهکننده از خود این خرج لزوماً نمیفهمد آیا مسیر جایگزینی وجود داشته یا چند طرف امضا ساختهاند.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1857–1957
در خرج script path Taproot چه دادههایی لازم است؟
مسیر کلیدی و اسکریپتی Taproot
آرگومانهای اجرای شاخه، خود اسکریپت و control block لازماند. control block اطلاعات کلید داخلی، نسخه برگ، parity و هشهای مسیر را برای بازسازی تعهد خروجی حمل میکند.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1857–1957
چرا کلید داخلی Taproot را نباید با کلید خروجی اشتباه گرفت؟
مسیر کلیدی و اسکریپتی Taproot
کلید خروجی پس از tweak ساخته میشود و همان چیزی است که خروجی به آن قفل شده است. امضای key path باید با کلید خصوصی متناظر خروجی سازگار باشد، نه صرفاً کلید داخلی بدون اعمال tweak.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1857–1957
اگر طراح بخواهد فقط مسیرهای اسکریپتی مجاز باشند، چه خطری از کلید داخلی میآید؟
مسیر کلیدی و اسکریپتی Taproot
دارنده راز متناظر کلید داخلی ممکن است کلید خرج key path را محاسبه کند و محدودیتهای شاخهها را دور بزند. برای حذف عملی این مسیر باید سازوکاری معتبر برای کلید داخلی بدون راز شناختهشده به کار رود.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1857–1957
چرا هش برگ Taproot فقط هش متن اسکریپت نیست؟
مسیر کلیدی و اسکریپتی Taproot
نسخه برگ و طول serialization نیز همراه متن در TapLeaf وارد میشوند. این دامنهبندی و قالببندی، تفسیرهای متفاوت یک رشته بایت را از هم جدا میکند.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1857–1957
آیا مسیر مرکل Taproot به بیت جهت چپ و راست نیاز دارد؟
مسیر کلیدی و اسکریپتی Taproot
در ترکیب TapBranch دو هش بهترتیب واژهنامهای مرتب میشوند، پس برای همان مرحله جهت جداگانه لازم نیست. این قاعده با درخت ترتیبدار تراکنشهای بلاک متفاوت است.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1857–1957
چه چیزی مانع جایگزینی یک شاخه دلخواه هنگام خرج Taproot میشود؟
مسیر کلیدی و اسکریپتی Taproot
گره از برگ و مسیر ارائهشده، ریشه و سپس کلید خروجی را دوباره میسازد. شاخه یا مسیر متفاوت معمولاً تعهد دیگری تولید میکند و با خروجی موجود تطبیق ندارد.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1857–1957
آیا Taproot همه خرجها را همیشه ارزانتر میکند؟
مسیر کلیدی و اسکریپتی Taproot
خیر. هزینه به مسیر، عمق درخت، دادهها و تعداد امضاها بستگی دارد. صرف نام Taproot تضمین نمیکند یک سیاست معین از تمام قالبهای دیگر کمهزینهتر باشد.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1857–1957
چرا CHECKMULTISIG در Tapscript استفاده نمیشود؟
Tapscript و مرز سازگاری
این opcode در آن زمینه غیرفعال است. CHECKSIGADD امکان شمارش نتیجه بررسی امضاها را با قواعد جدید فراهم میکند و به ساخت سیاستهای آستانهای سازگار کمک میکند.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1958–2004
CHECKSIGADD چه تفاوتی با CHECKSIG دارد؟
Tapscript و مرز سازگاری
نتیجه اعتبار امضا را به یک عدد روی پشته اضافه میکند. با تکرار این عمل برای کلیدها و مقایسه مجموع با آستانه، میتوان منطق چندامضایی ساخت.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1958–2004
چرا امضای خالی در Tapscript با امضای غیرخالیِ غلط فرق دارد؟
Tapscript و مرز سازگاری
در بررسی کلید معمول، امضای خالی میتواند نتیجه false بدهد تا منطق آستانهای ادامه پیدا کند؛ امضای غیرخالی نامعتبر اجرای اسکریپت را شکست میدهد. این تمایز بخشی از قواعد است.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1958–2004
چرا OP_SUCCESSx را نباید بهعنوان یک دستور بیاثر در اسکریپت تازه استفاده کرد؟
Tapscript و مرز سازگاری
این کدها برای توسعه آینده رزرو شدهاند و در قواعد فعلی میتوانند موفقیت را بدون اجرای منطق معمول ایجاد کنند. درج تصادفی آنها ممکن است حفاظت موردانتظار را از بین ببرد.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1958–2004
آیا Tapscript سقف منابع را حذف کرده است؟
Tapscript و مرز سازگاری
خیر. بعضی سقفهای قدیمی مانند شمارش ۲۰۱ opcode یا طول ۱۰هزار بایتی اسکریپت جای خود را به قواعد دیگر دادهاند؛ وزن، پشته و بودجه بررسی امضا همچنان محدودکنندهاند.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1958–2004
چرا انتخاب نسخه اسکریپت در آزمون امنیتی ضروری است؟
Tapscript و مرز سازگاری
opcode یکسان ممکن است در زمینه قدیمی، witness صفر و Tapscript معنا یا محدودیت متفاوتی داشته باشد. قبولی در یک مفسر با زمینه اشتباه، درباره خرج واقعی تضمینی نمیدهد.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1958–2004