🧾 txid 뜻, 비트코인은 위트니스 뺀 거래를 두 번, 이더리움은 서명까지 든 거래를 한 번 해시해요

txid(트랜잭션 ID)는 거래 데이터를 해시 함수에 넣어 나온 32바이트 값이에요. 화면에는 16진수 64자리로 보이고, 같은 거래 바이트에서는 누가 계산해도 같은 값이 나와서, 그 거래를 찾아 가리키는 번호로 쓰여요. 계산 방법은 체인마다 달라요. 비트코인은 위트니스(세그윗의 서명·스크립트 데이터)를 뺀 거래를 SHA-256으로 두 번 해시하고, 비트코인 코어는 그 결과의 바이트 순서를 뒤집어 보여 줘요. 이더리움은 서명까지 들어간 거래 바이트를 keccak256으로 한 번 해시해 앞에 0x를 붙여요. 이더리움 쪽 문서는 같은 값을 txid 대신 「트랜잭션 해시」라고 불러요.

먼저 요약하면 이래요.

• 비트코인 txid: 버전, 입력, 출력, 잠금 시간을 이어 붙인 전통 직렬화를 SHA-256으로 두 번 해시한 값이에요(BIP141, 비트코인 코어 transaction.cpp).
• wtxid: 위트니스까지 넣은 확장 직렬화의 해시예요. 위트니스가 없는 거래는 txid와 값이 같아요. 비트코인 코어가 거래를 풀어 보여 주는 명령(getrawtransaction, decoderawtransaction) 출력의 hash 칸이 이 값이에요.
• 표시 순서: 비트코인 코어는 32바이트를 거꾸로 뒤집어 16진수로 보여 줘요(uint256.h). 첫 블록의 거래로 다시 계산해 보니 뒤집은 값만 코어 소스에 적힌 검증값과 맞았어요.
• 이더리움 트랜잭션 해시: 레거시 거래는 RLP 인코딩을, 그 밖의 거래는 종류 바이트(0x01부터 0x04까지)를 앞에 붙인 인코딩을 keccak256으로 한 번 해시해요. 서명 필드가 재료에 들어가고, 바이트는 뒤집지 않아요.
• txid가 겹친 기록: 비트코인 메인넷 91,842번과 91,880번 블록에는 앞선 코인베이스 거래와 같은 txid가 다시 나와요. BIP30과 비트코인 코어는 이 두 블록을 예외로 적어 두었어요.

이 글은 2026년 10월 15일 오후 3시 51분부터 4시 8분 사이(한국 시각)에 비트코인 코어 v31.1(2026년 7월 8일 공개된 정식판) 원본 소스, 비트코인 개선 제안 BIP141·BIP144·BIP30 원문, 이더리움 실행 계층 스펙 저장소(커밋 067505d), EIP-2718, 이더리움 JSON-RPC 명세, ethereum.org 거래 문서 원본을 GitHub에서 직접 받아 정리했어요. 예시 해시 두 개는 이 원문에 적힌 값만으로 다시 계산했어요. 블록 익스플로러와 거래소 화면은 보지 않았어요.

이 글이 읽은 자료

비트코인 txid는 무엇을 해시한 값인가

위트니스를 뺀 거래를 SHA-256으로 두 번

비트코인 코어에서 거래의 txid를 만드는 함수는 transaction.cpp의 ComputeHash예요. 거래를 TX_NO_WITNESS 방식, 곧 위트니스 없이 바이트로 늘어놓은 다음 해시 계산기(HashWriter)에 넣고 GetHash를 불러요. hash.h는 이 GetHash를 「쓰인 모든 데이터의 double-SHA256 해시」라고 설명하고, 실제 코드도 SHA-256 결과를 한 번 더 SHA-256에 넣어요.

세그윗을 정의한 BIP141도 같은 내용을 적었어요. 문서는 txid의 정의가 바뀌지 않았다고 하면서, txid를 아래 「전통 직렬화」의 double SHA256이라고 적어요.

[nVersion][txins][txouts][nLockTime]

버전, 입력 목록, 출력 목록, 잠금 시간 네 부분이에요. 코어 소스에서 입력 하나는 이전 거래의 txid와 출력 번호, scriptSig, nSequence로 이뤄지고, 출력 하나는 금액과 scriptPubKey로 이뤄져요. 거래 하나가 다른 거래의 출력을 쓸 때 그 출력을 가리키는 표시(outpoint)도 「거래 해시와 출력 번호의 조합」이라고 코어 소스에 적혀 있어요. txid가 다음 거래의 재료로 다시 들어가는 셈이에요.

wtxid는 위트니스까지 넣은 두 번째 ID

BIP141은 「각 거래는 ID를 2개 갖는다」고 적고, 두 번째 ID인 wtxid를 위트니스까지 넣은 새 직렬화의 double SHA256으로 정의했어요.

[nVersion][marker][flag][txins][txouts][witness][nLockTime]

marker는 1바이트 0x00, flag는 0이 아닌 1바이트이고 지금은 0x01을 써요. 입력이 모두 위트니스 프로그램이 아니면 wtxid는 txid와 같아요. 코어 코드도 위트니스가 없는 거래는 txid 값을 그대로 wtxid로 돌려줘요(transaction.cpp의 ComputeWitnessHash).

두 ID는 쓰임새가 갈려요. BIP144는 블록의 거래 머클 트리와 입력이 이전 출력을 가리키는 참조에는 항상 위트니스 없는 직렬화로 계산한 해시, 곧 txid를 쓴다고 적었어요. 코어의 merkle.cpp도 블록 머클 루트는 각 거래의 txid로, 위트니스 머클 루트는 wtxid로 계산해요. 위트니스 머클 루트의 첫 자리에는 코인베이스 거래 대신 0을 넣는데, BIP141도 코인베이스 거래의 wtxid를 0x0000…0000으로 본다고 적었어요.

세그윗은 소프트포크로 들어온 변경이에요. BIP141 머리말의 계층 표시가 「Consensus (soft fork)」예요. 소프트포크와 하드포크가 어떻게 다른지는 하드포크와 소프트포크 차이에 정리돼 있어요.

코어 거래 조회 출력의 hash 칸은 txid가 아니에요

비트코인 코어의 getrawtransaction(상세 출력)과 decoderawtransaction 명령은 txid와 hash 두 칸을 함께 보여 줘요. core_io.cpp는 txid 칸에 GetHash의 결과(txid)를, hash 칸에 GetWitnessHash의 결과(wtxid)를 넣어요. 명령 도움말은 hash 칸을 「The transaction hash (differs from txid for witness transactions)」, 곧 위트니스가 있는 거래에서는 txid와 다르다고 설명해요. 지갑 명령 gettransaction은 같은 두 값을 txid와 wtxid라는 이름으로 보여 주고, wtxid를 「위트니스 데이터를 포함한 직렬화 거래의 해시」라고 적었어요.

이름만 보면 hash 칸이 「트랜잭션 해시」 같지만, 거래 조회 출력에서 거래 ID로 옮겨 적을 값은 txid 칸이에요. 위트니스가 없는 옛 형식 거래라면 두 칸이 같은 값이라 차이가 안 보일 뿐이에요.

서명이 바뀌면 txid도 바뀌나요

비트코인은 서명이 어디에 들어 있느냐에 따라 달라요. BIP141의 요약은 스크립트와 서명을 위트니스라는 새 구조로 옮긴다고 적었어요. 그리고 「서명 데이터가 더 이상 거래 해시의 일부가 아니므로, 거래에 서명한 방식이 바뀌어도 거래 식별과는 상관이 없어진다」고 설명해요. 위트니스에 들어간 서명은 txid 재료가 아니라서, 그 서명이 달라져도 txid는 그대로라는 뜻이에요. 반대로 서명이 scriptSig에 들어가는 옛 형식 입력에서는 서명이 txid에 반영돼요. 코어의 서명 코드(sign.cpp)는 세그윗·탭루트 출력을 쓸 때 서명을 위트니스에 넣어요. P2SH로 감싼 세그윗 출력도 마찬가지라서, 이때 scriptSig에는 감싼 스크립트만 남아요. 그 밖의 옛 형식 출력을 쓸 때는 서명을 scriptSig에 넣어요. scriptSig는 txid 재료인 전통 직렬화에 들어가는 부분이에요.

그래서 「txid는 서명이 끝나야 생긴다」는 말은 정확하지 않아요. txid는 거래 바이트만 있으면 계산되는 값이고, 위트니스 속 서명은 그 재료가 아니에요. 코어도 아직 고칠 수 있는 거래 객체(CMutableTransaction)에 같은 방식의 해시 계산 함수를 두고 있어요. BIP141은 이 성질이 쓰이는 예도 들었어요. 두 사람이 2-of-2 멀티시그 출력으로 돈을 보내는 펀딩 거래에 서명하기 전에, 그 출력을 쓰는 거래를 먼저 만들어 서명을 주고받고, 확인한 뒤에야 펀딩 거래에 서명한다는 방식이에요. 문서는 이런 확인 전 거래의 연결이 라이트닝 네트워크 같은 결제 네트워크의 기본 구성 요소라고 적었어요.

이더리움은 반대로 서명이 해시 재료에 들어가요. 실행 계층 스펙의 레거시 거래 필드는 nonce, gas_price, gas, to, value, data 다음에 v, r, s가 붙고, 그 뒤에 생긴 거래 종류는 끝에 y_parity, r, s가 붙어요. 트랜잭션 해시는 이 필드를 모두 담은 인코딩을 해시한 값이에요. 서명할 때 쓰는 해시는 따로 있어요. 스펙의 signing_hash_1559 같은 함수는 서명 필드를 뺀 나머지만 해시하고, recover_sender는 이 서명용 해시와 서명으로 보낸 사람의 공개키를 복원해요. 이더리움에서 서명용 해시와 트랜잭션 해시는 서로 다른 값이라는 뜻이에요.

표시할 때는 바이트를 뒤집어요

SHA-256을 두 번 거친 결과는 32바이트예요. 비트코인 코어는 이것을 16진수 문자열로 보여 줄 때 바이트 순서를 뒤집어요. uint256.h의 설명은 이 표기를 스스로 「특이하다(unusual)」고 적었어요. 4바이트 12, 34, 56, 78을 보통의 16진수 편집기나 파이썬 bytes.hex()는 12345678로 보여 주지만, 코어의 GetHex와 ToString은 78563412로 보여 준다는 예도 들었어요.

반대 방향도 같아요. 코어가 16진수 문자열을 값으로 바꾸는 FromHex도 문자열을 뒤집힌 바이트 순서로 읽고, 길이는 바이트 수의 두 배, 곧 64글자여야 해요. 해시 계산 결과를 내부 순서 그대로 16진수로 적은 값을 코어에 넣으면, 코어는 그것을 다른 txid로 읽어요.

재계산 예시 ① 비트코인 첫 블록의 거래

코어 소스의 chainparams.cpp에는 비트코인 첫 블록(제네시스 블록)을 만드는 함수와, 만든 결과를 확인하는 검증 줄이 있어요. 첫 블록에는 거래가 코인베이스 거래 하나뿐이에요. merkle.cpp는 해시가 하나뿐이면 그 값을 그대로 머클 루트로 돌려주기 때문에, 첫 블록의 머클 루트가 곧 그 코인베이스 거래의 txid예요. 함수에 적힌 재료로 거래를 직접 조립해 해시하면, 코어가 검증하는 값과 맞는지 바로 볼 수 있어요.

함수가 정한 재료와 기본값을 이어 붙이면 이렇게 돼요.

모두 더하면 204바이트예요. scriptSig에 들어간 문구는 「The Times 03/Jan/2009 Chancellor on brink of second bailout for banks」이고, 조립한 scriptSig는 chainparams.cpp 주석에 적힌 코인베이스 값과 글자까지 같아요. 이 204바이트를 해시한 결과는 아래와 같아요.

SHA-256 한 번      27362e66e032c731c1c8519f43063fe0e5d070db1c0c3552bb04afa18a31c6bf
SHA-256 두 번      3ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a
바이트 뒤집기      4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
코어 검증값        4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b

코어 v31.1 chainparams.cpp 137행은 첫 블록의 머클 루트가 4a5e1e4b…deda33b인지 확인해요. 두 번 해시하고 바이트를 뒤집은 값만 이 검증값과 맞았고, 내부 순서 그대로인 3ba3edfd…4b1e5e4a나 SHA-256을 한 번만 건 값은 맞지 않았어요. 같은 파일의 주석도 이 거래를 CTransaction(hash=4a5e1e, ...)처럼 뒤집은 값의 앞부분으로 적어 두었어요.

txid가 거래 내용의 지문이라는 것도 여기서 볼 수 있어요. 문구의 마지막 글자(banks의 s) 하나를 r로 바꿔 같은 계산을 하면 표시값이 0ebf7e9027e4ac7ae7aedcb172a3b02628387f991f3e6496eb0abaa3a24fcc0a로 바뀌어요. 64자리 가운데 원래 값과 같은 자리에 같은 글자가 남은 곳은 3곳뿐이었어요. 참고로 chainparams.cpp 주석은 첫 블록 생성 거래의 출력이 처음부터 데이터베이스에 없어서 쓸 수 없다고 적었어요. 이 예시는 계산을 확인하는 용도예요.

이더리움은 서명까지 넣고 keccak256 한 번

이더리움 실행 계층 스펙의 get_transaction_hash 함수는 짧아요. 레거시 거래면 RLP로 인코딩한 바이트를, 그 밖의 거래면 이미 인코딩된 바이트를 keccak256에 한 번 넣어요. 인코딩은 encode_transaction이 맡는데, 레거시 거래는 RLP 그대로 두고 나머지는 종류 바이트를 앞에 붙여요.

EIP-2718은 종류 바이트를 0부터 0x7f 사이의 수로 정하고, 레거시 거래는 항상 0xc0 이상의 바이트로 시작해서 서로 겹치지 않는다고 적었어요. 같은 문서는 클라이언트가 첫 바이트를 보고 두 형식을 구별할 수 있다고 설명해요. 스펙의 decode_transaction도 첫 바이트 1, 2, 3, 4로 종류를 골라요.

이 글이 연 판본은 스펙 저장소의 bpo2 폴더예요. 저장소의 포크 폴더 가운데 메인넷 활성 시각이 적힌 마지막 것이 bpo2(2026년 1월 7일 01시 01분 11초 UTC, 한국 시각 오전 10시 1분 11초)이고, 그 뒤의 bpo3, bpo4, bpo5, amsterdam, bogota는 일정 미정(Unscheduled)으로 적혀 있어요. 트랜잭션 해시 함수와 인코딩 함수는 osaka, bpo2, amsterdam 세 폴더에서 글자까지 같았어요. 포크 폴더를 세는 기준은 이더리움 하드포크 기준 정리에 따로 있어요.

적는 형식도 비트코인과 달라요. 이더리움 JSON-RPC 명세는 트랜잭션 해시를 hash32 형식, 곧 「0x 뒤에 소문자 16진수 64자리」로 정해요. 그래서 0x까지 합쳐 66자예요. 거래 한 건을 묻는 명령 eth_getTransactionByHash도 이 형식의 「Transaction hash」를 받아요. 이번에 연 이더리움 자료 네 개(실행 계층 스펙의 거래 파일, EIP-2718, JSON-RPC 거래 명세, ethereum.org 거래 문서)에는 txid라는 낱말이 한 번도 나오지 않았어요.

재계산 예시 ② ethereum.org 문서의 서명 예시

ethereum.org 거래 문서에는 서명 요청의 응답 예시가 실려 있어요. 문서는 응답의 raw를 「RLP로 인코딩한 서명된 거래」라고 설명해요. 이 133바이트를 keccak256에 한 번 넣으니 같은 응답에 적힌 hash 값과 정확히 같았어요.

raw 길이           133바이트, 첫 바이트 f8(레거시 RLP 목록)
keccak256(raw)     eba2df809e7a612a0a0d444ccfa5c839624bdc00dd29e3340d46df3870f8a30e
문서의 hash        eba2df809e7a612a0a0d444ccfa5c839624bdc00dd29e3340d46df3870f8a30e
sha3_256(raw)      4af90e47aa6a51cbf0f33ea702d743d7eb6c3c1ae0f99ecbb2b53c9417777e20

바이트를 뒤집지 않은 그대로가 문서 값과 맞았어요. raw를 RLP로 풀면 항목이 9개이고, 마지막 세 개가 v(0x26, 십진수 38), r, s예요. 스펙의 recover_sender는 이런 레거시 서명의 v를 35에 체인 ID의 두 배와 0 또는 1을 더한 값으로 다뤄요. 38은 35 + 2 × 1 + 1이라 체인 ID는 1이에요.

두 가지를 덧붙여요. 첫째, 같은 바이트를 파이썬 표준 라이브러리 hashlib의 sha3_256에 넣으면 4af90e47…로 전혀 다른 값이 나왔어요. 이름이 비슷해도 이더리움 스펙이 쓰는 keccak256과 같은 함수가 아니라서, 직접 계산해 볼 때는 keccak256을 골라야 해요. 둘째, 같은 응답의 tx 항목에 적힌 gas(0x55555), value(0x1234), input(0xabcd) 값은 raw를 풀어 본 값(gas 0x0333, value 0, data 36바이트)과 달라요. 그래서 이 글은 raw와 hash 두 값만 맞춰 봤어요.

비트코인 txid와 이더리움 트랜잭션 해시 한눈 비교

txid가 겹친 적도 있어요

txid는 거래 바이트에서 나오는 값이라, 바이트가 완전히 같은 거래가 두 번 생기면 txid도 같아져요. 비트코인에는 실제로 그런 기록이 있어요. BIP30은 「참조 구현은 같은 식별자를 가진 중복 거래가 없다고 가정해 왔지만 그렇지 않다」고 적고, 특히 코인베이스 거래는 중복되기 쉽고 그 위에 쌓은 일반 거래도 중복될 수 있다고 설명했어요.

BIP30이 택한 규칙은 앞서 같은 식별자를 가진 거래의 쓸 수 있는 출력이 남아 있지 않을 때만 중복을 허용하는 것이에요. 문서는 이 규칙이 처음에는 타임스탬프가 2012년 3월 15일 0시(UTC) 이후인 블록에 적용됐고, 나중에 메인넷의 91,842번과 91,880번 두 블록만 빼고 모든 블록에 적용하도록 넓혀졌다고 적었어요. 코어 v31.1의 validation.cpp도 이 두 블록을 블록 해시까지 적어 예외로 두고(IsBIP30Repeat), 같은 txid를 먼저 가진 거래가 든 블록으로 91,722번과 91,812번을 따로 적어 둬요(IsBIP30Unspendable). 같은 파일의 주석은 이 경우를 「이미 있는 중복 코인베이스 2쌍」이라고 부르지만, 어느 블록이 어느 블록과 짝인지는 코드에 적혀 있지 않아요.

출금 TXID를 다룰 때 이 글과 이어지는 것

출금 내역에서 받은 TXID를 블록 익스플로러 검색창에 넣어 거래 상태를 보는 방법은 블록체인 익스플로러 보는 법에, 입금이 「처리 중」에 머물 때 컨펌 수를 확인하는 순서는 코인 입금 컨펌 점검 가이드에 정리돼 있어요. 이 글에서 확인한 내용 가운데 그때 쓸 만한 것은 세 가지예요.

1. 비트코인 코어의 거래 조회 출력에서 옮겨 적는 값은 txid 칸이에요. hash 칸은 위트니스가 있는 거래에서 wtxid라 값이 달라요.
2. 비트코인 코어가 보여 주는 txid는 바이트를 뒤집은 값이에요. 계산 결과를 내부 순서 그대로 적은 값은 코어가 다른 txid로 읽어요. 받은 문자열을 손대지 않고 그대로 붙여 넣는 편이 안전해요.
3. 이더리움 트랜잭션 해시는 0x를 포함해 66자예요. JSON-RPC 명세의 형식은 0x 뒤에 소문자 16진수 64자리예요.

이 글이 다루지 않은 것

• 거래소가 TXID를 어느 화면에 보여 주는지, 출금 처리 단계별로 어떻게 표시하는지는 거래소마다 달라 다루지 않았어요.
• 블록 익스플로러가 txid와 wtxid 가운데 무엇을 보여 주는지는 익스플로러를 열지 않아 확인하지 않았어요.
• 솔라나, 리플, 트론 같은 다른 체인의 거래 식별자 계산은 보지 않았어요.
• 해시 충돌 확률이나 해시에서 거래 내용을 거꾸로 알아낼 수 있는지 같은 암호학 수치는 이번에 연 문서에 없어 적지 않았어요.

모든 내용은 2026년 10월 15일 오후 3시 51분부터 4시 8분 사이(한국 시각)에 받은 비트코인 코어 v31.1 원본, BIP 원문, 이더리움 실행 계층 스펙 커밋 067505d 기준이에요. 이더리움 스펙 저장소의 기본 브랜치 이름은 이날 forks/bogota였고, 같은 날 오후 4시 34분에 받은 브랜치 목록 116개에 master는 없었어요. 없는 master를 GitHub API에 물었을 때 돌아오는 답은 주소마다 달랐어요. 브랜치 조회(branches/master)는 forks/bogota로 옮겨졌다는 응답(301)을, 참조 조회(git/refs/heads/master)는 없다는 응답(404)을 돌려줬어요. 그래서 이 글은 브랜치 이름 대신 커밋을 고정한 주소로 적었어요.

이 글은 정보 제공 글이며 매매 권유가 아니에요. 가상자산은 변동성이 크고 원금 손실 위험이 있으며, 투자 판단과 그 결과에 대한 책임은 본인에게 있어요.