한 Node가 채굴에 성공하면,그 Node는 그 사실과 함께 채굴된 Block을, 자기와 교신하는 둘 또는 셋 정도의 다른 Node들에게 전달한다. 핵분열시의 연쇄 작용처럼 그 소문은 전체 Network에 퍼져 나가게 되지만,완전히 퍼지자면 수초의 시간(3~4초?)이 소요 된다. 그런데, 그 수초의 시간중에 다른 Node가 채굴에 성공할 확율이 분명히 있다. 즉,자주 일어나는 일은 아니지만, 동일한 부모Block에 대해서 2명의 자식Block이 생겨날 수가 있는 것이다. 이런 경우, 일시적으로 Blockchain의 분기(分岐,Fork)가 일어난다. "Fork"라는 영어 단어는, 우리가 식사할 때 쓰는 "포크 "처럼,한 몸체에서 여러개의 가지가 생겨남을 말하는 것이다.
이런 경우,어떤 분기가 정통성을 갖게되는가? 그런데, 이것 역시 경쟁체제로 되어 있다. 손자Block을 먼저 채굴하는 쪽이 승자가 되도록 규정 되어 있다. 무슨 말인가 하면,각 Node들은 자기에게 먼저 도착한 채굴Block을 일단 Blockchain에 포함시킨다. 그후 만약 또 다른 채굴Block의 소식에 접하게 되는 경우, 분기가 생겼음을 알고, 그 정보를 따로 보관해 둔다. 만약 다음 Block채굴(손자Block)이, 자기가 이미 Blockchain에 포함시킨 그Block에 이어지는 것이라면,자기들의 분기가 경쟁에서 이긴 것이 된다. 반대로, 따로 보관해 두었던 그 Block에서 채굴이 먼저 이루어지면, 그 쪽이 정통성을 갖게 되며(긴 Chain이 이긴다),따라서,Blockchain의 끝부분 2개를 고쳐서 저쪽 분기에 따라가는 것이다. 두개의 분기중에서,Hashing Power가 강한 쪽이 손자Block을 먼저 채굴할 가능성이 많기 때문에,결국은 어느 쪽이 대세(大勢)인가에 따라 결정이 된다는 이야기다.
우연에 우연이 겹치면,손자Block에서도 결판이 안나고, 경쟁이 좀 더 길어질 수도 있으나,어느 경우든 결말이 나기 마련이다. 그 결과,경쟁에서 진쪽이 채굴한 Block은 무효가 되므로,그것을 채굴한 Node는 운이 없어서 헛다리를 짚은 것이 될 뿐이다. Coinbase Tx이 아닌 일반적인 TX에는 아무 영향이 없다. 다만, 경우에 따라서,어떤 Tx이 Block #44500에 포함된줄 알았었는데 ,좀 지나고보니,그게 아니고, Block #44501에 포함된 것으로 최종 낙착이 되는 그런 경우는 있을 수 있겠다.
이상 언급한 Fork는,"정보"가 Network전체에 퍼지는 데에는 일정한 시간이 소요된다는 사실 때문에 확율적으로 간혹 생기는 일이고,이것들은 저절로 수습이 된다.
그런데, 이유가 있어서 Fork가 발생하는 경우가 있다. Bitcoin Protocol("헌법"이라 할수 있겠다)의 Version Up이 있을 때,
또는 Tx의 Version up이 있을 때,관련된 Software update를 한Node와 그렇지 않은 Node들이 같이 공존하는 상황에서 발생한다. Bitcoin은 어떤 "중앙"이 있어서,이래라 저래라 훈령을 내리는 System이 아니고,자율과 Concensus에 의해서 돌아가는 체제이다 보니,Version Up과 upgrade가 그리 간단한 문제가 아니다. 우선,Software개발자,일반 User들 그리고 채굴자들 등등,이해 관련자들의 의견 수렴과 합의가 전제되야 하고,New Version을 Test Network에서 철저히 검증하는 과정도 필요하고, 이러한 모든 것이 잘 되어서, 가령 Block # xxxxx 에서 부터 일제히 적용하는 것으로 하더라도,어떤 이유에서건 아직Update를 하지 않은 Node들(또는,반대하는 Node들)이 늘 있게 마련이다.
우리가 보통 Fork라고 하면, 이같은 상황에서 발생하는 Fork를 말하는 것이다.
New Version의 내용에 따라서, 두가지 상황이 벌어질 수 있다. Soft Fork와 Hard Fork가 그것이다.
예를 드는 것이 빠를 것이다. 가령,어느 시점부터 Coinbase Tx의 input Script에 Block Number(Block Height라고도 한다)를 써넣기로 하자는 제안이, 그 이유가 어떻든,다수의 지지로 채택되었다고 하자. 과거에는 그러한 규정이 없었다. 따라서,이런 경우,Update를 한 Node가 채굴한 Block을 update를 하지 않은 Node들이 받아 들이는 데는 규정상 문제가 없다(과거의 Rule은 "I don't care"였으므로). 그러나,반대로 update를 하지않은 Node가 채굴한 Block을 Update를 한 Node들의 입장에서는 받아들일 수가 없다. New Rule에 의하면 규정위반인 Block이므로. . . .
이런 경우를 Soft Fork라 하는데,Update를 한 Node들이 대다수라면, Hashing Power도 그들이 훨씬 우세하므로,Update를 하지 않은 쪽의 분기(分岐)에 비해서, Block채굴이 더 빨리 진행될 것이다. 그러므로,Update들 하지 않은 Node들은 채굴속도에서 늘 지게 되므로,결과적으로 Update한 쪽을 따라갈 수 밖에 없는 상황이 된다.
그래서, Soft Fork의 경우에는, 다수에 의한 Hashing Power로써, 아직update를 안한 Node들을 힘으로 제압하게 되므로, 큰 문제가 되지 않는다. 다음 그림을 참조하라.
Hard Fork는,
update를 하지 않은 Node들의 입장에서 볼때, Update를 한 Node가 채굴한 Block을, 규정위반이라 받아 들일수 없는 경우를 말한다. 예를들어,Block의 최대Size를 1Mega Byte 한다는 Rule이 전부터 있어 왔는데, 이를 2Mega까지도 허용하는 안이 채택되었다고 하자. Update를 한 Node가, 이 새로운 Rule을 십분 활용하여 2Mega에 가까운 Block을 채굴했을 경우, Update를 안한 Node들은 이 Block이 그들의 규정상으로는 최대Size 위반이므로 받아들일 수가 없다. Update를 한 Node가 대세이기 때문에 채굴 속도에서 밀린다고 해도,자기들의 Old rule상으로는 "규정위반"Block이므로 받아들이고 싶어도 받을 수가 없다. 이 때는 두개의 분기(Branch)가 공존하는 상태가 계속될 것이다. Old Rule을 따르는, 채굴 속도는 느린 Branch가 있고,한편으로는 New Rule에 따르고 채굴속도가 빠른(대다수 므로) Branch가 같이 있는 상황이 계속될 것이다.
다음 그림을 참조 하라.
이런 경우에 대비해서,다음과 같은 Rule이 Software에 심어져 있다.
"만약, 분기가 발생하여,자기가 추종하고 있는 Blockchain보다 6Block이나 더 빠른 분기(分岐)가 존재한다는 사실이 발견되면,작업을 멈추고, Software를 운용하는 사람(Operator)에게 경고 Message를 보낸다."
이 시나리오에 따르면, 경고Message를 본 Operator(Node를 운용하는 사람)는 Program이 멈춘 이유를 조사하기 시작할 것이고, 최근에 어떤 Update가 있었음을 그제야 알게 될 것이며,그에 따른 조치를 취하게 될 것이다.
Coinbase Tx의 특별취급:
채굴에 성공한 Node는, 첫거래로써 자기가 끼워 넣은 Coinbase Tx을 통하여, Block Reward와 Tx Fee를 받게 되는데, 이 금액을 Spend하려면 적어도 100Block이상이 더 경과해야 하도록 특별 규정이 있다. 위에서 설명한 여러가지 이유로 Forking 이
발생했을 때,채굴자가 아닌 제3자들을 보호하기 위한 것이다. 이 특별 규정이 왜 있는지 이해가 될 것이다.
Confirmation단계와 신뢰성:
Bitcoin으로 결제를 받는 On line Shop을 운영하고 있다고 가정하자. 물품의 대금이 적은 경우에는 Confirmation 0 단계에서 대금이 입금된것으로 보고, 물품을 발송해도 부담이 적겠지만, 대금이 큰 경우에는 Confirmation 7까지를 확인한 후에 발송하는 것이 권장된다. 왜냐하면, 위에서 말한 여러 원인으로, Forking이 발생한 상태라면,그런 애매한 상황을 교묘히 이용하여 속임수를 쓰는 Hacker가 있을 수 있기 때문이다. Confirmation1정도에서, 대금이 입금된 걸로 간주하고 물품을 발송 했는데,나중에 알고보니 그 Block들은 무효가 되고,그 대금 입금이 무효가 될 수도 있다는 것이다.
요컨데,Confirmation 단계가 올라 갈수록, 그 거래의 신뢰도,즉 그것의 확고 부동함의 정도가,확율적으로,기하급수적으로 점점 강화된다. 대체로, 7 confirmation이면 거의 100% 확신을 가질 수 있다고 보는 것이다. 그러나 이것은 거래의 당사자가 주관적으로 판단할 문제이다. 최근 채굴된 Block에서 입금된 금액을 그 다음Block에서 Spend하는 것을 금하는 Rule은 없다.
금년(2017년) 8월초에 Bitcoin에서, Hard Fork가 발생하면서 새로운 Branch가 생겨났다. 이것은, 뜻을 갖이하는
Miner들과 일부 개발자등등이 세력을 규합하여 의도적으로 Hard Fork를 일으킨 것이다. 말하자면,기존의 Rule에 대해서 "반기"를 들은 것이라 할 수있다. 지금까지 Block size는 1Mega Byte를 최대한계로 해 왔었는데, 이들은 이것을 8Mega Byte까지 확대하는 것으로 한 것이다. 이 배경에는, 약 3~4년 전부터 Bitcoin System이 겪고 있는 성장통이 있다. Bitcoin의 User층이 대폭 확대되면서 거래량이 급증하는데 비해서 처리하는 능력은 이를 쫒아가지 못하는 상황이 있어 왔었다. 거래량이 넘치다 보니,Miner들은 Tx Fee가 큰 거래를 선별적으로 Block에 포함하게 되면서,금액자체가 적거나 Tx Fee가 적으면,거래서의 처리가 자꾸 뒤로 미루어 지게 된다. 심한 경우,수일이 지나야 Blockchain에 등록이 되는 일들이 벌어지게 된 것이다. 이를 해결하기 위한 여러가지 방안이 제기되고 Test되었지만,문제는, 여러 관련자들의 이해가 상충하여 합의를 이루어 내지 못했던것이다. 금년에 와서, "Segwit"라고 불리우는 Soft Fork를 하는 것으로 대략 의견 수렴이 진척되는 와중에, 이 "8Mega로 확대"라는 Hard Fork가 발생한 것이다. 새로 생긴 이 Branch는 Bitcoin Cash라는 명칭을 갖게 되었고(기호 BTH),다음의 링크에서 보인 것처럼 독립적인 Block Explorer를 운용하고 있다.
현재 이 Bitcoin Cash는 1BTH에 400USD정도에 거래되고 있어서,Bitcoin의 4300USD와는 큰 차이를 보이고 있지만,일단 Crypto Currency 시가총액으로는 당당 3~4위를 차지하고 있어서, 장기적으로 과연 어느 쪽이 더 세력을 얻게 될지는 두고 보아야 할 것이다.
Bitcoin Original은 결제의 수단이라기 보다는, 투자 목적이라든가 가치의 보존에 중점을 두는,좀 단위가 큰 금액의 거래에 적합할런지 모른다. Bitcoin cash는 늘어난 Block size덕에 많은 Tx을 처리 할 수 있으므로,액수가 적은 거래도 취급할 여력이 있을 것이고, Tx Fee도 대폭 낮출수 있을지 모른다. 그러나 한편,이는 동시에 "낮은 문턱"을 의미하므로 불순한 의도를 가진 Hacker들에 의한 "Spam공격"에 취약해질 수도 있다. 모든 것에는 양면성이 있는 것이다.
이 마지막 절에서는, Bitcoin의 창시자로 알려져 있는, Satoshi 가 발표한, Bitcoin에 대한 White Paper(백서: 즉,사업 계획서 같은것)를 Block Chain에서 추출해 보는 작업을 해 보기로 한다.
누군가가 그 pdf 파일을 Bitcoin Blockchain에 올려 놓았다. 다음 링크를 열어보자.
Blockchain.info
단 하나의 거래지만 수많은 Output 들이 열거되어 있는 것이 보일 것이다. 모두 1 Satoshi 씩을 보내는 내용이다. 맨 아래로 가서 "출력 스크립트"를 보면 다음과 같다.
그 형식을 보면 "1 of 3"의 Multisig형식의 Output Script이다. 분석해 보면 다음 같이 쓸 수있다.
OP_1 < data 1 > < data2 > < data3 > OP_3 OP_CHECKMULTISIG
여기서, < data 1 > 등은 65Byte의 크기이고, 각각의 앞에는 0x41 (십진수65)이라는 Constant가 있지만 늘 하듯이 이를 생략한 것이다. 원래 < data 1 >등의 자리는 0x04로 시작하는 Full Public Key(65Byte)가 놓여야 하는 것이지만,실제로는 그렇지 않고, 65Byte의 data로 대치되어 있고,이것이 Blockchain에 올려 놓은 Pdf File의 내용인 것이다.
이후 이러한 Script가 계속된다. 다만, 출력 스크립트의 맨 끝에서 세번째 Output Script를 보면, 다음과 같은데,
OP_1 < 3e0a737. . . . 25454f460a0000000000000000 > OP_1 OP_CHECKMULTISIG
갑자기 "1 of 3"에서 "1 of 1"으로 Multisig의 방식이 변경되었다. 이는, File의 끝에 도달했음을 말해주는 것이 분명하다.
또한 data의 내용을 보면, 끝이 0000... 으로 끝나고 있는 것으로 보아, 아마도 454f460a가 File의 맨끝 부분일 것이라는 심증을 갖게 한다.
따라서,우리가 할 작업의 내용은 다음과 같다.
첫째, 이 Tx의 내용을 Hex형식으로 받은후 그것을 일단 Text File로 저장하고,
둘째로, 적절한 Hex Editor에서 위의 내용을 받아 들인후,
Editor의 기능을 써서,우리가 원하는 data부분만을 남길것.
마지막으로 이를 Satoshi.pdf라는 이름으로 저장한다.
늘 하던 대로, 주소난의 끝에 "?format=hex"를 추가하여,Hex형식으로 열면된다.
전체 내용을 마우스로 선택하여 복사한 다음,Notepad로 새 파일을 열어 복사한 내용을 Paste한후 Save한다.
다음 링크를 클릭하여, "Free 30day Trial"을 이용하면, 일단 30일 동안은 무료로 쓸 수 있다.
그 곳Download를 클릭한후, 자기의 OS에 맞는 010 Editor를 Down받아 설치한다.
010 Editor를 열고,메뉴에서
File > New >New Hex File
을 선택하여, 빈 새 Hex file을 연다.
한편, 18.1에서 준비했던 Text file을 열고 "편집>모두선택"을 한후 그 내용을 복사해 둔다.
다시, 010 Editor에서, 새 File의 선두에 커서를 위치 시킨후,
Edit > Paste From > Paste From Hex Text
를 선택하면,좀전에 복사해 두었던 내용이 Paste되면서,화면 가득히 Hex data가 채워질 것이다.
이제 부터 불필요한 부분을 단계적으로 삭제해야 한다.
선두 부분을 보면, Tx Version을 나타내는 01000000으로 시작하고 있는데, 160Byte쯤 뒤에
FF FF FF FF FD B4 03 이 보일 것이다. 선두 01000000. . . 부터, . . . .FF FD B4 03까지를 마우스로 선택한후 전부 Delete한다.
(이부분은 Input부와 Output Count부분이다)
다음. 수직 Scroll Bar를 써서 Hex data의 끝 부분 근처를 살펴 보면,
. . . . 45 4F 46 0A 00 00 00 00 00 00 00 00
를 발견할 수 있을 것이다. 45 4F 46 0A 가 Pdf File의 끝일 것이므로 45 4F 46 0A까지만 남기고,그 이후 내용을 전부 삭제한다. 여기서,나중에 혹시 필요할 수도 있으므로 ,
File >Save as 를 써서, 적당한 이름(가령, "satoshi.bin" )을 붙처 저장해 두는 것이 좋을지 모른다.
이제 전체 Hex data는 01 00 00 00 . . . .으로 시작하여, . . . . 45 4F 46 0A로 끝나고 있을 것이다.
선두인 01 00 00 00 00 00 00 00 은 1 Satoshi의 Little Endian식 표현이고, 그 뒤의 0xC9은 Script Byte Count이며,
0x51은 명령어인 OP_1이고 0x41은 Constant(뒤 따르는 65Byte를 Push하라는 Constant)이다. 그러한 0x41이 도합 3차례 있고 나서는, 0x53(OP_3) 와 0xAE(OP_CHECKMULTISIG)로 끝나면서,동시에 다음 Satoshi value인 01 00 00 00 . . . 으로 연결되고 있는 것이다. 이러한 순환이 이후에도 계속 되고 있는 것이다.
그러므로,먼저, 선두의 01 00 00 00 00 00 00 00 C9 51 을 마우스로 선택한후 Delete한다.
다음. 커서를 Hex data의 제일 선두 위치에 둔 다음, 메뉴에서
Search > Replace 를 선택한다. 그러면, 화면 아래쪽에 Find와 Replace 입력난이 뜰 것이다.
Find할 Hex Byte Pattern의 입력난에는
53AE0100000000000000C951 (Byte사이에 공백을 두지 않아도 무방함! )
을 입력하고,Replace난은 빈칸으로 그냥 둔다(이곳을 빈칸으로 둠으로써,결국은, Find에서 입력한 Pattern은 삭제되는 것이다).
그리고 나서,우측의 "Replace All"을 클릭하면,
Hex data전체에서 53 AE 01 00 00 00 00 00 00 00 C9 51 과 같은 pattern은 모두 삭제 된다.
그러나 삭제할 곳이 아직 한군데가 더 남아 있다. Hex data의 맨 끝 부근으로 가보면,
53 AE 01 00 00 00 00 00 00 00 45 51
이 아직 남아 있을 것이다. 이것을 Mouse로 선택하여 Delete한다.
(맨끝의 Script Byte Count는 0x45였기 때문에 약간 Pattern이 달랐던 것이다.)
지금까지 제대로 했다면, 이제 Constant인 0x41들만 제거하면 된다.
이를 위해서,메뉴에서
View > Line Width > Custom Width 를 선택한후, Number of Bytes per row 로써
66을 입력하고 OK를 클릭한다.
다음 처럼 1행당 66Byte가 되면서, 제일 첫 열은 전부 0x41이 될 것이다. 이 1열을 전부 삭제하면 된다.
원래 필자가 이 "010 Editor"를 택한 이유는 "Column mode"가 되기 때문이었다.
Tool Bar중에 "Column Mode"가 있다(마우스를 그 위로 가져가면 "Column Mode"라는 설명이 뜬다).
그 icon을 클릭하여 Column Mode로 들어간다.
(만약, Tool Bar를 잘 못 찾겠으면, 키보드에서 Alt 키와 3을 동시에 눌러도 된다)
이제 Mouse로 Column들을 선택하는 것이 가능해 진다. 제1 열을 전부 선택한 다음 Delete한다.
메뉴에서,
File > Save as 를 선택한후 , 가령 "satoshi.pdf"라는 이름으로 저장한다.
저장이 된후에 그 file을 한번 열어보라. 모든게 잘 되었으면 다음 같은 pdf file을 볼수 있을 것이다.
시작할 때는 한 4번 정도 올리면 될 것으로 생각하였는데, 생각보다 길어졌다.
이 Post를 쓰고 준비하면서 필자도 배운 것이 많이 있었다.
독자들도 그랬기를 바란다. 여기까지 읽어준 독자들에게 감사한다. 끝으로, Bitcoin에 대한 여러가지 구체적인 의문점이 있다면 다음 Site를 시작점으로해서 조사해 나가면 될 것이다.
Bitcoin-Wiki
.끝.
