پرسشهای میانفصلی و موقعیتهای واقعی
میانفصلی · ۷۸ پرسش
کلید، seed و عبارت بازیابی همهٔ مثالهای منتشرشده عمومیاند؛ هرگز برای پول واقعی استفاده نشوند. این مجموعه و کدهایش پیادهسازی تولیدی کیف پول یا مرجع مستقل اجماع نیستند.
seed را بازیابی کردهام اما موجودی صفر است؛ آیا سکهها از بین رفتهاند؟
بازیابی کیف پول و تشخیص موجودی گمشده
لزوماً نه. passphrase متفاوت، مسیر مشتقسازی یا نوع اسکریپت اشتباه، شبکهٔ نادرست، همگامسازی ناقص و دامنهٔ کشف محدود همگی میتوانند کیف پولی ظاهراً خالی بسازند. ابتدا این موارد را با اطلاعات عمومی و نسخهٔ پشتیبان تطبیق دهید؛ seed را برای عیبیابی افشا نکنید.
اصلاحات و رفع ابهام
- seed و بازیابی کانالE-047
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch05_wallets.adoc:448–545ch05_wallets.adoc:546–697ch05_wallets.adoc:1021–1069ch10_network.adoc:415–443
چرا یک passphrase اشتباه ممکن است هیچ خطایی نشان ندهد؟
بازیابی کیف پول و تشخیص موجودی گمشده
BIP39 برای هر passphrase یک seed تولید میکند و سامانه معیاری برای تشخیص قصد شما ندارد. نتیجه میتواند کیف پولی معتبر اما متفاوت باشد؛ تنها تطبیق آدرسهای شناختهشده یا تاریخچه مشخص میکند کدام بازیابی درست است.
اصلاحات و رفع ابهام
- seed و بازیابی کانالE-047
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch05_wallets.adoc:448–545ch05_wallets.adoc:546–697ch05_wallets.adoc:1021–1069ch10_network.adoc:415–443
اگر عبارت بازیابی درست باشد اما کیف پول مقصد نوع آدرس دیگری بسازد، چه رخ میدهد؟
بازیابی کیف پول و تشخیص موجودی گمشده
همان ریشهٔ کلید میتواند در مسیرها و قالبهای مختلف، خروجیهای متفاوتی بسازد. باید نوع اسکریپت و مسیر اصلی را بازیابی کرد؛ جستوجوی یک قالب، همهٔ داراییهای ممکن آن seed را پوشش نمیدهد.
اصلاحات و رفع ابهام
- seed و بازیابی کانالE-047
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch05_wallets.adoc:448–545ch05_wallets.adoc:546–697ch05_wallets.adoc:1021–1069ch10_network.adoc:415–443
چرا زیادبودن فاصلهٔ آدرسهای استفادهنشده، بازیابی را مختل میکند؟
بازیابی کیف پول و تشخیص موجودی گمشده
نرمافزار معمولاً پس از تعداد مشخصی آدرس بدون سابقه جستوجو را متوقف میکند. اگر خروجی بعد از آن فاصله باشد کشف نمیشود؛ سکه موجود است، اما الگوریتم جستوجو هنوز به آن نرسیده است.
اصلاحات و رفع ابهام
- seed و بازیابی کانالE-047
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch05_wallets.adoc:448–545ch05_wallets.adoc:546–697ch05_wallets.adoc:1021–1069ch10_network.adoc:415–443
چرا seed یک امضاکننده برای بازیابی کیف پول چندامضایی کافی نیست؟
بازیابی کیف پول و تشخیص موجودی گمشده
علاوه بر کلید خود، معمولاً سیاست، آستانه، کلیدهای عمومی دیگران، ترتیب و مسیر مشتقسازی لازم است. گمشدن این دادهها میتواند ساخت اسکریپت درست را ناممکن کند، حتی اگر تعداد کافی کلید خصوصی باقی باشد.
اصلاحات و رفع ابهام
- seed و بازیابی کانالE-047
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch05_wallets.adoc:448–545ch05_wallets.adoc:546–697ch05_wallets.adoc:1021–1069ch10_network.adoc:415–443
آیا اسکن با گره کامل، فرادادهٔ گمشدهٔ سیاست چندامضایی را خودکار بازسازی میکند؟
بازیابی کیف پول و تشخیص موجودی گمشده
نه. زنجیره تعهد به شرایط خرج را نگه میدارد، نه لزوماً تمام اطلاعات پنهان آنها را. گره کامل صحت داده را بررسی میکند؛ نمیتواند همیشه redeem script یا سیاستِ هنوز منتشرنشده را از یک هش بازیابی کند.
اصلاحات و رفع ابهام
- seed و بازیابی کانالE-047
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch05_wallets.adoc:448–545ch05_wallets.adoc:546–697ch05_wallets.adoc:1021–1069ch10_network.adoc:415–443
فقط xpub فروشگاه نشت کرده است؛ آیا مهاجم میتواند پول را خرج کند؟
نشت کلید، نشت xpub و دامنهٔ خسارت
xpub بهتنهایی معمولاً توان خرج نمیدهد، ولی آدرسها و جریان مالی شاخهٔ مربوط را آشکار میکند. اگر کلید خصوصی یکی از فرزندان غیرسختشده نیز نشت کند، خطر میتواند به کلید خصوصی والدِ آن شاخه گسترش یابد.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch04_keys.adoc:91–162ch05_wallets.adoc:1220–1314ch05_wallets.adoc:1364–1406ch13_security.adoc:246–256
چرا تعویض یک آدرس بعد از نشت کلید فرزند همیشه کافی نیست؟
نشت کلید، نشت xpub و دامنهٔ خسارت
دامنهٔ خسارت به اطلاعات دیگری بستگی دارد که مهاجم دارد. همراهشدن کلید فرزند غیرسختشده با xpub والد امکان بازیابی والد را میدهد؛ آدرس تازهای از همان شاخه نیز ممکن است ناامن باشد.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch04_keys.adoc:91–162ch05_wallets.adoc:1220–1314ch05_wallets.adoc:1364–1406ch13_security.adoc:246–256
آیا جداکردن کیف پول آنلاین و آفلاین با دو پوشه روی یک رایانه محقق میشود؟
نشت کلید، نشت xpub و دامنهٔ خسارت
خیر. بدافزار، سیستمعامل یا حساب مدیریتی مشترک میتواند هر دو را تحت تأثیر قرار دهد. جداسازی نام یا مسیر، مرز مستقل نگهداری کلید ایجاد نمیکند.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch04_keys.adoc:91–162ch05_wallets.adoc:1220–1314ch05_wallets.adoc:1364–1406ch13_security.adoc:246–256
چرا ساخت کلید تصادفی قوی، ضعف nonce امضا را جبران نمیکند؟
نشت کلید، نشت xpub و دامنهٔ خسارت
کلید اولیه ممکن است امن باشد، اما nonce تکراری یا قابل پیشبینی در امضا میتواند همان کلید را از روابط ریاضی امضا افشا کند. تولید کلید و تولید nonce دو نقطهٔ مستقل برای شکستاند.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch04_keys.adoc:91–162ch05_wallets.adoc:1220–1314ch05_wallets.adoc:1364–1406ch13_security.adoc:246–256
آدرس جایگزینشده توسط بدافزار checksum صحیح دارد؛ چرا کیف پول هشدار نمیدهد؟
آدرس درست از نظر قالب، گیرندهٔ غلط از نظر قصد
checksum خطاهای تصادفی در رشته را کشف میکند، نه هویت گیرنده را. مهاجم میتواند آدرس معتبر خودش را جایگزین کند؛ تطبیق مقصد با منبع قابل اعتماد و نمایشگر مستقل، مسئلهای جداگانه است.
اصلاحات و رفع ابهام
- امضا، هویت و مالکیتE-044
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch04_keys.adoc:623–764ch04_keys.adoc:1186–1453ch08_signatures.adoc:39–47ch13_security.adoc:209–219
امضای تراکنش صحیح است، پس چرا پرداخت ممکن است اشتباه باشد؟
آدرس درست از نظر قالب، گیرندهٔ غلط از نظر قصد
امضا مجوز رمزنگارانه نسبت به دادهٔ تحت تعهد را بررسیپذیر میکند، نه اینکه کاربر آن داده را درست دیده یا گیرنده همان فرد مورد نظر بوده است. رابط آلوده میتواند تراکنش اشتباه اما کاملاً معتبر را برای امضا عرضه کند.
اصلاحات و رفع ابهام
- امضا، هویت و مالکیتE-044
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch04_keys.adoc:623–764ch04_keys.adoc:1186–1453ch08_signatures.adoc:39–47ch13_security.adoc:209–219
آیا دستگاه سختافزاری فقط با نگهداشتن کلید درون خود، مقصد پرداخت را تضمین میکند؟
آدرس درست از نظر قالب، گیرندهٔ غلط از نظر قصد
نه. کاربر باید مقصد، مبلغ و سایر جزئیات قابل نمایش را بررسی کند و دستگاه نیز باید تغییر را درست بازشناسی کند. امضای امنِ یک درخواست فریبنده همچنان میتواند پول را به مهاجم بفرستد.
اصلاحات و رفع ابهام
- امضا، هویت و مالکیتE-044
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch04_keys.adoc:623–764ch04_keys.adoc:1186–1453ch08_signatures.adoc:39–47ch13_security.adoc:209–219
آیا یکسانبودن چند حرف اول و آخر آدرس، احراز کامل گیرنده است؟
آدرس درست از نظر قالب، گیرندهٔ غلط از نظر قصد
خیر. این تطبیق ناقص ممکن است آدرس اشتباه یا عمداً مشابه را نادیده بگیرد. آدرس کامل و کانال دریافت درخواست باید تا حد ممکن بهطور مستقل بررسی شوند.
اصلاحات و رفع ابهام
- امضا، هویت و مالکیتE-044
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch04_keys.adoc:623–764ch04_keys.adoc:1186–1453ch08_signatures.adoc:39–47ch13_security.adoc:209–219
کیف پول موجودی نشان میدهد ولی تراکنش نمیسازد؛ چه علتهایی محتملاند؟
موجودی، اختیار و قابلیت خرج
موجودی دیدهشده ممکن است شامل کوینبیس نابالغ، خروجی قفلشده، سیاست بدون امضاکنندگان کافی یا خروجی غیراقتصادی باشد. وضعیت «موجود»، «تحت کنترل» و «قابل خرج اکنون» را جداگانه بررسی کنید.
اصلاحات و رفع ابهام
- مخرج نرخ کارمزدE-027
- پایان یارانه و عرضهٔ صحیحE-038
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch06_transactions.adoc:1067–1135ch07_authorization-authentication.adoc:779–893ch07_authorization-authentication.adoc:928–966ch09_fees.adoc:104–149
چرا داشتن کلید خصوصی ممکن است برای خرج همین امروز کافی نباشد؟
موجودی، اختیار و قابلیت خرج
کلید فقط یکی از شروط احتمالی است. اسکریپت میتواند زمان، امضای دیگران یا پیشتصویر را نیز بخواهد؛ تا جمع شروط لازم برقرار نشود امضای همان کلید کافی نیست.
اصلاحات و رفع ابهام
- مخرج نرخ کارمزدE-027
- پایان یارانه و عرضهٔ صحیحE-038
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch06_transactions.adoc:1067–1135ch07_authorization-authentication.adoc:779–893ch07_authorization-authentication.adoc:928–966ch09_fees.adoc:104–149
آیا قفل زمانی با گذشت زمان مالکیت پول را خودکار به گیرندهٔ دیگری منتقل میکند؟
موجودی، اختیار و قابلیت خرج
نه. قفل زمانی مسیر خرجی را مجاز میکند یا تراکنشی را قابل درج میسازد. هنوز باید تراکنش مناسب ساخته یا منتشر شود و با شروط دیگر و کارمزد کافی تأیید شود.
اصلاحات و رفع ابهام
- مخرج نرخ کارمزدE-027
- پایان یارانه و عرضهٔ صحیحE-038
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch06_transactions.adoc:1067–1135ch07_authorization-authentication.adoc:779–893ch07_authorization-authentication.adoc:928–966ch09_fees.adoc:104–149
چرا یک خروجی کممقدار ممکن است از نظر اجماع قابل خرج اما از نظر اقتصادی نامناسب باشد؟
موجودی، اختیار و قابلیت خرج
هزینهٔ افزودن ورودی آن به تراکنش ممکن است از ارزش خود خروجی بیشتر شود. این نسبت به نرخ کارمزد و اندازهٔ مسیر خرج وابسته است، نه صرفاً معتبر بودن امضا.
اصلاحات و رفع ابهام
- مخرج نرخ کارمزدE-027
- پایان یارانه و عرضهٔ صحیحE-038
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch06_transactions.adoc:1067–1135ch07_authorization-authentication.adoc:779–893ch07_authorization-authentication.adoc:928–966ch09_fees.adoc:104–149
تراکنش از ممپول یک گره حذف شده است؛ آیا پرداخت لغو شده؟
پرداخت تأییدنشده و معنای واقعی لغو
نه. نسخهٔ تراکنش ممکن است نزد گره یا استخراجکنندهٔ دیگری باقی مانده باشد و دوباره منتشر شود. حذف محلی، تعهد اجماعی به لغو نیست؛ وضعیت خرج همان ورودیها در زنجیرهٔ معتبر اهمیت دارد.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch02_overview.adoc:435–446ch06_transactions.adoc:810–874ch09_fees.adoc:201–366ch12_mining.adoc:1488–1633
فروشگاه تراکنشی بدون علامت RBF میبیند؛ آیا میتواند آن را قطعی بداند؟
پرداخت تأییدنشده و معنای واقعی لغو
خیر. سیاست جایگزینی همهٔ گرهها یکسان نیست و استخراجکننده نیز لزوماً به علامت RBF محدود نیست. تراکنش تأییدنشده هنوز ممکن است با خرج متعارض کنار گذاشته شود.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch02_overview.adoc:435–446ch06_transactions.adoc:810–874ch09_fees.adoc:201–366ch12_mining.adoc:1488–1633
اگر تراکنش جایگزین به خودم بفرستم، آیا بازگشت پول تضمین میشود؟
پرداخت تأییدنشده و معنای واقعی لغو
نه تا زمانی که یکی از خرجهای متعارض در زنجیرهٔ پذیرفتهشده تأیید شود. گیرندهٔ اولیه یا استخراجکننده ممکن است هنوز نسخهٔ قبلی را داشته باشد؛ افزایش کارمزد ابزار رقابت است، نه فرمان لغو قطعی.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch02_overview.adoc:435–446ch06_transactions.adoc:810–874ch09_fees.adoc:201–366ch12_mining.adoc:1488–1633
چرا شناسهٔ سفارش نباید فقط txid اولین نسخهٔ پرداخت باشد؟
پرداخت تأییدنشده و معنای واقعی لغو
جایگزینی کارمزد میتواند txid را عوض کند و برخی قالبها خطر انعطافپذیری دیگری هم دارند. سامانه باید رابطهٔ نسخههای پرداخت، ورودیها و خروجی مقصد را نگه دارد، نه اینکه هر تغییر شناسه را پرداخت کاملاً نامرتبط بداند.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch02_overview.adoc:435–446ch06_transactions.adoc:810–874ch09_fees.adoc:201–366ch12_mining.adoc:1488–1633
چرا همهٔ نسخههای یک پرداخت جایگزین باید واقعاً با یکدیگر متعارض باشند؟
پرداخت تأییدنشده و معنای واقعی لغو
اگر نسخههای دورتر هیچ ورودی مشترکی نداشته باشند، ممکن است هر دو قابل تأیید شوند. اشتراک ورودی هر نسخه با نسخهٔ قبلی لزوماً تعارض همهٔ نسخهها با هم را تضمین نمیکند.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch02_overview.adoc:435–446ch06_transactions.adoc:810–874ch09_fees.adoc:201–366ch12_mining.adoc:1488–1633
چرا کارمزد زیادِ فرزند همیشه والد را سریع تأیید نمیکند؟
افزایش کارمزد در تراکنشهای وابسته
فرزند باید به استخراجکننده برسد و همراه والد قابل پذیرش باشد؛ مجموع کارمزد نسبت به اندازهٔ همهٔ اجداد لازم نیز مهم است. محدودیت پذیرش بسته، تعارض یا pinning میتواند مانع شود.
اصلاحات و رفع ابهام
- وزن هدر بلاکE-014
- ترتیب تعهد جدید و ابطال قدیمE-045
- seed و بازیابی کانالE-047
پرسشهای مرتبط
محل موضوع در کتاب: ch06_transactions.adoc:1136–1262ch09_fees.adoc:367–419ch09_fees.adoc:420–458ch14_applications.adoc:700–919
والد ۲۰۰ vB و ۲۰۰ ساتوشی کارمزد دارد؛ فرزند ۱۰۰ vB برای میانگین ۱۰ sat/vB چه کارمزدی میخواهد؟
افزایش کارمزد در تراکنشهای وابسته
بستهٔ ۳۰۰ vB به ۳٬۰۰۰ ساتوشی کارمزد کل نیاز دارد؛ پس سهم فرزند ۲٬۸۰۰ ساتوشی است. این محاسبه فقط برای همان دو تراکنش و بدون اجداد یا محدودیتهای دیگر است.
اصلاحات و رفع ابهام
- وزن هدر بلاکE-014
- ترتیب تعهد جدید و ابطال قدیمE-045
- seed و بازیابی کانالE-047
پرسشهای مرتبط
محل موضوع در کتاب: ch06_transactions.adoc:1136–1262ch09_fees.adoc:367–419ch09_fees.adoc:420–458ch14_applications.adoc:700–919
چرا افزایش کارمزد والد میتواند فرزند از پیش امضاشده را بیاستفاده کند؟
افزایش کارمزد در تراکنشهای وابسته
فرزند به outpoint مشخص شامل txid والد اشاره میکند. اگر جایگزینی والد شناسه را تغییر دهد، فرزند دیگر خروجی نسخهٔ جدید را خرج نمیکند و ممکن است نیاز به بازسازی و امضای دوباره داشته باشد.
اصلاحات و رفع ابهام
- وزن هدر بلاکE-014
- ترتیب تعهد جدید و ابطال قدیمE-045
- seed و بازیابی کانالE-047
پرسشهای مرتبط
محل موضوع در کتاب: ch06_transactions.adoc:1136–1262ch09_fees.adoc:367–419ch09_fees.adoc:420–458ch14_applications.adoc:700–919
چرا قرارداد زمانحساس علاوه بر مسیر خروج، بودجهٔ کارمزد لازم دارد؟
افزایش کارمزد در تراکنشهای وابسته
داشتن تراکنش معتبر کافی نیست؛ باید پیش از پایان فرصت در بلاک جا بگیرد. ازدحام میتواند کارمزد لازم را افزایش دهد و خروجی کوچک یا غیرقابل افزایش کارمزد، اجرای حق را دشوار کند.
اصلاحات و رفع ابهام
- وزن هدر بلاکE-014
- ترتیب تعهد جدید و ابطال قدیمE-045
- seed و بازیابی کانالE-047
پرسشهای مرتبط
محل موضوع در کتاب: ch06_transactions.adoc:1136–1262ch09_fees.adoc:367–419ch09_fees.adoc:420–458ch14_applications.adoc:700–919
آیا nLockTime میتواند پرداخت فردا را بدون اقدام دیگری انجام دهد؟
قفل زمانی، بازپرداخت و رقابت برای تأیید
نه. این فیلد فقط زودترین شرایط مجاز درج را محدود میکند؛ ارسال خودکار، داشتن ورودی خرجنشده و پرداخت کارمزد را فراهم نمیکند. برنامهٔ بیرونی باید انتشار و پیگیری را انجام دهد.
اصلاحات و رفع ابهام
- مرز nLockTimeE-012
- HTLC و نمونههای آموزشیE-046
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch06_transactions.adoc:1038–1066ch07_authorization-authentication.adoc:779–893ch07_authorization-authentication.adoc:928–966ch14_applications.adoc:920–978
چرا تغییر زنجیره میتواند زمان قابل خرجشدن یک قفل نسبی را تغییر دهد؟
قفل زمانی، بازپرداخت و رقابت برای تأیید
قفل نسبی به تأیید خروجی مرجع وابسته است. بازسازماندهی ممکن است آن تأیید را حذف کند یا به ارتفاع و زمان دیگری منتقل کند؛ زمان انتظار باید روی زنجیرهٔ فعلی دوباره ارزیابی شود.
اصلاحات و رفع ابهام
- مرز nLockTimeE-012
- HTLC و نمونههای آموزشیE-046
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch06_transactions.adoc:1038–1066ch07_authorization-authentication.adoc:779–893ch07_authorization-authentication.adoc:928–966ch14_applications.adoc:920–978
مهلت HTLC تمام شده است؛ چرا دریافت با پیشتصویر ممکن است هنوز رقابت کند؟
قفل زمانی، بازپرداخت و رقابت برای تأیید
در ساختار رایج، پایان مهلت مسیر بازپرداخت را باز میکند، نه اینکه مسیر پیشتصویر را خودکار حذف کند. تا خرج یکی از مسیرها تأیید نشده، دو طرف ممکن است برای خرج همان خروجی رقابت کنند.
اصلاحات و رفع ابهام
- مرز nLockTimeE-012
- HTLC و نمونههای آموزشیE-046
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch06_transactions.adoc:1038–1066ch07_authorization-authentication.adoc:779–893ch07_authorization-authentication.adoc:928–966ch14_applications.adoc:920–978
چرا دیدن پیشتصویر در ممپول لزوماً به معنی دریافت قطعی وجه در مسیر دیگر نیست؟
قفل زمانی، بازپرداخت و رقابت برای تأیید
انتشار، راز را آشکار میکند اما تأیید را تضمین نمیکند. طرفی که از پیشتصویر برای طلب بالادستی استفاده میکند باید زمان، کارمزد و احتمال تغییر یا عدم تأیید تراکنشها را نیز مدیریت کند.
اصلاحات و رفع ابهام
- مرز nLockTimeE-012
- HTLC و نمونههای آموزشیE-046
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch06_transactions.adoc:1038–1066ch07_authorization-authentication.adoc:779–893ch07_authorization-authentication.adoc:928–966ch14_applications.adoc:920–978
چرا فاصلهٔ مهلتها در مسیر چندپرشی نباید فقط با سرعت معمول شبکه انتخاب شود؟
قفل زمانی، بازپرداخت و رقابت برای تأیید
واسطه ممکن است مجبور به بستن کانال و خرج زنجیرهای شود. فاصله باید برای تأخیر تأیید، ازدحام و مدیریت رویدادهای نامطلوب حاشیه داشته باشد؛ مثال یکبلاکی، راهنمای امن عملیاتی نیست.
اصلاحات و رفع ابهام
- مرز nLockTimeE-012
- HTLC و نمونههای آموزشیE-046
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch06_transactions.adoc:1038–1066ch07_authorization-authentication.adoc:779–893ch07_authorization-authentication.adoc:928–966ch14_applications.adoc:920–978
چرا اسکریپتی که در آزمون مسیر درست موفق میشود، ممکن است ناامن باشد؟
خطای سیاست، حتی با رمزنگاری سالم
موفقیت فقط نشان میدهد یک شاهد پذیرفته میشود؛ باید ثابت شود شاهدهای ممنوع رد میشوند. شاخهٔ false بدون شکست صریح، دادهٔ باقیمانده روی پشته یا نوع SIGHASH نامناسب میتواند مسیر ناخواسته بسازد.
اصلاحات و رفع ابهام
- guard ناقص با OP_IFE-017
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1029–1087ch08_signatures.adoc:95–288ch13_security.adoc:63–92
چرا OP_EQUAL همراه OP_IF الزاماً جای OP_EQUALVERIFY را نمیگیرد؟
خطای سیاست، حتی با رمزنگاری سالم
OP_EQUALVERIFY هنگام نابرابری اجرای اسکریپت را شکست میدهد. OP_IF فقط شاخه را انتخاب میکند؛ اگر شاخهٔ false بدون الزام اضافی تمام شود، دادهٔ دیگری روی پشته ممکن است موفقیت نهایی بسازد.
اصلاحات و رفع ابهام
- guard ناقص با OP_IFE-017
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1029–1087ch08_signatures.adoc:95–288ch13_security.adoc:63–92
چرا استفاده از کتابخانهٔ امضای معتبر، قرارداد اشتباه را امن نمیکند؟
خطای سیاست، حتی با رمزنگاری سالم
کتابخانه میتواند امضا را کاملاً درست تولید کند، اما پیام، نوع تعهد یا سیاست انتخابشده اشتباه باشد. امنیت رمزنگاری، درستی قصد تجاری و منطق مجوز را بهجای برنامه بررسی نمیکند.
اصلاحات و رفع ابهام
- guard ناقص با OP_IFE-017
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1029–1087ch08_signatures.adoc:95–288ch13_security.adoc:63–92
در Taproot چرا «فقط شاخهٔ اسکریپت» به انتخاب کلید داخلی وابسته است؟
خطای سیاست، حتی با رمزنگاری سالم
اگر کسی کلید خصوصی مسیر کلیدی را بداند، ممکن است بدون اجرای اسکریپت خرج کند. برای سیاست اسکریپتمحور باید ساخت کلید داخلی بهگونهای باشد که راه دورزدنِ شناختهشدهای از مسیر کلیدی ایجاد نکند.
اصلاحات و رفع ابهام
- guard ناقص با OP_IFE-017
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1029–1087ch08_signatures.adoc:95–288ch13_security.adoc:63–92
چرا نباید اسکریپت CHECKMULTISIG تصویر MAST را مستقیماً در Tapscript به کار برد؟
خطای سیاست، حتی با رمزنگاری سالم
تصویر ساختار منطقی را توضیح میدهد، نه لزوماً بایتکد معتبر هر نسخه. Tapscript از CHECKMULTISIG پشتیبانی اجرایی نمیکند و ترکیب امضاها باید با ابزارهای سازگار، مانند CHECKSIGADD، ساخته شود.
اصلاحات و رفع ابهام
- guard ناقص با OP_IFE-017
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:1029–1087ch08_signatures.adoc:95–288ch13_security.adoc:63–92
چرا نسخهٔ پشتیبان seed برای بازیابی عادی کانال لایتنینگ کافی نیست؟
خرابی، نسخهٔ پشتیبان و وضعیت لایتنینگ
seed کلیدها را بازسازی میکند، اما لزوماً آخرین تعهدات، رازهای ابطال و وضعیت پرداختها را نگه نمیدارد. بازیابی کانال به سازوکار پشتیبان همان پیادهسازی نیاز دارد؛ نباید وضعیت قدیمی را خودسرانه منتشر کرد.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch05_wallets.adoc:448–545ch13_security.adoc:220–245ch14_applications.adoc:700–919
چرا انتشار تعهد قدیمی کانال ممکن است از نظر اجماع معتبر ولی برای من زیانبار باشد؟
خرابی، نسخهٔ پشتیبان و وضعیت لایتنینگ
زنجیره مفهوم «آخرین موجودی توافقشده» را مستقیماً نمیداند. طرح ابطال به طرف مقابل امکان تنبیه خرج قدیمی را میدهد؛ بنابراین معتبر بودن تراکنش، مناسب بودن آن برای صاحب کیف پول را تضمین نمیکند.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch05_wallets.adoc:448–545ch13_security.adoc:220–245ch14_applications.adoc:700–919
چرا ترتیب ذخیرهکردن وضعیت و افشای راز ابطال اهمیت امنیتی دارد؟
خرابی، نسخهٔ پشتیبان و وضعیت لایتنینگ
اگر وضعیت قبلی را بیاعتبار کنید اما امکان خرج معتبر از وضعیت جدید را پایدار نداشته باشید، خرابی میتواند شما را با اطلاعات ناکافی رها کند. تبادل پیام و دوام ذخیرهسازی باید با قواعد پروتکل هماهنگ باشند.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch05_wallets.adoc:448–545ch13_security.adoc:220–245ch14_applications.adoc:700–919
آیا واچتاور جای همهٔ نسخههای پشتیبان و پایش کاربر را میگیرد؟
خرابی، نسخهٔ پشتیبان و وضعیت لایتنینگ
خیر. واچتاور فقط در حدود داده، دسترسی و تعهد خدمت خود واکنش نشان میدهد. خرابی مشترک، ازدحام یا پیکربندی ناقص میتواند مانع شود و اطلاعات لازم برای بازیابی کامل را نیز الزاماً نگه نمیدارد.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch05_wallets.adoc:448–545ch13_security.adoc:220–245ch14_applications.adoc:700–919
کانال بزرگی دارم؛ چرا نمیتوانم همان مبلغ را دریافت کنم؟
ظرفیت و نقدینگی لایتنینگ
ظرفیت کل با نقدینگی ورودی یکی نیست. برای دریافت، طرف مقابل باید موجودی قابل ارسال به شما داشته باشد و مسیر نیز ظرفیت و محدودیتهای لازم را برآورده کند.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch09_fees.adoc:459–540ch14_applications.adoc:979–995ch14_applications.adoc:1111–1210
چرا بازکردن کانالی که همهٔ موجودی آن ابتدا برای من است، مشکل دریافت را لزوماً حل نمیکند؟
ظرفیت و نقدینگی لایتنینگ
چنین کانالی عمدتاً نقدینگی خروجی ایجاد میکند. برای دریافت از همان سمت باید موجودی به سمت مقابل منتقل شود یا ترتیبی برای تأمین نقدینگی ورودی وجود داشته باشد.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch09_fees.adoc:459–540ch14_applications.adoc:979–995ch14_applications.adoc:1111–1210
گراف عمومی مسیر موجود نشان میدهد؛ چرا پرداخت باز هم شکست میخورد؟
ظرفیت و نقدینگی لایتنینگ
گراف تمام موجودیهای جهتدار و وضعیت لحظهای کانالها را آشکار نمیکند. نقدینگی ناکافی، محدودیت HTLC، تغییر کارمزد یا در دسترس نبودن یک گره میتواند مسیر ظاهراً ممکن را ناموفق کند.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch09_fees.adoc:459–540ch14_applications.adoc:979–995ch14_applications.adoc:1111–1210
چرا بستن همزمان تعداد زیادی کانال خطر را تشدید میکند؟
ظرفیت و نقدینگی لایتنینگ
بستنها و خرجهای بعدی برای فضای بلاک رقابت میکنند. افزایش کارمزد و تأخیر میتواند اجرای مسیرهای مهلتدار را دشوارتر کند؛ نیاز به خروج و هزینهٔ خروج ممکن است همزمان افزایش یابند.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch09_fees.adoc:459–540ch14_applications.adoc:979–995ch14_applications.adoc:1111–1210
آیا لایتنینگ پرداخت کسری از ساتوشی را در خروجی عادی زنجیره ثبت میکند؟
ظرفیت و نقدینگی لایتنینگ
نه. حسابداری کانال میتواند میلیساتوشی داشته باشد، ولی مبلغ خروجی زنجیرهای عدد صحیح ساتوشی است. تسویه باید قواعد گردکردن و حذف خروجیهای کوچک پروتکل را رعایت کند.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch09_fees.adoc:459–540ch14_applications.adoc:979–995ch14_applications.adoc:1111–1210
اثبات مرکل پرداخت را دارم؛ چه چیزهایی هنوز ثابت نشدهاند؟
اثبات داده و کاملبودن داده
اثبات، عضویت تراکنش در ریشهٔ مشخص را نشان میدهد. اعتبار همهٔ تراکنشهای بلاک، تعلق آن بلاک به زنجیرهٔ پذیرفتهشده، خرجنشدهبودن خروجی و کاملبودن تاریخچهٔ کیف پول مسائل جداگانهاند.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch10_network.adoc:500–602ch10_network.adoc:808–846ch11_blockchain.adoc:533–558ch12_mining.adoc:1116–1166
چرا یک گره کامل هم ممکن است کیف پول من را با موجودی ناقص نشان دهد؟
اثبات داده و کاملبودن داده
اعتبارسنجی زنجیره با کشف آدرسهای کیف پول یکی نیست. اگر توصیفگر یا دامنهٔ جستوجو ناقص باشد، گره دادهٔ درست را دارد اما برنامه نمیداند کدام خروجیها مربوط به شما هستند.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch10_network.adoc:500–602ch10_network.adoc:808–846ch11_blockchain.adoc:533–558ch12_mining.adoc:1116–1166
چرا اثبات کارِ هدر، صحت فیلتر فشردهٔ دریافتی را ثابت نمیکند؟
اثبات داده و کاملبودن داده
فیلترهای BIP157/158 داخل تعهد اجماعی هدر بلاک قرار ندارند. زنجیرهٔ هدر فیلتر به کشف ناسازگاری کمک میکند، اما اتصال آن به محتوای درست بلاک به فرض منابع صادق و بررسیهای اضافی وابسته است.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch10_network.adoc:500–602ch10_network.adoc:808–846ch11_blockchain.adoc:533–558ch12_mining.adoc:1116–1166
پنج همتا یک پاسخ یکسان میدهند؛ آیا این برای یک کیف پول سبک اثبات است؟
اثبات داده و کاملبودن داده
نه، ممکن است هر پنج تحت کنترل یک مهاجم باشند یا از یک منبع بگیرند. توافق پاسخها را باید از استقلال منابع و امکان اعتبارسنجی خود داده جدا کرد.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch10_network.adoc:500–602ch10_network.adoc:808–846ch11_blockchain.adoc:533–558ch12_mining.adoc:1116–1166
چرا گره هرسشده میتواند اعتبارسنج کامل باشد ولی برای اسکن تاریخی محدودیت داشته باشد؟
اثبات داده و کاملبودن داده
هنگام دریافت، بلاکها را اعتبارسنجی کرده و وضعیت لازم را نگه میدارد، اما بدنهٔ بلاکهای قدیمی را حذف میکند. برخی اسکنها یا خدمترسانی تاریخی به دادهای نیاز دارند که دیگر محلی موجود نیست.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch10_network.adoc:500–602ch10_network.adoc:808–846ch11_blockchain.adoc:533–558ch12_mining.adoc:1116–1166
آیا رمزگذاری ارتباط بیتکوین ثابت میکند به گره مورد نظر وصل شدهام؟
رمزگذاری، هویت و حریم خصوصی
نه لزوماً. BIP324 محرمانگی در برابر شنود غیرفعال و حفاظت پیام فراهم میکند، اما بهتنهایی هویت مورد انتظار همتا را احراز نمیکند؛ این با احراز هویت گره در انتقال لایتنینگ یکسان نیست.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch10_network.adoc:1148–1162ch10_network.adoc:1163–1205ch13_security.adoc:93–144ch14_applications.adoc:1111–1210
چرا استفاده از Tor پیوند آدرسهای روی زنجیره را حذف نمیکند؟
رمزگذاری، هویت و حریم خصوصی
Tor دربارهٔ مسیر ارتباط و IP کمک میکند، اما ورودیها، خروجیها و الگوهای عمومی زنجیره را عوض نمیکند. ادغام سکهها یا استفادهٔ دوباره از آدرس میتواند همچنان روابط مالی آشکار کند.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch10_network.adoc:1148–1162ch10_network.adoc:1163–1205ch13_security.adoc:93–144ch14_applications.adoc:1111–1210
چرا خدمترسان عمومی کیف پول حتی با HTTPS میتواند حریم خصوصی را کم کند؟
رمزگذاری، هویت و حریم خصوصی
HTTPS مسیر بین کاربر و خدمت را حفاظت میکند؛ خود خدمت همچنان پرسوجوها و دادههای دریافتشده را میبیند. محرمانگی در مسیر با محرمانگی در برابر مقصد یکی نیست.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch10_network.adoc:1148–1162ch10_network.adoc:1163–1205ch13_security.adoc:93–144ch14_applications.adoc:1111–1210
چرا انتقال مبلغ بسیار بزرگ گاهی از انتقال مبلغ کوچک ارزانتر است؟
کارمزد و حریم خصوصی در انتخاب سکه
کارمزد عمدتاً به اندازهٔ مجازی و نرخ مورد نیاز بستگی دارد، نه ارزش پولی پرداخت. یک ورودی بزرگ میتواند از تعداد زیادی ورودی کوچک فضای کمتری بگیرد.
اصلاحات و رفع ابهام
- وزن هدر بلاکE-014
- مخرج نرخ کارمزدE-027
پرسشهای مرتبط
محل موضوع در کتاب: ch02_overview.adoc:276–291ch05_wallets.adoc:1315–1363ch06_transactions.adoc:1136–1262ch09_fees.adoc:104–149
چرا تجمیع سکهها در زمان کارمزد پایین تصمیمی صرفاً اقتصادی نیست؟
کارمزد و حریم خصوصی در انتخاب سکه
تجمیع میتواند هزینهٔ خرج آینده را کم کند، ولی چند خروجی را در یک تراکنش مشترک پیوند میدهد. صرفهجویی کارمزد باید در برابر کاهش جداسازی مالی و حریم خصوصی سنجیده شود.
اصلاحات و رفع ابهام
- وزن هدر بلاکE-014
- مخرج نرخ کارمزدE-027
پرسشهای مرتبط
محل موضوع در کتاب: ch02_overview.adoc:276–291ch05_wallets.adoc:1315–1363ch06_transactions.adoc:1136–1262ch09_fees.adoc:104–149
آیا بالابودن مبلغ خروجی تغییر ثابت میکند کیف پول اشتباه کرده است؟
کارمزد و حریم خصوصی در انتخاب سکه
نه. مدل UTXO ورودی را کامل مصرف میکند و باقیمانده را برمیگرداند. مهم این است که تغییر واقعاً تحت سیاست کیف پول شما باشد و جمع ورودیها، خروجیها و کارمزد درست باشد.
اصلاحات و رفع ابهام
- وزن هدر بلاکE-014
- مخرج نرخ کارمزدE-027
پرسشهای مرتبط
محل موضوع در کتاب: ch02_overview.adoc:276–291ch05_wallets.adoc:1315–1363ch06_transactions.adoc:1136–1262ch09_fees.adoc:104–149
چرا پرداخت دستهای میتواند هزینه را کم کند ولی اطلاعات بیشتری آشکار کند؟
کارمزد و حریم خصوصی در انتخاب سکه
چند پرداخت هزینهٔ سربار و گاهی ورودیها را به اشتراک میگذارند. در مقابل، مشاهدهگر میبیند چند خروجی در یک عملیات ساخته شدهاند و ممکن است گیرندگان یا زمانبندی پرداخت را به هم مرتبط کند.
اصلاحات و رفع ابهام
- وزن هدر بلاکE-014
- مخرج نرخ کارمزدE-027
پرسشهای مرتبط
محل موضوع در کتاب: ch02_overview.adoc:276–291ch05_wallets.adoc:1315–1363ch06_transactions.adoc:1136–1262ch09_fees.adoc:104–149
دو شاخه داریم؛ چرا شمردن بلاکها برای انتخاب کافی نیست؟
زنجیرهٔ معتبر، کار انباشته و حمله
بلاکها میتوانند هدفهای متفاوت و درنتیجه سهم متفاوتی از کار مورد انتظار داشته باشند. گره ابتدا اعتبار را میسنجد و سپس کار انباشته را مقایسه میکند؛ طول بیشتر لزوماً کار بیشتر نیست.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch11_blockchain.adoc:171–229ch12_mining.adoc:910–1019ch12_mining.adoc:1167–1244ch12_mining.adoc:1488–1633
آیا زنجیرهای با بیشترین اثبات کار میتواند تراکنش بدون مجوز را معتبر کند؟
زنجیرهٔ معتبر، کار انباشته و حمله
نه برای گرهای که همان قواعد را اجرا میکند. قاعدهٔ بیشترین کار فقط میان زنجیرههای معتبر به کار میرود؛ کار بیشتر، امضای نامعتبر یا خلق پول خارج از قواعد را جبران نمیکند.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch11_blockchain.adoc:171–229ch12_mining.adoc:910–1019ch12_mining.adoc:1167–1244ch12_mining.adoc:1488–1633
چرا خروج ناگهانی استخراجکنندگان فوراً با تنظیم سختی جبران نمیشود؟
زنجیرهٔ معتبر، کار انباشته و حمله
تنظیم اصلی شبکه در مرزهای دورهای رخ میدهد، نه بعد از هر بلاک. تا رسیدن به مرز، تولید بلاک کند میشود؛ سقف تغییر هر دوره نیز میتواند بازگشت به آهنگ معمول را چندمرحلهای کند.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch11_blockchain.adoc:171–229ch12_mining.adoc:910–1019ch12_mining.adoc:1167–1244ch12_mining.adoc:1488–1633
چرا ثابتبودن برنامهٔ عرضه، درآمد کافیِ آینده برای امنیت را تضمین نمیکند؟
زنجیرهٔ معتبر، کار انباشته و حمله
عرضه یک قاعدهٔ اجماعی است، اما درآمد استخراج به یارانه، تقاضای فضای بلاک، قیمت و هزینهها وابسته است. جایگزینی یارانه با کارمزد یک نتیجهٔ اقتصادی مشروط است، نه پیامد خودکار فرمول عرضه.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch11_blockchain.adoc:171–229ch12_mining.adoc:910–1019ch12_mining.adoc:1167–1244ch12_mining.adoc:1488–1633
چرا «شش تأیید» عدد مناسبی برای همهٔ انواع خطر نیست؟
زنجیرهٔ معتبر، کار انباشته و حمله
خطر به توان مهاجم، ارزش هدف، وضعیت شبکه و مدل تصمیم بستگی دارد. تأیید بیشتر معمولاً هزینه یا دشواری بازسازماندهی را بالا میبرد، اما برای جعل مقصد، سرقت کلید یا خطای نرمافزار درمان نیست.
اصلاحات و رفع ابهام
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch11_blockchain.adoc:171–229ch12_mining.adoc:910–1019ch12_mining.adoc:1167–1244ch12_mining.adoc:1488–1633
یک قابلیت BIP دارد؛ آیا میتوانم فرض کنم همهٔ کیف پولها از آن پشتیبانی میکنند؟
نسخهٔ نرمافزار، پیشنهاد و فعالشدن قاعده
خیر. شمارهٔ BIP وجود مشخصات را نشان میدهد؛ پیادهسازی، استقرار، فعالسازی اجماعی و سازگاری کیف پول مراحل متفاوتاند. قابلیت مورد نیاز باید در نسخهها و نقشهای دقیق آزمایش شود.
اصلاحات و رفع ابهام
- فرایند BIP و URIE-050
پرسشهای مرتبط
محل موضوع در کتاب: ch03_bitcoin-core.adoc:135–183ch12_mining.adoc:1634–1650ch12_mining.adoc:1837–1878appc_bips.adoc:3–73
چرا گره قدیمی پس از سافتفورک ممکن است بلاکی را بپذیرد ولی همهٔ شروط جدید را بررسی نکرده باشد؟
نسخهٔ نرمافزار، پیشنهاد و فعالشدن قاعده
سافتفورک مجموعهٔ معتبر را محدود میکند. گره قدیمی فقط قواعد قدیمی را میسنجد و ممکن است بخش جدید را از نظر معنایی نفهمد؛ پذیرش آن معادل اعتبارسنجی مستقل قواعد تازه نیست.
اصلاحات و رفع ابهام
- فرایند BIP و URIE-050
پرسشهای مرتبط
محل موضوع در کتاب: ch03_bitcoin-core.adoc:135–183ch12_mining.adoc:1634–1650ch12_mining.adoc:1837–1878appc_bips.adoc:3–73
چرا شکست دستور ساخت یا RPC کتاب را نباید فوراً مشکل پروتکل دانست؟
نسخهٔ نرمافزار، پیشنهاد و فعالشدن قاعده
فرمانها و امکانات نرمافزار با نسخه تغییر میکنند، درحالیکه قواعد زنجیره مسئلهای دیگرند. نسخه و مستندات همان نسخه را بررسی کنید و نمونهٔ تاریخی را از رفتار اجماع جدا نگه دارید.
اصلاحات و رفع ابهام
- فرایند BIP و URIE-050
پرسشهای مرتبط
محل موضوع در کتاب: ch03_bitcoin-core.adoc:135–183ch12_mining.adoc:1634–1650ch12_mining.adoc:1837–1878appc_bips.adoc:3–73
سه کلید دارم اما هر سه در یک حساب ابریاند؛ آیا سه لایهٔ مستقل امنیت دارم؟
چندامضایی، استقلال و امکان بازیابی
نه. تصاحب یا از دسترفتن آن حساب میتواند همهٔ کلیدها را همزمان تحت تأثیر قرار دهد. چندامضایی زمانی جداسازی مؤثر میدهد که مرزهای خرابی و دسترسی واقعاً متفاوت باشند.
اصلاحات و رفع ابهام
پرسشهای مرتبط
محل موضوع در کتاب: ch13_security.adoc:246–256ch13_security.adoc:257–270ch05_wallets.adoc:448–545ch07_authorization-authentication.adoc:314–384
چرا بالا بردن آستانهٔ چندامضایی همیشه امنیت کلی را بیشتر نمیکند؟
چندامضایی، استقلال و امکان بازیابی
آستانهٔ بالاتر سرقت با تعداد کم کلید را دشوار میکند، اما خطر از دستدادن دسترسی را نیز بالا میبرد. باید هم احتمال سازش و هم احتمال نابودی، غیبت یا عدم همکاری امضاکنندگان را سنجید.
اصلاحات و رفع ابهام
پرسشهای مرتبط
محل موضوع در کتاب: ch13_security.adoc:246–256ch13_security.adoc:257–270ch05_wallets.adoc:448–545ch07_authorization-authentication.adoc:314–384
آیا یک سیاست ارث روی زنجیره تعیین میکند چه کسی از نظر حقوقی وارث است؟
چندامضایی، استقلال و امکان بازیابی
نه. اسکریپت شرایط فنی خرج را تعیین میکند؛ تشخیص حق قانونی و اجرای تعهدات بیرون از پروتکل است. هماهنگی این دو مسئله نیاز به فرایند مستقل دارد.
اصلاحات و رفع ابهام
پرسشهای مرتبط
محل موضوع در کتاب: ch13_security.adoc:246–256ch13_security.adoc:257–270ch05_wallets.adoc:448–545ch07_authorization-authentication.adoc:314–384
چرا آزمون بازیابی باید پیش از بحران انجام شود؟
چندامضایی، استقلال و امکان بازیابی
در بحران ممکن است نقص مسیر، passphrase، دادهٔ سیاست یا دسترسی امضاکنندگان تازه آشکار شود. آزمون کنترلشده نشان میدهد نسخهٔ پشتیبان واقعاً قابل استفاده است، نه فقط اینکه فایلی یا چند کلمه نگه داشتهاید.
اصلاحات و رفع ابهام
پرسشهای مرتبط
محل موضوع در کتاب: ch13_security.adoc:246–256ch13_security.adoc:257–270ch05_wallets.adoc:448–545ch07_authorization-authentication.adoc:314–384
هش سند روی زنجیره است؛ آیا ثابت میکند محتوای سند درست است؟
تعهد داده، دارایی بیرونی و معنای تسویه
نه. تطبیق هش نشان میدهد سند ارائهشده با تعهد سازگار است و درج تعهد را میتوان در زنجیره بررسی کرد. صحت ادعا، هویت نویسنده و وجود دارایی پشتوانه از هش نتیجه نمیشوند.
اصلاحات و رفع ابهام
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:689–759ch07_authorization-authentication.adoc:1736–1777ch14_applications.adoc:174–195ch14_applications.adoc:232–272
آیا ثبت تعهد سند تضمین میکند خود سند در آینده پیدا میشود؟
تعهد داده، دارایی بیرونی و معنای تسویه
خیر. هش اطلاعات کامل سند را نگه نمیدارد و ابزار بازیابی آن نیست. نگهداری و دسترسپذیری داده باید جداگانه تأمین شود.
اصلاحات و رفع ابهام
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:689–759ch07_authorization-authentication.adoc:1736–1777ch14_applications.adoc:174–195ch14_applications.adoc:232–272
در دارایی با اعتبارسنجی سمت کاربر، چرا seed بیتکوین ممکن است همهٔ دارایی را بازیابی نکند؟
تعهد داده، دارایی بیرونی و معنای تسویه
کلید اجازهٔ خرج لایهٔ بیتکوین را بازسازی میکند، اما اثباتهای انتقال و دادهٔ خاص دارایی ممکن است بیرون زنجیره باشند. از دسترفتن آن دادهها میتواند انتقال معتبر دارایی را مختل کند.
اصلاحات و رفع ابهام
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:689–759ch07_authorization-authentication.adoc:1736–1777ch14_applications.adoc:174–195ch14_applications.adoc:232–272
آیا تسویهٔ بیتکوین میتواند تحویل کالای فیزیکی را اتمی تضمین کند؟
تعهد داده، دارایی بیرونی و معنای تسویه
بهتنهایی نه. زنجیره نمیتواند واقعیت تحویل یا کیفیت کالا را مستقیماً مشاهده کند. داور، وثیقه یا سازوکار بیرونی فرض اعتماد تازهای اضافه میکند که باید صریح باشد.
اصلاحات و رفع ابهام
پرسشهای مرتبط
محل موضوع در کتاب: ch07_authorization-authentication.adoc:689–759ch07_authorization-authentication.adoc:1736–1777ch14_applications.adoc:174–195ch14_applications.adoc:232–272
چرا هشکردن خام همهٔ بایتهای تراکنش الزاماً پیام درست برای امضا نمیسازد؟
آزمون مهندسی و مرزهای تعمیم
پیام امضا به نسخهٔ خرج و نوع SIGHASH وابسته است و میتواند دادههایی را حذف، تبدیل یا از خروجیهای قبلی اضافه کند. Legacy، SegWit v0 و Taproot قواعد یکسانی ندارند.
منابع اصلی
پرسشهای مرتبط
محل موضوع در کتاب: ch06_transactions.adoc:31–89ch08_signatures.adoc:95–288ch08_signatures.adoc:994–1034ch11_blockchain.adoc:559–568
تراکنش در regtest پذیرفته شده؛ آیا میتوان آن را بدون بررسی روی mainnet به کار برد؟
آزمون مهندسی و مرزهای تعمیم
نه. محیط، شبکه، پیکربندی سیاست، دادهٔ ورودی و شرایط فعالسازی باید منطبق باشند. موفقیت آزمایشی یک مسیر، امنیت نگهداری کلید، تابآوری و پذیرش واقعی تحت ازدحام را ثابت نمیکند.
پرسشهای مرتبط
محل موضوع در کتاب: ch06_transactions.adoc:31–89ch08_signatures.adoc:95–288ch08_signatures.adoc:994–1034ch11_blockchain.adoc:559–568
چرا تست فقط با مقادیر معمولی، خطای مبلغ یا قفل زمانی را پنهان میکند؟
آزمون مهندسی و مرزهای تعمیم
بسیاری از خطاها در مرز رخ میدهند: یک ساتوشی، اولین ارتفاع مجاز، خروجی صفر، بیشینهٔ مقدار یا گردکردن vsize. آزمون باید مرز و یک مقدار دو طرف آن را نیز پوشش دهد.
پرسشهای مرتبط
محل موضوع در کتاب: ch06_transactions.adoc:31–89ch08_signatures.adoc:95–288ch08_signatures.adoc:994–1034ch11_blockchain.adoc:559–568
چرا آزمون اتصال موفق به شبکه جای آزمون بازیابی پس از خرابی را نمیگیرد؟
آزمون مهندسی و مرزهای تعمیم
اتصال فقط یک وضعیت زنده را میسنجد. خرابی بین دریافت داده، ذخیرهٔ حالت و ارسال پاسخ میتواند تکرار عملیات، از دسترفتن شاخص یا استفاده از وضعیت قدیمی ایجاد کند؛ این نقاط باید مستقل آزموده شوند.
پرسشهای مرتبط
محل موضوع در کتاب: contrib/appdx-bitcoindevkit.asciidoc:192–204ch14_applications.adoc:404–449