작성자님처럼 초보 친구들도 많을 텐데요, 처음 WEB3 지갑을 사용했을 때 신나게 비트코인 지갑을 열어서 주소를 복사할 준비를 하다가 갑자기 자신이 만든 지갑에 실제로 여러 개의 주소가 있다는 것을 알게 되었습니다. 마치 낯선 교차로를 향해 어리둥절한 표정으로 걸어가는 것과 같습니다.
왜 주소가 다른가요? 다음 중 어떤 주소를 사용해야 합니까?
OKX 지갑을 위한 여러 비트코인 주소
이 주소는 무엇입니까?
비트코인 커뮤니티는 기술이 끊임없이 진화하고, 기술의 발전이 새로운 콘텐츠를 생산하는 커뮤니티입니다. 새로운 기술을 적용한 결과 다양한 주소 형식이 고려될 수 있습니다. 다음으로 다양한 주소 형식 간의 차이점을 살펴보세요.
기존 주소(P2P KH)
이 형식은 2009년 비트코인이 처음 출시되었을 때 사용되었으므로 레거시 형식이라고 합니다. 당시 비트코인 주소가 공개 키/개인 키 쌍으로 생성되었기 때문에 P2P(Payment Public Key Hash)라고도 합니다. KH) 주소입니다.
현재 레거시 유형 주소는 거래에서 더 많은 공간을 차지하여 거래 수수료가 높아질 것으로 보입니다. 현재 사람들은 새 주소와 호환되지 않는 일부 기존 지갑을 사용할 때만 이 유형의 주소를 사용합니다.
레거시 주소에는 특성이 있으며 주소는 모두 1로 시작한다는 것을 알 수 있습니다. 이는 주소를 생성할 때 다양한 시나리오(예: 테스트넷/메인넷)에 따라 생성된 공개 키 앞에 접두사가 추가되기 때문입니다. 접두사가 추가된 공개 키가 해시를 통해 계산된 후 결국 주소는 다음으로 시작됩니다. 1.
중첩된 SegWit 주소(P 2 SH-P 2 WPKH)
기존 레거시 주소와 비교하여 P 2 SH 주소는 공개 키의 해시를 사용하지 않고 상환 스크립트(redeem-script)의 해시를 사용합니다. 평신도의 관점에서 P2P KH는 공개 키의 해시에 지불하는 반면 P2SH는 수신자가 상환 스크립트의 전송 조건을 충족한 후에만 내부 자금을 사용할 수 있습니다.
결제 대상이 공개키에서 스크립트로 변환되기 때문에 유연성이 크게 확장되고, 상환 스크립트의 실행 로직을 맞춤 설정할 수 있습니다. 일반적인 애플리케이션에는 다중 서명 트랜잭션 구현이 포함됩니다.
P 2 SH를 기반으로 Segregated Witness 기술이 내장된 경우 이 주소의 형식은 Segregated Witness 호환 주소(Nested SegWit)입니다. 분리된 증인 주소를 소개할 때 분리된 증인에 대해 자세히 알아볼 수 있습니다. Segregated Witness 기술을 도입하면 거래량을 줄여 거래 수수료를 줄일 수 있습니다.
P 2 SH 주소가 3으로 시작하는 것을 볼 수 있습니다.
분리된 증인 주소(Native SegWit) 주소
이러한 유형의 주소를 도입하기 전에 그 안에 핵심 기술인 SegWit(Segregated Witness)을 도입해야 합니다. 이름에서 알 수 있듯이 Segregated Witness는 증인 데이터(증인)를 격리하여 별도로 처리합니다.
이를 통해 거래 정보의 크기를 줄여 거래 수수료를 절감할 수 있다는 것이 큰 장점입니다. 크기 감소로 인한 또 다른 이점은 비트코인 블록 트랜잭션 크기의 상한이 1MB에서 4MB로 늘어났다는 것입니다.
Segregated Witness 주소의 특징은 주소가 bc 1로 시작한다는 것입니다.
탭루트 주소(Taproot)
Taproot 주소의 장점은 복잡한 거래 시나리오에서 개인정보 보호와 효율성입니다. Native SegWit과 비교하여 Schnorr 알고리즘을 사용하여 타원 곡선 디지털 서명 알고리즘을 대체합니다. 전자는 일괄 거래 시나리오에서 더 효율적이며 다중 서명 지갑의 개인 정보 보호를 향상시킵니다.
기본 루트 주소는 일반적으로 bc 1 q로 시작하는 주소가 특징입니다.
어떤 주소 형식을 선택해야 합니까?
OKX, Unisat 및 기타 지갑과 같은 현재 주류 지갑은 위의 4가지 주소를 지원하므로 거래 비용을 줄이기 위해 Native SegWit 및 Taproot 형식의 주소를 사용하는 것이 더 합리적입니다.
또한, 비트코인의 비문 등에 관심이 있다면 이 두 주소가 최선의 선택입니다. 대부분의 지갑은 이 두 주소의 비문에 추가 처리를 수행하여 실수로 특별한 UTXO가 전송되는 것을 방지할 수 있습니다. 거래. bc 1로 시작하는 지갑주소를 찾아보세요!
물론, 다양한 주소 형식의 지갑에서도 자금 거래가 가능하니 걱정하지 않으셔도 됩니다.
비트코인 잔액이나 블록 정보를 확인하고 싶다면 ZAN의 노드 서비스를 이용해 보세요. 개발자가 사용할 수 있는 풍부한 API를 제공합니다. API 문서 세부정보: https://docs.zan.top/reference/zan_getbalance-enhance
더 자세히 알아보기 - 핵심 기술 소개
위의 소개를 마치고 나면 모두가 지갑에 대해 어느 정도 사전 이해를 하게 되었고, 나는 지갑에 있는 일부 기술을 획득하는 데 매우 관심이 있으므로 지갑 안에 있는 신비한 기술을 살펴보겠습니다.
상환 스크립트 상환 스크립트
P2SH를 도입할 때 우리는 이것이 상환 스크립트 거래를 위한 기술이라는 것을 알았습니다. 그렇다면 상환 스크립트란 무엇이며 비트코인 생태계에서 그 역할은 무엇입니까?
상환 스크립트를 소개하기 전에 비트코인 거래의 기본 구조를 소개해야 합니다.
다음은 04 ae로 시작하는 주소가 15 kD로 시작하는 주소로 10 BTC를 전송하려는 일반적인 P2P K 유형 트랜잭션입니다. 04 ae 주소를 가진 계정은 실제로 이 계정을 사용할 권리가 있음(개인 키 소유)을 체인의 다른 사람들에게 보여주어야 하며, 그런 다음 이 거래에서 자신의 신원을 증명하기 위해 서명(ScriptSig)을 제공해야 합니다.
검증자는 서명을 얻는 것 외에도 UTXO에 해당하는 이전 거래의 출력 스크립트도 찾아야 합니다. 이 두 스크립트는 함께 연결되어 구속 스크립트를 형성합니다. 상환 스크립트의 기능은 거래의 적법성을 증명하는 것입니다.
이 트랜잭션에서 서명과 출력 스크립트가 모두 컴퓨터 명령임을 알 수 있습니다. OP_PUSHBYTES는 데이터 조각을 스택에 푸시하는 것을 의미합니다. 먼저 ScriptSig의 04 ae가 자체 개인 키로 전체 트랜잭션에 서명하고 서명이 스택에 푸시됩니다. 그런 다음 공개 키를 스택에 푸시하고 마지막으로 OP_CHECKSIG에서 공개 키를 사용하여 서명을 해독하고 트랜잭션이 일치하는지 비교합니다. 일관성이 있으면 ID가 유효합니다.
이 P2P K 방법 외에도 상환 스크립트는 P2P KH 및 P2SH와 같은 다양한 신원 확인 방법을 구현할 수도 있습니다.
분리된 증인 분리된 증인
위의 소개를 통해 최신 지갑 형식이 현재 Segregated Witness 기술을 사용하고 있다는 것을 알 수 있습니다. 그렇다면 Witness란 무엇이며 어떻게 격리됩니까?
여기서 Witness는 비트코인의 기본 구조에 있는 스크립트 서명(scriptSig) 정보라고 생각하면 됩니다. Segregated Witness는 이를 기본 구조에서 추출하여 새로운 데이터 구조에 넣는 것입니다.
위 그림에서 볼 수 있듯이 트랜잭션에 꼭 필요한 내용은 트랜잭션 소스 정보와 트랜잭션 출력 정보뿐입니다. 노란색 부분(트랜잭션 전체 크기)에는 크기 제한이 있으므로 트랜잭션 크기가 줄어듭니다. 서명을 별도로 전송하면 하나의 블록이 더 많은 거래를 수용할 수 있습니다. 또한, 거래의 서명을 계산할 때 서명 부분의 내용을 포함하지 않으므로 거래 가변성 문제를 효과적으로 해결할 수 있다.
아래는 P 2 TR 거래입니다. 이 거래에는 추가 증인 부분이 있음을 알 수 있습니다. 그 기능은 거래의 적법성을 확인하는 것입니다. ScriptSig 대신 Witness를 사용한 후에도 적법성을 확인하는 방법은 여전히 동일합니다. 즉, 공개 키를 사용하여 Witness의 서명을 해독하여 거래 내용이 일치하는지 확인하는 것입니다. 노드가 거래의 합법성을 확인해야 하는 경우에만 증인 정보를 요청합니다. 이제 ZAN Node 서비스를 무료로 이용해보세요(ZAN.TOP 방문). BTC 네트워크에 안정적이고 빠른 속도로 연결됩니다.
요약하면 Segregated Witness는 트랜잭션 서명 부분을 원래 트랜잭션의 나머지 부분과 분리하여 단일 트랜잭션의 크기를 줄이고 전체 블록의 용량을 늘립니다. 또한, 거래의 해시값 계산에 서명 부분의 내용이 포함되지 않기 때문에 거래 가변성 문제를 효과적으로 해결할 수 있다.
이 글은 ZAN Team(X 계정 @zan_team )의 Yeezo(X 계정 @GaoYeezo 75065 )가 작성했습니다.
