Coinbase는 Coinbase 회사나 정기 결제가 아닌 합의된 유형의 거래입니다. 블록과 함께 노드는 제로 아웃포인트, BIP34에 따른 높이, 보상 한도, 제로 위치, 성숙도 및 가능한 SegWit 약속을 확인합니다. 별도로 멤풀에 들어가지는 않습니다.
블록에는 최소한 하나의 거래가 포함되어야 하며 코인베이스는 첫 번째 거래만 가능합니다. 비트코인 코어는 정확한 구조, 즉 이전 출력의 해시에 32개의 0바이트가 포함된 단일 입력과 0xffffffff 인덱스로 이를 인식합니다. 입력은 기존 UTXO의 잠금을 해제하지 않으므로 일반 서명이나 prevout 값이 없습니다. 트랜잭션에는 여전히 여러 출력, 일반 버전, 잠금 시간 및 사용자 정의 txid가 있을 수 있습니다. [비트코인 개발자 레퍼런스 - 코인베이스 입력] [비트코인 개발자 레퍼런스 - 블록체인] [비트코인 코어 - transaction.h (IsCoinBase)]
코인베이스 출력의 합계는 해당 금액에 블록 내 다른 모든 유효한 거래의 수수료를 더한 금액에 대해 GetBlockSubsidy를 초과할 수 없습니다. 새로 발행된 보상 구성요소만이 새로운 사토시를 생성합니다. 수수료는 기존 사토시를 변환합니다. 광부는 더 적은 금액을 청구할 수 있으며 그 차이는 영원히 사라지지만 한도를 초과하는 사토시가 전체 블록을 무효화합니다. 합의는 풀, 채굴자 또는 여러 스크립트 간의 분할을 결정하지 않습니다. [비트코인 코어 - 유효성 검사.cpp] [비트코인 코어 - miner.cpp]
BIP34부터 scriptSig 코인베이스는 최소로 인코딩된 CScript 번호로 현재 블록 높이로 시작해야 합니다. 전체 scriptSig는 2~100바이트입니다. 나머지는 추가 nonce, 풀 태그 또는 병합된 채굴 약정을 전달할 수 있지만 규칙을 벗어나지는 않습니다. 잘못된 높이나 길이로 인해 블록이 무효화되고 내장된 서명 opcode가 sigop 제한을 소비할 수 있습니다. [비트코인 개발자 참조 - 코인베이스 입력] [BIP 34 - 코인베이스의 블록 높이]
ASIC은 헤더의 nonce를 변경하지만 32비트 공간이 빠르게 부족해집니다. 따라서 채굴 소프트웨어는 추가 임시값을 코인베이스로 전환합니다. 이는 txid, Merkle 루트 트랜잭션 및 이후의 블록 헤더를 변경하여 새로운 해시 공간을 얻습니다. 풀 프로토콜은 공유가 충돌하지 않도록 작업자 간에 이 공간을 나눕니다. 추가 nonce는 추가 방출이 아닌 조정 부분입니다. [비트코인 코어 — miner.cpp] [BIP 22 — getblocktemplate] [Stratum V2 — 마이닝 프로토콜 사양]
Coinbase 출력은 공통 잠금 스크립트를 사용하며 여러 주소 또는 정책 간에 분할될 수 있습니다. 풀은 수집 주소로 지불하거나 수익을 즉시 분할하거나 운영자를 위해 출력을 예약할 수 있습니다. 그러나 노드는 계약이나 실제 소유자가 아닌 금액과 스크립트를 확인합니다. 지급 기준액, PPS, FPPS, PPLNS 및 이후 인출은 비프로토콜 풀 규칙입니다. [비트코인 코어 — miner.cpp] [BIP 22 — getblocktemplate]
블록에 증인 트랜잭션이 포함된 경우 BIP141은 하나의 출력에 코인베이스 증인 약속이 필요합니다. 즉, 6a24aa21a9ed로 시작하는 OP_RETURN 및 32바이트 약속입니다. 코인베이스 입력 감시에는 단일 32바이트 예약 값이 포함되어 있습니다. 일치하는 출력이 더 많으면 합의는 가장 높은 지수를 취합니다. 이 출력은 감시 Merkle 루트를 바인딩합니다. 채굴자에 대한 보상이 아닙니다. [BIP 141 - 분리된 증인 헌신]
코인베이스의 출력은 UTXO 세트에 특수 플래그로 표시되며 지출 및 생성 블록의 높이 차이가 오늘 COINBASE_MATURITY, 즉 100에 도달하는 경우에만 사용될 수 있습니다. 따라서 높이 H에 대한 보상은 처음으로 블록 H+100에서 사용될 수 있습니다. 지갑은 생성된 블록이 먼저 계산되기 때문에 한 번의 확인이라는 명백한 차이를 보일 수 있습니다. 성숙은 최종적인 것이 아닙니다. [비트코인 코어 — 합의.h (COINBASE_MATURITY)]
재구성 중에 채굴된 블록이 가장 많은 작업을 수행한 활성 체인에서 빠지면 해당 블록의 코인베이스 출력이 활성 UTXO 세트에서 사라집니다. 이미 성숙한 보상을 사용한 후속 거래도 유효하지 않을 수 있습니다. 100개 블록의 지연은 짧은 재구성으로 인한 손상을 제한하지만 불변성을 보장하지는 않습니다. 풀은 활성 체인, 성숙도 및 채굴자에 대한 약속을 별도로 모니터링해야 합니다. [비트코인 코어 — 유효성 검사.cpp] [비트코인 코어 — 합의.h (COINBASE_MATURITY)]
풀 노드는 검증 중에 위치 0의 코인베이스를 요구하고, 추가 코인베이스를 거부하고, scriptSig 길이 및 BIP34 높이를 확인하고, 다른 거래의 수수료를 계산하고, 새로운 발행 및 수수료 이상의 보상을 거부합니다. 또한 가치 범위, 가중치, 증인 약속 및 향후 지출 성숙도를 확인합니다. 높이와 블록 컨텍스트가 없는 별도의 코인베이스는 멤풀에 속하지 않습니다. [비트코인 코어 — transaction.h (IsCoinBase)] [비트코인 코어 — 유효성 검사.cpp] [BIP 141 — 분리된 증인 약속]
초기 블록에서는 높이가 아직 필수가 아니었기 때문에 동일한 txid 코인베이스가 생성될 수 있었습니다. BIP30은 이전 트랜잭션의 사용되지 않은 출력이 덮어쓰이는 것을 방지하고 BIP34는 최신 코인베이스를 일반적으로 고유한 높이로 만듭니다. Genesis는 역사적 예외입니다. 코인베이스는 직렬화된 블록에 있지만 초기화 코드는 출력을 확장 가능한 UTXO 데이터베이스에 넣지 않습니다. 따라서 유명한 50 BTC를 사용할 수 없습니다. [BIP 30 - 중복 거래] [BIP 34 - 코인베이스의 블록 높이] [비트코인 코어 - chainparams.cpp(제네시스 구성)]
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 블록, 블록 보상의 신규 발행분, 트랜잭션 수수료, 비트코인 채굴, Block Template, Bitcoin. 다음 항목에서도 이 글을 참조합니다 블록 보상의 신규 발행분, 확인, Reorg, Stale Block.