39 / 736CBTX

코인베이스 트랜잭션

채굴한 블록의 보상을 배정하는 거래

Bitcoin에 중앙 금고가 없다면 누가 채굴자에게 보상을 줄까요? 채굴자는 블록 맨 앞의 특별한 거래에 보상을 적고, 다른 노드가 허용된 금액을 넘지 않았는지 검증합니다. 이 거래가 coinbase입니다.

Coinbase 거래는 허용된 새 비트코인과 다른 거래의 수수료로 이루어진 블록 보상을 배정합니다. 일반 결제와 달리 이전에 받은 자금을 쓰는 거래가 아닙니다. 다만 유효한 블록 안에서만 유효하며 보상을 바로 쓸 수는 없습니다. 거래소 Coinbase가 아니라 거래 유형의 이름입니다.

안나가 채굴할 후보 블록을 준비한다고 합시다. 사용자 결제를 모으고 그 앞에 보상 수령자를 정하는 특별한 거래를 넣습니다. 이 예에서는 규칙이 3.125 BTC 신규 발행을 허용하고 선택한 결제들이 0.075 BTC 수수료를 냅니다. 따라서 안나는 최대 3.2 BTC를 받을 수 있습니다. 맨 앞의 이 거래가 coinbase입니다. 적어 넣기만 하면 보상을 버는 것은 아닙니다. 블록은 채굴 요건과 나머지 모든 조건을 충족해야 하며, 받는 노드가 직접 검증합니다. 너무 많이 청구했다면 블록을 찾는 데 아무리 많은 전력을 썼더라도 전체 블록을 거부합니다. 중앙 계좌가 보상을 송금해 주는 구조가 아닙니다. 새 코인은 채택된 블록 안에서 공통 규칙에 따라 생깁니다. 예시의 3.2 BTC 중 새로 생긴 것은 3.125 BTC뿐이고 나머지는 사용자가 냈습니다. 이는 보상이지 순이익이 아닙니다. 채굴 비용은 아직 빼지 않았습니다. [6] [4]

허용된 신규 발행분은 Block Subsidy이며 Halving 때 주기적으로 절반이 됩니다. Satoshi는 비트코인의 최소 단위입니다. 수수료는 실제 포함된 결제에 따라 달라지므로 두 블록의 보상은 서로 다를 수 있습니다. 보상 한도는 해당 높이에서 허용하는 신규 발행량과 블록 안의 다른 유효한 거래 수수료를 더한 값입니다. Bitcoin Core는 GetBlockSubsidy로 신규 발행량을 계산합니다. 공급량을 늘리는 것은 신규 발행분뿐이고 수수료는 기존 satoshi입니다. 적게 받을 수는 있지만 차액을 나중에 받을 수는 없습니다. 받지 않은 신규 발행분은 생성되지 않고, 받지 않은 수수료는 영구히 쓸 수 없게 됩니다. 한도를 단 1 satoshi만 넘어도 블록 전체가 무효입니다. [4] [6]

보상은 여러 채굴자의 작업을 조율하는 풀로 가는 경우가 많습니다. 잠금 스크립트는 나중에 출력을 쓰기 위한 조건을 정하는 짧은 프로그램입니다. PPS, FPPS, PPLNS는 풀이 참여자에게 수입을 나누는 서로 다른 방식입니다. 출력은 일반 잠금 스크립트를 사용합니다. 보상은 하나의 집금 주소로 가거나 여러 수령자에게 나뉘며, 풀 운영자의 몫을 포함할 수도 있습니다. 노드는 금액과 소비 조건을 검사할 뿐 계약이나 실소유자를 확인하지 않습니다. PPS, FPPS, PPLNS, 최소 지급액과 참여자에게 나중에 보내는 송금은 풀의 규칙이지 Bitcoin 합의 규칙이 아닙니다. [6] [7]

안나는 블록에서 보상을 보더라도 아직 전기 요금을 낼 수 없습니다. 거래소가 묶어 둔 것이 아니라 Bitcoin 규칙이 기다리도록 합니다. 블록 높이는 블록의 위치를 나타내는 번호이며, 여기서 H는 보상이 생긴 블록의 높이입니다. COINBASE_MATURITY는 소비하는 블록 높이와 출력을 만든 높이의 차이가 최소 100이어야 한다고 정합니다. 높이 H에서 만든 출력은 유효한 H+100 블록에서 처음 쓸 수 있습니다. 생성 블록도 첫 확인으로 세므로 지갑의 확인 횟수는 달라 보일 수 있습니다. 기준은 높이 차이이며 예상 시간이 아닙니다. 조건을 충족해도 블록이 영원히 체인에 남는다는 보장은 없습니다. [5]

재구성은 노드가 누적 채굴 작업량이 더 많은 다른 유효한 분기로 옮기는 것입니다. UTXO는 미사용 출력, 즉 개별적으로 쓸 수 있는 금액입니다. 보상은 이를 만든 블록과 함께 그 목록에서 사라질 수 있습니다. 재구성으로 원래 블록이 누적 작업량이 가장 많은 유효한 활성 체인에서 빠질 수 있습니다. 그러면 그 coinbase 출력이 활성 UTXO 집합에서 사라지고, 보상을 소비하는 후속 거래도 영향을 받을 수 있습니다. 100블록 대기는 짧은 재구성의 영향을 줄이지만 절대적인 보장은 아닙니다. 풀은 활성 체인상의 보상, 소비 가능 여부, 채굴자에게 진 지급 의무를 구분해야 합니다. [4] [5]

정확한 형식을 읽으려면 몇 가지 이름이 필요합니다. 입력은 보통 쓸 자금을 가리키고 출력은 금액과 사용 조건을 정합니다. Txid는 거래 식별자이고 버전은 형식을 나타내며 locktime은 거래가 들어갈 수 있는 시점을 제한할 수 있습니다. 블록에는 거래가 하나 이상 있어야 하며 첫 거래만 coinbase일 수 있습니다. 입력은 하나이고 이전 출력을 가리키는 참조가 null입니다. 해시는 모두 0인 32바이트, 인덱스는 0xffffffff입니다. outpoint라는 이 참조는 기존 출력을 소비하지 않으므로 그 지출을 허가하는 일반 서명을 검사하지 않습니다. 그래도 거래에는 txid, 버전, locktime과 하나 이상의 출력이 있습니다. [1] [2] [3]

높이는 블록의 위치 번호입니다. BIP34는 Bitcoin이 규칙을 채택한 제안의 이름이고, scriptSig는 입력 데이터 필드이며 CScript는 스크립트 명령과 숫자를 표현하는 방식입니다. BIP34는 scriptSig의 맨 앞에 최소 인코딩된 CScript 숫자로 블록 높이를 넣도록 요구합니다. 필드 전체는 2–100바이트입니다. 뒤에는 extra nonce, 풀 식별 정보, 병합 채굴 데이터 등을 둘 수 있습니다. 높이나 길이가 틀리면 블록이 거부됩니다. 입력이 일반 잠금 해제 스크립트처럼 실행되지는 않아도, 포함된 서명 연산 코드는 서명 연산 수 제한인 sigops에 계산될 수 있습니다. [1] [9]

채굴은 블록의 짧은 요약인 헤더의 해시, 즉 디지털 지문을 반복 계산합니다. Nonce는 바꾸는 숫자이고 Merkle root는 거래들을 묶은 지문입니다. 따라서 거래를 바꾸면 새로운 시도가 가능해집니다. 블록 헤더의 nonce는 32비트여서 채굴 장비가 가능한 값을 빠르게 모두 시도합니다. 따라서 소프트웨어는 coinbase의 extra nonce도 바꿉니다. 그러면 txid, Merkle 트리 루트, 블록 헤더가 달라져 새로운 해시 탐색 공간이 생깁니다. 풀은 장비들이 불필요하게 같은 후보를 시험하지 않도록 작업을 나눕니다. Extra nonce가 추가 코인을 발행하는 것은 아닙니다. [6] [7] [12]

SegWit은 서명 같은 검증 데이터 일부를 witness라는 부분으로 분리합니다. Commitment는 검증 가능한 데이터 연결이지 추가 지급이 아닙니다. 아래는 그 연결의 기술적 형식입니다. 블록에 witness 데이터가 있으면 BIP141은 그 데이터에 암호학적으로 결속된 witness commitment를 coinbase 출력에 요구합니다. 스크립트는 6a24aa21a9ed로 시작합니다. 이는 OP_RETURN, 36바이트를 넣는 명령, aa21a9ed 표시입니다. 이어지는 32바이트는 witness Merkle root와 예약 값을 연결한 뒤 SHA-256을 두 번 적용한 해시입니다. Coinbase 입력의 witness에는 이 32바이트 예약 값 하나만 있어야 합니다. 여러 출력이 맞으면 가장 높은 인덱스가 적용됩니다. 쓸 수 있는 보상 지급이 아니며, witness 데이터가 없는 블록에서는 선택 사항입니다. [10]

Full Node는 Bitcoin 규칙을 직접 검증하는 컴퓨터입니다. 블록 무게는 허용된 데이터 용량의 사용량을 재며 Mempool은 일반 미확인 거래를 로컬에 보관합니다. 보상 검사도 전체 블록 검증의 일부입니다. Full Node는 coinbase가 맨 처음에 있어야 한다고 요구하고 같은 블록의 추가 coinbase는 거부합니다. scriptSig, BIP34 높이, 금액 범위, 블록 무게, 수수료와 필요한 witness commitment를 검사합니다. 출력 합계는 허용 발행량과 수수료를 넘을 수 없고, 나중에 소비할 때도 성숙 조건을 지켜야 합니다. 채굴자가 자신에게 임의의 금액을 준다고 유효해지는 것은 아닙니다. 소속 블록 없이 coinbase는 mempool에 들어가지 않습니다. [3] [4] [10]

Genesis Block은 Bitcoin의 시작 블록입니다. 그 특수성과 과거의 중복 식별자는 오늘날의 일반 규칙을 모든 역사적 사례에 구별 없이 적용할 수 없는 이유를 보여 줍니다. 높이 기록이 의무화되기 전에는 서로 다른 coinbase가 같은 txid를 가질 수 있었습니다. BIP30은 아직 소비하지 않은 오래된 출력을 덮어쓰지 못하게 하고, BIP34는 보통의 현대 블록에 구별되는 높이를 넣습니다. Genesis Block은 예외입니다. 저장된 블록에 coinbase는 있지만 초기화가 그 출력을 소비 가능하게 만들지 않았습니다. 따라서 최초 50 BTC는 쓸 수 없으며, 보통처럼 100블록을 기다리면 되는 경우가 아닙니다. [8] [9] [11]

더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Block, Block Subsidy, Transaction Fees, 채굴, Block Template, Bitcoin. 다음 항목에서도 이 글을 참조합니다 Block Subsidy, 확인, Reorg, Stale Block.

DOC · 001Bitcoin Developer Reference — Coinbase input문서 DOC · 002Bitcoin Developer Reference — Block chain문서 DOC · 003Bitcoin Core — transaction.h (IsCoinBase)문서 DOC · 004Bitcoin Core — validation.cpp문서 DOC · 005Bitcoin Core — consensus.h (COINBASE_MATURITY)문서 DOC · 006Bitcoin Core — miner.cpp문서 DOC · 007BIP 22 — getblocktemplate명세 DOC · 008BIP 30 — Duplicate transactions명세 DOC · 009BIP 34 — Block height in coinbase명세 DOC · 010BIP 141 — Segregated Witness commitment명세 DOC · 011Bitcoin Core — chainparams.cpp (genesis construction)문서 DOC · 012Stratum V2 — Mining Protocol specification명세
개정일: 1차 출처 우선 · 투자 조언이 아닙니다