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

이는 기본 환율 제공자가 0 또는 음수 환율을 반환할 때 발생합니다 (예: yadio가 BTC_USD = 0을 반환). 임시 해결 방법으로 0 환율을 반환하지 않는 다른 기본 환율 제공자로 전환할 수 있습니다. 영구적인 수정을 위해 issue #7376을 추적하세요. 이 수정은 양수가 아닌 환율을 유효하지 않은 것으로 처리하고 대체 제공자가 실행될 수 있도록 합니다.

Question 3

BTCPay Server가 'Your nodes are syncing'을 보여주고 Bitcoin 블록이 표시되지 않는 이유는 무엇인가요?

Accepted Answer

이는 귀하의 기반 비트코인 노드(예: 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 환불 페이아웃이 'LNURL payRequest returned an invoice but its amount or hash did not match the request' 오류와 함께 'Awaiting Payment' 상태에서 멈춘 경우 해결 방법은?

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

주요 기능

할 수 없는 것

사용 사례

태그

시작하기

유사한 프로젝트