BTCPay Serverで自分でBitcoin決済を受け付ける方法

あらゆるホスト型の決済代行業者は、あなたを凍結できる会社です。これはBitcoinを受け付ける誰にとっても仮定の話ではありません — 大手の決済代行業者は何年も前から本人確認、出金の閾値、決済ルールを追加しており、そのいずれかの審査に落ちた加盟店は、たいてい資金が宙に浮いた状態でそれを思い知ることになります。BTCPay Serverが存在するのは、まさにこの問題のためです。これは無料のオープンソースソフトウェアで、自分が管理するサーバーを、請求書、POS画面、ストア用プラグイン、Lightningまで備えた自分自身のチェックアウトへと変えてくれます — 間に入る会社も、差し引かれる手数料も、失うアカウントもありません。インストール自体は、本当にただの半日で終わります。結果の良し悪しを左右するのは、その下で動くマシンと、デフォルトのインストールが静かにあなたを指し示したままにしてしまう、いくつかの細部です。

BTCPay Serverが実際に置き換えるもの

ホスト型の決済代行業者は、顧客とあなたのウォレットの間に割って入ります。アドレスを生成し、チェーンを監視し、金額を換算し、しばらく資金を預かってから、最終的にあなたへ支払います。その一つひとつの工程が、業者があなたについて知る機会であり、同時に拒否できるポイントでもあります。BTCPayは同じ作業を、あなたがレンタルしたハードウェア上で行います — そして、業者が知り得ることとの差は完全なものです。

• 支払いは直接、自分自身のウォレットに届きます。BTCPayに拡張公開鍵を渡せば、請求書ごとに新しいアドレスを導出して監視してくれます — オンチェーンの支払いに関する秘密鍵を保持することは一切なく、1 satoshiたりとも動かすことはできません。
• 手数料もアカウントもありません。ソフトウェアはオープンソースで自分自身が運用するものであり、申し込むものも停止されるものもありません。
• 請求書の期限切れ、リアルタイムのレート換算、支払い不足や過払い、分割払い、返金、そして顧客が独自に検証できる領収書といった、自分で作るには面倒な部分を代わりに処理してくれます。
• ほとんどの人が必要とするフロントエンドも最初から備えています — POS画面、支払いボタン、クラウドファンディングページ、主要なECプラットフォーム向けのプラグインに加え、自分のソフトウェアに組み込みたい場合のための本格的なAPIもあります。
• 希望すれば同じデプロイメントの中でLightningも使えるようになり、これが数ドル未満の支払いをそもそも成立させてくれます。

境界線ははっきりさせておく価値があります。BTCPayはBitcoinをあなたの地元通貨に変えてくれるわけではありませんし、資金が最終的に向かう先が取引所や銀行であるなら、それらを取り除いてくれるわけでもありません。BTCPayが取り除くのは決済代行業者だけです — 手数料を差し引き、資金を一時的に預かり、そのために身元確認を求めていた、あの仲介者です。手に入るものは、自分でホストするウェブサイトと同じ形をしています:より大きなコントロールと、それに伴う手間です。

あなた自身が決済代行業者になる

その手間こそが、セルフホスティングの正直なコストであり、インストールした後よりも前に理解しておいたほうがはるかによいものです。あなたの稼働状況を監視してくれる人はいませんし、バックアップを復元してくれる人もおらず、顧客が「支払った」と主張しているのにこちらでは確認できない、まさにその瞬間にサポート窓口の向こうで待っていてくれる人もいません。

• 稼働時間の責任は自分にあります。サーバーが落ちている間は請求書を作成できないため、常に機能していなければならないチェックアウトには、誰かが実際に監視しているマシンが必要です。
• バックアップの責任も自分にあります。サーバーを失っても立ち直れますが、ウォレットディスクリプタやLightningチャネルの状態を失うと、そうはいきません。
• 鍵の管理形態は二つに分かれます。オンチェーンの資金はBTCPayが監視するだけのウォレットに置かれ、これは安全な構成です。Lightningの資金はサーバー自体のホットウォレットに置かれ、こちらは安全ではありません — その残高は運転資金として扱い、決して貯蓄だとは考えないでください。
• トラブルを仲裁してくれる者はいません。チャージバックが存在しないこと自体がおおむね狙いなのですが、同時に、あらゆる返金があなた自身の判断であり、あなた自身が送るトランザクションであることも意味します。
• 更新の責任も自分にあります。使いやすいインターフェースの裏にはBitcoinノードを含むコンテナ群のスタックがあり、公開IP上で動かし続ける他のあらゆるものと同じ保守の規律が求められます。

どれも重い作業ではありません。一度動き出してしまえば月に数分程度で済み、最初に注意深く半日かけるだけです。ただしゼロではないというだけの話であり、決済代行業者の手数料は、まさにこの部分を一部買っていたのです。

マシンのサイジング: 土台となるノードがすべてを決める

BTCPay自体は軽量なアプリケーションです。しかし、それが向き合うBitcoinノードは軽量ではなく、ここでのサイジングの失敗のほとんどは、その下にあるチェーンではなくウェブアプリの方を基準に予算を組んでしまうことから生まれます。標準的なデプロイメントではBitcoin Core、ウォレットを追跡するインデクサー、データベース、リバースプロキシ、そしてアプリケーション本体が立ち上がります — そして、ディスクとメモリと忍耐を要求するのはCoreです。

• ストレージこそが、選ぶべきプランを決定づける要素です。unprunedのチェーンは現在750 GBを超えており、月におよそ7 GBずつ増加します。このデプロイメントにはブロックデータをおよそ100 GB、50 GB、あるいは25 GBに抑えるストレージ節約プリセットが用意されており、そのいずれを選んでも、すべてのルールを自分自身で検証する本物のフルノードであることに変わりはありません。
• pruningは初回同期を短縮してくれるわけではありません。Coreはどちらにしても、ジェネシスブロック以来のすべてのブロックをダウンロードして検証します。pruningが決めるのは、その後に何を残すかだけです。
• 同期速度を生むのはメモリです。4 GBあれば動きますが、8 GBあれば目に見えて速く同期し、Lightningや、ノードとキャッシュを奪い合わずに済むデータベースの余裕も生まれます。
• NVMeは省略できません。初回同期の大部分はUTXOデータベースに対するランダムな読み書きが占めており、遅いディスクで同じ作業を行うと時間単位ではなく日単位の話になってしまいます。
• 同期が終わってしまえば帯域は取り立てて問題になりませんが、最初の同期ではチェーン全体を引っ張ってくることになります。従量制のプランはこの用途には向きません。

実際には、Lightning付きのprunedノードであればVPS-8($13.99/mo) — 4 vCPU EPYC、8 GB DDR5 ECC、120 GB Gen4 NVMe — が無難なデフォルトとなり、ディスクのことをもう二度と考えたくないならVPS-16($26.99/mo)が向いています。VPSティアはどれもGen4 NVMeをRAID-10で搭載し、転送量も無制限なので、実質的な変数は容量だけです。チェーンをunprunedのまま保ちたい場合 — 古いウォレットを再スキャンしたい、あるいはストアの隣でElectrumサーバーを稼働させたい場合 — はVPSシリーズを丸ごと飛ばしましょう:$64/moからの専用サーバーは2 × 1 TB NVMeを備え、最大のVPSティアよりも安く、はるかに余裕があります。しかもその計算は時間が経つほど不利になっていきます。ここでのトレードオフはBitcoinのフルノードを運用することで扱ったものと同じです — なぜなら、ここでやっているのはまさにそれに、チェックアウトを一つ載せただけのことだからです。

ステップバイステップ: まっさらなVPSから稼働中のチェックアウトまで

1. 01VPSをデプロイし、まず先に強化するDebianまたはUbuntuのマシンに、鍵認証のみのSSHとデフォルト拒否のファイアウォールを、価値のあるものを置く前に用意します。その手順を順序立てて示したチェックリストは、別のガイドにまとめてあります。
2. 02ドメインをサーバーに向け、80番と443番を開放するBTCPayは初回起動時に自前の証明書を発行しますが、これはホスト名がすでにそのマシンに解決されていて、両方のポートに到達できる場合にしか機能しません。この順序を逆にしてしまうことが、インストール失敗の原因として圧倒的に多いものです。
3. 03公式のDockerデプロイメントをクローンするプロジェクトは、方針の定まったコンテナ構成を配布しています。パーツを手で組み立てるのではなくこちらを使いましょう — アップグレード経路がテストされているのはこの構成に対してです。
4. 04初回実行の前にオプションを決めておくネットワーク、ホスト名、Lightningの実装、ストレージプリセットは、セットアップ時に一度だけ読み込まれる環境変数です。pruningのレベルを後から変更するのはただでは済まないため、今のうちに決めておきましょう。
5. 05セットアップスクリプトを実行し、同期させるすべてがコンテナ上で立ち上がり、Bitcoin Coreが初回ブロックダウンロードを開始します。ここが最も時間のかかる部分です — NVMeでも数時間かかります — そして急ぐことのできない唯一のステップです。
6. 06管理者アカウントをすぐに登録する最初に登録したアカウントが管理者になります。翌朝ではなく、インターフェースが応答したその瞬間に済ませましょう。
7. 07ストアにウォレットを接続するストアを作成し、ハードウェアウォレットや自分のソフトウェア内の専用アカウントから拡張公開鍵をインポートしてウォレットを接続します。BTCPayはアドレスを監視するだけで、何かに署名することは一切ありません。
8. 08実際の支払いでテストし、それからフロントエンドをつなぐ自分宛てに少額を送金し、請求書の決済が確定することを確認しましょう。POS画面やストア用プラグイン、あるいは自分のサイトが実際に呼び出すAPIをつなぐのは、そのあとです。

Lightning: 導入する価値はあるか、実際のコストは何か

オンチェーンの支払いはどこでも機能しますが、その日のmempool次第の手数料がかかるため、数ドル未満の支払いは扱いにくく、時には馬鹿げたものになります。Lightningはそれを解決してくれ、BTCPayは同じデプロイメントの中でノードを立ち上げてくれます。少額または頻繁な支払いには最適な答えです。ただしこれは、Bitcoinノードとは種類の異なる運用上のコミットメントでもあり、有効にする前に知っておく価値のある違いがあります。

• 支払いを受け取れるようになる前に、受信側の流動性(インバウンド流動性)が必要です。自分でチャネルを開いても得られるのは送金する側の容量であり、受け取る側の容量ではありません。誰かがあなたに向けてチャネルを開くか、自分でインバウンドの容量を確保するまで、あなたのノードは何も受け取ることができません。
• 残高は設計上ホットです。チャネルの資金はサーバー上のウォレットに置かれ、そうせざるを得ない事情からオンラインになっています。そこには運転資金だけを置き、残りはオンチェーンへ掃き出しましょう。
• チャネルの状態は、ファイルをコピーするだけではバックアップになりません。Lightningノードの古いスナップショットを復元すると、そこに記録されているチャネルそのものを失いかねません。その実装自身が備えるバックアップの仕組みを使い、それが実際に何を復元してくれるのかを理解しておきましょう。
• ダウンタイムのコストは、オンチェーンよりもこちらの方が大きくなります。オフラインのノードは経路構築も受信もできず、古い状態のままオンラインに戻ってくるとペナルティを受けることもあります。
• チャネルには、開くときと閉じるときの両方にオンチェーンのコストがかかります。開設と閉鎖はどちらもトランザクションであるため、小さなチャネルを次々に作る習慣は静かに高くつきます。
• あなたのノードは、公開する設定にすれば誰の目にも見えるようになります。公開告知されたノードはエイリアスとネットワークアドレスを誰にでもブロードキャストするため、あなたのサーバーが誰でも読める地図の上に載ってしまいます。

現実的な中間案は、告知しないチャネルでLightningを使い — インフラを公開せずに支払いを受け取ることができます — 高額なものについてはオンチェーンをデフォルトにすることです。ノードを、身元にはつながらない形で到達可能にしたいなら、Tor経由で稼働させましょう。これはBitcoinノードを公開IPではなくオニオンサービスの背後に置くのと同じ理屈です。

デフォルトインストールが残したままにする身元の漏洩

あなたが誰であるかを知っている決済代行業者から逃れるために、あえてBTCPayを選んだのであれば、この節が本題です。このソフトウェアは、その決済代行業者を完璧に取り除いてくれます。しかしそれだけでは、チェックアウトを一人の人間に結びつけてしまう他の要素までは取り除いてくれません — そして、そのほとんどは支払いとは無関係に感じられる手順から生じています。

• ドメイン。公開WHOISが伏せられていても、レジストラはあなたの身元を保持しており、その名前を維持するには有効な連絡先住所が必要です。セルフホストされたチェックアウトがその所有者まで辿られる最も一般的な経路は、このホスト名です。
• 証明書の透明性(Certificate Transparency)。証明書が発行された瞬間、その正確なホスト名は誰でも検索できる公開ログに記録されます。pay.somethingやbtcpay.somethingのような、非公開のつもりでいたサブドメインも、タイムスタンプ付きで世界中に告知されてしまいます。
• ホスト。サーバーを本名のカードで購入したのであれば、そこで何を動かそうと、そのマシンはあなたの本名に紐づいたままです。それは最初の請求書が発行されるよりずっと前、登録の時点ですでに決まっています。
• 拡張公開鍵。xpubをBTCPayに渡すと、その鍵が導出するすべてのアドレスを監視できるようになり、そこにはウェブアプリケーションに晒すつもりのなかった残高や履歴も含まれます。ストアには専用のアカウントを使い、メインウォレットのxpubは決して使わないでください。
• Lightningノード。告知されたノードはエイリアスとアドレスを公開します。あなたのブランドを名乗るエイリアスが、チェックアウトにも使われているIPの上に乗っていれば、その二つは公開グラフの中で恒久的に結びついてしまいます。
• 発信通信。レート提供元、プラグイン、通知連携はいずれもこのマシンから外部へ接続し、メール通知は設定したSMTPアカウントを経由して送られます。そのひとつひとつが、あなたのサーバーを見ることになる第三者です。
• 出金経路。ストアから出て本人確認済みの取引所口座へ向かうコインは、その履歴を伴ったまま到着します。この漏洩はBTCPayより下流で起きるものであり、それまでの上流での配慮をすべて台無しにしてしまう、最も多い原因です。

これらを塞ぐのは、特殊なことではなくごく普通の作業です。暗号資産に対応し、最小限の情報しか集めないレジストラを選び、あなたの身元とは結びつかないメールアドレスを渡しましょう。マシンは身元を一切尋ねてこなかったホストに置き、暗号資産の残高から支払います — Bitcoinは仮名性であって匿名ではありません。そのため、それが自分にとって重要であるなら、Moneroでチャージすることがオンチェーンの痕跡を断つことになります。そして管理画面には、資金を扱うもののログインページを晒すのではなく、WireGuardトンネル経由でアクセスしましょう。それぞれは一度きりの小さな決定ですが、積み重なることで「決済代行業者がいない」状態と、本当にプライベートな状態との違いを生み出します。

公開後も動かし続ける

1年間問題なく動いてきたチェックアウトとは、1年間誰も見ていなかったチェックアウトのことでもあります。短い保守手順が、それが最も忙しい日の障害に変わるのを防いでくれます。

• 更新は自分のペースではなく、プロジェクトのペースに合わせましょう。このデプロイメントには、対応するコンテナのバージョンをまとめて動かすアップグレード経路が用意されています — パーツを手で個別に上げていくやり方は、動いていたスタックを壊す典型的な原因です。
• 再生成できないものをバックアップしましょう:ストアのデータベースと設定、ウォレットディスクリプタ、そしてLightningを運用しているならそのバックアップです。ブロックチェーンはバックアップにはなりません — それは再ダウンロードされるだけです。
• 何も問題が起きていないうちに、あえて一度リストアを試しておきましょう。テストしていない決済システムのバックアップは、自分の収益についての仮説にすぎません。
• ディスクを監視しましょう。prunedノードのディスク使用量は安定していますが、ログやデータベースはそうではなく、ディスクが満杯になればノードが止まり、ノードが止まれば請求書の発行も止まります。
• マシンには常にパッチを当て、ポートは閉じたままにしておきましょう。最初の10分の強化チェックリストに書かれていることはすべてここにも当てはまり、しかも懸かっているものははるかに大きくなります。

ついでに、ストアに対する外部からのチェックも追加しておきましょう。外部から請求書のエンドポイントに定期的にアクセスするだけの単純な監視でも、顧客より先にチェックアウトの停止に気づけます。これが、セルフホスティングと単に到達不能であることとの、実務上の違いの大部分です。そしてマシン自体は、新しいVPSでの最初の10分が説明する通りに扱いましょう。資金を扱うマシンでは、懸かっているものがより大きいのですから。

本当にお金を失うミス

• 拡張公開鍵の代わりにシードフレーズをインポートしてしまい、公開されたウェブアプリケーションを、これまで受け取ったすべての支払いを抱えるホットウォレットに変えてしまう。
• インストーラーを実行した後でDNSを設定し、なぜ証明書が発行されずサイトも読み込まれないのか首をかしげる。
• 最も厳しいpruningプリセットを選んでおきながら、何年分もの履歴を持つウォレットを接続しようとし、ノードがもう再スキャンできないことに気づく。
• Lightningの残高を、たまたまオンラインに置かれている運転資金ではなく、貯蓄として扱ってしまう。
• データディレクトリをコピーするだけでLightningノードをバックアップしたつもりになり、それが復元手段になると思い込んでしまう。
• ウェブアプリケーションに合わせたサイズのプランを購入してしまい、初回同期の途中でディスクが尽きる。
• 管理画面を、他で使い回しているパスワードだけを盾に、インターネット全体に公開したままにしてしまう。
• それ以外のすべてを正しく行っておきながら、ドメインの登録とサーバーのレンタルだけは自分名義で行ってしまう。

BTCPayは、仲介者をより親切な別の仲介者に置き換えるのではなく、丸ごと取り除いてしまう数少ないソフトウェアの一つです。インストールにかかるのは半日、同期にかかるのは一晩です。あとに残るのは、BitcoinとLightningを受け付け、何も課金せず、何も預からず、誰にも報告しないチェックアウトです — しかもそれは、自らが集める残高から支払いを賄えるマシンの上で動いています。ノードに合わせてディスクをサイジングし、シードはサーバーから遠ざけ、そのマシンは、あなたの名前を一度も尋ねてこなかった場所に置きましょう。