اگر ماینر روشن است، فن‌ها کار می‌کنند، اما در پنل استخر هیچ ورکری دیده نمی‌شود، مشکل تقریباً همیشه یکی از این سه چیز است: آدرس، پورت، یا نام ورکر. و اگر وصل شده ولی ریجکت بالا می‌زند، مشکل تقریباً هیچ‌وقت «اینترنت ایران» نیست — این را پایین‌تر با عدد نشان می‌دهم.
نسخهٔ ۱ پروتکل Stratum فقط یک اتصال TCP ساده است که رویش JSON خط‌به‌خط رد و بدل می‌شود. ماینر یک اتصال باز می‌کند، mining.subscribe می‌فرستد، بعد mining.authorize با نام ورکر و رمز، استخر با mining.notify جاب می‌فرستد و ماینر با mining.submit شیر تحویل می‌دهد. نه رمزنگاری دارد، نه HTTP است، و مهم‌تر از همه: یک اتصال طولانی‌مدت است که ساعت‌ها باز می‌ماند.
دو نتیجهٔ عملی از این دو خط بیرون می‌آید. اول، هر تجهیز بازرسی بستهٔ میانی می‌تواند محتوای آن را بخواند و ماینینگ را تشخیص دهد — پس عوض کردن پورت به‌تنهایی همیشه کافی نیست. دوم، هر چیزی که اتصال‌های طولانی را می‌کُشد (تایم‌اوت NAT روی مودم، قطعی‌های چندثانیه‌ای، ری‌ست تزریقی) دقیقاً به ماینر آسیب می‌زند، حتی وقتی مرور وب روی همان خط بی‌نقص است.
برای Braiins Pool که مدل اکانت واحد دارد، سه فیلد فرم‌ور این‌ها هستند:
| فیلد | نمونه | نکته |
|---|---|---|
| URL | stratum+tcp://stratum.braiins.com:3333 |
یک URL جهانی؛ آدرس‌های منطقه‌ای قدیمی منسوخ شده‌اند |
| Worker | username.rig01 |
بخش قبل از نقطه باید دقیقاً نام کاربری اکانت باشد |
| Password | x |
معمولاً بی‌اهمیت است؛ بعضی استخرها با d=8192 سختی را ست می‌کنند |
قاعده‌های نام‌گذاری ورکر که واقعاً به کار می‌آیند: فقط ASCII و حروف کوچک، بدون فاصله، زیر ۳۲ کاراکتر، و هیچ‌وقت یک نام روی دو دستگاه. اگر ده ماینر همه worker1 باشند، آمارشان در پنل روی هم می‌افتد و دیگر نمی‌فهمید کدام دستگاه ریجکت می‌دهد؛ عیب‌یابی از همان‌جا غیرممکن می‌شود. نام را طوری بگذارید که محل را بگوید: karaj-r2-s19-04.
این تفکیک ساده نصف کار عیب‌یابی است: اگر ورکر هرگز در پنل ظاهر نشود، احراز هویت یا اتصال شکست خورده؛ اگر ظاهر شود ولی هش‌ریت صفر باشد، احراز هویت موفق بوده و مشکل جای دیگری است.
پورت‌های بالا و غیراستاندارد ارزان‌ترین چیزی هستند که یک فیلتر میانی می‌تواند دور بریزد. برای Braiins سه پورت اعلام شده است — ۳۳۳۳، ۴۴۳ و ۲۵ — و در عمل شانس‌شان یکسان نیست:
Stratum V2 رمزنگاری‌شده است و اثر انگشت ترافیک را کامل عوض می‌کند، ولی فرم‌ورِ کارخانهٔ آنت‌ماینر عموماً پشتیبانی نمی‌کند و به Braiins OS+ نیاز دارید؛ آدرس و پورت فعلی‌اش را از مستندات خودشان بگیرید، نه از مقاله.
هر سه اسلات Pool 1/2/3 فرم‌ور را پر کنید — همان اکانت با پورت‌های مختلف. اما بدانید که failover فوری نیست: فرم‌ور ده‌ها ثانیه روی استخر اول تلاش می‌کند و بعد سراغ بعدی می‌رود. یک استخر اولِ ناپایدار از یک استخر اولِ کاملاً مرده بدتر است، چون مدام برمی‌گردد سراغش.
پروکسی استراتوم یک اتصال داخلی به شما می‌دهد و خودش یک اتصال به بالادست نگه می‌دارد. چیزی که حل می‌شود دسترس‌پذیری است، نه فیزیک: تأخیر کل شما می‌شود «شما تا پروکسی» به‌علاوهٔ «پروکسی تا استخر». اگر پروکسی داخل ایران باشد، پای اول ۵ تا ۳۰ میلی‌ثانیه است و پای دوم ثابت.
سه چیز عوض می‌شود که باید قبل از تصمیم بدانید:
۱. نام ورکر شما بالادست بازنویسی می‌شود. در مدل اکانت تجمیعی، همهٔ هش‌ریت زیر یک حساب می‌رود؛ پس ورکر خودتان را در پنل استخر اصلی پیدا نمی‌کنید. حسابداری منتقل می‌شود به دفترِ اپراتور. این معاملهٔ واقعی است: شما به شمارندهٔ شیرِ کسی دیگر اعتماد می‌کنید. حداقل چیزی که باید بخواهید، عدد accepted و stale به‌تفکیک هر ورکر است، نه فقط یک موجودی. (هشریال هم همین مدل را دارد و کارمزد ۲٪ را روی جریان شیر برمی‌دارد؛ رکورد هر کاربر سمت خودش نگه داشته می‌شود.)
۲. کارمزدها روی هم سوار می‌شوند — کارمزد استخر بالادست به‌علاوهٔ کارمزد واسط.
۳. یک نقطهٔ شکست اضافه می‌شود. پروکسی که بخوابد، ماینر شما بیکار است حتی وقتی استخر سلامت کامل دارد. اگر استخر بین‌المللی هرچند لنگ‌زنان در دسترس است، آن را در اسلات ۳ نگه دارید.
از یک لپ‌تاپ روی همان سوییچ، به همین ترتیب:
nslookup stratum.braiins.com — اگر جواب یکی از آدرس‌های 10.10.34.x بود، سر DNS فیلتر شده‌اید و اصلاً به مقصد نرسیده‌اید.nc -vz stratum.braiins.com 3333 (روی ویندوز: Test-NetConnection -ComputerName stratum.braiins.com -Port 3333). بی‌پاسخ ماندن SYN یعنی بسته دور ریخته می‌شود؛ RST فوری یعنی ری‌ست تزریقی.printf '{"id":1,"method":"mining.subscribe","params":["t"]}\n' | nc stratum.braiins.com 3333. برگشتن یک خط JSON تنها آزمونی است که ثابت می‌کند مسیر در سطح محتوا هم باز است. مرحلهٔ ۲ می‌تواند موفق باشد و این یکی شکست بخورد — دقیقاً همان‌جاست که بازرسی محتوا دارد کار می‌کند.ping -c 600. به درصد loss و mdev نگاه کنید، نه به میانگین.و بعد این جدول، که مفیدترین بخش کل ماجراست:
| نشانه | معمولاً یعنی |
|---|---|
| ورکر هرگز در پنل ظاهر نمی‌شود | نام اکانت/ورکر، یا پورت بسته |
| ظاهر می‌شود، هش‌ریت صفر | احراز هویت اوکی؛ submit مسدود یا سخت‌افزار خوابیده |
| هر چند دقیقه reconnect | تایم‌اوت NAT، افت لینک، یا ری‌ست تزریقی |
| همهٔ ماینرها، در همان لحظه، در دو سایت جدا | استخر یا مسیر بالادست |
| یک ماینر از ده ماینر | همان دستگاه: برد، فن، کابل، تغذیه |
همبستگی بین دستگاه‌ها را همیشه اول چک کنید. یک ماینر خراب از ده ماینر، هیچ‌وقت مشکل استخر نیست.
شیر پذیرفته‌شده (accepted) یعنی کار معتبری برای جابِ جاری تحویل داده‌اید. stale یعنی جواب برای جابی رسید که دیگر جاری نبود. آستانهٔ سلامت: زیر ۱٪، و روی یک دستگاه سالم معمولاً زیر ۰٫۵٪.
حالا بحث اصلی. فرض کنید تأخیر رفت‌وبرگشت تا اروپا ۱۲۰ میلی‌ثانیه است و بازهٔ آسیب‌پذیر پس از هر بلاک — انتشار بلاک تا استخر، ساخت جاب جدید، رسیدن mining.notify به شما — حدود ۰٫۴ ثانیه. بلاک‌ها به‌طور میانگین هر ۶۰۰ ثانیه پیدا می‌شوند. سهم شیرهایی که در این بازه گیر می‌افتند:
۰٫۴ ÷ ۶۰۰ ≈ ۰٫۰۷٪
حتی اگر بازه را سخاوتمندانه ۱ ثانیه بگیریم، به ۰٫۱۷٪ می‌رسیم. پس تأخیر جغرافیایی نمی‌تواند ریجکت ۳٪ بسازد. اگر عدد شما ۳٪ است، دنبال این‌ها بروید:
low difficulty share: شیرِ زیر تارگت. تقریباً همیشه محلی است — اورکلاک، حرارت، برد معیوب، افت ولتاژ منبع.duplicate share: تنظیم غلط پروکسی یا برخورد extranonce.unauthorized: نام ورکر.job not found / stale واقعی: بستهٔ گم‌شده و بازارسال. اینجا به loss و jitter نگاه کنید، نه ping میانگین. یک خط با ۳٪ اتلاف بسته می‌تواند stale بسازد، در حالی که میانگین تأخیرش عالی به نظر می‌رسد.دو تلهٔ رایج در خواندن همین اعداد: خطای سخت‌افزاری (HW) ستون جداگانه‌ای است و همیشه محلی — دستگاهی با ۲٪ خطای سخت‌افزاری بدون توجه به استخر ۲٪ درآمد از دست می‌دهد. و اگر تعداد شیرها نصف شد ولی هش‌ریت تغییر نکرد، استخر سختی (vardiff) را بالا برده؛ این ایراد نیست.
حساب کنیم. یک دستگاه ۱۰۰ تراهش با سختی ۶۵۵۳۶ در ثانیه 10^14 ÷ (65536 × 2^32) ≈ ۰٫۳۶ شیر می‌فرستد، یعنی حدود ۲۱ شیر در دقیقه. هر submit با پاسخش حدود ۲۶۰ بایت است؛ به‌علاوهٔ جاب‌ها (هر ۳۰ ثانیه چند کیلوبایت) و سرِ بستهٔ TCP/IP، جمعاً چیزی حدود ۲۵۰ بایت بر ثانیه ≈ ۲۲ مگابایت در روز ≈ زیر ۱ گیگابایت در ماه. این تخمین است و به سختی‌ای که استخر می‌دهد حساس؛ اما مرتبهٔ بزرگی‌اش درست است — و عددِ «۳۲ کیلوبایت بر ثانیه» که در مقاله‌های فارسی دست‌به‌دست می‌شود، بیش از صد برابر این است.
نتیجهٔ عملی: پهنای باند هیچ‌وقت مشکل نیست. پایداری مشکل است. یک خط ۱ مگابیت با ۰٫۲٪ اتلاف، برای ماینینگ از یک خط ۵۰ مگابیت با ۳٪ اتلاف بهتر است.
هیچ عددی دربارهٔ مجوز، تعرفهٔ برق ماینینگ یا ساعات ممنوعه را — از این متن یا هر متن دیگری — به‌عنوان وضعیت روز نپذیرید. تعرفهٔ ماینینگ فرمولی است که به‌صورت فصلی بازتنظیم می‌شود و ضریب‌های ساعتی دارد؛ هر مقاله‌ای که آن را یک عدد ثابت بنویسد، فصل بعد غلط است. مرجع، اعلامیهٔ رسمی توانیر و شرکت توزیع منطقهٔ خودتان و صورت‌حساب واقعی خودتان است. وضعیت حقوقی اتصال از مسیرهای جایگزین هم روشن نیست؛ خودتان تصمیم بگیرید و به کسی که برایتان قطعی حرف می‌زند اعتماد نکنید.
یک کار آخر که ارزشش را دارد: از روز اول برای هر ماینر لاگ بگیرید — تاریخ، پورت، درصد stale، درصد HW. سه هفته بعد که سؤال «مشکل از استخر است یا از من؟» پیش بیاید، جواب در همان فایل است.
Hashrial is a Bitcoin mining pool proxy with 2% fees. Connect your ASIC miners and earn BTC with high reliability, real-time monitoring and instant payouts.