Bitcoin과 Lightning으로 결제하는 방법입니다.
온체인은 10분, Lightning은 수 초입니다.

Lightning은 충전 금액이 작고(몇 달러에서 수백 달러), 긴급도가 높으며(10분이 아니라 몇 초 안에 서버가 필요할 때), 인바운드 유동성을 갖춘 작동하는 Lightning 지갑을 이미 운영 중일 때 적합합니다. 온체인은 금액이 충분히 커서 온체인 수수료가 비율상 무시할 만하거나, 채널 관리의 엣지 케이스를 다루고 싶지 않거나, 자주 충전할 필요가 없는 장기 선불 잔액을 적립할 때 적합합니다.

온체인의 경우, 데스크톱의 Sparrow Wallet이 현재 기본 권장 사항입니다 — 최신, 다중 형식(단일 서명, 다중 서명, 하드웨어 지갑 친화적), 내장 Tor, 깔끔한 수수료 조정 UI. Electrum은 더 가벼운 설치를 선호한다면 여전히 훌륭한 선택입니다. Lightning의 경우, Phoenix가 가장 간단한 모바일 지갑(자동 관리 채널), 수동 채널 제어를 원하면 Blixt, 브라우저 기반 옵션을 원하면 Mutiny입니다. 자체 노드를 운영한다면 Core Lightning이나 LND가 LN과 직접 통신하며 워크플로우는 동일합니다.

기술적으로는 가능하지만 프라이버시 결과는 약해집니다. 거래소는 사용자의 신원과 처리한 모든 출금 기록을 보관하며, 온체인 그래프는 거래소 출금을 NordBastion의 수금 지갑과 공개적으로 연결합니다. 호스트를 입구에서 KYC 없는 것으로 취급하되 거래소-호스트 체인이 분석 가능한 상태를 수용하는 고객이라면 이로도 충분합니다. 위협 모델이 "조사관이 호스트의 지갑에서 역추적한다"를 포함하는 고객이라면 BTC를 먼저 셀프 커스터디 지갑을 통해 보내세요(가능하다면 코인조인을 사용한 적이 있다면 이를 함께 활용).

NordBastion은 네트워크 컨펌 1회 후 적립합니다. Bitcoin은 평균 약 10분마다 블록을 생성하므로 일반적으로 10분 정도 소요됩니다. 멤풀 혼잡 시 지연될 수 있으며, 현재 "next-block" 수준(모든 최신 지갑에서 확인 가능)에 맞춰 수수료를 설정하면 대기 시간을 예측 가능하게 유지할 수 있습니다. 패널에 실시간 진행 상황이 표시됩니다.

예. Lightning은 양 당사자 중 하나가 비정직하게 행동하면 Bitcoin 베이스 레이어에서 강제할 수 있는 서명된 양자 간 트랜잭션으로 정산됩니다. 두 가지 운영상 주의 사항이 있습니다. (1) 수신 지갑은 해당 금액에 대한 인바운드 유동성이 있어야 하며, NordBastion이 이를 유지합니다. (2) 고객 지갑은 아웃바운드 유동성을 갖추어야 하며, 이는 모든 Lightning 사용자의 일상적인 고려 사항입니다. 경로를 찾을 수 없으면 결제는 단순히 실패하고 자금은 이동하지 않습니다.

이는 가명성을 띱니다. 모든 Bitcoin 거래는 공개 원장 기록입니다. 의지가 있는 조사관은 수신자에서 송신자, 자금 출처까지 그래프를 역방향으로 체인 분석할 수 있습니다. 이를 포함하는 위협 모델의 경우 프라이버시 기준을 개선하는 두 가지 옵션이 있습니다: (a) 대신 Monero를 사용하십시오 — /guides/how-to-pay-vps-with-monero/ 참조. (b) 결제 전 코인조인 서비스(Wasabi 또는 가용한 경우 Whirlpool)를 사용하여 조인 지점에서 온체인 추적이 끊어지도록 하십시오.

지갑에서 "next-block" 또는 "one-block" 수수료 제안을 선택하세요. Sparrow, Electrum, Mutiny 모두 현재 멤풀 요율을 명확히 표시합니다. 수수료가 낮으면 트랜잭션이 몇 시간 동안 미컨펌 상태로 머물 수 있고, 너무 높으면 사토시를 낭비합니다. 특정 시점의 정확한 vByte당 사토시는 멤풀 상황에 따라 달라집니다.

최신 지갑은 RBF(Replace-By-Fee)를 지원하여 동일한 트랜잭션을 더 높은 수수료로 재방송합니다. Sparrow와 Electrum은 이를 원클릭으로 제공합니다. 두 버전 중 하나가 컨펌되면 다른 하나는 폐기됩니다. NordBastion은 컨펌된 버전만 보고 도착 시 잔액에 적립합니다. RBF를 사용할 수 없다면 CPFP(Child-Pays-For-Parent)가 대안입니다. 막힌 트랜잭션의 출력을 사용하는 고수수료 자식 트랜잭션을 송금하면 채굴자가 둘 다 포함합니다.