منظومة bitcoind + LND على Garrison بسعر 7.90$/شهر، موجَّهة عبر Tor افتراضياً، وجاهزة لـ BTCPay. استضافة خالية من KYC لتوجيه دفعات خالية من KYC — التماثل مهم.
Garrison بسعر 7.90$/شهر يشغّل bitcoind مُقَلَّماً + LND بأريحية؛ Ravelin بسعر 16.90$/شهر يحمل الشبكة الرئيسية الكاملة ~700 GB على NVMe مع متسع لـ BTCPay.
توجيه Tor فقط افتراضياً — عقدتك هي .onion، لا تسرّب IP للرسم العام لـ LN، ولا بصمة مسح منافذ. Clearnet+Tor يبقى متوفراً لعقد التوجيه.
تسجيل خالٍ من KYC + فوترة بالعملات المشفرة فقط + قضاء شمالي بدون التزام معاهدة KYC-AML بتسجيل أرباح رسوم التوجيه. متماثل حتى النهاية.
الخاصية البارزة لـ Bitcoin — "لا تثق، تحقّق" — تنحدر إلى "لا تثق، اسأل مزوّد محفظة" في اللحظة التي تستخدم فيها محفظة وصاية أو عميلاً خفيفاً. تشغيل bitcoind الخاص بك يعني أن كل معاملة توقّعها أو تتلقاها تتم التحقق منها بنسختك الخاصة من قواعد التوافق؛ وكل UTXO تنفقه يعرفه عقدتك مباشرةً. التحقق هو ما صُمم البروتوكول لتمكينه؛ والاستضافة الذاتية هي ما تجعله واقعاً.
Lightning يُضاعف الحجة. اقتصاديات عقدة التوجيه، وانضباط رصيد القناة، واستراتيجية الرسوم on-chain عند الإغلاق القسري — لا تريد تفويض أيٍّ من هذه القرارات لطرف ثالث يحمل مفاتيحك. كُتبت مواصفة Lightning افتراضاً أن المشغّل يتحكم بالصندوق؛ التشغيل في وصاية شخص آخر منتج مختلف (وأسوأ).
VPS صغير يجعل هذا قابلاً للتنفيذ. Garrison يشغّل bitcoind مُقَلَّماً + LND مع متسع متبقٍ؛ Ravelin يحمل تاريخ الشبكة الرئيسية كاملاً على NVMe إذا كانت حالة استخدامك تطلبه. BTCPay Server يأتي فوقه لتدفقات التجار. المسار بأكمله — من تلقي الساتوشيات إلى توجيه HTLCs إلى إصدار الفواتير — يعمل على صندوق واحد (أو اثنين) تديره أنت.
السؤال الصحيح ليس "استضافة ذاتية أم وصاية" بشكل مجرّد — بل هو "هل أعامل مفاتيحي كملك لي، أم كمنتج لشخص آخر". إذا كانت الإجابة هي الأولى، فإن باقي هذه الصفحة هو الوصفة.
لـ bitcoind مُقَلَّم + LND على Tor — الإعداد المبتدئ النموذجي الذي يتعامل مع الدفعات الشخصية ومجموعة صغيرة من القنوات ووضعية توجيه دفعات خاصة — فإن Garrison (7.90$/شهر، 4 vCPU، 8 GB، 240 GB NVMe) هو الفئة المناسبة. bitcoind المُقَلَّم يستقر حول 5 GB، وLND يضيف 1–3 GB، والـ 200+ GB المتبقية لك لسجلات اللوغات ونسخ حالة القناة الاحتياطية وإعادة IBD العرضية.
لـ bitcoind أرشيفي كامل (~700 GB ويتنامى) بالإضافة إلى LND أو CLN بالإضافة إلى BTCPay Server على الصندوق نفسه، فإن Ravelin (16.90$/شهر، 8 vCPU، 16 GB، 480 GB NVMe) هو الخيار الصحيح. NVMe هو الجزء الذي يهم — كتابات UTXO في Bitcoin Core ثقيلة جداً من حيث الإدخال/الإخراج العشوائي أثناء التحقق، والفرق بين NVMe وSATA يظهر كساعات مقابل أيام في IBD، وثوانٍ مقابل دقائق في اللحاق برأس الكتلة.
لعقدة توجيه جدّية — فتح عشرات القنوات، التحسين لإيرادات الرسوم، تشغيل استراتيجية سيولة مُدارة بنشاط — فإن متسع فئة Bulwark أو تقسيم إلى صندوقين (bitcoind على فئة، وLND + BTCPay على أخرى، مرتبطين عبر WireGuard) هو الخطوة التالية الطبيعية. يسعدنا شرح هذا التخطيط؛ افتح تذكرة معنا عندما تصل إلى هناك.
ما لا تكون أي من هذه: خدمة Lightning وصائية للمستخدمين النهائيين. NordBastion يستضيف الصندوق — المفاتيح وحالة القناة وسياسة التوجيه ووصاية الأموال كلها بالكامل في نطاق المشغّل.
رسم هيكلي — تبقى وثائق Bitcoin Core ودرس LND المراجع النموذجية للضبط الدقيق. التدفق أدناه هو مسار أقل احتكاك.
من PPA الخاص بـ bitcoin.org لـ Ubuntu أو من الأرشيف الرسمي مع توقيع GPG موثق. لا تثق بحزم توزيعات عشوائية في هذه الحالة.
add-apt-repository \
ppa:bitcoin/bitcoin
apt update && apt install \
bitcoindوضع مُقَلَّم، ZMQ مفعَّل (LND يحتاج إلى تغذيات الكتل والمعاملات)، RPC مقيّد بـ localhost. أبقِه في الحد الأدنى في البداية.
prune=550
zmqpubrawblock=tcp://127.0.0.1:28332
zmqpubrawtx=tcp://127.0.0.1:28333
rpcbind=127.0.0.1~24 ساعة مُقَلَّم على Garrison، ~48 ساعة أرشيفي كامل على Ravelin. استخدم tail على debug.log وbitcoin-cli getblockchaininfo للتقدّم.
systemctl enable \
--now bitcoind
bitcoin-cli \
getblockchaininfoمن ثنائيات إصدار lightninglabs، بتوقيع موثق. tor.active=true والاستماع حصراً على خدمة .onion.
# /etc/lnd/lnd.conf
[tor]
tor.active=true
tor.v3=true
tor.streamisolation=truelncli create يكتب البذرة مرة واحدة — اكتب الكلمات الـ 24 على ورق، بلا استثناءات. ثم فعّل شحن channel.backup خارج الصندوق فوراً.
lncli create
# سجّل بذرة الـ 24 كلمة دون اتصال# شحن channel.backup عبر rclone خارج الصندوق عند التغييراختر مركزاً جيد الاتصال (سوق LN+، Amboss، BoltzExchange) وافتح بمعدل رسوم مناسب لظروف mempool الحالية. راقب تأكيدها.
lncli openchannel \
<NODE_PUBKEY> 1000000 \
--sat_per_vbyte 8توجيه دفعات خالية من KYC من مضيف أجرى عليك KYC كاملاً يعيد إدخال نقطة الاختناق التي صُمم Bitcoin لإزالتها — فقط طبقة واحدة أدنى. التسجيل الخالي من KYC والفوترة بالعملات المشفرة فقط وعدم وجود بطاقة مسجلة يعني أن سلسلة العهدة لـ "من يدير عقدة التوجيه هذه" لا يمكن استدعاؤها عبر قسم فوترة المضيف. البروتوكول بدون استئذان؛ والمضيف على الأقل صديق لـ "بدون استئذان".
السويد وفنلندا والنرويج وآيسلندا لا تفرض إبلاغ KYC-AML على مشغّلي البنية التحتية الذين تصادف استضافتهم لعقد Bitcoin — تشغيل عقدة ليس نشاطاً مالياً منظماً في أي من الأربع. لا يوجد مكافئ لإيداع MSB أمريكي لـ "أنا أمرّر HTLCs"، ولا التزام علينا كمضيف بمعرفة أي محفظة كسبت أي رسوم توجيه. السجلات ببساطة لا توجد عندنا.
NVMe في كل فئة — وليس كتحسين مدفوع — يحوّل مسار التحقق الثقيل بكتابات UTXO في Bitcoin Core إلى حدث غير ذي بال، ويُبقي استيعاب gossip لرسم قناة LND سريعاً. الوصلة الصاعدة غير المحسوبة 1 Gbps تستوعب تنزيل IBD وgossip الاستقراري دون فوترة إضافية. مواصفتان يبيعهما المضيفون غالباً منفصلتين؛ هنا هما خط الأساس.
الاستضافة الذاتية لعقدة Bitcoin + Lightning هي التعبير التشغيلي عن خاصية "لا تثق، تحقّق" التي صُمم البروتوكول من أجلها. بنحو سعر فئة "مميزة" واحدة لمحفظة وصائية تحصل على بنية تحتية للتحقق + قنوات التوجيه مفاتيحها تعيش على صندوقك، ورسوم توجيهها لا تلمس طرفاً ثالثاً أبداً، ومضيفها لا يعرف لمن تعود محفظتها.
NordBastion رأيي بشأن الأجزاء التي تهم لهذه المهمة بالذات — تسجيل خالٍ من KYC بحيث تتوقف سلسلة العهدة عند رصيدك المدفوع مسبقاً، قضاء شمالي بدون التزام إبلاغ على غرار MSB، NVMe في كل فئة بحيث لا يستغرق IBD أسبوعاً — وعادي عمداً بشأن البقية. bitcoind هو bitcoind. LND هو LND. Tor هو الخدمة الرسمية. الصندوق هو الصندوق.
مسار التقليم-ثم-النموّ هو الوضعية الابتدائية الصحيحة: شغّل العقدة، افتح أول قناة، اجعل مهمة rclone لشحن channel.backup خارج الصندوق تعمل. قرارات عقدة التوجيه الجدّية يمكن أن تأتي لاحقاً، على Bulwark أو تقسيم بصندوقين. العقدة الأولى هي Garrison وسهرة.
الأسئلة الثمانية التي يطرحها مشغّلو العقد فعلاً قبل lncli openchannel. انضباط النسخ الاحتياطي للقناة هو السؤال الرابع لسبب وجيه.
لخادم توجيه دفعات وواجهة BTCPay، يكفي pruned=550 (~5 GB على القرص) كفاية تامة — تحتاج LND وCLN وBTCPay فقط إلى مجموعة UTXO وتاريخ الكتل الحديث للتحقق والتوجيه. يخفض التقليم متطلب التخزين من ~700 GB إلى GB من خانة واحدة، ويقلّص عبء IBD-ثم-المواكبة من "أسابيع" إلى "أيام". شغّل الأرشيفي الكامل فقط إذا كانت لديك حالة بحث أو متصفح كتل تحتاج وصولاً إلى بيانات الكتل التاريخية بحسب الارتفاع؛ وإلا فإن التقليم يفوز على كل محور تشغيلي.
LND هو الأكثر نشراً (~70% من رسم Lightning العام)، ولديه أكبر منظومة أدوات (Thunderhub وride-the-lightning وBalance of Satoshis) وأكثر تكامل BTCPay صقلاً. Core Lightning (CLN) هو القاعدة البرمجية الأكثر تحفظاً، ولديه أنظف بنية للمكوّنات الإضافية، وهو ما يشغّله كثير من مشغّلي مشغّلي العقد لأسباب أعمال التوجيه. Eclair هو تنفيذ Scala، يُرى غالباً خلف محفظة ACINQ. لأول عقدة، LND على Garrison هو المسار الأقل احتكاكاً؛ CLN هو الخيار الصحيح إذا أردت دفع أداء التوجيه واهتممت بقابلية توسيع المكوّنات الإضافية.
Tor فقط (tor.active=true، بدون مستمع clearnet) هو الإعداد الافتراضي المتطرف للخصوصية — يمكن الوصول إلى عقدتك فقط بصفة .onion، بدون تسرّب IP، وبدون بصمة مسح منافذ. Clearnet + Tor (مستمع مزدوج) يمنح اكتشاف قنوات أفضل وكموناً أقل للتوجيه على حساب كشف IP عقدتك للرسم العام. يبدأ معظم المشغّلين بـ Tor فقط لأن التكلفة التشغيلية لفتح منفذ clearnet ليست بسيطة (جدار حماية، المنفذ 9735، تحديد دقيق لسجلات LN) ويتدرّجون إلى المزدوج عندما يهتمون فعلاً بتحسين رسوم التوجيه.
استخدم النسخ الاحتياطي الثابت للقنوات (SCB) — يكتب LND ملف channel.backup كلما فُتحت قناة أو أُغلقت، وهذا الملف كافٍ لاستعادة الأموال on-chain (إغلاق قسري من جانب الطرف المقابل) ولكن ليس لاستئناف القنوات. شحّن channel.backup خارج الصندوق عند كل تغيير (rclone إلى Backblaze مشفّر، أو نص برمجي صغير يرفعه إلى VPS منفصل). القاعدة الوحيدة التي تكلّف الناس ساتوشيات: لا تستعِد أبداً قاعدة channel.db قديمة. استعادة حالة قديمة تُحفّز معاملة العدالة للطرف المقابل وتخسر أموال القناة. SCB هو المسار الآمن.
محفظة عقدة توجيه Lightning ساخنة بالضرورة بحكم التعريف — يجب على المفاتيح توقيع التزامات HTLC في الوقت الفعلي. الانضباط هو الحجم: احتفظ فقط بما تحتاجه لأرصدة القنوات التي تديرها، وعامِل محفظة عقدة التوجيه كرصيد عمل (لا كمدّخرات)، وانقل الرصيد on-chain الزائد إلى تخزين بارد بإيقاع منتظم. لمشغّل صغير الحجم، 500$–2,000$ في المحفظة الساخنة نموذجي؛ ولعقدة توجيه جدّية، الرصيد الساخن يعكس سعة القناة التي التزمت بها.
عقدة مُقَلَّمة على Garrison بـ 4 vCPU / 8 GB / 240 GB NVMe تُكمل IBD خلال ~24 ساعة عبر وصلة صاعدة 1 Gbps — معظم ذلك الوقت يُنفَق في التحقق من التواقيع، وهو محكوم بالمعالج. عقدة أرشيفية كاملة على Ravelin (8 vCPU / 16 GB / 480 GB NVMe) تُكمل خلال ~48 ساعة. NVMe مهم: الأقراص الدوّارة تحوّل IBD إلى شأن متعدد الأيام لأن كتابات UTXO في Bitcoin Core ثقيلة جداً من حيث الإدخال/الإخراج العشوائي. NordBastion يأتي بـ NVMe في كل فئة.
تتوقع منظومة docker-compose لـ BTCPay Server وجود bitcoind + تنفيذ LN + nbxplorer + طبقة BTCPay الويب. على Ravelin يمكنك استضافة المنظومة كاملةً على صندوق واحد لتاجر صغير (بضعة آلاف معاملة سنوياً)؛ أما على Garrison فالضغط حقيقي بمجرد أن تبدأ فهارس nbxplorer بالعمل، لذا نوصي بفصل BTCPay على فئة ثانية — Garrison للعقدة، وSentinel لـ BTCPay يعمل كوكيل عكسي عبر WireGuard إلى العقدة. كلا التدفقين خالٍ من KYC من البداية إلى النهاية.
عرض قيمة Bitcoin هو التسوية بدون استئذان. في اللحظة التي تعمل فيها بنيتك التحتية للتوجيه على مضيف يعرف عملاءه، ويطبّق AML، ويحتفظ ببطاقة مسجلة، فإنك أعدت إدخال نقطة اختناق — ليس في طبقة البروتوكول، بل في طبقة البنية التحتية. الاستضافة الخالية من KYC لبنية تحتية للدفع خالية من KYC ليست مذهبية مطلقة؛ بل هي إزالة المكان الذي يمكن فيه استدعاء سلسلة العهدة لـ "من يدير عقدة التوجيه هذه". البروتوكول بدون استئذان؛ والمضيف ينبغي أن يكون على الأقل صديقاً لـ "بدون استئذان".
تبرّع بنطاق ترددي شمالي لشبكة Tor — الجار الطبيعي لعقدة Lightning موجَّهة عبر Tor على حساب المشغّل نفسه.
مخرج VPN بسرعة النواة على Sentinel — للاتصال عبر ssh بعقدتك وواجهة BTCPay عبر النفق الخاص بك.
Synapse مشفّر من الطرف إلى الطرف — للمشغّل الذي يدير منظومة سيادته الخاصة بين المراسلة والمال جنباً إلى جنب.
استضافة خاصة، مبنية في الشمال.