Question 1

iOS SafariでBTCPay Keypad POSの+/−ボタンが最初のタップ後に反応しなくなる問題を修正するには？

Accepted Answer

この問題は、BTCPay Server 2.3.9 以前の Keypad/Light POS ビューに影響します。`addToCart()` が実行されると、`common.js` がアイテム行に `posItem--added` を追加し、`common.css` が `.posItem--added { pointer-events: none }` を適用します。このクラスは通常、`.posItem-added` オーバーレイからの `transitionend` イベント後に削除されます。`VueLight.cshtml` にはこのオーバーレイが存在しないため、iOS Safari ではイベントが発火せず、ボタンがブロックされたままになります。Android で動作するのは、無関係な Bootstrap ボタンのトランジションが偶然 `transitionend` をトリガーするためだけです。

一時的な回避策: Keypad アイテムパネルを閉じて再度開いてください。これにより行の状態がリセットされます。

恒久的なコード修正: `VueLight.cshtml` で、`Cart.cshtml` に存在するのと同じ `.posItem-added` オーバーレイのマークアップを各 Keypad アイテム行内に追加し、BTCPay を再ビルドして再デプロイします。より堅牢な代替案は、`common.js` で `transitionend` のみに依存するのを避け、CSS のフェード時間に合わせたタイムアウトによるフォールバックを追加することです。例:

```js
row.classList.add('posItem--added');
setTimeout(() => row.classList.remove('posItem--added'), 300);
```

緊急の CSS のみの回避策として、ポインターイベントを強制的に再有効化できますが、追加状態の視覚的な動作を事前にテストしてください:

```css
.posItem--added {
  pointer-events: auto !important;
}
```

カスタムイメージにコミットしない限り、一時的な Docker コンテナ内でファイルを直接編集しないでください。そうしないと、コンテナが再作成されたときに変更が失われます。

Question 2

BTCPayが「The calculated rate should not be 0」と表示し、支払い方法を無効にするのはなぜですか？

Accepted Answer

これは、主要な為替レートプロバイダーがゼロまたはマイナスのレートを返した場合に発生します（例：yadioがBTC_USD = 0を返す）。一時的な回避策として、ゼロレートを返さない別の主要レートプロバイダーに切り替えてください。恒久的な修正については、issue #7376を追跡してください。この修正では、非正のレートを無効として扱い、フォールバックプロバイダーが実行されるようにします。

Question 3

なぜBTCPay Serverは 'Your nodes are syncing' と表示し、Bitcoinのブロックを表示しないのですか？

Accepted Answer

これは、あなたのBitcoinノード（例：bitcoind）がまだブロックチェーンの同期中であることを示しています。同期状況を確認してください：Dockerデプロイメントの場合は `docker logs bitcoind` を実行、Umbrelの場合はダッシュボードのBitcoin Nodeアプリを確認してください。完全に同期が完了するまで待ちます。停止した場合は、ノードサービスを再起動します：`docker restart bitcoind` またはUmbrelデバイスを再起動してください。ディスク容量とネットワーク接続が十分であることを確認してください。同期が完了すると、メッセージは消え、ウォレット機能が再開されます。

Question 4

FastTest traitでタグ付けされたxUnitテストがBTCPayServer CIパイプラインで実行されないのはなぜですか？

Accepted Answer

BTCPayServer の CI ワークフローは、特定の trait フィルター(ci.yml では `Fast=Fast|ThirdParty=ThirdParty`、加えて `Playwright` および `Integration` ジョブ、release.yml では `PreReleaseCheck=PreReleaseCheck`)に一致するテストのみを選択します。`[Trait("FastTest", "FastTest")]` のみが付与されたテストは、これらのフィルターのいずれにも一致しないため、ローカルでは成功するにもかかわらず、すべての CI ジョブから暗黙的に除外されます。修正方法: 該当するテストに `[Trait("Fast", "Fast")]` を付け直し、既存の fast-test ジョブがそれらを拾うようにします(これらのテストは外部サーバーや Docker サービスを必要としないため、CI の変更は不要です)。選択を確認するには、BTCPayServer.Tests をビルドし、`dotnet test --list-tests --filter "Fast=Fast|ThirdParty=ThirdParty"` を実行します(docker-entrypoint.sh で使用されているものと同じフィルタリングメカニズムです)。テストが表示されるはずです。修正前にこれらのテストを直接実行するには、`--filter "FastTest=FastTest"` を使用します。注意: テストのクラスが継承を通じて選択対象となる別の trait(例: `Integration`)を持っている場合、そのテストは影響を受けません。

Question 5

BTCPay Lightning の返金ペイアウトが「Awaiting Payment」の状態で止まり、「LNURL payRequest returned an invoice but its amount or hash did not match the request」というエラーが発生する場合の修正方法は？

Accepted Answer

原因：BTCPay Server v2.4.3以降（commit af8b6e5c）でLightningペイアウトの丸め処理がmillisatoshi精度に変更されたため、法定通貨建ての返金でsatoshi未満の端数を含むペイアウト（例：14729.443 sats）が発生する場合があります。Strikeなどの一部のLNURLプロバイダーは、BOLT11インボイスを生成する際に要求金額を整数のsatoshiに丸めるため、BTCPayの厳格な金額完全一致検証によって拒否されます。自動Lightningペイアウトプロセッサーはエラー閾値に達するまで再試行を繰り返し、その後ペイアウトは「Awaiting Payment」の状態で停滞したままになります。回避策：（1）LNURLペイアウトを整数のsatoshiに丸めるv2.4.2以前にダウングレードする。（2）直接ペイアウトはmillisatoshi精度を維持するため、返金申請者にLightning Address/LNURLではなくBOLT11インボイス（直接Lightningペイアウト）を提供してもらう。（3）整数のsatoshiとなるBTC金額が得られる換算レートを使用して返金を承認する。（4）自動プロセッサーは失敗が繰り返されると自ら無効化されるため、停滞したペイアウトを手動で処理する。

BTCPay Server

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト