Своя Bitcoin-нода на VPS

Своя нода — це межа між «повірити комусь на слово про ланцюг» і «перевірити самому». Ваша нода незалежно застосовує кожне правило консенсусу, а гаманці можуть питати вашу ноду замість публічного сервера, який тихо логує всі ваші адреси. Стіна, об яку спотикаються: повній архівній ноді потрібно 600 ГБ+ диска, і вона тільки зростає. Pruned-нода це обходить — вона так само валідує весь ланцюг, а потім викидає старі блоки, які більше не потрібні, і вкладається приблизно в 10–15 ГБ. Це влазить у невеликий VPS. Нижче — чесне «як» і в що вам обходиться прунінг.

Що реально дає нода

• Незалежна валідація. Правила застосовуєте ви самі. Нічого невалідного не пройде через вашу ноду через те, що вона повірила незнайомцю.
• Приватність власних запитів. Гаманець питає вашу ноду, а не публічний оглядач, який бачить кожну адресу, яку ви дивитеся.
• База для решти. Нода — фундамент, на який потім стає інше: Lightning, оглядачі, ваші застосунки.

Pruned проти повної — чесна суть

Під час початкової синхронізації нода завантажує й перевіряє весь ланцюг. Це приблизно 600 ГБ трафіку, один раз. Прунінг міняє лише те, що відбувається після: вона тримає свіжі блоки й скидає старі, тому підсумковий диск лишається маленьким.

Те, чим ви жертвуєте, реальне: pruned-нода не може віддавати історичні блоки іншим пірам і не може пересканувати довільну стару історію гаманця. Тож якщо будете імпортувати старий гаманець із ранніми транзакціями, потрібна повна історія — повна нода на великому диску, а не pruned. Для того щоб просто валідувати й ганяти поточні гаманці, pruned — саме те, що треба.

Що потрібно

• Диск: ~15–20 ГБ для pruned-ноди — маленької машини вистачає.
• Оперативка: 2–4 ГБ. Більше dbcache — швидше початкова синхронізація; потім можна знизити.
• Канал: нормальна пропускна здатність для разового повного завантаження.
• Доступний IP: щоб приймати вхідних пірів на порт 8333 і реально допомагати мережі, потрібен публічний IP з відкритим 8333 — тариф із виділеним IP. На NAT у вас один SSH-порт, і 8333 не відкрити.

Встановлення

Поставте bitcoind, потім мінімальний bitcoin.conf:

prune=10000        # тримати ~10 ГБ свіжих блоків
dbcache=2048       # швидше початкова синхронізація; потім знизити
listen=1           # приймати вхідних пірів

Запустіть під systemd, щоб рестартував після падіння й піднімався після ребуту, і відкрийте порт 8333, щоб піри до вас достукалися. Потім дайте синхронізуватися — це довга частина, від годин до доби-двох, бо ланцюг перевіряється від генезису.

Закрийте машину

• SSH лише за ключами, фаєрвол на 8333 і ваш SSH-порт. (Чек-лист на десять хвилин.)
• Ніколи не виставляйте RPC-порт в інтернет. Прив'яжіть його до localhost і ходіть через SSH-тунель або лише із застосунків на тій самій машині. Відкритий RPC — відчинені двері.

Чесні обмеження

• Перша синхронізація довга й ненажерлива до трафіку. Це неминуче — перевірку ланцюга з нуля не обійти конфігом.
• Pruned-нода не віддає старі блоки й не пересканує стару історію. Потрібно це? Тоді повна нода й великий диск.
• Про Monero питання справедливе, і чесна відповідь — про охоплення. Його ланцюг більший — пара сотень ГБ, і навіть pruned близько 90 ГБ, — тож йому потрібен диск більший, ніж несуть наші невеликі тарифи. Це історія про повну ноду на іншій машині, і ми краще скажемо прямо, ніж вдамо, що вона влазить.
• Обслуговування на вас: оновлення, диск, рідкі затримки з пірами. Нода — невелике зобов'язання, а не «поставив і забув».

Як платити

Реєстрація за email, оплата в USDC чи USDT — без картки й без документів. Логічний спосіб оплатити свій власний куточок Bitcoin.