비트코인 / blockchain / bitcoin / 블록체인 /
conan's lazy blogging : 비트코인의 원리
1. Introduction
거래 발생시간순서의 증거(이 증거는 계산을 요구한다.)를 만들어내기 위해 p2p 분산 timestamp server 를 이용하는데, 이를 이용해서 우리는 이중으로 사용하는 문제에 대한 해결책을 제시한다.정직한 node 들이 다른 협력적인 공격 node 들의 그룹보다 좀 더 많은 CPU 파워를 집합적으로 통제하는 한, 이 시스템은 안전하다.
we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions.
The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes.
2. Transactions
전자코인을 "디지털서명의 연결(chain)"로 정의한다.(역자: 여기서 이야기하는 transaction 이 block 안에 들어가는 transaction 들중 한개를 이야기하는 것이다.)
owner 는 자신의 코인을 다음 주인(next owner) 에게 전달하기 위해
"이전 거래(previous transaction)의 값 + 다음 주인(next owner)의 public key" 의 hash 를 얻고
이것을 디지털방법으로 서명(sign)한다.
그리고 이 것을 코인의 끝에 더한다.
- digital signing(hash(previous trans. + next owner's public key))
문제는 지불받는 사람(payee) 이 주인중 하나가 중복해서 이 코인을 사용하지 않았다는 것을 증명할 수 없다는 것이다.(double-spend)
이것에 대한 일반적인 해결책이 중복사용(double-spend) 를 방지하기 위해 모든 거래를 검사하는 "신뢰할 수 있는 중앙기관"(trusted central authority) 이나 "조폐국"(mint) 를 도입하는 것이다.
각 거래후에 코인은 새로운 코인을 발행하기 위해서 조폐국(mint)에게 돌아가야만 한다. 그리고 조폐국이 직접발행한 코인만이 중복사용(double spent)이 안되었다고 신뢰할 수 있다.
이 해결책의 문제는 전체의 화폐시스템이 화폐를 주조하는 회사에 의존한다는 것이다. 모든 거래가 그 회사를 통해야만 한다. 마치 은행처럼 말이다.
지불받는 사람(payee)이 이전의 주인들(previous owners) 이 다른 이전의 거래들에 사인하지 않았다는 것을 알기위한 방법이 필요하다.(중복 사용하지 않았다는 것을 알 방법이 필요하다.)
이것을 위해서, 가장 빠른 거래(the earliest transaction)가 세는 주체다.(one that counts) 그래서 우리는 이후의 중복사용(double spend)의 시도들을 신경쓰지 않는다.(코인의 맨처음 거래가 거래들을 세기 시작한다. 가장 빠른 시점의 거래부터 세기 시작하니, 뒤에 중복사용은 들킨다?)
거래가 빠졌다는 것(absence of a transaction)을 확신하는 유일한 방법은 모든 거래를 아는 것이다.
조폐국 모델에서는, 조폐국이 모든 거래를 알고 있고, 어느쪽에 먼저 도착할지를 결정했다.
신뢰성있는 집단(trusted party)없이 이것을 달성하기 위해서, 거래들은 공개적으로 알려져야 한다.(publicly announced)
(역자: the earliest transaction 이 순서를 count 하고, 이 count 를 공개적으로 알려서 신뢰를 얻는다?)
그리고 우리는 참가자들이 그들이 수신받은 기록에 대한 "하나의 순서 기록"(single history of order in which they were received) 에 동의하기 위한 시스템이 필요하다.(참가자들이 받은 수신기록들이 어떤 순서로 이루어진 것인지 알 수 있어야 한다.)
3. Timestamp Server
우리가 제안하는 해결책은 timestamp server (날짜 도장 서버)로 시작한다.
timestamp server 는 "날짜도장이 찍힐 item 들에 대한 block" 의 hash 를 취한다.(그림)
그리고 넓게 그 hash 를 배포한다.(publishing the hash) .마치 신문 또는 Usenet post 처럼 말이다.
날짜도장(timestamp) 은 그 시각에 그 data 가 틀림없이 존재하고 있는 상태라는 것을 증명한다. 그 data 가 hash 에 들어가기 위해(in order to get into the hash) 존재했기에, hash 가 만들어질 수 있었던 것이니 말이다.
각 날짜도장(timestamp) 는 그들의 hash 에 이전의 날짜도장(previous timestamp) 을 포함한다. 이런 방법을 이용하면 날짜도장(timestamp) 들로 이뤄진 chain 을 형성하게 된다. 이런 chain 이 형성되기 때문에 새로운 날짜도장(timestamp) 이 들어오면, 이전의 chain 에 추가되는 모습이 된다. 즉 chain 이 계속 늘어나게 된다.
4. Proof-of-Work
분산 timestamp server(날짜도장서버, 날짜도장 서비스를 해주는 무엇) 를 p2p 기반에서 구현하기 위해 Proof-of-Work 를 사용할 필요가 있다. 이 Proof-of-work 는 신문이나 Usenet post들 보단 Adam Back의 Hashcash 와 비슷한 Proof-of-Work 시스템을 사용할 필요가 있다.(여러 곳에서 동시에 timestamp 가 생길테니 이것들을 너무 쉽게 만들어 내지 못하도록, 그래서 어떤 일을 했다는 것에 대한 증명을 하기 위해, 하지만 만들어진 것의 증명은 쉬어야 하기에, Proof-of-Work 가 필요?)
(즉, 작업하는데에 어느정도 시간이 들어가야 한다.? timestamp server의 작업이 쉬운일이 아니라 부하를 줘서 어려운 일로 만들어서 이것을 모든 참가자들이 동의하는 하나의 history 로서 역할하게 하기 위해 진입장벽을 높여야 한다.?)
Proof-of-Work(일의 증명) 는 SHA-256등의 hash 함수로 hash 된 값 중에 n 개의 0 bit 로 시작하는 녀석을 찾는 것(scanning)을 포함한다.
필요한 0 bit 의 수가 늘어날 수록, 필요한 "평균적인 일의양" (the average work required)은 기하급수적(exponential ) 으로 늘어난다. 이것은 한개의 hash 를 수행하는 것으로 증명되어 질 수 있다.(간단히 증명된다. 즉, 찾아낸 값을 input 으로 hash function 을 돌리면 바로 hash 값을 알 수 있고, 이 hash 값이 몇개의 '0' bit 로 시작하는지 확인하면 된다.)
우리의 timestamp 네트워크에서, 우리는 block 의 hash 값이 "필요한 수의 0 bit" 를 갖게 되는 순간까지 block 의 nonce를 증가시키는 것으로 "proof-of-work" 를 구현한다.
(Proof-of-work_system : client 쪽에서 시간이 걸리는 작업을 해서 자신을 증명할 수 있는 무엇인가를 server 로 보내고 서버는 간단히 그것이 증명됐다는 것을 판단할 수 있게 해주는 것?, 이것을 통해서 mining 등은 어렵지만, 그렇게 만들어진 block 을 다른 node 들이 검사할 때는 간단하게 할 수 있다. proof-of-work란? )
"CPU 노력(CPU effort)"이 proof-of-work 를 만족시키기 위해 "CPU 노력"이 쓰여진 상태가 된 이후에는, 그 block 은 다시 그 작업을 하지 않고서는 변경되어질 수 없다.
나중 block들(later blocks) 이 그 block에 연결되면(chained after it) , 그 block 을 변경하는 작업은 그 뒤에 연결된 모든 block 들을 재작업해야만 한다.
proof-of-work 는 또한 다수결에서 대표를 결정하는 문제를 해결해 준다.
만약에 다수가 "1개의 IP 주소"가 "1 표"를 의미한다고 하면, 그것은 많은 IP 주소를 할당 받은 어떤 사람이 그 체제를 전복시킬 수 있다는 이야기가 된다.
Proof-of-work 는 근본적으로 "1개의 CPU" 가 "1표"를 의미한다.
다수는 가장 긴 연결(the longest chain) 에 의해 나타내어진다.(가장 긴 연결이 다수이다.) 이 가장 긴 연결은 그것에 투자된 가장 큰 proof-of-work 노력을 했다는 이야기가 된다.(the greatest proof-of-work effort)
(역자: 즉, 긴 연결일 수록 '0' bit 로 시작하는 hash 값을 더 많이 찾아야 한다. 더구나 이 hash 값을 찾는 것은 갈수록 어려워진다. 그러므로 가장 긴 녀석이 가장 많은 노력을 기울였다고 할 수 있다.)
만약 CPU 의 대다수가 정직한 node들에 의해 조정된다면, 이 정직한 연결(chain) 은 가장 빠르게 커지고(grow), 다른 경쟁하는 연결들을 앞설 것이다.
(역자 : 여기를 보고, 이해한 바는 이렇다. 만약 2곳에서 동시에 block 을 만들어서 퍼뜨렸다고 할 때 더 빠르게 퍼진쪽의 block 이 최종적으로 받아드려질 가능성이 높다. 왜냐하면, 더 많은 노드가 있다는 것은 새로운 block 을 추가할 가능성이 더 높다는 것을 의미한다. 어차피 한시간당 평균 block 수는 어느정도 일정하다. 그렇다면, 많은 node 가 자신이 만든 block 을 가지고 있을 때 자신의 block 을 가지고 그 다음 block 을 만들 가능성이 높아진다. 어느 한 순간에 만들어지는 block 수는 일정하다면, 그 "block 을 만드는 node" 가 될 가능성은 당연히 node 의 수가 많을 수록 확률이 높다. 그렇게 되면 더 많은 노드가 내가 만든 block 을 기초로 연결(chain) 을 확장했다는 뜻이되고, 최종적으로 내가 만든 block 을 기초로 만든 연결(chain) 이 가장긴 연결(the longest chain) 이 될 가능성이 크다는 뜻이 된다. 그뜻은 곧 내 block 이 받아드려질 가능성이 높다는 이야기가 된다.)
과거 block 을 수정하기 위해서, 공격자는 그 block 과 그 block 이후에 연결된 block 들에 대한 proof-of-work 를 다시 해야만 한다. 그리고 나서 정직한 node들의 work 를 따라잡고, 그리고 정직한 node 의 work 보다 많이 일해야 한다.(surpass)
(역자: 즉, 누군가가 현재있는 history 를 조작해서 자신이 사용한 내역을 없애거나, 또는 추가하거나 등의 작업을 할려고 한다면, 과거 block 을 조작하거나, 현재 새로 만들어질 block 에 그 내용을 추가하거나 해야 한다. 일단 과거 block 을 조작하는 일은 조작한 block 이후의 block 에 대한 proof-of-work 를 해야만 하기에 거의 불가능하다.)
우리는 이따 좀 더 느린 공격자들이 따라 잡을 가능성이 block 들이 추가될 수록 기하급수적으로 줄어드는 것을 보여줄 것이다.
증가하는 하드웨어 속도를 감안하고 작업시간에 따른 이익을 다양화 하기 위해서 proof-of-work 의 난이도(difficulty) 는 "움직이는 평균"(moving average)에 의해 결정된다. 이 움직이는 평균은 한시간당 평균 block 수를 목표로 한다.
만약 proof-of-work 가 너무 빠르게 만들어 진다면, 난이도(difficulty) 는 증가한다.
5. Network
네트워크를 운영하기 위한 단계들은 아래와 같다.
- 새로운 거래들(transactions)이 모든 node 들에 알려진다.(broadcast)
- 각 노드는 새로운 거래들을 한개의 block 으로 모은다.
- 각 노드는 그 block 에 대한 "어려운 proof-of-work"(difficult proof-of-work) 를 찾기위해 일한다.
- 노드가 proof-of-work 를 찾으면, 그 노드가 그 block 을 모든 node 에게 알린다.
- 그 block 안에 있는 모든 거래들이 유효하고(valid) 이미 사용(spent)되지 않은 것일 때만 노드들이 그 block 을 받아 드린다.(역자: 각node 가 자신이 가지고 있는 block 과 같은 block 에 대한 proof-of-work 인 것을 확인한다?)
- 노드들은 그 block 을 받아 드리게 되면 그들이 그 block 을 받아드렸다고 표현한다.(express) 그 표현은 연결(chain) 에서 자신들이 받아드린 그 block 의 hash 를 previous hash 로 사용해서 다음 block 을 만드는 것을 작업하는 것으로 한다.
노드들은 언제나 가장 긴 연결(the longest chain)을 올바른 것(correct one) 이라고 인식한다. 그리고 노드들은 계속해서 그 연결(chain) 을 확장한다.
만약에 2개의 노드가 동시에 다른 버전의 "다음 block"을 퍼뜨리면(broadcast) , 어떤 노드들은 둘 중 하나를 먼저 받게 될 것이다.
이 경우에, 그들은 그들이 먼저 받은 녀석을 가지고 작업을 할 것이다. 하지만 다른 branch 가 더 길어지는 경우를 대비해서 저장해 놓는다.
이런 tie(무승부) 는 다음 proof-of-work 를 찾게되고 한개의 branch 가 길어지면 깨진다.
새로운 거래(transaction) 를 퍼뜨리는 것은 꼭 모든 노드들에게 닿을 필요는 없다.(새로운 거래가 모든 노드들에게 퍼뜨려지지 않아도 된다.)
그들이 많은 노드들에 닿는한, 그들은 오래지 않아 블럭에 포함될 것이다. 블럭 퍼뜨림(block broadcasts) 들은 또한 dropped message 에 잘 견딜 수 있다.(tolerant of dropped messages)
만약 노드가 block 을 수신하지 못하면, 노드는 다음 block 을 받고 한개를 miss 했다는 것을 인지할 때 그 block 을 요청할 것이다.
(이 글 참고하면 이해하는 데에 도움을 줄 것이다.)
6. Incentives
관습적으로 block에 있는 첫번째 거래(transaction) 은 특별하다.이 첫번째 거래는 block의 창조자가 소유한 "새로운 코인"을 시작한다.
이 첫번째 거래(transaction) 는 노드를 위해 인센티브(incentive) 를 더해준다. 이 인센티브가 있어서 노드들은 네트워크를 지원하게 되고, 코인이 처음에 유통 (circulation) 되는 상황으로 배포시키는 방법을 제공한다.
아시다시피 그것을 발행하는 중앙기관이 없기때문에.
(Bitcoin Fees | Bitcoin Transaction Fees Explained 에는 25 XBT 가 새로운 코인을 만들면 생긴다고 한다. 이것이 210,000 block 이 생길 때 마다 반감된다. 대신에 transaction fee 를 더 많이 챙기게 돼서 이것을 상쇄한다고 이야기 한다. 그런데 거래비용(transaction fee) 를 부과하는 것은 자유라서, 못받을 수 있다.)
일정한 양의 새로운 코인이 꾸준히 추가되는 것은 금을 캐는 광부가 금을 유통(circulation) 시키기 위해 자원을 쓰는 것과 같다. 우리의 경우에, 쓰여지는 것은 "CPU 시간"과 "전기"이다.
인센티브는 거래 비용(transaction fee)을 이용해서 자금이 제공되어 진다.
만약에 거래의 결과 값(output)이 입력값(input)보다 작으면, 그 차이가 "그 거래을 포함하는 block" 에 대한 인센티브에 더해진 거래비용(transaction fee) 이 된다.
(하지만 TX fees aren't mandatory 라는 글에 따르면, 거래비용을 주는 것이 의무적인 사항은 아니기 때문에 거래에 거래비용을 추가하지 않을 수 있지만, 이 경우에 새로운 block 을 만드는 miner 가 거래비용이 없는 거래를 block 에 추가하는 데에 오래 걸리게 될 것이고, 영영 추가하지 않을 수도 있다. 이것은 즉 그 거래가 승인되지 않음을 뜻한다. Bitcoin Fees | Bitcoin Transaction Fees Explained)
미리 정해진 수의 코인이 유통에 들어간 상태가 되자마자, 그 코인에 붙어있는 그 인센티브는 거래비용(transaction fee) 으로 완전히 변경 될 수 있다.(transition entirely) 그리고 이때 전혀 인플레이션이 없다.
(역자: 새롭게 통화가 늘어났으니, inflation 이 발생할 수 있다. 하지만, 가치도 함께 더해져서 그 시장에는 가치가 많아졌고, 그 가치에 대한 통화가 발행됐으니 인플레이션이 없다?)
인센티브는 아마 노드들이 정직하게 머무는 것을 장려할 것이다. 만약 탐욕적인 공격자가 모든 정직한 노드들보다 좀 더 큰 CPU power 를 만들 수 있다면, 그는 2가지 선택중 하나를 선택해야 한다. 하나는 그의 지불을 다시 빼내오는 방법으로 사람들을 속여서 빼앗는데(defraud) 사용할 것이고, 다른 하나는 새로운 코인을 만드는 데에 사용하는 것이다.
그는 그 시스템과 그가 가진 부의 타당성을 약화시키는 것 보다는 규칙들을 따라서 play 하는 것이 좀 더 이익이라는 것을 알아야 할 것이다.(ought to) 이 규칙들이 그에게 다른 사람들이 가지고 있는 코인을 합한 것보다 더 많은 새로운 코인을 준다.(이 bitcoin 의 규칙이 그렇게 큰 CPU power 가 있다면, 규칙을 따라서 작업했을 때 다른 사람을 속이는 것보다, 그냥 새로운 코인을 만드는 것이 더 이득이 되게 되어 있다.? 코인을 만들때 거래비용이 있는transaction 을 많이 포함해서 만들 수록 더 큰 금액을 얻을 수 있다면, 그 방법이 더 빠르다.?)
7. Reclaiming Disk Space
코인에 있는 최근의 거래(transaction)가 충분한 block 들 아래로 묻히자마자, 그 이전에 사용된 거래(spent transaction) 은 disk 공간을 절약하기 위해 버려질 수 있다.
block 의 hash 를 파괴하지 않고 이것을 이용하기 위해서, 거래들(transactions)은, 오직 그 블럭의 hash 를 만들때 사용된 root hash와 함께, Merkle Tree 형태로 hashed 되어야 한다.
그리고나서 오래된 blocks 들은 그 tree 의 branch 들을 뽑아 없애는 것을 통해서(stub off) 작게 되어질 수 있다.(compacted)
(이것은 Merkle Tree 의 모습이다. Merkle Tree 는 대체로 binary tree 로 되어 있는데, 자체가 각각의 node leaf 를 hash 하고, 이 hash 된 값들을 모아서 다시 hash 하는 형식으로 단계적으로 hash 를 계속해 나간다. 이렇게 되면, 하나의 tree 안의 작은 tree 들도 각각 독립된 Merkle Tree 의 모습이 된다. 즉, root hash 가 맞다면 이 tree 전체가 맞는 값이 된다. 이런 형식이라서 그 이전의 값이 필요없다. 자세한것은 wikipedia 를 참고하자.)
내부의 hash 들은 저장할 필요가 없다.
거래(transaction) 들이 없는 block 헤더는 약 80 bytes 정도이다. 만약에 블럭들이 매 10분마다 만들어진다고 가정하면, 1년에 약 4.2 MB 정도가 된다.(80bytes * 6 * 24 * 365 = 4.2MB )
2008년에 일반적으로 팔리는 컴퓨터 시스템들은 일반적으로 2.4 GB 의 RAM 을 가지고 있고, Moore's Law(무어의 법칙, 2년에 약 2배로 증가) 으로 계산해 보면 1년에 1.2GB 정도의 성장을 예상할 수 있다.
그러므로 심지어 block header 들이 memory 에 저장된다고 해도 저장공간(storage) 문제가 되지 않을 것이다.
8. Simplified Payment Verification
지불(payment)들을 증명하는 것은 모든 네트워크 노드에서 증명하지 않아도 가능하다.유저는 "가장 긴 proof-of-work 연결(chain) 의 block" 의 header 의 복사본을 유지하는 것이 필요하다. "가장 긴 proof-of-work 연결(chain) 의 block" 의 header 는 그가 가장 긴 연결(longest chain) 을 가지고 있다고 확신할 때까지 네트워크 노드들에게 질문을 해서 얻을 수 있다.
그리고 그 거래(transaction) 를 날짜도장이 찍힌 그 block (the block it has timestamped in) 에 연결하는 Merkle branch 를 얻는 것이 필요하다.
그는 거래를 그 스스로 점검할 수 없다. 그러나 그 거래(transaction)를 연결(chain)에 있는 어떤 지점으로 연결하는 것으로 그는 네트워크 노드가 그것을 받아드렸다는 것을 확인 할 수 있다.
그리고 그 이후로 더욱 추가된 block 들이 그 네트워크가 그것을 받아드렸다는 것을 확인해준다.
그렇기 때문에, 정직한 노드들이 네트워크를 컨트롤하는 한은 그 증명(verificaiton) 은 신뢰할 수 있다. 하지만 만약 그 네트워크가 공격자에게 압도당하면 그 증명은 더욱 취약하다.
네트워크 노드들이 스스로 거래들을 증명할 수 있는 반면에, 이 간단화된 방법은, 공격자가 네트워크를 계속해서 압도하고 있는 동안에는 공격자의 가상 거래들(fabricated transactions)에 의해 속을 수 있다.
이것을 막는 한가지 전략은 노드들이 유효하지 않은 block 을 발견했을 때 그들로 부터 경고(alert)를 받고, 사용자의 소프트웨어가 full block과 경고가 발생한 거래(alerted transaction)들을 다운로드 하는 것을 촉진하는 것이다. full block 과 alerted transactions 을 받아서 불일치(inconsistency) 하는 것을 확인할 수 있다.
빈번히 돈을 받는 비지니스들은 아마도 여전히 좀 더 독립적인 보안과 빠른 증명을 위해서 그들의 노드들을 운영하기를 원할 것이다.
9. Combining and Splitting Value
코인들을 각각 다루는 것이 가능하지만, transfer 에서 모든 cent 에 대해 각각의 거래(separate transaction) 로 다루는 것은 힘들다.
가치(value) 가 분리되고, 다시 합쳐지는 것을 가능하게 하기 위해, 거래들(transactions) 은 여러가지 input 들과 output 들을 포함한다.
일반적으로 더 큰 이전의 거래(transaction) 으로 부터 온 한개의 input 이나 또는 더 작은 양들을 묶은 여러개의 input 들 이 있을 것이다.
그리고 많아야 2개의 output 이 있다.
하나는 지불, 또 하나는 보낸자(sender)에게 돌아가는 거스름돈(change) 이다.
그리고 더 많은 것으로 이루어진 거래들(transactions) 에게 팬아웃(fan-out: 전자회로에서 output 에 연결 가능한 input 의 수)은 문제가 아니다.
(output 에 연결가능한 input 의 수의 제한 등은 없으니, 그냥 마음껏 연결해도 된다.라는 것 같다.)
거래 history 의 완전한 독립적인 복사본(complete standalone copy of a transaction's history) 을 추출할 필요는 전혀 없다.
10. Privacy
전통적인 은행 모델은 정보에 대한 접근을 "관여된 집단"과 "믿을 수 있는 제3의 집단"으로 제한해서 프라이버시의 레벨을 달성한다.
공개적으로 모든 거래를 알리는 것의 필요성은 이 방법을 사용하는 것을 불가능하게 한다.(preclude)
그러나 다른 장소에서 정보의 흐름을 차단하는 것(public key 들을 익명으로 보관하는 것에 의해 )으로 프라이버시는 여전히 유지될 수 있다.
대중은 누군가가 다른 누군가에게 보내는 것을 볼 수 있지만, 누구에게도 그 거래(transaction) 에 연결(linking)되는 정보가 없다.
이것은 증권거래소에서 제공되는 정보의 레벨과 비슷하다. 증권거래소에서는 그 집단이 누구인지 안알려주고, 개개의 거래들의 시간과 규모를 나타내는 테이프(tape) 가 공개된다.
추가적인 방화벽으로서, 거래가 공통의 owner 에 연결(link)되는 것을 막기위해, 각각의 거래(transaction) 에 new key pair 가 사용되어져야 한다.
몇몇 multi-input 거래들(transactions) 에서 연결(linking)은 여전히 어쩔 수 없다.
multi-input 거래들은 그들의 input 들이 같은 주인에 의해 소유됐었다는 것이 필연적으로 노출된다.
이것의 위험은 만약 키의 주인(owner)이 노출되면, 연결(linking) 은 같은 주인에게 속한 다른 거래들(transactions) 을 노출 시킬 수 있다.
11. Calculations
심지어 이것이 달성된다고 하더라도, 그것은 시스템에서 난데없이(out of thin air) 새롭게 가치(value) 를 만들거나 공격자의 소유가 아닌 돈을 가져가는 등의 임의적인 변경이 가능하지는 않다.(역자: 2.Transaction 을 보면, 돈의 소유가 변경되려면 이전의 소유자(previous owner)가 sign 을 해줘야 한다. 이것이 불가능하기에 공격자가 가져갈 수 없는 듯 하다.)
노드들은 가치없는 거래(transactions) 을 payment 로 받아들이지 않는다.
그리고 정직한 노드들은 그것을 포함한 블럭을 받아드리지 않을 것이다.(never accept)
공격자는 단지 그가 가진 거래중에서 그가 최근에 사용한 돈을 다시 가져오기 위해서만 거래를 변경하려고 시도할 것이다.
<참고>
- block 이 몇개의 transaction 을 가져야 되는지는 없다. 하지만 많은 transaction 을 가지고 있다면 더 많은 인센티브를 얻게 되고, 더 큰 돈(거래비용)을 얻을 수 있다.
- [Why does this block have so few transactions - Coinbase Developers / Toshi - Coinbase Community]
- 비트코인 블럭 샘플
See Also
- 비트코인을 예제로 쉽게 설명한 글 : http://bitcoin.stackexchange.com/a/8033
- 쿠...sal: [컴] 비트코인의 hash 알고리즘
비트코인 원본 논문: http://bitcoin.org/bitcoin.pdf
댓글 없음:
댓글 쓰기