کارمزد، تأیید و رفع ابهام پرداخت

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

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

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

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

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

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

در RBF، تراکنش تأییدنشده با تراکنشی ناسازگار که همان ورودی را مصرف می‌کند جایگزین می‌شود، مشروط به سیاست پذیرش گره. این کار معمولاً برای افزایش کارمزد به کار می‌رود. سازوکار جایگزینی و سیاست اولیه گفتن اینکه «فقط تراکنش‌های ازپیش علامت‌خورده قابل‌جایگزینی‌اند» قاعدهٔ عمومی امروز نیست: بیت‌کوین کور در نسخهٔ ۲۸، پذیرش جایگزینی کامل را به‌صورت پیش‌فرض فعال کرد. این تصمیم دربارهٔ سیاست حافظهٔ تراکنش است، نه اختیار تغییر تراکنش تأییدشده. یادداشت انتشار نسخهٔ ۲۸

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

برای دقیق‌بودن ارجاع نسخه‌ای: در بیت‌کوین کور ۲۹، گزینهٔ تنظیمِ mempoolfullrbf حذف شد؛ این پس از پیش‌فرض‌شدن جایگزینی کامل در نسخهٔ ۲۸ است. این توضیح دربارهٔ سیاست آن پیاده‌سازی است، نه ادعای اینکه همهٔ گره‌ها و کیف پول‌های شبکه یک نسخه یا رفتار واحد دارند. یادداشت انتشار نسخهٔ ۲۹

در CPFP، خروجی یک تراکنش تأییدنشده در تراکنش فرزند خرج می‌شود و کارمزد فرزند می‌تواند مجموعه را برای استخراج جذاب‌تر کند. برای گنجاندن فرزند، والد باید زودتر در زنجیره یا زودتر در همان بلاک قرار بگیرد. نرخ مؤثر مجموعه از مجموع کارمزدها نسبت به مجموع اندازه‌های مربوط به دست می‌آید؛ بالا بودن نرخ فرزند به‌تنهایی کافی نیست. سازوکار والد و فرزند

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

نمایش هر ابزار از داده‌ای می‌آید که همان ابزار یا خدمت پشتیبانش دیده است. برای نمونه، مستندات الکتروم تصریح می‌کند که دربارهٔ تراکنش‌های تأییدنشده به گزارش سرور اتکا دارد و سرور ممکن است تراکنشی را اصلاً گزارش نکند. پس ندیدن تراکنش در یک ابزار، به‌تنهایی اثبات نبودن آن در سراسر شبکه نیست. محدودهٔ مشاهدهٔ کیف پول سبک

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

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

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

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

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

به پرداخت سارا برگردید: ۱۲۰٬۰۰۰ ساتوشی ورودی، ۹۰٬۰۰۰ برای نرگس، ۲۹٬۰۰۰ باقی‌مانده و ۱٬۰۰۰ کارمزد. فرض می‌کنیم تراکنش هنوز تأیید نشده و کیف پول امکان ساخت جایگزین را دارد. اگر هدف، افزایش کارمزد به ۲٬۰۰۰ ساتوشی با همان ورودی‌ها و همان مبلغ گیرنده باشد، باقی‌مانده باید به ۲۸٬۰۰۰ کاهش یابد.

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

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

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

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

مثال توضیحی: یک والد و فرزند فرضی، هرکدام ۲۰۰ بایت مجازی‌اند. با کارمزد ۲۰۰ ساتوشی برای والد و ۲٬۶۰۰ ساتوشی برای فرزند، مجموع کارمزد ۲٬۸۰۰ و مجموع اندازه ۴۰۰ است؛ نرخ مجموعه ۷ ساتوشی بر بایت مجازی می‌شود. این محاسبه فرض می‌کند اجداد تأییدنشدهٔ دیگری وجود ندارند. نرخ حاصل، زمان قطعی تأیید نمی‌دهد؛ پذیرش مجموعه و انتخاب در بلاک همچنان لازم‌اند.

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