خروجی‌های خرج‌نشده و ساختار تراکنش

در مدل بیت‌کوین، موجودی یک عدد مستقل در حساب مرکزی نیست؛ کیف پول خروجی‌های مرتبط را جمع می‌کند. هر خروجی خرج‌نشده یا UTXO مبلغ و شرط خرج‌کردن دارد. ورودی تراکنش جدید به یک خروجی قبلی اشاره می‌کند و اجازهٔ مصرف آن را ارائه می‌دهد. پس از خرج‌شدن، همان خروجی دوباره قابل‌مصرف نیست، هرچند خروجی‌های تازه‌ای در تراکنش ساخته می‌شود. مدل ورودی و خروجی

مثلاً موجودی آموزشیِ پانزده‌هزار ساتوشی می‌تواند از سه خروجی پنج‌هزارتایی تشکیل شده باشد یا از یک خروجی پانزده‌هزارتایی. عدد جمع یکسان است، اما برای یک پرداخت، ساختار ورودی‌ها ممکن است متفاوت باشد. همین تفاوت بعداً بر اندازه و کارمزد اثر می‌گذارد. همچنین «قابل‌مشاهده»، «تأییدشده» و «قابل‌خرج با کلیدهای فعلی» برچسب‌های یکسانی نیستند؛ موجودی فقط‌ناظر الزاماً قابل‌خرج نیست.

وقتی یک خروجی مصرف می‌شود، تمام آن وارد محاسبهٔ تراکنش می‌شود؛ نمی‌توان نیمی از همان خروجی قدیمی را دست‌نخورده باقی گذاشت. کیف پول معمولاً بخشی را به گیرنده و بخشی را در خروجی تازه‌ای به خودش می‌فرستد. این خروجی دوم «باقی‌مانده» است و ممکن است آدرس آن با آدرس دریافت اولیه متفاوت باشد. توضیح ویکی جامعه این سازوکار را روشن می‌کند، اما توصیه‌های تاریخی آن دربارهٔ تعداد دفعات پشتیبان‌گیری، قاعدهٔ عمومی کیف پول‌های امروز نیست. توضیح باقی‌مانده

مثال ساختگی: از ورودی ده‌هزار ساتوشی، شش‌هزار برای گیرنده و سه‌هزاروپانصد برای خودتان ساخته می‌شود؛ اختلاف پانصد ساتوشی کارمزد است. این بازگشت به خود، پرداخت دوباره از سوی گیرنده نیست. اگر کیف پول خروجی باقی‌مانده نسازد، باید روشن باشد اختلاف به کجا رفته است؛ صرف مشاهدهٔ یک خروجی، تمام محاسبه را توضیح نمی‌دهد.

آدرس برای بیان مقصد پرداخت به کار می‌رود؛ شناسهٔ تراکنش یا txid یک تراکنش مشخص را شناسایی می‌کند. چون هر تراکنش می‌تواند چند خروجی داشته باشد، برای اشارهٔ دقیق به یک خروجی، شناسه به‌همراه شمارهٔ آن خروجی لازم است؛ این زوج «ارجاع خروجی» نام دارد. شماره‌گذاری خروجی‌ها از صفر شروع می‌شود. ساختار ارجاع خروجی

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

ساختن یعنی انتخاب ورودی‌ها و تعیین خروجی‌ها. امضا یعنی افزودن دادهٔ لازم برای اثبات اجازهٔ خرج، مطابق شرایط خروجی؛ منظور رمزگذاریِ خود تراکنش نیست. ممکن است چند امضا لازم باشد و یک بستهٔ نیمه‌امضاشده هنوز برای انتشار آماده نباشد. مراحل تکمیل تراکنش انتشار یعنی رساندن تراکنش کامل به همتایان شبکه؛ تأیید یعنی قرارگرفتن آن در بلاکی که در زنجیرهٔ پذیرفته‌شده قرار دارد. بررسی پرداخت

این تفکیک در رفع مشکل تعیین‌کننده است: اگر فایل فقط ذخیره شده، انتظار برای بلاک مسئله را حل نمی‌کند؛ اگر امضا ناقص است، افزایش کارمزد به‌تنهایی آن را معتبر نمی‌کند. از سوی دیگر، موفقیت دکمهٔ «ارسال» ممکن است فقط پذیرش درخواست توسط برنامه را نشان دهد. وضعیت را با شواهد هر مرحله بخوانید: تکمیل امضاها، نتیجهٔ انتشار، مشاهدهٔ تراکنش و سپس وجود بلاک، چهار گزارش متفاوت‌اند.

آدرس اطلاعات لازم برای ساخت نوع مشخصی از مقصد را منتقل می‌کند؛ تراکنش، مبلغ و اسکریپت خروجی را ثبت می‌کند. P2PKH پرداخت به هش کلید عمومی است. P2SH به هش اسکریپت متعهد می‌شود و هنگام خرج، خود اسکریپت و دادهٔ برآورده‌کردن شرایطش لازم است. پس هر خروجی اسکریپتی الزاماً چندامضایی نیست. قالب‌های کلاسیک خروجی

در سگویت نسخهٔ صفر، P2WPKH گونهٔ مبتنی بر هش کلید عمومی و P2WSH گونهٔ مبتنی بر هش اسکریپت است؛ دادهٔ اثبات خرج در بخش شاهد می‌آید. قالب‌های سگویت P2TR خروجی تپ‌روت است و قواعد خرج از مسیر کلید یا مسیر اسکریپت را دارد؛ استفاده از مسیر اسکریپت در هر پرداخت الزامی نیست. قواعد تپ‌روت

این‌ها گونه‌های دارایی جداگانه نیستند. تفاوتشان در قفل و اثبات مجازبودن خرج است. کیف پول باید قالب مقصد را پشتیبانی کند و آدرس از گیرنده احراز شود. تغییر دستی پیشوند، قالب یا شبکه را تبدیل نمی‌کند؛ حتی آدرس از نظر ساختاری معتبر هم می‌تواند متعلق به فرد اشتباه باشد.

انتخاب خروجی یعنی کیف پول تصمیم بگیرد کدام خروجی‌های خرج‌نشده را ورودی تراکنش کند. انتخاب‌های مختلف می‌توانند تعداد ورودی، اندازهٔ تراکنش، نیاز به باقی‌مانده و ارتباط قابل‌مشاهده میان دریافت‌های قبلی را تغییر دهند. الگوریتم‌ها ممکن است میان هزینه و حریم خصوصی موازنه برقرار کنند؛ یک انتخاب واحد برای همهٔ وضعیت‌ها بهترین نیست. انتخاب خروجی در کیف پول

«کنترل خروجی» به کاربر اجازه می‌دهد در ابزارهای پشتیبان، این انتخاب را محدود یا مشخص کند. «تجمیع» خرج‌کردن چند خروجی به خروجی‌های کمتر است؛ همین عملیات یک تراکنش با هزینه و اثر حریم خصوصی است، نه مرتب‌سازی رایگان فهرست. مثال آموزشی: ترکیب دو دریافت با منشأ متفاوت می‌تواند رابطه‌ای ایجاد کند که هنگام جدا ماندن آشکار نبود. بنابراین کاهش تعداد خروجی‌ها را نباید بدون بررسی پیامدها هدف مستقل دانست.

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

از این رو عددی واحد را نباید «حداقل مبلغ همیشگی بیت‌کوین» معرفی کرد. نوع خروجی و سیاست نرم‌افزار در محاسبهٔ غبار نقش دارند؛ این سیاست با قواعد اجماع هم‌معنا نیست. برای مثال فرضی، خروجی هزارساتوشی اگر برای خرج‌شدن هزینه‌ای بیش از هزار ساتوشی ایجاد کند غیراقتصادی است، حتی اگر قبلاً منتشر و تأیید شده باشد. این وضعیت به معنی پاک‌شدن خودکار خروجی از زنجیره یا انتقال آن به ماینر نیست.

قفل زمانی می‌تواند زودترین زمان یا ارتفاع مجاز برای ورود تراکنش به بلاک را محدود کند. قفل نسبی، سن خروجی مصرف‌شونده را در نظر می‌گیرد؛ BIP68 برای تفسیر مشخصی از شمارهٔ توالی ورودی، چنین قیدی تعریف می‌کند. قید ممکن است برحسب بلاک یا زمانِ مبتنی بر قواعد شبکه باشد. قفل نسبی تراکنش

این سازوکار ساعت ارسال خودکار نیست: پس از رسیدن شرط، تراکنش هنوز باید معتبر، منتشر و انتخاب شود. همچنین قفل زمانیِ یک تراکنش را با ممنوعیت خرج‌کردن خروجی از هر مسیر دیگری اشتباه نگیرید؛ برای آن باید شرایط خود خروجی و مسیرهای جایگزین نیز بررسی شود. در مثال آموزشی، «پس از چند بلاک امکان استفاده از این مسیر هست» با «در ساعت معین حتماً پرداخت می‌شود» فرق دارد. در این مرحله هدف فهم شرط است، نه ساخت قرارداد واقعی.

بایت واحد اندازهٔ داده است. نمایش شانزده‌شانزدهی، هر بایت را با دو نویسه نشان می‌دهد؛ مثلاً 00 یک بایت است، نه دو بایت داده. اندازهٔ تراکنش از قالب باینری به دست می‌آید، نه تعداد حروف نمایشگر. در قالب تراکنش، شمارهٔ نسخه و قفل زمانی هرکدام چهار بایت‌اند؛ ارجاع ورودی به خروجی قبلی ۳۶ بایت است؛ مبلغ هر خروجی هشت بایت دارد. شمارها و طول‌ها نیز جا می‌گیرند. اعداد کمتر از ۲۵۳ در CompactSize یک بایت‌اند. قالب و طول فیلدها

مثال فرضی با قالب واقعی: یک ورودیِ بومی P2WPKH و دو خروجی از همین نوع داریم. اسکریپت هر خروجی ۲۲ بایت است؛ scriptSig ورودی خالی است. فرض می‌کنیم دادهٔ امضا، با احتساب بایت نوع امضا، ۷۲ بایت و کلید عمومی فشرده ۳۳ بایت باشد. این فرضِ طول است، نه امضای واقعی؛ طول امضاها همیشه یکسان نیست. ساختار این نوع خرج

در قالب همراه شاهد، دو بایت نشانگر و پرچم اضافه می‌شود. شاهد این ورودی هم شمار اقلام دارد، هم طول هر قلم: یک بایت برای شمار دو قلم، یک بایت طول امضا و ۷۲ بایت خود آن، یک بایت طول کلید و ۳۳ بایت خود کلید. در نتیجه شاهد ۱۰۸ بایت و اضافهٔ کل قالب ۱۱۰ بایت است. اندازهٔ کامل می‌شود ۲۲۳ بایت. این طول‌ها از قواعد واقعی سریال‌سازی می‌آیند؛ شاهد صرفاً چسباندن امضا و کلید به هم نیست. قالب همراه شاهد

وزن، اندازهٔ پایه ضرب‌در سه، به‌علاوهٔ اندازهٔ کامل است؛ معادل چهار برابر بخش پایه و یک برابر بایت‌های افزوده. اندازهٔ مجازی، وزن تقسیم بر چهار با گردکردن رو به بالاست. تعریف وزن و اندازهٔ مجازی

در مثال ما: ۳ × ۱۱۳ + ۲۲۳ = ۵۶۲ واحد وزن؛ سپس ۵۶۲ ÷ ۴ = ۱۴۰٫۵ و با گردکردن، ۱۴۱ بایت مجازی. پس یک تراکنش واحد، هم‌زمان ۲۲۳ بایت داده و ۱۴۱ بایت مجازی دارد؛ هیچ‌کدام اشتباه نیستند.

تغییر فرضی: اگر تنها طول دادهٔ امضا یک بایت کمتر شود، اندازهٔ کامل ۲۲۲، وزن ۵۶۱ و اندازهٔ مجازی همچنان ۱۴۱ است. گردکردن علت این برابری است. اگر مبلغ خروجی بزرگ‌تر شود ولی همچنان در محدودهٔ معتبر باشد، فیلد مبلغ همچنان هشت بایت است؛ زیادشدن مبلغ لزوماً تراکنش را بزرگ‌تر نمی‌کند.

مثال کاملاً فرضی: سارا دو خروجی تأییدشده در اختیار دارد: یکی ۷۰٬۰۰۰ و دیگری ۵۰٬۰۰۰ ساتوشی. می‌خواهد ۹۰٬۰۰۰ ساتوشی به نرگس بدهد. روی کاغذ، کیف پول هر دو خروجی را انتخاب می‌کند و تراکنشی می‌سازد که ۱٬۰۰۰ ساتوشی کارمزد دارد. این اعداد، دادهٔ شبکه یا نرخ پیشنهادی نیستند.

ساختار ورودی، به شناسه و شمارهٔ خروجی قبلی اشاره می‌کند؛ مبلغ قبلی از دادهٔ آن خروجی معلوم می‌شود. در قالب معمول، مبلغی دلخواه با ادعای فرستنده جای آن را نمی‌گیرد. قالب ورودی و خروجی

حالا رخدادها را جدا دنبال کنید:

۱. پیش‌نویس: هیچ خرجی صرفاً با رسم این جدول روی زنجیره رخ نداده است.

۲. امضا: سارا اجازهٔ خرج را مطابق شرط ورودی‌ها فراهم می‌کند؛ نرگس برای دریافت لازم نیست کلید خصوصی خود را بدهد.

۳. انتشار: گره‌ها تراکنش را می‌گیرند و در صورت سازگاری با قواعد و سیاستشان، آن را می‌پذیرند و بازپخش می‌کنند. مم‌پول، وضعیت محلیِ پرداخت تأییدنشده است.

۴. قرارگرفتن در زنجیرهٔ فعال: دو خروجی قدیمی خرج شده‌اند؛ خروجی ۹۰٬۰۰۰ و خروجی ۲۹٬۰۰۰ ساخته شده‌اند. از خروجی نخست یک «تکهٔ مصرف‌نشده» باقی نمانده؛ باقی‌مانده، خروجی جدید است. سازندهٔ بلاک می‌تواند کارمزد را در سقف دریافتی کوین‌بیس منظور کند. پردازش ورودی‌ها و کارمزد

اگر سارا خروجی باقی‌مانده را حذف کند و فقط ۹۰٬۰۰۰ ساتوشی به نرگس بفرستد، در این مدل کارمزد ۳۰٬۰۰۰ ساتوشی می‌شود. شبکه قصد ذهنی سارا برای «برگرداندن بقیه» را حدس نمی‌زند. نرم‌افزار ممکن است جلوی چنین کارمزد بزرگی را بگیرد، اما حسابداری تراکنش همان اختلاف ورودی و خروجی است.

در ادامه، جایگزینی همین پرداخت و تغییر شاخهٔ تأیید آن را بررسی می‌کنیم.

مثال توضیحی: دو ورودی فرضیِ ۷٬۰۰۰ و ۵٬۰۰۰ ساتوشی، در مجموع ۱۲٬۰۰۰ ساتوشی‌اند. اگر خروجی گیرنده ۸٬۰۰۰ و باقی‌مانده ۳٬۲۰۰ ساتوشی باشد، جمع خروجی‌ها ۱۱٬۲۰۰ و کارمزد ۸۰۰ ساتوشی است. هر دو خروجی قدیمی خرج شده‌اند؛ باقی‌مانده یک خروجی تازه است، نه بخش خرج‌نشدهٔ ورودی قدیمی.

بخش پیشین · نقشهٔ موضوع‌ها · واژه‌نامه · بخش بعدی