비트코인 주소

앨리스가 밥에게 돈을 보내려 합니다. 밥은 지갑에서 받기를 열고 표시된 주소를 확인한 다음, 텍스트나 QR 코드로 보냅니다. 앨리스는 자신의 지갑에 이를 읽어 들이고 전송 전에 수취인과 금액을 확인합니다. 주소의 글자 하나하나를 이해할 필요는 없습니다. 앱이 처리하기 때문입니다. 지갑은 주소를 바탕으로 나중에 이 돈을 쓰기 위해 충족해야 할 조건을 만듭니다. 보통은 올바른 개인 키로 만든 서명이 필요합니다. 트랜잭션에는 이 조건이 scriptPubKey라는 스크립트로 기록됩니다. 금액과 스크립트가 들어가며, 익숙한 주소 문자열 자체를 저장하는 것은 아닙니다. 따라서 주소는 지급 정보를 전달하는 편리한 표현이지, 코인이 담긴 상자가 아닙니다. [1] [3]

긴 주소는 직접 입력하기보다 복사하거나 QR 코드를 스캔하세요. 하지만 그것으로 확인이 끝나지는 않습니다. 악성 프로그램은 클립보드의 주소를 다른 주소로 바꿀 수 있습니다. 신뢰할 수 있는 경로로 수취인에게 받은 주소와 전체를 대조하세요. Hardware Wallet을 사용한다면 기기 자체 화면도 확인해야 합니다. 사기 주소가 앞부분과 뒷부분을 흉내 낼 수 있으므로 그 부분만 비교해서는 부족합니다. 주소에는 입력 오류를 찾는 체크섬이 있지만, 형식이 올바른 주소가 의도한 사람의 것인지는 알 수 없습니다. 지갑이 해당 형식과 네트워크를 지원해야 한다는 점도 중요합니다. 소액 시험 전송이 도움이 될 수는 있지만, 다음 전송에서 주소를 다시 확인하는 일을 대신하지는 못합니다. 잘못된 상대의 주소라도 유효한 주소라면, 확정된 지급을 프로토콜에서 간단히 취소할 수 없습니다. [2] [7] [8] [18]

밥이 다음번에 받기를 열면 다른 주소가 표시될 수 있습니다. 돈이 사라졌다는 뜻은 아닙니다. 새 주소는 사생활 보호에 도움이 됩니다. 공개된 주소 하나를 아는 사람은 블록체인에서 그 주소의 수신 내역을 추적할 수 있지만, 그것만으로 지갑의 모든 수입을 알게 되어서는 안 됩니다. 같은 주소를 재사용하면 그런 연결이 쉬워집니다. 물론 새 주소도 익명성을 보장하지는 않습니다. 이후 트랜잭션이 다른 연결을 드러낼 수 있습니다. 수신을 위해 공유할 수 있는 주소라도 아무 생각 없이 널리 공개하는 것은 피하는 편이 좋습니다. 한 주소가 한 사람을 뜻하는 것도 아닙니다. 여러 사람이 공동으로 관리하거나 서비스가 고객을 대신해 관리할 수 있습니다. [1] [14]

지갑은 키를 관리하고, 쓸 수 있는 지급 내역을 찾아 그 합계를 보여 줍니다. 잔액은 여러 주소에서 온 돈으로 구성될 수 있습니다. 일반적인 HD Wallet은 공통 출발점에서 여러 키를 만들므로, 새 주소를 받는다고 새 지갑을 여는 것은 아닙니다. 지급할 때 앱이 쓰고 남은 금액을 자신의 Change Address, 즉 잔돈 주소로 돌려보내기도 합니다. 하지만 주소만으로 지갑을 복구할 수는 없습니다. 백업은 필요한 키와 그 사용 조건을 복원할 수 있어야 합니다. 많은 지갑은 Seed Phrase라는 복구 단어 모음을 사용하며, 복잡한 설정에는 추가 정보가 필요할 수 있습니다. 지급인은 그 단어나 개인 키를 전혀 필요로 하지 않습니다. [10] [14]

QR 코드는 정보를 표현하는 방식일 뿐입니다. 주소만 담을 수도 있고, bitcoin:으로 시작하면서 금액, 수취인 표시나 메시지를 더한 지급 요청을 담을 수도 있습니다. 이 방식은 BIP21이 설명했고 BIP321이 확장합니다. 승인 전에 지갑이 실제로 무엇을 읽었는지 확인하세요. Lightning Network의 한 번의 지급에 쓰는 invoice나 새로운 invoice를 반복해서 요청할 수 있는 offer는 다른 지급 절차를 사용합니다. Lightning Address는 이러한 요청을 받기 쉽게 해 줍니다. 일부 요청은 여러 결제 방법을 제공합니다. 마찬가지로 메시지의 디지털 서명이 자동으로 신원을 확인해 주지는 않습니다. BIP322는 스크립트의 조건을 충족할 수 있음을 보여 줄 수 있지만, 그 자체로 법적 신원이나 임의의 청구서에 대한 동의를 증명하지는 않습니다. [15] [16] [17]

Base58Check는 버전 바이트와 payload라고 부르는 데이터를 결합합니다. SHA256(SHA256(version || payload))의 처음 4바이트를 붙이고 Base58 문자 집합으로 인코딩합니다. mainnet에서 0x00은 P2PKH, 0x05는 P2SH를 뜻하므로 보통 1이나 3으로 시작합니다. 테스트 네트워크는 다른 버전을 사용합니다. 문자 집합에서는 혼동하기 쉬운 0, O, I, l을 제외합니다. 이 32비트 체크섬은 많은 입력 오류를 찾아내지만 수신인의 신원을 인증하지는 않습니다. [2] [3]

네이티브 SegWit 표기에는 mainnet의 bc 또는 testnet의 tb 접두사, 구분자 1, witness 버전, 5비트씩 묶은 데이터가 들어갑니다. 끝에는 체크섬 문자 6개가 붙습니다. BIP173이 Bech32를 도입했지만 특정 삽입·삭제에 대한 약점이 발견되자 BIP350은 버전 0에 Bech32를 유지하고 버전 1–16에는 Bech32m을 지정했습니다. 영문자는 모두 소문자이거나 모두 대문자여야 하며 섞어 쓰면 안 됩니다. 인코딩 한도는 90자입니다. 유효한 표기라도 다른 네트워크나 지원하지 않는 버전을 가리킬 수 있습니다. [7] [8]

P2PKH와 P2WPKH는 공개키의 20바이트 HASH160을 참조합니다. P2SH는 redeemScript의 HASH160을, P2WSH는 witnessScript의 SHA256을 사용합니다. 따라서 SegWit v0는 20바이트 P2WPKH와 32바이트 P2WSH를 구분합니다. BIP341의 P2TR은 다릅니다. 버전 1 프로그램에 조정된 32바이트 x-only 출력 키 Q가 들어가며, 일반 수신 키의 해시가 아닙니다. Q를 만들 때 추가 스크립트 트리의 루트를 반영할 수도 있습니다. 이렇게 하면 키와 해당 지출 조건이 암호학적으로 연결됩니다. 따라서 주소만으로 모든 지출 방법을 알아낼 수는 없습니다. [6] [9]

초기 비트코인 출력은 공개키에 직접 지급하는 경우가 많았습니다. P2PKH는 공개키 공개를 지출 시점까지 미뤘습니다. BIP13과 BIP16은 P2SH를 통해 더 복잡한 스크립트의 해시를 전달할 수 있게 했습니다. BIP141은 버전이 있는 witness 프로그램, BIP173은 Bech32, BIP341과 BIP350은 Bech32m을 쓰는 Taproot 형식을 추가했습니다. 모양이 다르면 검증 조건도 다릅니다. 접두사를 손으로 바꿔 주소를 ‘변환’하지 마세요. 다른 출력이나 지출할 수 없는 출력을 만들 수 있습니다. 일부 비표준 스크립트와 초기 pay-to-pubkey 출력에는 일반적인 표준 주소가 없습니다. [4] [5] [6] [7] [8] [9] [3]

BIP32의 HD Wallet은 공통 루트에서 많은 키를 파생합니다. 경로는 출력 유형을 구분하며 BIP44는 P2PKH에 목적값 44', BIP84는 P2WPKH에 84', BIP86은 단일 키 P2TR에 86'을 사용합니다. 그다음에는 코인 종류(coin type), 계정, 수신 또는 거스름돈 분기, 주소 인덱스가 이어집니다. Seed Phrase만으로는 모든 경로와 계정, Multisig 규칙을 알 수 없는 경우가 있습니다. Output Descriptor는 키의 출처와 스크립트 구성도 기록합니다. 복구는 익숙한 주소 하나를 다시 보여주는 데 그치지 않고 실제 자금을 찾아야 합니다. [10] [11] [12] [13] [14]

P2PKH와 P2WPKH에서는 처음에 보통 키의 해시만 보이며 지출할 때 공개키가 드러납니다. P2SH와 P2WSH는 사용한 redeemScript나 witnessScript를 공개합니다. Taproot는 이미 출력에 조정된 공개키가 들어 있습니다. key path로 지출할 때는 보통 Schnorr Signature를 추가하고, script path로 지출할 때는 선택한 스크립트, control block, Merkle 경로를 공개합니다. 사용하지 않은 분기는 숨겨 둘 수 있습니다. 따라서 모든 주소가 공개키를 숨긴다는 설명은 틀립니다. [6] [9]