비트코인 주소 유형 개요

11-22

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

원문 표시

저자:익명

사용자가 비트코인을 접할 때 처음으로 "주소"라는 개념을 접하는 경우가 많습니다. 비트코인 결제를 받으려면 주소를 제공해야 합니다. 블록체인 익스플로러 에서 결제 완료 여부를 확인할 때 특정 주소를 검색 조건으로 사용하는 경우가 많습니다.

"주소는 비트코인 세계의 은행 계좌와 동일하며 비트코인을 받는 데 사용될 수 있습니다."라고 생각할 수도 있습니다. 그러나 이러한 이해는 지갑 사용 중 일부 상황 대면 때 여전히 혼란을 야기할 수 있습니다. 예를 들어, 비트코인 소프트웨어 지갑을 처음 사용할 때 "Bech32(SegWit)", "P2PKH", "Nested-SegWit(P2SH)" 등과 같은 "유형" 주소를 선택하라는 메시지가 표시될 수 있습니다. 다른 소프트웨어 지갑으로 전환하고 싶어도 겁이 날 것입니다. 새 소프트웨어 지갑은 원래 소프트웨어 지갑과 완전히 다른 비트코인 주소 세트를 제공할 수 있습니다. 이때 무엇을 해야 합니까?

이 글은 독자들이 주소 유형 및 소프트웨어 선택을 포함하되 이에 국한되지 않고 비트코인을 독립적으로 보관하는 과정에서 발생할 수 있는 몇 가지 문제를 해결하는 데 도움이 되도록 비트코인 주소 및 주소 유형의 개념에 대해 좀 더 심층적으로 설명합니다. 지갑 마이그레이션 과정에서 발생할 수 있는 문제.

마지막 장에서는 독자가 액세스할 수 있는 다양한 주소의 특성과 경제성을 설명하는 데 중점을 둘 것입니다. 기술적 세부 사항에 전혀 관심이 없거나 정보를 빠르게 확인하려는 경우 마지막 장으로 건너뛸 수 있습니다. 그러나 자기 양육권 방법을 계획하고 싶다면 처음부터 읽는 것이 좋습니다.

간단히 말해서, 비트코인 주소는 실제로 표준화된 비트코인 스크립트 에 사용되는 주요 데이터 의 특수 인코딩(번역) 의 결과입니다. 특수 인코딩 방법은 이를 전송에 더 적합하게 만들고 오류를 경고하는 기능을 제공합니다. 기본 비트코인 스크립트의 경제적 차이.

표준화된 비트코인 스크립트

우리 모두 알고 있듯이 비트코인은 P2P 네트워크에서 실행되는 전자 화폐입니다. 비트코인을 개발할 때 사토시 나카모토“UTXO”로 알려진 통화의 존재 형태를 설계했습니다. 이 형식은 비트코인 자금을 한 계좌에 다른 계좌에 보관하는 돈이 아니라 하나의 독립적인 수표에 더 가깝게 만듭니다. 이러한 "수표"에는 두 가지 주요 정보가 기록됩니다. 즉, 자금 액면가("sats")와 자금이 사용될 수 있는 상황을 정의하는 데 사용되는 스크립트 공개 키(scriptPubkey)입니다. 스크립트 공개 키는 열려면 특정 키가 필요한 자물쇠와 같습니다.

사토시 나카모토 영리한 잠금 장치를 사용자 정의할 수 있다면 비트코인이 다양한 시나리오에서 더 유연하게 사용될 수 있다는 것을 깨달았습니다. 그래서 그는 "Bitcoin Script"라는 프로그래밍 언어와 UTXO 기반 거래 검증 모드를 설계하여 스크립트 공개 키로 사용되는 프로그램을 작성하고 해당 자금이 소비되면 검증할 수 있습니다. 이러한 절차를 기반으로 검증됩니다.

이러한 혁신은 실질적인 어려움을 가져옵니다. 트랜잭션이 P2P 네트워크에서 전파되면 트랜잭션을 수신하는 노드가 먼저 일부 확인 작업을 실행합니다. 프로그래밍 언어와 프로그래밍에 트랜잭션을 검증하는 과정에서 노드가 충돌할 수 있는 고유한 취약점이 있는 경우 이 취약점을 악용하는 트랜잭션을 사용하여 전체 네트워크를 중단시킬 수 있습니다. 거래의 자유로운 확산과 네트워크 보안 사이에서 균형을 유지하는 방법은 무엇입니까?

비트코인 스크립트의 유연성을 의도적으로 제한하는 것 외에도 사토시 나카모토 충분히 간결하고 오류를 유발하지 않는 일부 스크립트를 정의하는 방법을 고안했습니다. 이러한 스크립트를 사용할 때 "표준화된 비트코인 스크립트" ^[1] ; 스크립트를 사용하면 해당 거래는 "표준 비트코인 거래"로 처리되며 네트워크 전체에 방해 없이 전파될 수 있습니다. 반대로, 이렇게 표준화된 스크립트를 사용하지 않으면 거래가 유효하더라도 채굴자에게 직접 제출해야만 채굴자가 이를 블록으로 패키징하여 채굴한 후 전체 네트워크로 확산할 수 있습니다. 이는 보안 문제가 네트워크에 전파되어 노드 충돌을 일으킬 수 있는 트랜잭션을 제한합니다.

구현된 두 가지 초기 표준화된 비트코인 스크립트는 "P2PKH"와 "P2PK"입니다. 이름에서 알 수 있듯이 스크립트의 공개 키에 공개 키(또는 공개 키의 해시)를 배치하고 거래에 자금이 필요합니다. 해당 공개 키의 서명(개인 키 뒤에 있음)

P2PKH 스크립트 공개 키는 다음과 같습니다.

 OP_DUP OP_HASH160 55ae51684c43435da751ac8d2173b2652eb64105 OP_EQUALVERIFY OP_CHECKSIG

(유명한 비트코인 과학 웹사이트에서: 비트코인 배우기 )

주소의 개념

표준화된 스크립트를 사용하면 비트코인 시스템이 기본 기능을 가질 수 있습니다(개인은 비트코인을 보관하고 개인 키를 보유하여 다른 사람에게 전자 통화 지불을 시작할 수 있음). 그러나 그것은 여전히 컴퓨터용으로 설계된 데이터입니다. 이러한 문자열을 이해해야 하는 주체는 컴퓨터입니다. 컴퓨터는 문자열 길이에 민감하지 않으며 데이터를 복사하는 동안 오류가 발생하지 않습니다. 그리고 사람들은 여러 면에서 그 반대입니다.

문제는 이 시스템의 사용자인 사람들이 이 데이터를 처리해야 한다는 것입니다. 사람이 비트코인 지불을 받을 때 TA가 요구하는 것은 상대방이 비트코인 자금의 합계를 TA가 관리하는 은행(또는 TA는 (성공적으로 잠금 해제) 할 수 있습니다. 또한 TA가 오랫동안 자체 자금을 유지하려는 경우 TA는 자체 비트코인 스크립트를 백업해야 할 수도 있습니다.

이때 우리는 무엇을 해야 합니까? 위와 같이 긴 문자열은 분명히 전송(너무 길다)이나 백업(잘못 복사하기 쉬움)에 적합하지 않습니다.

앞서 언급했듯이 대부분의 사람들에게 유용한 스크립트는 표준화 되어 있습니다. 이러한 표준화는 두 스크립트가 하나의 핵심 데이터만 다르다는 것을 의미합니다. 두 P2PKH 스크립트의 경우 고유한 차이점은 기록된 공개 키 해시 값이 다른. 따라서 돈을 모을 때 해시값과 스크립트 유형(P2PKH 스크립트)만 제공하면 충분합니다. 지불인(소프트웨어)은 이 정보를 사용하여 전체 비트코인 스크립트를 복구하고 비트코인을 거래의 올바른 위치로 보냅니다.

게다가(엔지니어링 사토시 나카모토 깨달음) 이 해시값의 16진수 형식( 55ae51684c43435da751ac8d2173b2652eb64105 , 40자)을 전달할 수 없습니다. 특별히 설계된 인코딩 방법을 사용하면 더 짧고 읽기 쉬운 형식으로 변환할 수 있습니다.

이것은 "주소"입니다. 비트코인 스크립트를 올바르게 복구할 수 있게 해주는 주요 정보를 전달하는 인코딩된 데이터입니다.

코딩방법

베이스58

"Base58" ^[2]은 사토시 나카모토 발명한 인코딩 방법으로, 유명한 인코딩 방법인 "Base64"를 수정한 것입니다. Base64의 문자 세트에는 모든 숫자, 대문자 및 소문자, 두 개의 기호("+" 및 "/")가 포함됩니다. 사토시 나카모토 여기서 숫자 0, 대문자 I와 O, 소문자 l과 기호를 삭제하고 Base58이 되었습니다.

이번 삭제는 의도적인 것이었습니다. 사토시 나카모토)의 자기 설명은 다음과 같습니다.

base64 대신 base58을 사용하는 이유는 무엇입니까?
0OIl은 이러한 문자가 유사해 보이고 거의 동일해 보이는 계정을 만드는 데 사용할 수 있으므로 사용되지 않습니다.
사람들은 자신의 계좌번호에 문자와 숫자 외에 다른 문자가 있을 것이라는 사실을 받아들이기 쉽지 않습니다.
구두점을 사용하지 않으면 일반적으로 이메일이 줄바꿈으로 인해 중단되지 않습니다.
문자와 숫자만 있으므로 전체 문자열을 선택하려면 두 번 클릭합니다.
– 사토시 나카모토 사토시, 비트코인 v0.1(base58.h)

주소를 비트코인 스크립트로 복원해야 하므로 문자 하나가 잘못된 경우 자금이 완전히 다른 비트코인 스크립트(전혀 잠금 해제할 수 없는 스크립트일 수 있음)로 전송되어 손실이 발생할 수 있습니다. 자금, 심지어 이러한 혼란스러운 문자가 허용되는 경우 악성 코드는 사용자의 주소를 유사해 보이지만 실제로는 공격자가 제어하는 주소로 자동 대체하여 지불을 받을 때 자금을 잃을 수 있습니다.

따라서 사토시 나카모토 의 고려 사항은 완벽하게 이해됩니다.

Base58 인코딩을 수행하기 전에 키 데이터(예: 위 P2PKH 스크립트의 해시 값)에 접두사 로 유형 코드를 추가하고 접두사가 붙은 두 번의 연속 SHA256 작업 결과의 처음 4바이트를 사용해야 합니다. 접미사 로서의 주요 데이터.

접두사는 데이터의 유형과 목적을 빠르게 나타낼 수 있으며, 정확하게 접두사가 추가되기 때문에 동일한 유형의 데이터는 Base58로 인코딩된 결과에서 항상 동일한 시작을 갖습니다. 이것이 바로 비트코인 주소의 시작 부분만 보면 그것이 어떤 유형의 주소인지 알 수 있는 이유입니다.
접미사는 체크섬 역할을 할 수 있습니다. 전사 오류가 있는 주소를 소프트웨어에 입력하면 소프트웨어는 실수를 했을 수 있음을 알려줍니다(실수한 위치를 지정할 수는 없지만).

즉, 인코딩을 시작하기 전에 다음과 같은 문자열을 구성해야 합니다.

类型码+ 关键数据+ SHA256(SHA256(类型码+ 关键数据))[0:4]（这里的“+” 是字符串拼接的意思）

위의 P2PKH 스크립트를 예로 들면, 먼저 키 데이터( 55ae51684c43435da751ac8d2173b2652eb64105 )에 접두사 00 추가한 다음 이 데이터에 대해 두 번의 연속 SHA256 계산을 실행하고 처음 4바이트(16진수로 8자, 96ab3cb1 를 가져와야 합니다. ), 접미사로 0055ae51684c43435da751ac8d2173b2652eb6410596ab3cb1 얻습니다. 마지막으로 Base58 인코딩을 실행하고 18p3G8gQ3oKy4U9EqnWs7UZswdqAMhE3r8 얻습니다.

이 문자열에는 비트코인 스크립트에 사용되는 키 정보(공개 키 해시 값)가 포함될 뿐만 아니라 이를 사용하는 방법(접두사 1 은 P2PKH 스크립트로 복원해야 함을 나타냄)을 설명하고 전사를 감지하는 기능도 있습니다. 잘못된 함수는 여전히 34자에 불과하며 이는 원래 해시 값보다 짧습니다.

Bech32

"Bech32"는 BIP 0173 ^[3] 에 의해 정의된 인코딩 방법이며, 이 BIP의 두 작성자는 Pieter Wuille과 Greg Maxwell입니다. 그러나 이 인코딩에는 고유한 유래도 있습니다. "Bech"는 "BCH"를 나타냅니다 ^[4] . 이는 1959년과 1960년에 세 명의 수학자에 의해 각각 발명된 순환 오류 수정 코딩 알고리즘입니다(BCH라는 이름은 이 세 명의 수학자). 그리고 "32"는 이 인코딩 방법의 문자 집합에 숫자 "1"을 제외한 영어 소문자와 숫자, 문자 "b", "i", "o"의 32자만 있음을 의미합니다.

이 BIP의 고려 사항은 두 개의 새로운 표준화된 스크립트 "P2WPKH" 및 "P2WSH"의 주소에 대해 새로운 인코딩 방법을 사용하기 위해 "SegWit" 업그레이드를 기회로 삼는 것입니다.

BIP 0173 시작 부분에서 저자는 Base58의 단점을 지적했습니다.

Base58은 대문자와 소문자 영어 문자를 모두 사용하므로 데이터를 QR 코드로 그릴 때 더 작은 "숫자 알파벳" 모드를 사용할 수 없으며 더 큰 "바이트 데이터" 모드만 사용할 수 있습니다.
대문자와 소문자를 모두 사용하면 복사하기, 모바일 키보드로 입력하기, 소리내어 읽기도 어렵습니다.
체크섬에는 두 번의 연속 SHA256 작업이 필요하며 이는 속도가 느리고 오류를 찾는 기능이 없습니다.
오류를 찾을 수 있는 대부분의 인코딩 방법은 문자 세트 크기가 소수이고 58이 소수가 아닌 경우에만 작동합니다.
Base58 디코딩은 더 복잡하고 작업 속도가 느립니다.

따라서 Bech32의 이 새로운 방법은 필요한 경우(예: QR 코드를 그릴 때) 소문자와 숫자만 사용하며 이러한 문자를 모두 대문자로 변경하여 보다 간결한 표현을 얻을 수 있습니다. 동시에 Bech32에는 오류를 찾는 기능도 있습니다. 복사한 오류를 찾을 수 있을 뿐만 아니라 잘못 복사한 단어도 지적할 수 있습니다(오류를 찾는 기능은 Base58보다 훨씬 뛰어납니다).

실제로 BCH 알고리즘에는 "오류 수정" 기능도 있습니다. 이 기능은 어떤 문자를 잘못 복사했는지 지적할 수 있을 뿐만 아니라 어떤 문자여야 하는지도 지적할 수 있습니다. 그러나 BIP 0173의 작성자는 고유한 위험을 발견했습니다. 한편으로는 오류 수정 기능을 강화하면 오류 찾기 기능이 약화되고, 다른 한편으로는 사용자가 소프트웨어의 오류 수정 기능을 너무 신뢰하면 오류가 발생합니다. 소프트웨어는 사용자를 오도할 수 있습니다. 입력된 잘못된 데이터는 "유효하지만 쓸모없는" 데이터로 수정됩니다. BCH로 인코딩된 데이터는 유효하지만 이에 의해 복구된 비트코인 스크립트는 수취인이 제어할 수 없습니다. 누구도 통제할 수 없는 것조차. 이것은 매우 위험합니다. 따라서 BIP 0173은 다음과 같이 경고합니다. "어떤 문자가 잘못 복사되었을 수 있는지 사용자에게 상기시키는 것 외에도 소프트웨어는 오류 수정 기능을 구현해서는 안 됩니다 (수정 제안 제공)."

그렇지 않으면 Bech32는 Base58 인코딩의 패턴을 따릅니다.

Bech32 데이터의 시작 부분에는 "의미 있는 데이터(hrp)"라는 조각이 있을 것인데, 이는 Base58의 접두사와 유사하며 이것이 어떤 데이터인지 설명할 수 있습니다.
- hrp는 32자보다 훨씬 많은 문자를 사용할 수 있습니다. 따라서 Bech32는 hrp와 디코딩할 실제 데이터를 구분하는 구분 기호로 숫자 "1"도 사용합니다.
- 비트코인 외에도 Bech32를 사용하는 다른 프로젝트도 많이 있습니다. 서로 다른 프로젝트의 데이터는 hrp를 사용하여 서로를 구별합니다. 여기에 등록된 HRP의 매우 흥미로운(그러나 단지 흥미로운) 목록이 있습니다 ^[5] .
Bech32는 또한 인코딩된 데이터의 마지막 6자를 차지하는 체크섬을 설계했습니다.

위의 경우와 동일한 공개 키 해시 값을 사용한다고 가정하면 P2WPKH 스크립트는 다음과 같습니다. 0 55ae51684c43435da751ac8d2173b2652eb64105 (예, 원래 P2PKH보다 더 간단하고 추상적입니다.) 주소는 다음과 같습니다. bc1q2kh9z6zvgdp4mf634jxjzuajv5htvsg9ulykp8 , 길이는 42자입니다.

베흐32m

"Bech32m"은 BIP 0350 ^[6] 에 정의된 인코딩 방식이다. 개발자가 Bech32 인코딩의 취약점을 발견했기 때문에 제안되었습니다.

마지막 문자가 "p"인 경우 문자 앞에 "q"를 삽입하거나 삭제해도 체크섬 오류가 발생하지 않으며 체크섬 메커니즘이 완전히 쓸모 없게 됩니다.

표준화된 비트코인 스크립트를 추가할 필요가 없다면 이 문제는 쉽게 해결될 수 있습니다. P2WPKH 주소와 P2WSH 주소에는 특정 길이가 있으므로 길이 확인만 추가하면 됩니다. 그러나 앞으로는 주소 길이가 변경될 수 있는 새로운 표준화된 스크립트를 추가할 예정이므로 이 문제를 해결해야 합니다.

Bech32m은 Bech32 체크섬 생성기의 매개변수를 변경하여 이 문제를 해결합니다.

현재 Bech32m은 "Taproot" 업그레이드로 추가된 "P2TR" 스크립트의 주소를 인코딩하는 데에만 사용됩니다. 향후 다른 표준화된 스크립트의 주소 인코딩에 사용될 수 있습니다.

경제

주소가 표준화된 비트코인 스크립트의 특별한 표현이라는 점과 주소 유형이 실제로 표준화된 비트코인 스크립트 유형에서 나온다는 점을 이해한 후, 주소 유형에 따라 경제성이 어떻게 달라지며, 사용 시 효과가 달라질 수 있습니까? 취급 수수료 가격 - 문제는 쉽게 해결될 것입니다. 이는 비트코인 스크립트마다 경제성이 다르기 때문입니다.

네트워크의 탈중앙화 와 보안을 유지하기 위해 비트코인의 블록 크기는 제한되어 있으며, 더 작은 거래량을 허용하는 스크립트는 경제적 이점을 갖습니다.

그런 점에서 가장 큰 변화는 단연 2017년 활성화된 '세그윗(SegWit)' 소프트 포크. Segregated Witness는 두 개의 새로운 표준화된 스크립트 "P2WPKH" 및 "P2WSH"를 제공하는 동시에 이 두 스크립트에 대한 새로운 트랜잭션 확인 모드도 설계합니다.

레거시 비트코인 스크립트에서는 스크립트의 공개 키로 정의된 확인 프로세스에 사용되는 데이터(예: 디지털 서명)가 트랜잭션( scriptSignature 필드)에 배치되며 이로 인해 소위 "트랜잭션 융합" "섹시성" 문제가 발생합니다 ^{. 7]} 다자간 애플리케이션을 프로그래밍하기 위해 비트코인 스크립트를 사용하는 것을 방지하고 심지어 지갑이 거래를 전혀 추적할 수 없게 만듭니다.

Segregated Witness의 트랜잭션 확인 모드는 데이터의 이 부분을 트랜잭션( witness 필드) 외부에 배치합니다. 또한 Segregated Witness는 증인 필드에 배치되는 새로운 측정 볼륨 단위("가상 바이트(vByte)")를 도입합니다. . 현장의 데이터는 볼륨을 측정할 때 할인됩니다(이는 SegWit 거래를 기존 거래보다 더 경제적으로 만들기 위한 의도적인 설계입니다).

최종 결과는 SegWit 유형 스크립트 P2WPKH 및 P2WSH가 기존 스크립트 P2PKH 및 P2SH보다 훨씬 더 경제적이라는 것입니다. 한편으로는 SegWit 스크립트의 스크립트 공개 키가 더 간결합니다. 기존 스크립트를 트랜잭션에 넣고 트랜잭션 외부에 Segregated Witness 스크립트의 서명을 넣습니다. 데이터 볼륨이 동일하더라도 후자의 vByte는 더 작습니다.

다음은 트랜잭션의 입력 및 출력으로 사용될 때 다양한 유형의 스크립트가 차지하는 공간을 보여주는 표입니다.

- 사진 출처: Optech Limited Weekly·확인 대기 중-

그런 다음 특정 유형의 스크립트에 따라 다양한 양의 거래량이 얼마나 생성되는지 알려주는 거래량 계산기가 있습니다.

참고: 경제성을 고려할 때 입력으로 사용되는 스크립트의 크기만 비교할 수는 없습니다. 일반적으로 비트코인 거래에는 "변경 출력"이 있기 때문입니다(거래를 위해 제공하는 자금 금액이 결제 금액보다 큰 경우가 많습니다). , 일부 금액이 본인에게 다시 이체됩니다.) 변경 출력은 일반적으로 이 지갑의 지불 주소와 동일한 유형의 스크립트를 사용합니다.

주소 유형

이 섹션에서는 사용자에게 노출될 수 있는 다양한 주소 유형의 특성과 경제성에 대해 설명합니다.

P2PKH

Base58 인코딩을 사용하세요. 숫자 "1"로 시작하며 일반적으로 길이는 34자입니다.
단일 서명 지갑의 경우.
덜 경제적입니다.
예(위와 동일): 18p3G8gQ3oKy4U9EqnWs7UZswdqAMhE3r8

P2SH

Base58 인코딩을 사용하세요. 숫자 "3"으로 시작하며 일반적으로 길이는 34자입니다.
사용자가 가장 일반적으로 접하는 P2SH 주소는 실제로 "Nested SegWit(P2SH)"라는 스크립트의 주소입니다. 이름은 "Segregated Witness 스크립트를 캡슐화하는 P2SH 스크립트"를 의미합니다.
- 이런 캡슐화를 구현할 수 있다는 것은 P2SH 자체의 능력이지만, 이런 캡슐화를 정의하는 근본적인 목적은 지갑 소프트웨어의 호환성 문제를 다루기 위한 것이다. 분리된 증인 주소는 새로운 인코딩 방법을 사용하기 때문에 새로운 방법을 구현하지 않는 지갑 소프트웨어는 분리된 증인 주소를 잘못된 입력으로 인식하고 유효한 비트코인 스크립트를 복구할 수 없습니다. Nested SegWit P2SH 스크립트는 적절한 절충안을 제공합니다. 지불인의 지갑(업그레이드 여부에 관계없이)은 이러한 주소를 일반 P2SH 주소로 인식한 다음 P2SH 스크립트를 복원하고 수신자의 거래를 올바르게 구성합니다. 자금을 사용하면 Segwit(Segwit을 지원하는 지갑 소프트웨어 사용)이 제공하는 이점 중 일부를 얻을 수 있습니다.
단일 서명 지갑인 경우 P2PKH보다 경제가 더 좋습니다.
다중 서명 지갑과 함께 사용할 수 있습니다(Segregated Witness 기능 포함 또는 제외).
예: 38Y2PBD1mihxtoVncaSz3oC2vRrjNF8sA2 (이 P2SH 스크립트는 이점이 없지만 위와 동일한 P2PKH 스크립트를 래핑합니다.)

P2WPKH

기본 SegWit 스크립트. Bech32 인코딩을 사용하고 숫자와 문자 "bc1q"로 시작하며 길이는 42자입니다.
단일 서명 지갑의 경우.
경제는 P2PKH보다 훨씬 낫고 Nested SegWit P2SH보다 좋습니다.
예(위와 동일): bc1q2kh9z6zvgdp4mf634jxjzuajv5htvsg9ulykp8

P2WSH

기본 SegWit 스크립트. Bech32 인코딩을 사용하고 숫자와 문자 "bc1q"로 시작하며 길이는 62자입니다.
일반적으로 다중 서명 지갑에 사용됩니다.
다중 서명 지갑으로서 경제는 P2SH보다 훨씬 좋습니다.
예: bc1q56cuwyqlmq64aq0y3c8swd8a9gefe4wf7faxe2uyatyahfrly5aq0e6mfc (이 P2WSH 스크립트는 장점이 없지만 위와 동일한 P2PKH 스크립트를 래핑합니다.)

P2TR

기본 SegWit 스크립트(Taproot는 "SegWit v1"입니다). Bech32m 인코딩을 사용하고 "bc1p"로 시작하며 길이는 62자입니다.
단일 서명 지갑과 다중 서명 지갑 모두에서 사용할 수 있습니다.
싱글 시그니처 지갑으로 사용하면 P2WPKH에 비해 경제성은 약간 좋지만 차이는 거의 없습니다. P2TR의 장점은 더 커집니다.)
일부 Schnorr 서명 집계 알고리즘의 도움으로 다중 서명 지갑으로 사용되면 경제는 P2WSH보다 훨씬 더 좋을 수 있습니다. 그러나 이 기사를 작성하는 시점(2024년 11월)에는 이러한 알고리즘의 상호 작용이 복잡하기 때문에 지갑 소프트웨어에서는 이러한 집계 알고리즘을 거의 구현하지 않습니다.
P2TR과 이전 비트코인 표준 스크립트의 주요 차이점은 원본 스크립트가 단일 서명 지갑 사용자와 고급 스크립트 기능("스마트 계약") 사용자를 구별하는 반면 후자(포함)는 공개 키 해시 스크립트를 사용한다는 것입니다. 다중 서명 지갑) 서명 장치 및 라이트닝 채널과 같은 고급 장치)은 상환 스크립트 해시 값 스크립트를 사용합니다. P2TR은 처음으로 두 가지를 통합하여 스크립트의 외부 형식에서 사용을 직접 유추하는 것을 불가능하게 합니다. /주소. 따라서 P2TR은 장기적으로 더 나은 개인 정보 보호를 제공하게 됩니다.
지금까지 모든 지갑이 P2TR 주소를 지원하는 것은 아닙니다(그러나 거의 모든 지갑은 P2WPKH 및 P2WSH를 지원합니다). 사용자의 선택 범위와 마이그레이션 기능은 상대적으로 제한되어 있습니다. 또한 P2TR 기반 다중 서명 장치에 대한 지원도 드물습니다.
예(무작위로 선택): bc1pxy5r3slcqc2nhc0r5698gmsqwruenj9c8pzmsy5cedp3649wyktstc6z3c

결론

주소는 특정 비트코인 스크립트를 나타냅니다. 이러한 비트코인 스크립트는 표준화되어 있으며 주소의 정보를 기반으로 완전히 복원될 수 있습니다. 특수 인코딩 방법을 사용하여 주소를 보다 간결하게 만들고 표기 오류를 확인하는 기능을 갖추고 있습니다. 다양한 주소 유형의 경제성은 그 뒤에 있는 표준화된 비트코인 스크립트의 경제성에서 비롯됩니다.

부록 A. 설명자

"주소 개념" 섹션에서 사용자에게 컴팩트하고 신뢰할 수 있는 스크립트 기록이 필요할 수 있는 두 가지 시나리오, 즉 결제(배송) 시나리오와 장기 보관 시나리오가 있다고 언급했습니다.

"인코딩 방법" 섹션에서는 이러한 인코딩 방법의 설계가 주로 장기 저장 시나리오보다는 전송 프로세스를 기반으로 한다는 것을 알 수 있습니다. 그렇다면 양육권 시나리오에서 주소는 어떻게 저장되어야 할까요?

다행스럽게도 이제 "출력(주소) 설명자(출력 설명자)"인 주소 그룹(단지 하나가 아닌)을 나타내는 적절한 방법이 있습니다.

비트코인의 탄생과 주소 개념의 등장 이후 자기보관에 대한 기술과 보안 관행이 많이 향상되었습니다. 주요 발전은 소위 "계층적 결정론적(HD) 지갑"입니다. 아이디어는 비밀 자료를 사용하여 결정론적 무작위 알고리즘에 따라 많은 개인 키를 추론한 다음 많은 주소를 파생시키는 것입니다. "재사용 금지" 요구 사항을 충족할 수도 있습니다. 주소 보안 습관을 사용하면 개인 키 백업 부담을 최대한 줄일 수 있습니다.

설명자도 이 개념을 기반으로 하며 주소 유형과 이 주소 집합을 일반 텍스트로 생성하는 단계와 체크섬을 표현합니다. 예를 들어:

 wpkh([8b47f816/84h/0h/0h]xpub6C8vwWQ[...]NgW2SnfL/<0;1>/*)#c38kz2nr

위의 텍스트에서 P2WPKH 주소 집합을 나타내는 것을 알 수 있으며, 이 주소 집합에 사용되는 공개 키는 84h/0h/0h 기준으로 8b47f816 의 지문을 갖는 마스터 공개 키에서 얻습니다. BIP32에서 파생됩니다. 파생 경로, 0 과 1 의 파생 경로를 사용하여 결제 주소와 변경 주소를 구분합니다. 마지막으로 c38kz2nr 은 체크섬으로 전사 오류가 있는지 확인할 수 있습니다.

이러한 문자열은 이 주소 집합을 생성하는 프로세스를 완전히 설명하므로 장기 저장에 매우 적합하며 지갑 마이그레이션에도 매우 적합합니다.