Ваш собственный узел Bitcoin.
Ваши собственные каналы Lightning. Без KYC, от начала и до конца.

Для платёжного маршрутизирующего узла и фронтенда BTCPay pruned=550 (~5 ГБ на диске) более чем достаточно — LND, CLN и BTCPay нужны лишь набор UTXO и недавняя история блоков для валидации и маршрутизации. Pruned снижает требования к хранилищу с ~700 ГБ до однозначного числа гигабайт и сокращает нагрузку IBD-затем-догнать с «недель» до «дней». Запускайте полный архивный режим только если у Вас есть исследовательский сценарий или сценарий блок-эксплорера, требующий доступа к историческим данным блоков по высоте; в остальных случаях pruned выигрывает по всем операционным осям.

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-related логов), и переходят к двойному режиму, когда им действительно становится важна оптимизация маршрутизирующих комиссий.

Используйте Static Channel Backups (SCB) — LND записывает channel.backup при каждом открытии или закрытии канала, и этого файла достаточно для восстановления on-chain средств (через force-close со стороны контрагента), но недостаточно для возобновления каналов. Отправляйте channel.backup за пределы сервера при каждом изменении (rclone в зашифрованный Backblaze или крошечный скрипт, загружающий на отдельный VPS). Единственное правило, из-за нарушения которого люди теряют сатоши: никогда не восстанавливайте старый channel.db. Восстановление устаревшего состояния запускает justice-транзакцию контрагента, и Вы теряете средства в канале. SCB — это безопасный путь.

Кошелёк маршрутизирующего узла Lightning по определению является «горячим» — ключи должны подписывать обязательства HTLC в реальном времени. Дисциплина — в размере: держите только то, что нужно для балансов каналов, которыми Вы оперируете, относитесь к кошельку маршрутизирующего узла как к оборотному капиталу (а не сбережениям) и регулярно выводите избыток on-chain баланса в холодное хранение. Для оператора небольшого масштаба типично $500–$2 000 в горячем кошельке; для серьёзного маршрутизирующего узла горячий баланс отражает выделенную ёмкость каналов.

Pruned-узел на Garrison с 4 vCPU / 8 ГБ / 240 ГБ NVMe завершает IBD за ~24 часа по аплинку 1 Гбит/с — большая часть этого времени уходит на валидацию подписей, которая упирается в CPU. Полный архивный узел на Ravelin (8 vCPU / 16 ГБ / 480 ГБ 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 — расчёты без разрешения. В тот момент, когда Ваша маршрутизирующая инфраструктура работает на хостинге, который провёл KYC, выполнил AML, держит карту в файле, Вы заново ввели узкое место — не на уровне протокола, а на уровне инфраструктуры. KYC-свободный хостинг для KYC-свободной платёжной инфраструктуры — это не абсолютизм; это устранение места, где цепочку владения «кто запускает этот маршрутизирующий узел» можно вызвать в суд. Протокол не требует разрешений; хостинг должен быть как минимум дружественным к отсутствию разрешений.