暗号資産 · KYC不要
Bitcoin Core (bitcoind) をオフショアVPSでホスト
自分自身でBitcoin Coreのフルノードを運用することは、他人のサーバーを信用するのではなく、チェーンを自らの手で検証できる唯一の方法です。そしてオフショアのノーKYC VPSを使えば、自分の身元と結び付けることなくそれを実現できます。
概要
Bitcoin Core（bitcoind）はBitcoinプロトコルのリファレンス実装です。すべてのブロックとトランザクションをダウンロードして独自に検証し、ピアへ中継し、ウォレットやアプリが信頼できるJSON-RPCインターフェースを公開します。フルノードを運用すれば、セルフカストディ級の検証、パブリックなブロックエクスプローラーからのプライバシー保護、そしてウォレット・Lightningノード・Electrumサーバー（Fulcrum/electrs）・BTCPay Serverのバックエンドが手に入ります。
オフショアでホストする理由
ノードのIPアドレスは接続するすべてのピアに見えてしまうため、暗号資産払いで身元不要のVPSから運用することで、自宅回線や本名と切り離しておけます。ChainVPSはノーKYCで帯域無制限なので、初期ブロックダウンロード（IBD）や継続的なピアリレーで数百ギガバイトが動いても、従量制の上限を超えて困ることがありません。
デプロイ
実際に動作するリファレンス構成
これを新しいChainVPSインスタンスにコピーしてください。プレースホルダーを置き換えてから起動します。
# docker-compose.yml — Bitcoin Core full node (pruned by default for a small VPS)
# 1) Generate an RPC credential first (do NOT store a plaintext password):
# curl -sSL https://raw.githubusercontent.com/bitcoin/bitcoin/master/share/rpcauth/rpcauth.py \
# | python3 - bitcoin
# It prints an rpcauth=... line and a matching password. Paste the rpcauth line below.
# 2) docker compose up -d then follow IBD: docker compose logs -f
services:
bitcoind:
image: bitcoin/bitcoin:28.1
container_name: bitcoind
restart: unless-stopped
stop_grace_period: 2m
user: "1000:1000"
ports:
- "8333:8333" # P2P — public, lets you serve/accept peers
- "127.0.0.1:8332:8332" # RPC — bound to localhost ONLY, never expose
volumes:
- ./bitcoin-data:/home/bitcoin/.bitcoin
command:
- -printtoconsole
- -server=1
- -listen=1
- -prune=10000 # ~10 GB of blocks; set -prune=0 -txindex=1 for a full archival node
- -dbcache=1024 # MB; raise to 2048-4096 on bigger boxes to speed IBD
- -maxmempool=300
- -maxconnections=40
- -rpcbind=0.0.0.0 # binds inside the container; host mapping keeps it on 127.0.0.1
- -rpcallowip=172.16.0.0/12 # docker bridge range, so host-side tools can reach RPC
- -rpcauth=bitcoin:REPLACE_WITH_GENERATED_HASH # <-- paste rpcauth output here
- -disablewallet=1 # node-only; drop this line if you want the built-in wallet
# First run needs ./bitcoin-data owned by uid 1000: mkdir -p bitcoin-data && sudo chown 1000:1000 bitcoin-dataファイアウォール
開放するポート
| ポート | プロトコル | 用途 |
|---|---|---|
| 8333 | TCP | Bitcoin P2P — ピアの受け入れと提供を行う。外部に公開すべき唯一のポート |
| 8332 | TCP | JSON-RPC制御インターフェース — 127.0.0.1のみにバインドし、SSHトンネルまたはプライベートネットワーク経由でアクセスすること |
| 28332/28333 | TCP | Lightningノードやelectrumサーバー向けのオプションのZMQブロック/トランザクション通知。localhostのみ |
| 9050 | TCP | bitcoindをTor経由で動かしピアレベルのプライバシーを確保する場合に使う、オプションのローカルTor SOCKSプロキシ |
適正サイジング
必要なプラン
VPS Small (2 vCPU / 4 GB RAM / 60-80 GB NVMe)
prune=10000なら約10 GBのブロックデータと約10 GBのchainstateのみを保持しつつ、チェーン全体を検証します。過去のブロックデータが不要なウォレット/Lightningのバックエンドに最適です。
VPS Pro or Storage VPS (4 vCPU / 8 GB RAM / 1 TB disk)
prune=0にするとすべてのブロックを保存します（2026年時点で約650 GB、さらに増加中）。Storageプランなら大容量ディスクを低コストで確保でき、帯域無制限が初期ブロックダウンロード全体とピアリレーをカバーします。
専用サーバーまたは大容量Storage VPS (8+ vCPU / 16-32 GB RAM / 1.5-2 TB NVMe)
txindex=1とFulcrum/electrsを組み合わせると大規模なアドレスインデックスが追加され、多数のウォレットクライアントに対応できます。dbcacheやインデックス再構築のために高速なNVMeとRAMが必要です。
最適なロケーション: ChainVPSの帯域は無制限なので、15拠点のどこを選んでも問題ありません。ノードの数百ギガバイト規模のIBDと継続的なリレーには、まさにこれが必要です。身元を明かさずに運用したい場合は、プライバシー重視の拠点 — アイスランド、スイス、モルドバ、オランダ、ルーマニア、ルクセンブルク — を選べば、ノードがあなたの本名と結び付けられることはありません。長期間稼働させるノードをTor経由で運用し、安定したプライバシーフレンドリーな拠点を求めるなら、アイスランドやスイスのような法域も良い選択です。
セキュリティを固める
セキュリティ強化チェックリスト
- ポート8332を絶対にインターネットへ公開しないこと。上記のとおりRPCのマッピングは127.0.0.1のままにし、`ssh -L 8332:127.0.0.1:8332 user@server` 経由でアクセスします。外部から到達可能なRPCに脆弱/推測可能な認証情報が使われていると、ノードの資金が抜かれたり乗っ取られたりする典型的な原因になります。
- -rpcuser/-rpcpasswordではなく-rpcauth（ソルト付きハッシュ）を使うことで、composeファイルやプロセスリストに平文パスワードが残らないようにします。サーバーを他人と共有したりスナップショットを取ったりした場合は、必ずローテーションしてください。
- ピアレベルのプライバシーを確保するにはTor経由で運用します。ホストにtorをインストールし、-proxy=127.0.0.1:9050 -listen=1 -bind=127.0.0.1にonionサービスを追加すれば、ピアからはVPSのIPではなく.onionアドレスが見えるようになります。クリアネットのピアを一切持ちたくない場合は、-onlynet=onionも組み合わせてください。
- ufwでファイアウォールを固めます。インバウンドは22番（SSH、理想的には鍵認証のみ＋ポート変更）と8333番のみを許可し、それ以外はすべて拒否してください。bitcoindはいずれにせよ自らアウトバウンドのピア接続を開始します。
- ディスク使用量を監視してください。プルーニングノードは約20 GBで安定しますが、非プルーニングノードは継続的に増加します。ディスク使用量アラートと十分な余裕を確保しておきましょう。ディスクが満杯になると検証が停止し、強制クラッシュ時にchainstateが破損する恐れがあります。
- stop_grace_period（上記では2m）を設定し、強制killではなく必ず`docker compose stop`を使用してください。bitcoindはLevelDBのchainstateを正常にフラッシュするための時間が必要で、そうしないと次回起動時に時間のかかる再インデックスが発生するリスクがあります。
質問
ホスティング Bitcoin Core (bitcoind) — FAQ
実際にはどれくらいのディスク容量が必要ですか?
プルーニングノード（設定でprune=10000）なら約15〜20 GBに収まり、それでもチェーン全体を検証します。完全なアーカイブノードはすべてのブロックを保存するため、2026年時点で約650 GB、年間およそ50〜70 GBずつ増加します。1 TB以上を見込んでおきましょう。txindex=1やElectrumサーバーを追加する場合は、高速なNVMeで1.5〜2 TB程度が必要になります。
初期ブロックダウンロード（IBD）にはどれくらい時間がかかりますか?
帯域無制限でdbcache=2048以上を設定した最新のVPSであれば、CPUとディスク速度にもよりますが、ジェネシスブロックから完全に同期・検証するまで数時間〜1日程度で済みます。初回同期中に-dbcacheを増やすことが最大の高速化策です。これは一度きりのコストで、それ以降ノードは新しいブロックのみをダウンロードします。
このノードに対してLightningノードやElectrumサーバーを運用できますか?
はい、可能です。ZMQを有効化し（ポート28332/28333で-zmqpubrawblockと-zmqpubrawtxを追加）、LND、Core Lightning、Fulcrum、electrsをローカルDockerネットワーク経由でRPCおよびZMQエンドポイントに接続してください。ただしFulcrum/electrsはtxindex=1が必要なため、プルーニングノードと組み合わせることはできません。
プルーニングノードはセキュリティやプライバシーの面で劣りますか?
いいえ、劣りません。プルーニングノードはアーカイブノードと全く同じように、すべてのブロックとトランザクションを完全に検証します。違いは検証後に古いブロックデータを破棄する点だけです。ウォレットのセキュリティとプライバシーは同一です。失われるのは、他のピアに過去のブロックを提供したり、任意の古いトランザクションを再スキャンしたりする機能だけです。
自分のノードのIPは他者から見えてしまいますか?
はい — 仕組み上、接続するすべてのピアにノードのIPが見えます。だからこそノーKYCのオフショアVPSで運用することが有効なのです。そのIPは、あなたの身元や自宅回線と一切結び付いていないサーバーのものになります。ピアレベルで完全なプライバシーを確保したい場合は、上記のセキュリティ強化のヒントに従ってbitcoindをTor経由で運用し、ピアには.onionアドレスだけが見えるようにしてください。
セルフホストをもっと見る