[ 비트코인 ] 머 클 패스 의 주체 는 누구 ? 거래 검증 ? 거래 확정 ? 
 [ 비트코인 ] 머 클 패스 의 주체 는 누구 ? 거래 검증 ? 거래 확정 ? 본문 
 [ 前 草 ] 이승현 ( wowlsh 93 @ gmail . com ) 2018 . 03 . 12 15 : 22 
 * 이 글 은 누군가 를 이해 시키 기 위한 글 이 아닙니다 . 블록체인 을 처음 만난 개발자 가 비트코인 의 핵심 이 라 할 수 있 는 거래 ( 검증 ) 에 대한 공부 / 삽질 을 하 며 겪 는 여정 으로써 굉장히 불 친절 한 글 이 라는 것 을 말씀 드립니다 . 
 그림 7 - 5 에서 는 단지 32 바이트 크기 의 해시 4 개 의 길이 ( 총 128 바이트 ) 인 머 클 경로 를 생성 함 으로써 거래 K 가 블록 내 에 포함 되 어 있 다는 사실 을 노드 가 입증 할 수 있 다는 것 을 보여준다 . 머 클 패스 는 HL . ......( 그림 에서 파랑 ) 등등 이렇게 4 개 의 해시 로 구성 되 어 있 다 . 인증 경로 로 제공 된 이 4 개 의 해시 를 가지 고 어떤 노드 라도 4 개 의 해 쉬 에 대응 하 는 해시 쌍 인 H . ... ( 그림 에서 점선 ) 와 머 클 트리 루트 를 계산 함 으로써 HK 가 머 클 루트 에 포함 되 어 있 다는 사실 을 증명 할 수 있 다 . 
 마스터링 비트코인 의 243 p 나온 글 이 다 . 해당 챕터 를 읽 어 보 면 머 클 트리 가 왜 필요 한지 , 머 클 패스 를 이용 해서 검증 하 는 기술 에 대해서 는 이해 하 기 어렵 지 않 지만 , 그럼 머 클 패스 를 던져 주 는 주체 는 누구 인가 에 대해서 는 아리송 할 것 이 다 . 즉 단위 기술 의 이해 보 다는 전반 적 인 스토리 이해 의 부재 를 느낄 것 이 다 . ( 사실 저 책 의 내용 중 오역 도 많 은 듯 하 고 , 실 저자 가 친 철 하 게 쓰 지 못한 내용 도 있 다는 핑계 를 대 고 싶 다 . 뭐 책 두께 가 한 800 페이지 는 되 야 가능 하 겠 지만 . . 블록체인 의 성경 과 같 은 보석 같 은 책 에 대해 불손 한 자세 를 보인 것 같 아서 자진 검열 함 ) 
 즉 저 책 으로 처음 블록체인 ( 비트코인 ) 을 마주 친다면 " HK 가 검증 대상 이 면 , 그 쌍 이 HL 임 을 어떻게 아 는지 ? 이미 머 클 트리 상 에 HK , HL 이 같이 있 는 것 을 확신 한다면 보낼 필요 도 없 는 게 아닌지 . .?? 모든 노드 가 참여 하 는지 ? 누가 보내 는지 ? ? 언제 보내 는지 ? HK 거래 는 현재 거래 인가 , 아니면 현재 거래 를 검증 하 기 위한 모든 과거 트랜잭션 중 하나 인가 " 라는 합당 한 의문 들 이 생기 기 마련 이 다 . 
 이 에 대해서 는 아래 와 같이 추측 을 했 다 . ( 사실 이 아니 다 . or 아닐 수 도 있 다 . ) 
 " 주변 의 p 2 p 의 상대 노드 중 풀 노드 는 거래 데이터 를 받 고 자신 의 전체 블록체인 과 대조 하 여 해당 거래 의 유효 성 확인 하 지만 p 2 p 상대 가 SPV 이 면 거래 데이터 와 함께 " 머 클 패스 " 를 보내 서 검증 에 참여 시킨다 . 
 책 에 있 는 거래 K 도 현재 발생 된 거 래 그 자체 라고 한참 오해 했 는데 , 아니 라고 추측 했 다 . 
 " 현재 거래 에 사용 된 UTXO or 입력 값 의 근거 과거 거래 들 중 하나 " 일 것 이 다 . 
 지금 거래 의 입력 값 ( or UTXO ) 으로 사용 된 코인 이 합당 한 것 인지 어떻게 검증 할 수 있 는지 가 궁금 해졌 다 . 일단 현재 거래 의 입력 값 을 검증 을 위해서 , 해당 입력 값 이 어떤 입력 값 에서 부 터 나왔 는지 에 대한 내용 을 블록체인 에서 찾 아야 한다고 짐작 할 수 있 는데 아래 의 두 가지 궁금 즘 을 해결 하 기 위해서 먼저 비트코인 을 구성 하 는 것 들 중 4 가지 구조 를 한눈 에 살펴보 는 것 으로 시작 하 자 . 
 @ 입력 값 과 UTXO 와의 구조 적 차이점 ( UTXO 를 가지 고 입력 값 만들 기 ? 출력 값 에서 UTXO 생성 하 기 ? ) 
 @ 기술 적 으로 입력 값 or UTXO 가 완성 된 블록 안 의 머 클 트리 에 존재 하 는 거래 해 쉬 와 어떻게 연관 되 는지 
 1 . UTXO 구조 
 https : / / github . com / zoinofficial / zoin / blob / master / src / coins . h 
 CTransaction 의 잘라 내진 ( Pruned ) 버전 : 오직 메타데이터 및 UTXO 용 으로 유지 
 시리얼 라이즈 포맷 : 
 - VARINT ( nVersion ) 
 - VARINT ( nCode ) 
 - the non - spent CTxOuts ( via CTxOutCompressor ) 
 - VARINT ( nHeight ) 
 nCode 는 다음 으로 이루어져 있 다 . 
 - bit 1 : IsCoinBase ( ) 
 - bit 2 : vout [ 0 ] is not spent 
 - bit 4 : vout [ 1 ] is not spent 
 - The higher bits encode N , the number of non - zero bytes in the following bitvector . 
 - In case both bit 2 and bit 4 are unset , they encode N - 1 , as there must be at 
 least one non - spent output ) . 
 Example : 0104835800816115944 e 077 fe 7 c 803 cfa 57 f 29 b 36 bf 87 c 1 d 358 bb 85 e 
 < > < > < - - - - - - - - - - - - - - - - - - - - - - - - - - ------------------><----> 
 version code vout [ 1 ] height 
 - unspentness bitvector : as 0 non - zero bytes follow , it has length 0 
 - vout [ 1 ] : 835800816115944 e 077 fe 7 c 803 cfa 57 f 29 b 36 bf 87 c 1 d 35 
 * 8358 : compact amount representation for 60000000000 ( 600 BTC ) 
 * 00 : special txout type pay - to - pubkey - hash 
 * 816115944 e 077 fe 7 c 803 cfa 57 f 29 b 36 bf 87 c 1 d 35 : address uint 160 
 01 09 0440 86 ef 97 d 5790061 b 01 caab 50 f 1 b 8 e 9 c 50 a 5057 eb 43 c 2 d 9563 a 4 eebbd 123008 c 988 f 1 a 4 a 4 de 2161 e 0 f 50 aac 7 f 17 e 7 f 9555 caa 486 af 3 b 
 < > < > < - - > < - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > < - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ------------------><----> 
 / \ \ | | / 
 version code unspentness vout [ 4 ] vout [ 16 ] height 
 2 ( 1 , + 1 because both bit 2 and bit 4 are unset ) non - zero bitvector bytes follow ) 
 - unspentness bitvector : bits 2 ( 0 x 04 ) and 14 ( 0 x 4000 ) are set , so vout [ 2 + 2 ] and vout [ 14 + 2 ] are unspent 
 - vout [ 4 ] : 86 ef 97 d 5790061 b 01 caab 50 f 1 b 8 e 9 c 50 a 5057 eb 43 c 2 d 9563 a 4 ee 
 * 86 ef 97 d 579 : compact amount representation for 234925952 ( 2 . 35 BTC ) 
 * 61 b 01 caab 50 f 1 b 8 e 9 c 50 a 5057 eb 43 c 2 d 9563 a 4 ee : address uint 160 
 - vout [ 16 ] : bbd 123008 c 988 f 1 a 4 a 4 de 2161 e 0 f 50 aac 7 f 17 e 7 f 9555 caa 4 
 * bbd 123 : compact amount representation for 110397 ( 0 . 001 BTC ) 
 * 8 c 988 f 1 a 4 a 4 de 2161 e 0 f 50 aac 7 f 17 e 7 f 9555 caa 4 : address uint 160 
 - UTXO 는 블록 과 별개 로 LevelDB 에 저장 된다 . 사용자 의 지갑 에 남 은 돈 이 얼마 인지 빠르 게 알 수 있 게 해 준다 . 
 - 입력 값 에 사용 된 UTXO 는 데 이타 베이스 에서 삭제 될 것 이 고 , 출력 값 은 새로운 UTXO 를 데이터베이스 에 입력 할 것 이 다 . 
 - 아직 잘 모르 겠 다 . 
 1 . " txid " ( string , required ) The transaction id 
 2 . " n " ( numeric , required ) vout number 
 3 . " include _ mempool " ( boolean , optional ) Whether to include the mempool . Default : true . Note that an unspent output that is spent in the mempool won ' t appear . 
 " value " : x . xxx , ( numeric ) The transaction value in BTC 
 - txid ( 거래 아이디 ) 와 vout 숫자 ( 해당 거래 에서 돈 줄 사람 중 몇 번 째 ) 로 출력 정보 ( UTXO ) 를 얻 을 수 있 구나 . 
 - 출력 정보 안 의 scriptPubKey 를 얻 는군 
 - 블럭 해 쉬 도 기본 적 으로 리턴 해 주 네 . 
 2 . 거래 구조 ( 인용 : 책 ' 비트코인 , 블록체인 과 금융 의 혁신 ') 
 거래 구조 안 에 는 입력 값 / 출력 값 / 기타 등등 이 있 다 . 
 입력 값 안 에 는 해제 스크립트 가 있 고 ( 근데 출력 값 인덱스 는 뭐 지 ? ) 
 출력 값 안 에 는 잠금 스크립트 가 있 다 . 
 하나 의 거래 안 의 잠금 스크립트 를 해제 스크립트 로 푸 는 건가 ? ( 아니 다 ) 
 오호 ~ 이전 UTXO 를 잠그 고 있 군 ? 그럼 이전 거래 를 잠그 고 현재 거래 에서 해제 시킨다는 건가 ? 
 근데 스크립트 가 뭐 지 ? @.@ 
 쉽 게 설명 하 는 블록체인 , 스크립트 란 뭔가요 ? [ 비트코인 의 언어 ] 
 쉽 게 설명 하 는 블록체인 , 비트코인 거래 의 원리 와 과정 - 1 
 쉽 게 설명 하 는 블록체인 , 비트코인 거래 의 원리 와 과정 - 2 [ 거래 의 입력 값 과 출력 값 ] 
 비트코인 시스템 에서 사용 하 는 암호 기술 ( II ) - 거래 검증 
 " amount " : x . xxx , ( numeric ) The transaction amount in BTC 
 " fee ": x . xxx , ( numeric ) The amount of the fee in BTC . This is negative and only available for the 
 " account " : " accountname ", ( string ) DEPRECATED . The account name involved in the transaction , can be "" for the default account . 
 " amount " : x . xxx , ( numeric ) The amount in BTC 
 " fee ": x . xxx , ( numeric ) The amount of the fee in BTC . This is negative and only available for the 
 " value " : x . xxx , ( numeric ) The value in BTC 
 > bitcoin - cli getrawtransaction " mytxid " true 
 - 개발 트랜잭션 안 에 는 그 트랜잭션 과 연관 된 block hash 가 있 다 . 결국 UTXO 는 이전 TXID 를 가르키 기 때문 에 UTXO 로 블럭 을 찾 을 수 있 다는 것 이 고 , 해당 블럭 이 그 UTXO 를 가지 고 있 는지 는 merkle path 를 통해서 알 수 있 을 것 이 다 . 
 3 . 블록 구조 
 - 채굴 로 만들 어 진 블록 의 최종 구조 
 - 이전 블록 해 쉬 , 머 클 루트 등 의 블록 헤더 와 개별 거래 들 을 모아 둔 블록 바디 가 있 다 . 
 - 블록 해 쉬 ( ID ) 는 자체 헤더 정보 를 이용 해서 만들 어 진다 . 
 - 그래서 nounce 와 bits 기반 으로 블 럭 마다 채굴 을 첨 부터 다시 시작 해야 하 지 . 
 getblock " blockhash " ( verbosity ) 
 If verbosity is 0 , returns a string that is serialized , hex - encoded data for block ' hash '. 
 If verbosity is 1 , returns an Object with information about block < hash >. 
 If verbosity is 2 , returns an Object with information about block < hash > and information about each transaction . 
 4 . 블록 구조 내 의 바디 
 - 3 번 그림 의 transaction 이 스택 형태 가 아니 라 해 쉬 값 의 트리 형태 로 구성 됨 . 아래 그림 은 뒤짚 어 놓 은 것 이 다 . 
 - 2 번 거래 구조 가 아래 그림 의 입력 값 A 이 고 , 이것 을 해싱 해서 나온 값 들 로 머 클 트리 를 만들 어서 블록 구조 바디 에 추가 
 - 즉 거래 자체 데이터 가 블록 에 추가 되 는 것 이 아니 다 . 
 비트코인 개발자 가이드 및 남 이 그린 그림 들 을 토대 로 전체 적 으로 훑어보 아도 예상외 로 UTXO 와 Transaction 간 의 연결 고리 를 찾 기 가 힘들 다 . Transaction 를 위해 UTXO 는 찾 을 수 있 는데 , 그 반대 방향 은 안 보이 는데 . . 다시 찾아보 자 . 내 가 TxID 에 집중 해서 그런 거 같 은데 아마도 Address 라는 공통 분모 가 있 는 거 같 기 도 하 고 . ..( 이미 주화 입마 상태 이 다 . 아 는 것 같 은데 잘 모르 겠 다 . ) 
 즉 UTXO 의 주인 의 address 를 얻 고 , 그 address 를 통해서 과거 거래 정보 를 얻 은 후 에 그 TxID 를 통해 머 클 패스 를 구성 할 것 이 라고 추측 할 수 도 있 겠 다 싶 었 는데 . .. 웬 걸 ~ 
 이미 위 에서 UTXO - TXID - 블럭 해시 간 에 연결 고리 를 발견 해 놓 고 먼 딴 생각 을 한 거 냐 
 위 의 이미지 를 보 듯이 , vin ( 입력 값 ) 에 는 " 이전 거래 " 와 " 몇 번 째 UTXO 인가 " 를 가르키 는 txid , vout 이 있 다 . 이 txid 를 매개변수 로 GetRawTransaction API 를 호출 하 여 이전 거래 를 찾 거나 , 그 거래 ( txid ) 를 포함 하 는 블록 의 머 클 트리 를 검증 한다는 추론 이 더 그럴싸 하 다 . 근데 이렇 다고 치 면 머 클 패스 / 머 클 트리 로 검증 하 는 것 은 얼마나 깊이 검증 해야 한다는 거 냐 ? 즉 내 가 채굴 자 인데 이 거래 를 내 임시 풀 에 넣 기 전 에 검증 하 는 용도 면 채굴 자 선 에서 끝나 는 거 아닌가 ? 만약 임시 풀 에 넣 고 있 다가 , 채 굴 에 성공 한 후 에 제대로 된 블록 에 넣 었 다고 치 고 이걸 다른 노드 들 에게 전파 한다고 칠 때 , 그 블록 의 검증 을 채굴 , 풀 노드 말 고 SPV 도 하나 ? SPV 가 하 니깐 머 클 패스 가 필요 한 거 니 당연 한 건가 ? SPV 한데 머 클 패스 를 보내 나 ? 아니 면 SPV 가 트랜잭션 을 받 으면 주변 노드 한테 머 클 패스 달 라고 요청 하 나 ? 
 아직 전체 적 인 비트코인 와 꾸 가 선명히 스케치 되 기 엔 스크립트 의 이해도 가 떨어져서 그런 듯 하 니 . . 좀 더 힘 을 내보 자 . 
 반복 만큼 좋 은 것 은 없 다 . 머리 를 정돈 하 기 위해 아주 쉬운 기초 적 인 내용 부터 다시 시작 해 보 자 . 
 그리고 나 서 이 글 의 애 니매 이 션 을 통해 스크립트 의 스택 연산 에 대해 감 잡 고 Bitcoin protocolfor developer 
 트랜잭션 의 로우 포맷 에 대해 익힌 후 Bitcoins the hard way : Using the raw Bitcoin protocol 
 비트코인 개발자 가이드 의 거래 부분 을 참고 로 수동 으로 가상 거래 를 해 보 는 아래 멋진 글 로 스크립트 에 대한 이해 를 끝장내 자 . 
 다시 한 번 읽 어 보 니 , 이제 감 이 잡힌 거 같 기 도 하 다 . 장 님 코끼리 다리 만지 기 를 했 던 것 같 다 . 
 비트코인 에서 의 검증 및 확정 은 아래 와 같 다 . - 3 가지 
 1 . 거래 가 일어나 고 그 거래 에 대한 검증 ( 노드 가 거래 풀 에 넣 기 위함 ) - 거래 검증 
 ㅁ 공개 키 검증 ( A 에게 돈 을 보낸 것 이 맞 나 ) 
 ㅁ coinbase 까지 이전 UTXO 전체 혹은 옵 셔 널 하 게 깊이 를 체크 한다 . ( 라고 누군가 말 하 던데 , 생각 해 보 면 깊이 1 이 면 충분 하 다고 추론 한다 . 마스터링 비트코인 에 도 이거 에 대한 언급 이 없 다 . ) 
 2 . 노드 에 의해 블록 이 완성 되 고 그 블록 에 대한 검증 - 블럭 검증 
 ㅁ 채굴 하 면서 노드 들 은 다른 곳 에서 날라온 블록 에 대한 검증 을 한다 . 블록 해 쉬 의 정확 성 과 깊이 를 조사 한다 . 
 3 . 블록 의 높이 에 따른 거래 확정 
 ㅁ 거래 가 포함 된 블록 이 길이 ( 높이 ) 를 체크 한다 . 
 검증 시 사용 되 는 것 들 
 A . LevelDB 에 저장 된 UTXO set 과 메타데이터 이용 
 B . 블록체인 자체 이용 
 자 마지막 결과 ! !! 여기 서 머 클 패스 를 던 저주 는 과정 1 , 2 , 3 중 어디 일까 ? 
 당연히 거래 검증 부분 이 다 . UTXO 들 에 대한 검증 시 이전 UTXO 는 어떤 블록 에 들 어 있 을 것 이 고 , 블록 은 단단히 고정 되 어 있 다 . 단단히 고정 되 어 있 는 블록 안 에 그 UTXO 가 포함 된 것 이 확실 하 다면 그 UTXO 는 신뢰 할 수 있 을 것 인데 , 풀 노드 라면 그냥 자신 의 정보 로 검증 하 고 , SPV 일 경우 머 클 패스 를 받 기 위해 요청 ( Push or Pull ) 할 것 이 다 . 
 참 먼 길 을 걸어왔 다 . 이러 한 여정 을 통해서 막힌 속 은 어느 정도 해소 할 수 있 게 되 었 다 . 하지만 이 글 은 모두 추측 에 기반 하 며 틀린 내용 도 있 을 것 이 다 . 본 글 을 사실 로 받 아 드리 지 말 자 . 추후 에 내 가 직접 C ++ 소스 를 까보 며 정확히 확인 해야 할 거 같 다 . 개발자 적 인 소명 이 랄까 ? 나 는 오로지 실제 소스 에 기반 한 것 만 사실 이 라고 생각 한다 . 조만간 C ++, Golang , Scala 소스 등 확인 할 것 이 며 관련 내용 은 블로그 에 작성 할 것 이 다 . 
 * 나중 에 발견 한 관련 동영상 . 
 * 마지막 으로 머 클 트리 에 먼가 문제 가 있 다고 느끼 는 사람 이 있 을지 도 모르 겠 다 . 그런 사람 이 실제 있 다 . 
 이 사람 인데 --> 
 다음 링크 를 참조 하 자 . 
 머 클 트리 , 머 클 패스 
 [ 블록체인 ] 개발자 를 위한 블록체인 로드맵 2018 . 04 . 15 
 [ 비트코인 ] Raw Transaction 만들 기 ( sig 는 어떻게 만들 어 지 는가 ? ) 2018 . 04 . 07