支払いは自分自身で受け取る。
それを凍結できる者は、もう誰もいない。

ブロックチェーン上の支払いには、間に入る会社は要らない。顧客がトランザクションに署名し、ネットワークがそれを承認し、資金はあなたのものになる——アクワイアラーもなく、決済ウィンドウもなく、支払いの可否を握る誰の承認も要らない。それこそがこの仕組みの要点であり、この技術がそもそも存在する理由である。

そのうえで、ストアは実際に支払いを受け取る必要があり、実務上の要件が一度に押し寄せてくる。支払いを見分けられるように、インボイスにはそれぞれ専用のアドレスが要る。誰かがチェーンを監視し、インボイスがいつ支払われたかを判断しなければならない。金額は、顧客が普段考えている通貨で提示され、送金ボタンを押すまでの間もつだけのレートを保っていなければならない。注文ステータスはストアへ戻ってこなければならない。そしてそれは、誰も見ていない朝の2時にも機能しなければならない。これらすべてを構築するのは一大プロジェクトだ。それを構築しないからこそ、ほとんど誰もがホスト型ゲートウェイに登録することになる——そして、1枚のフォームを埋める間に、そもそも存在しないように設計されていたはずの仲介者を、システムに戻してしまうのだ。

その仲介者が握っているものは、手数料以上のものであるだけに、はっきり述べておく価値がある。まずコインを握っている。少なくともペイアウトが実行されるまでは、つまりそれを遅らせることができるということだ。次に一覧を握っている——すべての顧客、すべての金額、すべてのタイムスタンプ、すべての商品を、あなたが読むことも消すこともできないデータベースの中に。あなたの本人確認情報も握っている。他人のお金を扱う会社は、それを収集することを義務付けられているからだ。そしてスイッチも握っている。利用規約は、あなたの事業をもう歓迎しないと決める権利を留保しているからだ——その決定はメールで届き、アカウントだけでなく残高にも適用され、実務上、異議を申し立てることはできない。

BTCPay Server は、まさにその問題だけに対する答えだ。自分のマシンで動かす、無料でオープンソースの決済プロセッサーであり、インボイスごとにアドレスを導出し、チェーンを監視し、法定通貨建ての価格を提示し、チェックアウトとAPIを公開し、Lightningを話す。あなたのコインを保持することは決してない。監視しているウォレットは、すでにあなた自身が保有しているものだからだ。暗号通貨での支払いを受け取る4つの方法と、それぞれの実際のコストは次のとおり。

2番目の列も冗談ではない——フッターに置いた1つのアドレスは、寄付リンクとしては本当にそれで十分であり、そうではないふりをするのは、誰も必要としていないソフトウェアを売りつけることに等しい。それが十分でなくなるのは、2人が同じ日に同じ金額を支払った瞬間、あるいは、自分の年間収入を誰でも合計できる公開の数字にしたくないと思った瞬間だ。

サーバーを注文する。パネルでは注文 → VPS → Garrisonと進み、イメージはDebian 12、ストアの記録を置きたい拠点を選ぶ——ヘルシンキ、ストックホルム、オスロ、レイキャビクのいずれかだ。Garrisonが正しい既定の選択である理由は、100 GBのプルーニングされたチェーンとLightningノード、データベースを、何年もディスクのことを考え直さずに動かせるからだ。Sentinelはより厳しいプルーニングでも動く。Bulwarkはアーカイブノード向けのティアだ。アカウント開設にメールアドレスは不要で、インボイスはMonero、Bitcoin、Lightning、あるいはほかのサポートされている資産で決済できる——これがこのプロジェクトならではの気持ちいい部分だ。暗号通貨の支払いを受け取るためのマシンを組み立てていて、その代金を暗号通貨の一つで支払っているのだから。

そのあと、何よりもまず最初の1時間のハードニングチェックリストを実行する——ポートを変更した上での鍵認証のみのSSH、無人アップグレード、既定拒否のファイアウォールだ。このサーバーはやがて、あなたのすべての顧客の記録と、実際の資金が入ったLightningノードの鍵データを保持することになる。パスワード認証のまま1週間放置していいサーバーではない。

次はDNSレコードだ。しかもインストーラーを実行したあとではなく、その前に済ませておく。チェックアウトを置くホスト名を決め——shop.example.com、pay.example.com、何でも構わない——VPSのアドレスへAレコードを向け、IPv6でも到達可能にしたいならAAAAレコードも加える。それが伝播するのを待つこと。インストーラーが設定するリバースプロキシは、初回起動時にそのまさに名前の証明書を取得しようとし、その名前がすでにこのマシンを指して解決することを要求するHTTPチャレンジを使う。まだ有効になっていないレコードは、初回インストールが分かりにくいエラーで終わる、最もありふれた原因だ。

そのあと、まだ何も待ち受けていないうちにファイアウォールルールを書いておく。4つのポート、それだけだ。チェックアウトは必然的に公開のHTTPSエンドポイントになる——顧客のブラウザがそこへ到達できなければならないからだ——そしてポート80は、証明書の更新がそれを使うために開けたままにしておく。Lightningのピアツーピアポートが必要になるのは、ほかのノードがあなたに向けてチャネルを開けるようにしたい場合だけだが、ステップ05はそうすべきだと主張することになる。Bitcoinのピアツーピアポートはまったく開ける必要がない——あなたのノードはアウトバウンド接続だけで十分に機能し、インバウンドを開けても、見つけられやすくなるだけである。

ufw default deny incoming
ufw allow 47222/tcp                  # administrative SSH, moved off 22
ufw allow 80/tcp                     # ACME HTTP-01 challenge and the redirect
ufw allow 443/tcp                    # the checkout
ufw allow 9735/tcp                   # Lightning peer-to-peer, only if you want inbound channels
ufw enable
ufw status numbered

先に進む前に、リソースに関する注意点が2つある。サーバーにスワップがなければ与えておくこと——最初のブロックダウンロードはこのプロジェクトで最もメモリを食う時間であり、4 GBのRAMだけより、2 GBのスワップを添えた4 GBのほうがはるかにうまく振る舞う。そして、ステップ01のディスクの計算を、実際に注文したティアと照らし合わせておくこと。同期の途中でボリュームを埋め尽くしたノードは行儀よく失敗するのではなく、自分のインデックスを破損させてやり直すことになるからだ。

fallocate -l 2G /swapfile && chmod 600 /swapfile
mkswap /swapfile && swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab
df -h /                              # confirm the volume matches step 01

ストアを作成し、このページで実際に重要な唯一の決定を行う。BTCPayはBitcoinウォレットを紐づける2つの方法を提示する——既存のものを接続するか、新しく生成させてシードをサーバーに保持させるかだ。前者はウォッチオンリーであり、これこそが望ましい選択だ。後者は、見知らぬ相手に応答することが仕事のすべてである公開のインターネット向けマシンを、あなたの売上を保持するホットウォレットに変えてしまう。どれだけハードニングを施しても、それは割に合う取引にはならない。

この推奨の背後にある仕組みは、理解するに値するほど洗練されている。現代のウォレットは階層的だ——1つのシードが鍵の木構造を導出し、そこには拡張公開鍵——xpub、あるいはネイティブSegwit向けのzpub亜種——があり、そこからアカウント内のすべての受け取りアドレスを、署名する能力なしに計算できる。それをストアに渡せば、インボイスごとに新しいアドレスを生成し、それぞれへの支払いをチェーン上で監視し、残高を見せてくれるようになる。それは1サトシも動かすことができない。秘密鍵の側はあなたのウォレットか、ハードウェアデバイスの中にとどまり続け、外へ出ることは決してない。

そこで、Sparrow、Electrum、あるいはハードウェアウォレットのデスクトップアプリを開き、このストア専用の新しいアカウントを作成し、その拡張公開鍵をエクスポートする。ストアのウォレット設定で既存のウォレットを接続することを選び、その鍵を貼り付け、BTCPayが導出する最初の数個のアドレスを、自分のウォレットが示すものと突き合わせる。一致すれば導出パスは正しく、接続は完了だ。一致しなければ、スクリプトタイプを間違えている——xpubとzpubの違いは、まったく別の2組のアドレスの違いに等しい。

次はインボイス設定だ。ストアが実際にチューニングされるのはここである。有効期限は既定で15分前後であり、技術的な制限というよりレートロックだ——ボラティリティのある資産に対して、法定通貨建ての価格をどれだけ保持し続ける気があるかを表す。値動きの激しい市場では短くし、顧客の動きが遅いなら長くすること。確認数は、インボイスがいつ決済済みとみなされるかを決める——ゼロ確認は即時でコーヒー1杯には十分であり、1確認が通常の既定値、6確認は1時間待つほうが代替手段より安く済むような金額向けだ。不足払いの許容範囲を設定すると、わずかに不足したまま届いたインボイスも受け付けられるようになる。これは、顧客のウォレットが手数料を上乗せするのではなく金額から差し引く場合に絶えず起きる現象であり、ここにわずかな割合を設定しておくだけで、サポートメールの丸ごと一つのカテゴリーがなくなる。

そのあと、テストネットではなく実際のお金でテストする。ごくわずかな金額の支払いリクエストを発行し、スマートフォンのウォレットから支払い、インボイスがnewからprocessing、settledへと移り変わるのを見届ける。その1件の取引だけで、ノードが同期していること、導出パスが正しいこと、レートプロバイダーが機能していること、証明書がモバイルブラウザ上で有効であること、そしてお金が自分の管理するウォレットに届いたことの5つが証明される。ほかに、この5つを同時に証明してくれるものはない。

すでに持っているものに合った、最も小さいチェックアウト面を選ぶこと。支払いリクエストは誰かに送るリンクだ——ウェブサイトは不要で、クライアントに請求する最も速い方法である。ポイントオブセールアプリは、同じインスタンスを商品リスト付きのレジに変え、市場の屋台からスマートフォン一つで使える。ペイボタンは静的サイト向けのHTMLの断片だ。ショッププラグインは本物の店舗にBitcoinを支払い方法として追加し、注文ステータスを自動的に書き戻す。そしてREST APIはインボイスを発行し、その状態を報告し、決済が完了するとWebhookを呼び出す——これはHTTPと共有シークレット以外の何にも依存しないため、最も長く通用する統合方法だ。

どれを選ぶにせよ、Webhookを配線し、それが実際に発火することをテストすること。決済は完了したのにアプリケーションに一切通知が届かないというのは、誰も気づかない種類の障害だ。それぞれ単独で見るとどちらも正しく見えるからである——お金は届き、顧客は確認ページを見て、注文は未処理のまま放置される。意図的に決済完了インボイスのWebhookを自分宛てに送り、自分のエンドポイントがそれを受け取ったことを確認し、ペイロードを鵜呑みにするのではなく署名を検証すること——そのエンドポイントは公開されており、誰でもそこへポストできるのだから。

それを理解したうえでなら、日課そのものは短い。このデプロイメントには、ブロックチェーンのデータを除外しつつボリュームをアーカイブしデータベースをダンプするバックアップスクリプトが同梱されており、パスフレーズを受け付けるので、アーカイブはサーバーを出る前に暗号化される。それをタイマーで実行し、その結果をバックアップガイドが説明する方法で別の法域にあるマシンへ送ること——追記専用のリポジトリは、ここでは余分にかかる10分の価値がある。侵害された決済用サーバーが、自分の処理した記録を消せてしまってはならないからだ。

cd ~/BTCPayServer/btcpayserver-docker
export BTCPAY_BACKUP_PASSPHRASE="a long passphrase you keep elsewhere"
./btcpay-backup.sh                   # archives volumes + database, skips the chain
# then ship the archive offsite, and keep the channel backup separately

次はアップグレードだ。そして決済用サーバーは、「あとで、意図的にアップデートする」というのが正しい方針になる唯一のマシンである。このデプロイメントには、composeファイルを再生成し新しいイメージを取得する専用のアップデートスクリプトが備わっている——それを実行するのは、cronジョブがそうしたい気分になったときではなく、リリースノートを読み終えたときにすること。まずアーカイブを取ること。リリースは一度に1つずつ上げること。そして以前のバージョンを書き留めておくこと。1分でできるロールバックがあることこそが、この作業全体をローリスクにしてくれるからだ。

./btcpay-update.sh                   # deliberate, after reading the release notes
df -h /                              # the check that should be an alert, not a habit

最後に、アラートを1つとリマインダーを1つ設定する。アラートはディスク使用量に対するものだ——ブロックチェーンノードは、このマシン上で自分だけで肥大していく唯一のプロセスであり、ボリュームが満杯になるとチェックアウトが止まるが、ほかに何も変わっていないため原因の特定に時間がかかる。95パーセントではなく80パーセントで鳴らすこと。リマインダーは月次で、ストアを開いて2つのことを確認するためのものだ。インボイスがまだきちんと決済されているか、そして開いたLightningチャネルがまだ生きているか。決済プロセッサーは静かに壊れるものであり、それに気づく方法は、顧客から支払えなかったと言われることである。