BIP352: 무소음 지불의 현재와 미래

03-28

이 기사는 기계로 번역되었습니다

원문 표시

작성자: 익명

"침묵 지불"은 개인정보 보호 요구 사항을 고려하면서 정적 지불 식별자를 달성하기 위해 제안된 솔루션입니다. 이를 이용하려면 결제 수취인은 안정적이고 변경되지 않는 식별자(특수 주소로 간주될 수 있음)만 공개하면 되고, 보내는 사람은 결제 과정에서 수취인을 위한 반복되지 않는 새로운 비트코인 주소를 생성합니다.

본 논문에서는 기본 개념과 무음 지불을 위한 최초의 비트코인 강화 제안인 BIP352 ^[5] 에 대해 설명하고 BIP352 사양을 기반으로 한 무음 지불의 채택을 기대합니다.

무소음 결제의 기본 개념

침묵의 지불 개념을 이해하기 위해 먼저 비트코인의 "온체인"(즉, 거래 확인 방법으로 블록체인을 사용) 지불 프로세스를 살펴보겠습니다.

앨리스는 밥에게 돈을 지불하려고 하기 때문에 밥이 사용할 수 있는 비트코인 스크립트를 요청합니다(주소는 이러한 스크립트의 간결하고 오류 없는 표현입니다 ^[1] ).
밥은 앨리스에게 주소를 적어 답장한다.
앨리스는 해당 주소를 자신의 비트코인 지갑 소프트웨어에 복사하고, 다른 거래 세부 정보를 추가한 후, 거래를 브로드캐스트하여 블록체인 확인을 받습니다.
밥의 소프트웨어가 새로운 블록을 받으면 밥이 저장한 정보(주소 등)를 기반으로 일치하는 거래를 검색합니다. 일치하는 것이 있으면 거래 정보를 저장하고 관련 거래 출력을 사용 가능한 자금으로 태그.

이 과정은 다음 사항과 관련이 있습니다.

은둔. 밥이 이미 사용된 주소를 제공하면 주소의 '익명성이 해제'될 리스크 커집니다. 즉, 제3자가 주소의 실제 소유자를 감지할 수 있습니다. 개인 정보를 침해하는 이런 습관을 "주소 재사용"이라고 하며, 재사용이 많을수록 익명성 해제 리스크 커집니다.
상호작용성. 위의 과정에서 Bob은 Alice와 상호작용하고 그녀에게 주소를 제공합니다. 이런 종류의 상호작용이 어느 정도 번거로울 수는 있지만, 개인정보 보호를 고려한다면 그 가치는 명확합니다. 밥은 이 기회를 이용해 새로운 주소를 제공하고 주소 재사용을 피할 수 있습니다.
백업의 편리함. 밥이 송금을 받은 후 바로 사용하지 않는 한, 비트코인은 그의 주소에 그대로 남아 있게 되므로, 주소의 주요 정보를 백업해 둘 필요가 있습니다. 개인정보 보호를 위해 밥은 새로운 결제가 있을 때마다 새 주소를 생성해야 하지만, 이를 어떻게 편리하게 백업할 수 있을까요?

현재 비트코인 보관 체계에서 BIP-32 계층적 결정적 지갑 체계는 위에서 언급한 개인 정보 보호와 백업 편의성 간의 모순을 해결합니다 ^[2] : Bob이 사용하는 키는 모두 특정 단계를 거쳐 동일한 시드에서 파생됩니다. 이러한 키는 동일한 출처를 가지고 있으므로 Bob은 시드만 백업하면 됩니다(최대 아주 소량의 파생 단계 정보만 추가로 백업하면 됩니다). 그리고 도출 단계가 단방향이므로 제3자는 이들 키의 공개 키를 통해 이들이 동일한 출처에 속한다는 것을 유추할 수 없으며, 이는 또한 개인 정보 보호도 잘 보장해줍니다.

유일하게 불만족스러운 점은 상호작용에 대한 수요가 여전히 존재한다는 것입니다. 각 지불인은 지불을 시작하기 전에 먼저 밥과 통신을 설정하고 새로운 주소를 받아야 합니다. 개인 정보를 침해하지 않고 정적인 결제 식별자(주소)를 얻을 수 있는 방법이 있을까요?

침묵의 결제 개념의 창시자인 루벤 솜센(Ruben Somsen)은 한 연설 ^[3] 에서 가능한 해결책에 대해 논의한 적이 있습니다. 침묵의 결제는 그 중 하나이며 특별한(다소 급진적인) 균형을 보여줍니다. 수신자 밥의 스캐닝 부담을 증가시켜서 상호작용의 필요성을 없앱니다(즉, 위에서 언급한 결제 프로세스의 네 번째 단계의 복잡성).

침묵의 지불은 "Diffie-Hellman 키 교환"이라는 개념을 사용합니다(이것은 "공개 키 암호화" 개념과 같은 시대입니다! ^[4] ): Alice와 Bob이 각자 공개-개인 키 쌍을 가지고 있다면, 서로의 공개 키만 알면 간단한 연산을 통해 자신만 아는 공유 비밀을 얻을 수 있습니다. 즉, 자신의 개인 키에 상대방의 공개 키를 곱하는 것입니다.

개인 키와 공개 키 사이의 수학적 관계로 인해 앨리스가 자신의 개인 키와 밥의 공개 키를 곱하면, 결과 값은 밥이 자신의 개인 키와 앨리스의 공개 키를 곱한 값과 같을 것입니다.
예를 들어 타원 곡선을 기반으로 한 공개 키와 개인 키를 살펴보겠습니다. 앨리스의 공개 키 A는 개인 키 a와 타원 곡선 점 G에 점 곱셈을 수행하여 얻습니다. 밥의 열쇠 쌍도 비슷합니다. 그러면: aB = a*bG = b*aG = bA . 이것을 "ECDH(타원 곡선을 통한 DH 키 교환)"라고 합니다.
정의에 따르면, 개인 키 중 하나를 아는 사람만이 이 비밀 값을 얻을 수 있으므로 다른 사람은 이를 알 수 없고, 본인과 다른 사람만 알 수 있습니다.

만약 밥이 자신의 공개 키를 미리 공개한다면, 앨리스는 밥과 상호작용하지 않고도 자신의 개인 키를 사용하여 새로운 비밀 값을 도출하고, 이 비밀 값에서 새로운 공개 키(그리고 해당 주소)를 도출할 수 있습니다. 예를 들어, 새로운 공개 키는 Bob의 공개 키의 해시 값과 공유 비밀 값의 타원 곡선 점입니다. New PK = B + H(aB).G ; 이 공개 키 뒤에 있는 개인 키는 다음과 같습니다. New sk = b + H(bA) . 분명히 이 공개 키가 어떻게 구성되는지는 앨리스와 밥만이 알 수 있다. 왜냐하면 이 키는 자신들만 아는 공유 비밀 값을 사용하기 때문이다. 더욱이 이 주소에 있는 자금을 사용할 수 있는 사람은 밥뿐입니다(개인 키 b를 밥만 알고 있고 앨리스는 모르기 때문입니다).

이 방법은 위의 세 가지 요구 사항을 충족합니다. (1) 앨리스가 개인 키를 재사용하지 않는 한 그녀는 동일한 주소를 얻지 못할 것입니다. (2) 앨리스는 더 이상 밥과 상호작용할 필요가 없으며 밥만이 사용할 수 있는 주소를 직접 구성할 수 있습니다. (3) Bob은 각각의 새로운 주소에 대한 키 자료를 백업할 필요가 없습니다. 왜냐하면 어떤 의미에서 이들은 모두 동일한 시드(키 쌍)에서 파생되었기 때문입니다.

하지만 문제는 앨리스가 밥에게 자신이 사용한 키 쌍을 어떻게 말하느냐는 것입니다. 밥이 앨리스의 공개 키를 모른다면 이 방법이 먹히지 않을까요?

이것이 이전의 비슷한 개념보다 침묵의 지불이 더 급진적인 이유입니다. 앨리스가 거래 입력에 사용된 공개 키를 사용해야 하지만, 다른 수단(예: 추가 OP_RETURN 거래 출력)을 통해 이 정보를 전달하지 않기 때문에 위의 키 교환 트릭을 사용한 거래가 그러한 트릭을 사용하지 않는 거래와 다르지 않게 보입니다! 이를 통해 개인정보 보호 요구 사항이 극대화되고 비밀 정보를 발견하는 작업은 전적으로 밥에게 맡겨집니다.

위 내용은 묵시적 지불의 기본 개념입니다. 다음으로, BIP352가 위의 무음 결제의 골격에 어떻게 살과 피를 더해 사용 가능한 기술로 만드는지, 그리고 다양한 사양이 결제 수신자 밥의 스캐닝 부담에 어떤 영향을 미치는지 살펴보겠습니다.

BIP352: 최초의 무음 결제 BIP

BIP352는 개요에서는 단계별 절차를 따르고 세부 내용에서는 매우 엄격하게 작성되어 잘 작성되었습니다. 본 문서의 목적과 내용을 제시해야 할 필요성의 균형을 맞추기 위해 주요 디자인 목표와 선택 사항을 다음과 같이 다시 기술합니다.

생태적 호환성
- BIP352는 Bech32m 인코딩 ^[6] 을 사용하여 침묵 지불의 수신자 주소를 인코딩합니다.
  - 이러한 설계는 P2TR 출력을 지원하는 비트코인 소프트웨어가 새로운 인코딩 및 디코딩 방법을 구현할 필요가 없으며, 침묵의 지불 주소에서 필요한 정보를 디코딩하도록 미세 조정만 하면 된다는 것을 의미합니다.
  - 이러한 설계를 통해 여러 버전의 무언 지불 프로토콜을 정의할 수도 있습니다. BIP352는 "v0에 대한 침묵의 지불 프로토콜"로 정의되어 있습니다.
저장 보안
- BIP352의 무통장 지불 주소에는 공개 키가 하나가 아니라 "스캐닝 공개 키"와 "지출 공개 키"라고 하는 공개 키 두 개가 포함되어 있습니다. 본인과 관련된 결제를 스캔하려면 "스캐닝 개인 키"를 알아야 하지만, "지출 개인 키"는 알 필요가 없습니다.
  - 따라서 사용자는 지출 개인 키를 더욱 안전한 장치(예: 잘 설계된 서명자)에 저장할 수 있습니다.
은둔
- 거래 입력의 "아웃포인트"도 공유 비밀 값의 도출에 포함됩니다. 출력 지점은 UTXO의 고유 식별자로, UTXO를 생성한 거래의 ID와 거래 출력 중 UTXO의 순서 번호로 구성됩니다.
  - 이 설계는 앨리스(결제 개시자)가 밥(결제 수신자)에게 주소/공개 키를 재사용함으로써 발생하는 영향을 방지합니다. 거래 ID가 겹치지 않는 한 ^[7] 각 UTXO의 출력 포인트는 고유합니다. 같은 공개 키를 사용하더라도 파생된 공유 비밀 값은 다르며, 밥에게는 같은 주소가 생성되지 않습니다.
- 모든 입력은 공유 비밀 값의 파생에 참여합니다. 모든 거래 입력의 가장 작은 출력 지점을 가져와 공유 비밀 값을 도출합니다. 게다가 앨리스는 모든 적격 입력에 대한 개인 키를 사용하여 공유 비밀 값을 도출합니다.
  - 이러한 디자인은 또한 밥이 앨리스로부터 온 입력이 무엇인지 구별하는 것을 방지하는 데 도움이 됩니다.
- 가능한 한 많은 입력 유형과 호환됩니다. BIP352는 "P2PKH", "P2WPKH", "P2SH-P2WPKH" 및 "P2TR"을 적격 입력으로 정의합니다. 즉, 지불자는 이러한 주소 유형의 자금을 사용하여 침묵의 지불을 시작할 수 있습니다.
  - 비트코인 입력 유형에 익숙한 독자라면 이것이 단일 공개 키로 제어되는 거의 모든 표준화된 스크립트를 포함한다는 것을 알 수 있을 것입니다. 필요한 입력 유형이 적을수록 무음 결제를 시작할 수 있는 사용자 그룹이 커집니다. 이는 또한 일반 결제와의 차이가 더 작고 식별 가능성이 낮다는 것을 의미합니다.
  - 동시에, 이전 항목의 요구 사항으로 인해, 침묵의 지불 거래를 구성할 때 지불자는 요구 사항을 충족하는 각 거래 입력의 개인 키가 공유 비밀 값의 파생에 참여할 수 있도록 해야 합니다.
- 수신자의 비트코인 주소를 도출하는 데 추가적인 일련번호를 사용하면 지불자는 단일 거래에서 실제 지불 금액을 여러 개의 다른 주소에 분산할 수 있습니다.
  - 이는 돈의 양에 따른 투기를 상쇄하는 데 사용될 수 있습니다.
스캐닝 편의성/관리 편의성
- 위의 "모든 입력 사용" 디자인은 Bob이 스캔하고 지불하는 것을 더 쉽게 만듭니다.
- P2TR 출력이 Bob에게만 예약되도록 허용합니다.
- 추가 태그를 통해 여러 개의 지출 공개 키를 생성하여 Bob이 동일한 스캔 키와 지출 키 세트를 사용하여 여러 개의 무음 지불 주소를 생성할 수 있도록 허용합니다.
  - 밥은 추가 백업 없이도 여러 개의 무통장 결제 주소를 생성하고 수취인/결제 목적에 따라 각기 다른 주소를 정할 수 있습니다.

위 내용은 BIP352의 일반적인 내용입니다.

위의 설계를 기반으로, 결제 수취인 Bob이 온체인 자신과 관련된 침묵의 결제 거래를 스캔하는 프로세스는 대략 다음과 같습니다.

첫째, Bob은 블록에서 잠재적인 침묵 지불 거래(BIP352에서는 "자격 거래"라고 함)를 찾아야 합니다.
- 잠재적 거래를 판단하기 위한 기준은 3가지가 있습니다. (1) P2TR 출력이 있는 것, (2) 위에서 허용된 사용 유형의 입력을 하나 이상 포함합니다. (3) SegWit v1보다 높은 버전의 입력을 포함하지 않습니다. 여기서는 첫 번째 표준을 적용하기 위해서만 거래 자체에 대한 정보만 필요합니다. 마지막 두 표준은 판단을 수행하기 위해 입력의 이전 출력에 대한 스크립트 공개 키를 얻어야 하며, 이 정보는 암묵적이며 거래에 반영되지 않습니다.
그런 다음, 밥은 잠재적인 거래의 모든 입력을 탐색해야 하는데, 한편으로는 가장 작은 출력 지점을 찾고, 다른 한편으로는 위에서 사용 가능한 입력에서 공개 키를 클레임 하여 추가해야 합니다.
- 이 과정에서는 공유 비밀 값을 도출하는 데 필요한 두 가지 핵심 정보가 생성됩니다. 하나는 BIP352에서 "input_hash"라고 불리는 최소 출력 지점 정보를 포함하는 해시 값입니다. 다른 하나는 BIP352에서 "A"로 표시되는 모든 적격 입력의 공개 키의 합계입니다.
마지막으로, Bob은 input_hash, A와 자신의 스캔된 개인 키를 사용하여 공유 비밀 값을 도출한 다음, 지출 공개 키를 기반으로 공개 키와 해당 P2TR 스크립트를 도출합니다. 그런 다음 그는 거래 출력에 그러한 P2TR 출력이 있는지 확인합니다. 그렇다면 그는 그러한 거래와 출력을 저장하고 사용할 수 있는 자금으로 태그. 그렇지 않다면 그 거래는 그와 관련이 없다는 것을 의미합니다.

통찰력 있는 독자는 위의 두 단계 1과 2가 BIP352가 "침묵 지불"의 기본 개념에 대해 만든 두 가지 핵심 설계의 직접적인 결과라는 것을 알 수 있을 것입니다. (1) 지불 보내는 사람과 받는 사람의 공유 비밀 값을 도출할 때 모든 거래 입력의 정보를 사용합니다. (2) 가능한 한 많은 입력 유형을 지원합니다. 이러한 스캐닝 부담은 침묵 지불의 도입에 분명히 영향을 미칠 것입니다(즉, 이 비용은 침묵 지불의 적용 시나리오를 제한할 것입니다).

다음으로, BIP352 무음 지불 지갑의 가능한 작업 모드를 논의하고 비교 접근법을 사용하여 스캐닝 부담을 이해합니다.

두 가지 작업 모드와 스캐닝 부담

위의 수신기 스캐닝 과정을 분석하면 스캐너가 Bob이든 Carol이든 관계없이 스캔의 처음 두 단계를 실행해야 하며 두 단계의 끝에서 얻는 결과가 동일하다는 것을 알 수 있습니다. 즉, BIP352의 침묵의 결제는 "모든 입력을 사용"하기 때문에 거래가 잠재적인 침묵의 결제 거래인지 여부와 (만약 그렇다면) 해당 거래의 input_hash와 A는 모든 침묵의 결제 수신자에게 똑같이 유용한 정보이며, 재사용이 가능한 정보입니다(실제로 수신자는 두 가지의 곱만 얻으면 됩니다). 따라서 상상할 수 있는 작업 모드 중 하나는 "서버-클라이언트 모드"입니다. 서버는 스캔의 처음 두 단계를 실행하고 그 결과를 클라이언트에 제공합니다. 클라이언트는 로컬 키 정보에 따라 마지막 단계만 실행합니다. 이 모드는 기존 지갑의 '전체 노드-라이트 노드' 모드와 유사하며, 클라이언트의 작업 부하를 크게 줄일 수 있습니다.

이와 대조적으로 "통합 모드"는 작업 부하를 분할 하지 않으며, 세 단계가 모두 동일한 컴퓨터로 완료됩니다.

하지만 위의 스캐닝 단계를 보다 주의 깊게 고려하고 이를 전체 노드의 작업 모드와 연결해 보면 다음과 같은 추가적인 발견을 할 수 있습니다.

1단계와 2단계 스캐닝에서는 거래의 모든 입력에 대한 스크립트 공개 키를 얻어서 입력 스크립트 유형을 결정하고, 스크립트 유형에 따라 해당 공개 키 클레임 단계를 수행해야 합니다. "스크립트 서명(ScriptSig)"과 "증인(txinwitness)"을 포함하여 거래에서 노출된 정보는 충분하지 않습니다. 그러나 전체 노드도 새로 도착한 블록의 거래를 검증할 때 이 정보가 필요하며, 이 정보를 얻으려면 과거 블록과 과거 거래에 접근하지 않고(더 깊은 하드 디스크 읽기를 트리거하지 않고) UTXO 집합에서만 검색하면 됩니다.

즉, 위의 스캐닝 단계가 새로운 블록의 거래를 검증하는 동안 수행된다면 그것은 우연적인 것이고, 추가적인 오버헤드는 전적으로 계산(입출력 유형 검사, 공개 키 클레임, 공유 비밀 값 도출, ECDH 등)에서 발생하며, 객관적으로 말해서 이러한 계산의 양은 너무 크지 않을 것입니다. 그러나 별도의 프로세스를 사용하여 스캔을 실행하는 경우 추가적인 컴퓨팅 오버헤드를 지불해야 할 뿐만 아니라 추가적인 심층적 하드 디스크 읽기도 필요합니다.새로운 블록이 검증되면 거래 입력의 스크립트 공개 키를 더 이상 UTXO 집합에서 얻을 수 없고 과거 거래에 액세스하여만 얻을 수 있기 때문입니다(여기에는 추가적인 저장 공간 오버헤드가 있습니다. 온체인 모든 거래를 인덱싱하는 것입니다. 이러한 인덱스가 없으면 과거 거래를 실제로 읽을 수 없으며 동기식 검증-스캐닝 모드에서는 과거 거래 인덱싱이 필요하지 않습니다).

오버헤드의 이러한 상당한 차이 ^[8] 로 인해 우리는 "통합 모드"의 정의를 추가합니다. 스캐닝 단계는 블록 검증의 보조 단계이며 블록 검증과 동기적으로 완료됩니다.

정의를 추가한 후에는 "통합 모드"와 "서버-클라이언트 모드"의 조합이 완전한 세트를 구성하지 않는다는 점에 유의하세요. 스캐닝 워크로드가 분할 되지 않았지만 스캐닝 작업이 여전히 별도의 프로세스로 완료될 수 있습니다.

이 두 모드의 정의는 비교를 통해 BIP352 무통장 결제 수신자의 스캐닝 부담을 이해하는 데 도움이 되도록 구성되었습니다. 정의가 정확하기 때문에 두 모드 모두 적절한 비교 대상이 있습니다. 통합 모드는 전체 노드를 기반으로 한 일반 지갑과 비교할 수 있습니다. 서버-클라이언트 모드는 BIP158 블록 필터의 라이트 노드를 기반으로 하는 일반 지갑과 비교될 수 있습니다 ^[9] .

이를 위해 우리는 네트워크에서 발생하는 거래의 수와 비율, 그리고 지갑이 제어하는 주소의 수에 대해 다음과 같은 가정을 합니다.

평균적으로 각 블록에는 n 거래가 포함되며, 거래 입력은 총 m 개이고 거래 출력은 o .
최소한 하나의 P2TR 출력을 포함하는 거래의 점유비율p 이고, 단일 블록의 모든 출력에 대한 P2TR 출력의 비율은 q 입니다.
침묵의 지불 지갑은 침묵의 지불 주소를 1 공개합니다.
일반 지갑에는 20 P2TR 주소가 포함되어 있습니다.
이 지갑 주소가 거래 출력에 나타나는 경우(결제를 받는 경우)만 고려하세요.

위의 가정에 따르면 전체 노드를 기반으로 하는 일반 지갑의 스캐닝 부담은 20 * o * q 입니다. 즉, 블록의 각 P2TR 출력에 대해 20개의 주소 일치 검사를 실행합니다. 통합 모드에서 무음 결제 지갑의 스캐닝 부담은 다음과 같습니다. n * p * I + o * q * 1 첫 번째 항목은 거래를 기반으로 하는 무음 결제 스캔의 처음 두 단계로 인해 발생하는 오버헤드입니다. 여기서 I 트랜잭션에서 유형 검사, 공개 키 클레임, ECDH 및 기타 작업을 수행하는 데 필요한 계산량이며 여기서는 상수로 가정합니다. 두 번째 항목은 이러한 잠재적 거래의 각 P2TR 출력에 대해 주소 일치 검사를 수행하는 데 필요한 계산량입니다. 지갑 소유자가 단 1 비공개 지불 주소만 공개했기 때문에 실행은 1 수행하면 됩니다.

경량 노드 기반의 기존 지갑의 경우, 해당 지갑의 작동 모드는 먼저 블록 필터를 검증하는 것입니다. 필터에서 블록에 해당 입력 및 출력이 없다고 표시되면 전체 블록을 더 이상 다운로드할 수 없습니다. 블록 필터에서 (잘못 판단할 가능성이 매우 적음) 오류가 발견되면 다운로드해서 주소가 일치하는지 확인하세요. 블록 필터를 검증하는 부담을 상수로 간주합니다(이것은 비교에 영향을 미치지 않습니다). 그러면 스캐닝 부담은 1/x * 20 * o * q 입니다. 여기서 1/x 필터가 필터에 적중할 확률이며, 이는 BIP158 블록 필터의 오판정 확률보다 커야 하지만 실제 크기는 이 지갑이 블록 간에 수신한 거래의 분포에 따라 달라집니다.

서버-클라이언트 모델을 기반으로 하는 무음 지불 지갑의 경우 스캐닝 부담은 다음과 같습니다. n * p * I_1 + o * q * 1 . 이 공식이 통합 모드와 매우 유사한 이유는 서버가 스캐닝 작업의 일부만 완료하고, 가능한 각 트랜잭션에 대해 클라이언트는 여전히 작업의 일부(특히 ECDH)를 수행해야 하기 때문입니다(이는 I 의 일부일 뿐이므로 I_1 로 기록됩니다). 반면 P2TR 출력의 주소 일치 검사는 서버 작업의 이점을 전혀 얻을 수 없으므로 그대로 유지됩니다.

위의 분석을 요약하면 다음과 같습니다.

일반 지갑의 스캐닝 부담은 주로 동일한 유형의 출력 수에 따라 결정되지만, 침묵 지불 지갑의 스캐닝 부담은 부분적으로(또는 주로) 적격 거래 수와 관련이 있습니다. 둘은 직접 비교하기 쉽지 않습니다. 하지만 계산적 복잡성의 관점에서 보면 침묵의 결제로 인한 스캐닝 부담이 더 클 가능성이 큽니다. 구체적으로 이 부담은 P2TR 출력을 포함하는 거래의 점유비율 과 관련이 있습니다. 점유비율 이 클수록 무음 결제 지갑의 스캐닝 부담이 커집니다.
일반 지갑과 침묵 지불 지갑 모두 가벼운 노드/클라이언트 모델로 전환하면 상당한 이점을 얻을 수 있습니다.
클라이언트 모드에서는 무음 결제 지갑과 일반 지갑 간의 스캐닝 부담 차이가 더 크므로 사용자가 성능 차이를 더 쉽게 느낄 수 있습니다. 조용한 지불 지갑은 일상적인 사용을 위한 모바일 기기보다는 안정적인 데스크톱에 더 적합할 수 있습니다.

무소음 결제의 현재와 미래

성능/비용은 의심할 여지 없이 기술 도입에 영향을 미칩니다. 위의 분석을 통해, 어떤 작업 모드에서든 무음 지불 지갑은 일반 지갑보다 더 높은 가격을 지불해야 한다는 것을 알 수 있습니다. 이 역시 우리가 예상한 바라고 할 수 있는데, 이는 '침묵의 지불'의 본질적인 특성이기 때문이다. 적어도 사람들이 상상하는 사용 사례(기부금 수락, 기관으로서의 결제 수락)에서는 정적 결제 방법의 이점이 추가 비용보다 더 커야 합니다. 게다가 서버-클라이언트 가능성이 주어지면 작업 부하의 일부를 재사용할 수도 있습니다.

현재 여러 프로젝트에서 BIP352 무음 결제 지갑을 구현하려고 시도하고 있습니다. 예:

Bitcoin Core에 BIP352 구현: https://github.com/bitcoin/bitcoin/issues/28536
Dana Wallet 모바일 무음 결제 지갑: https://github.com/cygnet3/danawallet

또한, 개발자들은 Coinjoin 거래와 호환되는 무음 지불을 가능하게 하기 위해 다양한 사양을 추가하는 작업을 진행하고 있습니다. 코인조인 거래에서는 여러 참가자가 각각 거래에 대한 입력을 제공하고 출력을 지정합니다. BIP352에 따르면, 이러한 거래에서 침묵의 지불을 수행하려면 지불자가 각 적격 입력의 개인 키가 공유 비밀 값의 파생에 참여하도록 허용해야 합니다. 동시에, 이로 인해 실제 개인 키가 유출되는 일은 발생하지 않습니다. 또한, 당사자 간에 구성된 거래에 대한 정보를 전송할 수 있는 도구가 필요합니다(수신자의 스크립트는 모든 참가자가 계산에 참여한 후에만 파생되어야 함). 관련 사양은 다음과 같습니다.

BIP374 이산 대수 동등성 증명: https://github.com/bitcoin/bips/pull/1689
- 이산대수 등식 증명은 개인 키 보유자가 개인 키가 무엇인지 밝히지 않고도 개인 키를 알고 있다는 것을 증명할 수 있게 해줍니다.
BIP375는 PSBT를 사용하여 침묵 지불을 보냅니다: https://github.com/bitcoin/bips/blob/master/bip-0375.mediawiki
- 다자간 서명된 침묵 지불 거래 협업에서 정보를 전달하는 데 사용할 수 있는 "PSBT(보류 중인 서명된 비트코인 거래)" 데이터 형식을 정의합니다.

또한, 침묵의 지불과 관련된 프로토콜 설계 공간도 탐색되고 있습니다.

(위에)