develop custom_top_html:no
default debug random = 0 / type = READ / detected = READ

@loum 님이 몇번의 포스팅에 걸쳐서 기존의 PoW 알고리듬의 문제점을 해결하는 방법으로서 Proof of Randomness 를 제안하셨습니다.


http://www.ddengle.com/bitcoindeveloper/890555

http://www.ddengle.com/bitcoindeveloper/889821

http://www.ddengle.com/bitcoindeveloper/873253


PoW 에 대한 근본적인 고민의 흔적이 많이 보입니다. 설사 제안하신 모델에 문제가 있다 하더라도, 이러한 시도를 통해서 PoW 알고리듬에 대한 이해를 더 심화시키고, 더 나은 모델을 만들기 위한 노력에 많은 보탬이 될것이라 생각합니다.


로우님의 생각을 좀 무리하게 단순화시킨다면 이렇습니다.

블럭체인을 생성하는 노드를 선정하는 기준을 해시경쟁(PoW) 이나 코인에이지 경쟁(PoS) 을 하지 말고 완전히 랜덤하게 만든다면, 이러한 경쟁으로 부터 나오는 여러가지 단점들을 해결할 수 있지 않겠느냐 하는 것입니다.

빗코의 해시경쟁으로 부터 나오는 문제는 이미 많은 글들에서 제기 되었듯이, 51% 어택의 위험이 존재하고,  풀들을 중심으로 한 해시의 독점화와 이로 인한 추가적인 보안취약성 노출(51% 어택위험증가, 디도스 어택위험 증가),  광범위한 코인디스트리뷰션 방해, 재사용이 불가능한 초단기간에 퇴출되는 전문 채굴기의 낭비, 막대한 에너지 자원 낭비.. 등등 여러방면에 존재합니다.


로우님은 이런 문제들이 결국 해시경쟁이라는 메카니즘에서 비롯되는 것이라 보고, 이 경쟁을 없애는 방법을 찾으려고 하는 것입니다.

블럭생성권을 랜덤하게 모든 참여 노드에게 준다면,  많은 사람들이 블럭생성에 참여할 수 있고, 블럭보상도 이렇게 더 많은 수의 사람들에게 골고루 배포하게 되니까 코인의 대중화에도 기여하게 될 수 있고, 무엇보다 어느 특정세력이 블럭 생성권을 장악하기 더 어려워지기 때문에 보안상에도 도움이 될꺼고, 특수 채굴장비나 에너지 소모도 거의 필요가 없는 그런 방식이 될 수 있지 않나 기대를 하는 것으로 보입니다.


일견 이런 그림은 사토시의 이상적인 마이닝 생태계 그림에 더 잘맞아 보이는 것 같기도 합니다. 

사토시는 GPU 마저도 신사협정을 통해 사용을 자제해 주기를 바랬습니다. 보다 더 많은 사람이 자기의 피시로 손쉽게 마이닝에 참여하는 것이 네트웤의 보안향상과 빗코가 추구하는 분산시스템에 더 적합한 모델이었기 때문입니다. 하지만 블럭체인의 합의구조를 위해 도입했던 PoW는 이런 바램이 매우 나이브하다는 것을 증명해주었습니다. 해시간의 경쟁은 보다 더 해시생산 효율성을 높은 장비를 확보하기 위한 경쟁으로, 그리고 이 경쟁과정은 끊임없이 "뒤떨어지는"  열등한 플레이어들을 도태시키는 과정으로 이어지게 만든것이죠. 결국에는 소수의 ASIC 제조업체와 대규모 자본, 불과 몇개의 집중화된 풀만이 이 PoW 를 유지시키는 주체로 남게 되었습니다.  어떻게 보면 자본주의 시스템에서  다수에 의한 시장경쟁이 결국에는 독점구조를 잉태시킬 수 밖에 없는 메카니즘과도 유사합니다.


따라서 로움님의 시도가  구현 가능하고, 또 그것이 효과적이라면 블럭체인기술에 있어서 매우 큰 전환점이 될 수도 있을 것입니다.

하지만 안타깝게도 로움님의 랜덤한 블럭생성권 부여방식은 구현하기가 극히 어려울 뿐만 아니라, 설사 구현이 된다하더라도 노드간의 합의과정이 매우 비효율적인 방식으로 이루어지게 될 것이라는 것입니다.


로움님의 제안에는 몇가지 다른 알고리듬과 전제들이 혼재되어 있어서 단일한 내용으로 평가하기 좀 어려운 부분들이 있는데, 일단은,

http://www.ddengle.com/bitcoindeveloper/889821

글에 대한 내용부터 살펴봅시다.


각 노드는 일종의 기준해쉬값’ 맞추기 게임을 하게 되며각 노드 당 단 하나의 완전히 랜덤한 노드 해쉬값을 생성 및 전파하고이 값이 기준해쉬값과 가장 가까운 노드 해쉬값을 제출한 노드가 블록을 생성함.


위의 과정은 어느 노드가 이번 블럭을 만들지를 결정하는 일종의 사전판단 과정입니다. 기준해시값을 어떻게 결정할지에 대해서도 여러가지 이야기들이 나와 있지만, 예를 들어 바로 이전 블럭해시값을  특정해시 함수에 넣어서 나온 해시값이라고 가정해 봅시다.

현재 포크가 나 있지 않으면, 모든 노드들은 똑같은 기준을 가지고 있는 것이고, 각 노드가 보내온 "노드해시값"과 비교해서 제일 가까운 노드값을 보내온 노드가 생성권을 가지게 된다는 것입니다.


(1) "가장 가까운 해쉬값" 결정론


일단 이 논리의 가장 결정적인 취약점 중의 하나는 노드를 선정함에 있어서  정답/오답 이라는 바이너리한 결정이 아니라 누가 더 가까운가 하는 아날로그적 결정논리를 가지고 있다는 점입니다.  각 노드가 보내오는 노드해시값과 기준해시값만 비교해서는 누가 선택되어야 할지를 결정할 수가 없고,  모든 노드의 전체 노드해시값을 전부비교해서만, 즉 전수 조사를 해야지만 누가 결정될지를 확인할 수 있다는 것입니다.


이런 결정논리를 PoW의  블럭선정 방식과 비교해봅시다.  PoW에서는 각 노드가 특정한 블럭해시패턴이 나오게 만드는 난스값을 찾아서 이것을 가지고 블럭을 만들고 네트웤에 전파합니다. 다른 노들은 이렇게 전파된 블럭헤드에서, 이전블럭해쉬값, 타임스탬프, 트랜잭션머클트리, 난스 값을 가지고 이 블럭이 정답인지 아닌지 바로 간단히 확인할 수 있습니다. 

즉 다른 노드들이 어떤 값을 전파하고 있는지 기다릴 필요가 없습니다. 이 경우에는 정답값이 다른 노드들의 블럭안과 독립적으로 존재할 수 있습니다.  받은 블럭해시값이 정답이면 더 이상 기다리지 않고, 이것을 베이스로 해서 다시 새로운 블럭의 작업을 시작하게 됩니다. 나중에 다른 노드에서 또 다른 정답값을 보내오면 그 때가서 누가 우선권이 있는지만 가리면 됩니다.


반면, 로움님의 결정방식은 모든 노드들의 노드해시값을 전부 비교해야 함으로, 모든 노드가 모든 노드에 대해 매 블럭마다 노드해시값을 전파해야 하고, 이것이 완료될까지 대기해야 과정이 됩니다.  이 과정에서 비롯되는 여러가지 전파속도, 과중한 네트웤 로드 등과 함께 또다른 문제들이 발생합니다.


(2) 노드간 타임싱크 문제


위의 "가장 가까운 해시값" 결정론은 우선 모든 노드가 똑같은 시간에 투표를 종료해야 한다는 전제가 따릅니다. 노드 마다 각각 다른 시간에 투표를 종료한다면 누가 "가장 가까운"지 다를 수 있기 때문입니다. 하지만 무차별적 노드간에 시간을 완벽하게 싱크한다는 것은 불가능에 가깝습니다. 이전블럭의 타임스탬프와 비교한 상대적 선후를 가리는 로직은 가능할지 모르나, 절대적으로 같은시간에 투표를 종료하는 것을 보장하는 방법은 없을 것으로 봅니다. 따라서 물리적 블럭생성시간 기준에 대한 노드들간의 불일치에 의해서  노드마다 다른 승자값이 나올 가능성이 존재합니다. 이를 통제하기 위해서 각 노드가 선정한 우승자에 대한 투표를 또 한번해서 최종 우승자를 가릴 수 있을지도 모르겠습니다. 하지만 이 또한 최종 우승자를 가리기 위한 투표마감시간을 다시 싱크해야 하는 순환논리에 빠질 것 같습니다. 

그리고 이런 "검증"과정은 결국 계속 전수조사를 해야한다는 조건 때문에 시간면에서나, 전송되는 데이타량면에서는 효율성을 계속 저해하는 요인으로 작용하게 됩니다. 


(3) 포크된 블럭체인의 선택문제


노드간의 타임싱크, 전파속도 등의 문제 등으로 인해 포크가 발생할 수도 있고, 의도적인 포크 공격이 있을 수 있습니다. 이 때 각 노드는 다른 두 체인중에 어느 체인을 선택해야 할까요? 단순하게 가장 블럭 하이트가 가장 높은 체인을 선택하면 된다고 할 수 있습니다. 하지만 이것은 보안상 문제를 일으킬 수 있습니다.  PoW 의 경우에는 단순하게 블럭 하이트가 높다는 기준에 의해서가 아니라, 그 블럭생성까지 소요된 전체 해시량에 의해 더 "긴" 체인이라는 것이 확인이 됩니다. 즉 누군가가 현재의 블럭체인대신에 과거 6개의 블럭을 전부 다시 만들어서 지금 블럭체인보다 한 블럭 더 높은 체인을 만들려고 한다고 합시다. 이렇게 하려면, 이 사람은 현재블럭체인에 투입된 해쉬량보다  더 많은 해쉬량을 투입해야만 다른 노드가 인정을 해 줍니다. 단순히 블럭하이트가 높다는 것만으로는 자기 자기체인이 더 우선권이 있다는 것을 증명할 수 없습니다. 그렇기 때문에 자기 해쉬생산량이  나머지 네트웤 해쉬생산량보다 크지 않으면 이렇게 블럭체인 바꿔치기 공격이 불가능합니다. 그렇지 않고서는 과거 블럭작업하다 보면 새로 생성되는 블럭의 해쉬량을 영원히 따라잡을 수 없기 때문입니다. 이런 점에서  PoW 는 과거블럭 변조불가능성에 대한 안전판을 제공해줍니다. PoS 의 경우에도 해쉬량은 아니지만, 전체 파괴된 코인에이지를 들여야 블럭바꿔치기를 할 수 있습니다.  하지만 PoW 에 비해 조금 취약해 보이기는 합니다. 그래서 피어코인이 이를 보완하기 위한 방법으로 체크포인트를 도입했습니다.  일종의 중앙집중식 솔루션이라는 비판을 감수하면서 말입니다.

그런데 위의 랜덤한 방식으로 선정된 블럭을 누군가가 바꿔치고 하고 재조립해서 더 긴 체인을 만든다고 할 때 과연 어떤 기준을 가지고 이 체인이 원래 체인보다 "열등"하다 또는 "틀렸다"라고 판단할 수 있을까요?

과거 6블럭부터 기준해시값에 "더" 근접하는 노드해시값을 다시 찾아서 블럭을 재조립하고 블럭하이트까지 더 높게 만든다면, 다른 노드들은 이 체인이 '더' 정답에 가깝고, 체인길이도 더 길고, 따라서 이 체인을 메인체인이라고 인정할 것입니다.


(4) 각 노드당 단 하나의 해쉬값


노드입장에서 보면 어떤 기준값이 있을 때, 이에 근접한 값이 생성권을 가진다고 하면, 계속 해쉬값을 계산해봐서 가능한한 정답에 가까운 값을 찾아서 전파하려고 할 겁니다. 이렇게 되면 결국 이 계산능력간의 경쟁이 되고, 해쉬경쟁이 되니까, 로움님은 노드당 블럭생성시간당 딱 한번만 해쉬값을 보낼 수 있게 하자 이렇게 제안도 합니다.


 “UUID”는 것은 노드가 절대 변경할 수 없는 것으로서 UUID 또는 CPU번호 또는 네트워크카드번호 등을 말하는 것임조건은 노드에서 단 하나의 생성이 되는 것이고다른 노드에서 이를 확인할 수 있으면 됨더 구체적으로 하나의 노드 해쉬값을 전파하기 전에 단 한번만 생성할 수 있으면 됨.


각 노드에서 변경할 수 없는 UUID 가 있고 이 노드가 전파한 노드해시값 역시 단 한번만 생성된다는 것을 보장해야 된다고 합니다.  굳이 네트웤상의 아이덴터티를 기준으로 해서 제한을 가하고자 한다면 ip 주소를 이용하는 것이겠지만,  ip 역시 보조적인 제한을 가하는 수단이 될 수 있을지는 모르겠지만, 노드의 아이덴던티를 100% 보장하는 기준은 될 수 없다고 봅니다. 또한 블럭생성권을 가진 노드의 ip 가 전파되는 것은 디도스 공격에 매우 취약하게 됩니다. DPOS 의 경우에는 ip 가 공개되는 것이 아니라 지갑주소가 공개되는 것이라 디도스의 직접적인 공격의 대상이 되지는 않습니다. 


(5) 이러한 문제들로 인해서 위의 글들에서 언급한 랜덤한 노드선택 방식이 그리 안전하지도, 효율성이 높지도, 또 구현하기 쉽지도 않다는 것인데, 이에 대해서 로움님이 최근에 저에게 좀 더 "개선" 된 형태의 아이디어를 보내었습니다.


기준해쉬값 - 이전 블럭해쉬값을 특정해쉬함수에 넣어서 출력한 값

노드해쉬값 - 각 노드의 주소를 또다른 특정해쉬함수에 넣어서 나온 해쉬값


이 두값을 비교해서 가장 가까운 쪽이 블럭생성권을 가진다는 것입니다.

위의 내용들과 차이점은,


-- 노드의 ip 나 uuid 를 쓰지 않고 주소만 사용

-- 매 블럭생성 때마다, 노드 해시값을 받는 것이 아니고, 각 노드에서 전체 다른 노들의 해쉬값을 계산할 수 있다는 점. 왜냐하면 다른 노드들의 주소만 정해진 해쉬함수에 넣으면 노드해시값이 나오니까 매번 이 값을 따로 받을 필요가 없음.

-- 각 노드들은 전체 지갑의 각 주소와 밸런스를 관리하는 데이타베이스를 만들 것

-- 필요에 따라 보유코인수가 전체의 0.001% 이상을 가진 주소만을 대상으로 블럭생성권을 주기 등의 제한을 가할 수 있음


이 모델은 이전보다는 진일보한 면이 있습니다. 우선 블럭생성권을 결정하기 위해 매번 모든 노드들의 투표를 기다릴 필요가 없어졌다는 점입니다. 블럭체인을 베이스로 해서 현재주소리스트만 계속 업데이트 시키면 하나의 노드내에서 누가 더 현재 블럭생성 기준해시값에 "가까운지" 찾을 수 있다는 것이죠.

하지만 여전히 문제들이 있습니다.

노드들간의 타임싱크문제는 여전히 남아 있고, 이로 인한 포크가능성, 그리고 포크시 체인 선택문제 등은 여전히 남아 있습니다.

또한 블럭생성권 획득 확률을 높이기 위해서 더 많은 주소를 생성시키는 스팸이 일어날 수도 있을 것 같습니다.


(6) 과연 랜덤성(randomness) 이 노드선정 문제를 해결하기 위한 적절한 방향인가?


로움님은 랜덤성을 노드선정의 가장 중요한 화두로 보고 있는 것 같습니다.


""즉, 비트코인의 POW는 DOS 공격을 방어하기 위한 기존 POW의 기능에 더하여, 다수의 피어(노드) 환경에 의한 랜덤성이 더 포함되어 운용되는 것으로 보입니다.


일단 제 생각에는 이것 중에서 코인의 합의 알고리즘에서 필요한 부분은 2) 랜덤성인 것처럼 보이는데요.. 


이유는 POS의 경우, 이런 비대칭성을 이용하지 않는 것으로 보이며, 단지 coinday에 의한 랜덤성을 이용하는 것으로 보이기 때문입니다. (확실하지는 않습니다.)""


빗코는 PoW 의 비대칭성+랜덤성, POS의 경우에는 비대칭 없이 랜덤성만을 사용한 것으로 봐서 노드선정 로직에 있어 비대칭성은 필수불가결한 본질성이 아니고, 양 쪽에 다 있는 랜덤성만이 본질적인 것이고, 본인은 이를 논리적으로 극대화 또는 "순수화" 하려 한다는 것으로 볼 수 있을 것 같습니다.


여기서 비대칭성이라는 것은 문제를 푸는 것은 어렵고 시간이 많이 걸려도 답을 확인하는 것은 매우 쉽고 단순한 것을 말합니다.

쉬운 예를 들어 봅시다.  Sudoku 라는 게임이 있습니다.

아래 그림에서 1에서9의 숫자가 한번만 가로 세로로 들어가야 되고, 내부에 있는 9개의 작은 사각형안의 9개 칸에도 1-9의 숫자가 한번만 들어가도록 숫자를 배열하는 퍼즐입니다. 한번 풀어보세요.


500px-Sudoku-by-L2G-20050714.svg.png (500×500)


답이 금방나오지 않죠. 숫자를 이렇게 넣어보고 저렇게 넣어 보고 계속 트라이해야 합니다. 어떤 규칙에 의해 답이 담박에 나오는 공식같은 건 없습니다. 규칙적으로 얼마나 빨리 많은 시도를 해보느냐가 이 퍼즐을 얼마나 빨리 풀 수 있는지를 가늠하는 척도입니다.


자 그럼 여기 답이 있습니다.


500px-Sudoku-by-L2G-20050714_solution.svg.png (500×500)


이 답이 정답이 아닌지 한번에 금방 확인할 수 있지요? 각 가로줄 세로줄로 숫자가 1번씩만 들어갔는지 확인하고, 내부의 9개의 네모에 역시 1-9 가 한번만 들어갔는지 확인하면 정답인지 아닌지 검증이 됩니다.


바로 이런식의 푸는 건 엄청 어렵고, 일일히 모든 경우의 수를 대입해야 하는데, 그 답을 확인하는건 매우 쉬운 이런 상태가 로움님이 말하는 비대칭구조이고, 이것을 이용하는 대표적인 예가 PoW 입니다. 숙제 엄청내주고 정답 가져오면 네가 생성한 블럭을 인정해주겠다. 그런데 만일 이를 검증하는 노드도 숙제해온 노드가 들인 노력만큼 똑같은 노력을 들여야 숙제를 끝냈는지 안끝냈는지 확인이 가능하다면 서로 숙제내고 확인하다 세월 다 가겠죠.


빗코의 PoW도 위의 수도쿠와 거의 비슷합니다.

정답은 딱 한개만 있는 것이 아니고 여러개가 있을 수 있는 어떤 특정한 패턴이라고 칩시다.

예들 들어 블럭해시값이 앞에 "0" 이 6개 나와야 된다고 칩시다.

즉 "000000dfdfs9043444" 이나 "000000sle4999dfsd"  이나 둘다 정답패턴입니다.

각 마이너는 몇가지 입력요소를 주어진 해쉬함수에 넣어서 이런 패턴이 나오는지를 계속 테스트해보게 됩니다.

여기서 입력요소란 이전블럭해쉬, 타임스탬프, 이 블럭에 포함된 트랜잭션 해쉬값을 층층히 쌓아올린 해쉬값, 그리고 마지막으로 임의의 값인 난스값입니다.  해시함수에 이런 입력요소들을 넣고 돌려서 나온 해쉬값이 위의 패턴에 만족하는지를 확인하는 작업을 계속하게 됩니다.

대부분 "000dsdkfdso44" 나 "034344dsfsdf" 와 같이 앞에 0이 3개만 오는 경우, 1개만 오는 경우 등 정답 패턴에 맞지 않는 경우가 대부분일 겁니다. 이를 때 마다 난스 값을 1씩 증가시켜서 계속 다시 대입해서 결과값을 확인하는 것입니다. 

그러다가 어느순간 특정한 난스값을 넣었을 때 결과 해쉬값이 0이 6번 나오는 모양이 되었다면, 이게 바로 정답이고,

이 때 발생한 블럭해쉬값, 해쉬함수에 입력한 다른 변수들, 무엇보다 바로 이 난스값을 블럭헤드에 넣고 다른 노드에게 보내는 거죠.

이를 받는 노드는 블럭헤드에 들어있는 입력요소들을 주어진 해쉬함수에 넣어 보면 곧바로 결과 해쉬값이 블럭해쉬값인지 확인할 수 있고, 또 이 블럭해쉬값이 앞에 0 이 6개 달린 것인지도 담박에 확인할 수 있죠.


여기에서 정답을 발견할 수 있는 확률은 마이닝에 투입된 해시량에 달려 있기 때문에,  똑같은 난이도라고 한다면, 해시량이 몰릴수록 블럭생성속도가 계속 빨라질 수 밖에 없습니다. 이를 통제하기 위해서 난이도라는 개념이 도입되고, 블럭생성속도가 너무 빨라지면 난이도가 문제를 더 어렵게 만들어서 다시 주어진 블럭생성속도에 근접하도록 조정합니다.


PoW 설명이 너무 길어졌군요.


로움님은 PoS 의 경우에 이런 비대칭성이 이용되지 않았다고 했지만,  PoS 코인의 아버지격인 피어코인의 경우에도 여전히 난이도가 존재하고 해쉬경쟁이 있습니다. 코인에이지에 의해서 경쟁조건이 바뀐다는 것이지 이 경쟁이 완전히 없어진 것은 아닙니다. 


" Thus the more coin age consumed in the kernel, the easier meeting the hash target protocol."


사용되어서 없어진 코인에이지 양 만큼 타겟 해쉬패턴을 찾기 쉬워 진다는 것이죠. 그래서 블럭생성을 할 수 있는 주 결정요인이 해쉬파워가 아닌 코인에이지의 크기에 주어지지만  이렇게 주어진 해쉬패턴에 매칭되는 값을 찾을 때 여전히 난이도가 존재하고, 이 난이도에 의해 다시 블럭생성주기가 조절이 됩니다.  이전에 다른 분이 PoS 코인은 해쉬파워가 낮기 때문에 gpu 몇개만 모아서 공격해도 쉽게 블럭생성권을 획득해서 어뷰징을 할 수 있다고 주장한 것은 이런 메카니즘에 대한 이해부족이었던 것 같습니다.


제가 보기에는 빗코나 피어코인이 이러한 PoW 와 PoS 의 블럭생성권을 둘러싼 합의 알고리듬에서 랜덤성을 강화하려 했다기 보다는, 반대로 검증불가능한 통제가 어려운 랜덤성을 제한하기 위한 것이라고 보는게 더 맞을 것 같습니다. 사토시나 피어코인의 써니 킹의 화이트페이퍼에서  한번도 랜덤이라는 단어를 쓰지 않는 것이 우연한 것은 아니라고 봅니다.


블럭을 생성할 때 항상 누구나 똑 같은 조건을 가져야 하고 이것이 합의의 근거가 된다고 하면, 이러한 랜덤성을 공격할 수 있는 모든 경우의 수에 대해서 전부 방어를 해야 하는 상황이 생깁니다.

사실 랜덤을 보장하고 증명한다는 것은 생각보다 대단히 어려운 과제입니다. 정확히는 랜덤을 증명하는 것이 아니고 랜덤이 아니라는 것을 증명할 수 없기 때문에 랜덤하다라고 인정되는 것일 뿐입니다.  불특정 다수가 모여 있는 네트웤상에서 특정 노드가 랜덤하다는 것을 보증하기 보다는, 랜덤하지 않게, 즉 특정한 조건에 의해 제한되게 만들고, 이 조건이 이룰려고 하는 목적에 얼마나 잘 맞는지 안맞는지를 검증하는 것이 훨씬 쉽고 효율적이라는 것이죠.  "특정한 해쉬패턴 정답을 찾아오는 노드" 라는 조건이 랜덤성을 제한하는 것이고,  랜덤성은 이 제한된 선택안에서만 존재합니다. 그리고 이렇게 가한 제한이 블럭생성권 합의의 객관성을 보장해주니까 이 조건은 이룰려는 목적에 맞고 그래서 이용된다는 것이죠.


더 나아가서 DPOS 의 경우에는 이러한 제한된 랜덤성마저도 제거를 합니다. 각 코인보유자들에 의해 투표에 의해 결정되는 101개의 노드생성권자가 만들어지고 이들이 노드를 생성하는 순서도 더 이상 랜덤하지 않게 미리 설정됩니다. 이렇게 랜덤성을 제한하고 없애는 조건들이 과연 합의 과정에 효과적으로 기여하는가를 검증해서 그렇다는 것이 확인된다면, 더 이상 노드의 다른 조건들에 대해서 방어하고 고민해야 할 필요가 없어집니다. 왜나하면 랜덤성에 의해 다른 효과가 생길 가능성이 이 조건에 의해 사전에 차단되기 때문이죠.

반면에 순전한 랜덤성에 기초에 합의구조는 이 랜덤성이 깨지면, 전체구조가 무너지기 때문에, 이 랜덤성을 공격할 수 있는 모든 가능한 경로, 경우의 수들을 전부 염두에 두어야 합니다. 


로움님의 로직도 제한된 숫자의 노드안에서만 일어나는 합의구조방향으로 간다면, 좀 더 방어하기가 쉬워집니다. 역시 무한대의 랜덤성에 일정한 제한을 가하는 것입니다.  그런데 이렇게 제한된 노드 숫자안에서 경쟁을 없애는 방향으로 가다 보면 본질적으로 DPOS 와 큰차이가 없게 되는 것 같습니다.  합의해야 되는 노드숫자가 제한되면, 100% 에 가까운 합의도 매우 빠른 시간안에 이루어낼 수가 있습니다. 그래서 DPOS가 지금 딱 10초 마다 블럭을 생성하면서도 추가적인 컨펌조차도 필요치 않게 됩니다. 이미 합의구조안에서 절대다수가 합의했는데,  또다른 외부 어딘가에 있있지도 모를 더 나은 정답을 염두에 둘 필요가 없습니다.


저 역시 기존의 PoW 나 PoS 가 여러가지 문제들을 내포하고 있고, 이를 극복하기 위한 솔루션들을 계속 찾아야 한다는 점에는 누구보다 더 찬성합니다. 노드의 랜덤성이라는 주제로 생각할 포인트를 제공해주신 로움님께 매우 감사하게 생각합니다. 하지만 랜덤성이 합의 알고리듬을 가능케하는 본질적인 개념인가에 대해서는 의문이 드는군요.

 




0

atomrigs님의 서명

 

한국이더리움 사용자 그룹: https://www.facebook.com/groups/ethereumkorea/

블로그:  https://www.facten.co.kr/news/articleList.html?sc_sub_section_code=S2N13&view_type=sm

 

댓글 9
  • ?
    글 잘 읽었습니다.

    긴 글을 정성들여서 적어주셔서 먼저 감사드립니다.

    일단 몇가지 오해가 있기는 합니다.

    1)말씀하신 '(3) 포크된 블럭체인의 선택문제'는 좀 오해가 있는 것 같습니다.
    제 글(http://www.ddengle.com/bitcoindeveloper/889821)에서 보면 '두번째 리스트'를 다시 만들게 되는데.. 이 부분은 사실 없어도 되는 부분입니다.

    이 부분을 제가 추가한 단 하나의 이유는 블럭에 포크가 났을 때 pow와 같이 가장 긴 길이를 가진 블럭을 정하기 위한 목적이외에 다른 목적은 없습니다.

    따라서 제게는 포크 문제에 따른 문제는 크게 없는 것으로 보입니다.


    2) dpos를 말씀하신 것과 같이 랜덤 방식이 아닙니다. 그리고 운영도 현재까지는 잘 되고 있습니다.

    그렇다고 해서, 제 아이디어와 같이 랜덤 방식으로 블럭생성기회를 주는 것에 비해서 dpos의 비랜덤 방식이 보안상 또는 알고리즘적으로 더 좋은 방식이라는 근거가 되는 것은 전혀 아닙니다.
    이 부분은 어떤 오해가 있는 것 같습니다.

    dpos를 비랜덤방식으로 운영되기 위해서 내부적인 알고리즘, 즉 보안을 위한 검증 시스템은 pow의 보안 알고리즘 이외에 더 가지고 있어야 할 것으로 추측해봅니다.

    따라서, 개인적인 입장은 랜덤 방식이 dpos의 이런 보안 알고리즘의 일정 부분을 가지고 있는 것이 아닌가라는 추측은 해봅니다. 하지만 근거는 없습니다.

    일단 닌의 글을 접하면서 드는 느낌은 dpos에 상당한 호감이 있는 것으로 보입니다.

    이는 님이 말씀하신 '(6) 과연 랜덤성(randomness) 이 노드선정 문제를 해결하기 위한 적절한 방향인가?'에 도 나와 있는데요..

    제게는 dpos의 알고리즘적인 장점은 단지 특정 그룹에게만 블럭생성권한을 주어지는 것이 좋은 효과를 얻는 것으로 보입니다. 이것은 pos와 상당히 비슷한 측면이 있습니다. 즉, 저에게는 dpos의 보안상의 이점은 특정 그룹에게만 블럭생성 기회를 준다는 것에 있는 것으로 보입니다.

    하지만 이런 방법은 랜덤 또는 비랜덤 방식 모두에 적용이 가능한 방법으로서 비랜덤 방식이 좋다는 근거가 되는 것은 아닙니다.

    따라서 제가 이번에 올린 글에서 블럭 생성에 참여할 수 있는 숫자를 제한하는 방법을 제시했습니다.


    3) 말씀하신 '(2) 노드간 타임싱크 문제'는 실제 문제가 될 수도 있을 것으로 저도 보았습니다.
    하지만, 모든 노드가 표준 시간을 네트워크를 통해서 주기적으로 받아온다면 시간 싱크 문제는 큰 영향이 없을 것으로 추측해봅니다.

    또한 저의 경우 모든 노드가 참여하는 것이 바람직하기는 하지만 이것이 목적은 아닙니다. 이 때문에 시간 싱크가 안된 노드가 보낸 정보는 무시하면 되는 것입니다. 합의 알고리즘의 '합의'라는 의미는 제게는 '대부분 또는 전부 노드와 같게 판단을 하도록 만든다'는 것으로 보여집니다.


    4) 말씀하신 '(1) "가장 가까운 해쉬값" 결정론'에서 모든 노드가 한번에 알 수 있는 방식으로 결정되는 것이 저도 좋은 방식이라고 생각을 합니다. 하지만 저의 이전 글에서 더 큰 문제는 일단 게임을 하기기 위해서 노드가 특정 정보를 네트워크 전파를 하는 것이 더 큰 문제로 제게는 보입니다.

    그래서 이번에 제가 새로게 만든 알고리즘을 다시 올렸습니다.
    http://www.ddengle.com/bitcoindeveloper/893822

    님께서 전수조사를 말씀하셨는데요..
    저는 POS도 전수조사를 하는 것으로 추측하고 있습니다.
    즉, 노드 자신이 가지고 있는 db에서 coinday(또는coinage)가 가장 긴 것을 전수조사해서 알아내는 것으로 추측하고 있는데.. 혹시 틀린 추측일 수는 있습니다.

    어째든, 누가 블럭을 생성할 것인가를 두고, 판단을 해야 하는데, pos의 경우 이 판단을 pow와 같이 각 노드가 독단으로 하는 것으로 저는 추측을 하고 있습니다. 만일 그렇지 않다면,, 모든 노드가 네트워크에 자신의 코인데이를 전파하여 가장 큰 코인데이를 찾아야하는 문제가 발생을 합니다. 이것은 제 이전 글에서와 같은 문제입니다.


    글에서 db 문제를 얘기하셨는데요..
    db는 새로 만드는 것이 아니라, 이미 노드가 db를 가지고 있습니다. 볼럭에는 거래 내역만 들어있기 때문에 현재 최종적으로 특정 주소에 얼마의 코인을 가지고 있는지는 각 노드가 블럭을 참조하여, 즉 최초블럭 부터 현 블럭까지 모두 서칭을 해서 db를 만들어 놓게 됩니다.

    이런 db 정보가 없으면 각 노드는 실제 가진 코인 보다 많이 보냈는지(더블 스팬딩)를 검증할 수 없습니다.


    5) 말씀하신 '(4) 각 노드당 단 하나의 해쉬값'에서 IP를 말씀하셨는데요..
    제가 올린 글 중에 IP에 대한 것은 포함되어 있지않습니다. ip는 개인적으로 보낸 글에서만 나오는 내용인 것 같습니다.


    간단히 쓰려고 했는데.. 보시는 분이 힘드시겠네요..
  • @loum
    1) 오해가 아니라, 두개의 블럭체인으로 포그가 났을 때 어느 쪽을 선택할 것인가 하는 문제에서, 빗코의 경우에 긴 블럭체인을 선택한다는 기준이 있는데, 이 때 이 긴 블럭체인이 단순히 블럭수가 많다는 것이 아니고, 이 블럭 하이트까지 사용된 총 해시량이 이를 보호해주고 있다는 점을 지적하고 있는 것입니다. 랜덤으로 선택된 블럭들의 체인일 경우 공격자가 이전의 각 블럭 기준해쉬값에 더 가까운 노드해시값을 다시 찾아내는 것은 쉬운 일이고 이를 바탕으로 블럭을 재구성해서 포크를 했을 때, 다른 노드에서 '올바른' 체인을 찾아 낼 기준이 없어진다는 것입니다.

    2) 랜덤성이 pow 나 pos 의 근본적인 공통점이라는 점을 지적하시고, 랜덤성이 빠지고는 블럭선정 기준의 근본적인 공통성인 것처럼 묘사를 하시는 것 같아서, 오히려 다른 솔루션들은 랜덤성을 제한함으로써 목적을 이루고 있다는 점을 강조하고자 했습니다. 그리고 랜덤성을 보장하기 위한 조건은 이를 제한하기 위한 조건보다 일반적으로 구현하기 더 힘들고 리스크가 커질 수 있다는 점을 지적했습니다. 물론 그럼에도 순수한 랜덤성에 기초한 솔루션이 나올 수 있는 가능성을 완전히 부정하지는 않습니다.

    3) 정확한 타임싱크가 이 시스템에서 결정되는 값의 선정에 직접적인 영향을 미치는 조건이기 때문에 문제가 됩니다. 타임싱크를 의도적으로 피하는 어택커도 있을 수도 있고, 자발적인 참여에 의해 100% 싱크를 유지한다는 전제는 쉽게 이룰 수 있는 조건은 아니라고 봅니다. 기존의 블럭체인에서도 타임스탬프가 이용되고 있지만, 모든 마이너나 노드들이 정확한 타임싱크를 할 필요성을 전제하고 있는 것은 아닙니다. 다른 마이너가 제출한 블럭헤더에 포함된 타임스탬프가 표준시간에 정확히 싱크되어 있는지 아닌지가 이 블럭에 대한 검증에 직접적 기준이 되는 것은 아닙니다. 타임스탬프간의 상대적 차이를 확인해서 특정한 레인지를 벗어나는 것은 리젝트할 수 있어도 이 마니너의 타임과 내 컴의 타임이 싱크되어있는지가 기준은 아닙니다.
    전수가 아니라 '대부분' 이 합의하면 된다는 주장도 사실상 전수조사와 거의 같은 개념입니다. 얼마나 모아야 대부분인지를 결정하기도 힘들고, 설사 전체 모집단의 갯수를 알고 있어도, 최소한 절반의 수는 모아서 이것이 전부 일치된 값이라야 '대부분'이라는 논리적 결론을 도출할 수 있기 때문입니다.

    4) PoS 에서는 일반적으로 전수조사를 하지 않습니다. 각 노드가 코인에이지 스테이킹을 하고 타겟 해쉬에 맞는 값을 찾아내면, 다른 노드들이 얼마의 코인에이지를 스테이이킹하는지 상관없이 아직 작업하는 블럭하이트의 블럭이 발견되었다고 다른 노드에서 먼저 노티파이가 오지 않는한 생성된 블럭을 전파시킵니다. 그래서 블럭주기가 짧은 경우 더 많은 수의 올펀블럭들이 생길 수가 있는데 이를 어떻게 처리할것인지에 대한 전략이 PoS 의 안정성에 큰 영향을 미칩니다.
    만일 같은 블럭하이트에 대해 2개의 블럭이 다른 노드에서 생성되어 전파되었고, 이 두개의 노드를 모두 전파받은 노드입장에서는 모든 노드들의 코인에이지를 전수조사하는 것이 아니고, 이 두 블럭이 모두 자체 검증을 통과했다면 사용된 코인에이지 트랜잭션만 확인해서 비교해서 결정하면 됩니다.

    5) db 문제
    빗코나 피어코인의 블럭체인의 경우 "최종적으로 특정 주소에 얼마의 코인을 가지고 있는지는 각 노드가 블럭을 참조하여, 즉 최초블럭 부터 현 블럭까지 모두 서칭을 해서 db를 만들어 놓"지 않습니다. 이런 밸런스 테이블을 별도로 만들지 않더라도 어떤 트랜재션이 더블스팬딩이 되었는지 확인이 필요할 때, 그 트랜잭션의 아웃풋이 스팬딩되었는지 안되었는지만 확인하면 됩니다. 빗코의 블럭체인에서 모든 트랜잭션의 아웃풋은 사용되었다 / 안되었다 하는 두가지의 바이너리한 상태외엔는 없습니다. 밸런스라는 것을 확인할 필요가 없습니다.
    물론 코인의 특수한 로직의 필요에 의해서 이러한 밸런스 db를 별도로 생성관리하는 것은 얼마든지 가능하겠지만요.
    노드선정에 있어서 이 테이블을 이용한다는 것은 하나의 방법일 수 있다는 점은 저도 인정했습니다.

    6) ip 에 대한 내용은 언급하신 적이 없다고 하시는데,

    "노드 해쉬값’은 예로 들면 자신의 “UUID”(노드가 바꿀 수 없고 하나의 노드에 단 하나만 존재하는 것을 사용.) + “nonce 값”을 입력하여 만든 해쉬값임. “IP”주소와 “난스값”가 포함되어 모든 ‘노드 해쉬값’이 다르게 됨."

    라는 문장이 포스팅하신 글에 있습니다. 여기서 본 ip 값이 아마도 노드의 단일성을 개런티하는데 사용된 것이라, 이에 많이 의존하시는 것이 아닐까 생각한 것 같습니다. 물론 저도 지적했듯이 새 제안에는 노드의 주소만을 사용함으로써 ip 사용으로 인한 문제는 없을 것 같습니다. 하지만 반대로 공격자가 노드수를 증가시키려는 스팸의 위험은 다시 증가를 하게되겠지요.

    =====

    이런 류의 글들은 어쩔 수 없이 길어질 수 밖에 없습니다. 사실 새로운 합의 알고리듬을 만든다는 것은 논리적으로 검토해야 할 문제들이 매우 많이 있을 수 있습니다. 몇문장 말로 쉽게 이해되고 비판되기는 어렵다고 봅니다.
    그런 점에서 저역시 잘못이해하거나 또는 잘못 표현한 점이 많을 수도 있겠지만, 이렇게 정리해 놓으면 혹시라도 누군가에게 약간이라도 도움이 될까해서 올립니다.
  • ?
    @atomrigs
    네..

    감사합니다.

    저는 근거를 주고 받으면서 얘기하는 것을 좋아합니다. 이러면 얘기가 생산적이 되고, 도움도 많이 됩니다.

    사람은 서로 다른 정보 set을 가지고 있는데요.. 그래서 보는 면도 다르고, 얘기하면서 자기가 간과한 부분도 알 수 있는데요.. 근거로 얘기해 주시면 얘기가 재미있어집니다.

    1) 맞습니다..
    다시 생각해보니, 50% 이상이 나쁜 노드이라면 이전의 제 방법(http://www.ddengle.com/bitcoindeveloper/889821)은 무너지는 것 같습니다. 다시 생각해보니, pow나 pos보다 나쁜 모델로 보입니다.


    2) proof of work의 proof를 저는 '기준'이라고 해석해서, proof of randomness(가칭)로 했는데요.. 이 부분이 문제를 일으킨 것 같기도 합니다.

    즉, work(일) 기준으로 블럭 생성 권한을 준다는 식으로 해석을 했습니다. 사실 work에는 보안성도 들어있기 때문에 이 부분을 무시한 발상 때문으로 보입니다..

    제가 랜덤성을 이야기 하는 것은, 처음 pow의 개념을 이해하고 좀 충격을 받았기 때문입니다. pow의 해쉬게임이 단순히 블럭생성권한을 정하기 위한 것이고, 이 때문에 그 비싼 장비값과 전기료를 사용해야 한다는 것 때문으로 이해했거든요.. 물론 이와 달리, 이런 부분이 보안성이나, 현 비코 가격을 지탱하는 기반이 되는 측면도 있습니다. 이런 초기의 경험 때문에 개인적으로 랜덤성에 좀 집착하는 것일 수도 있습니다.


    3) 타임싱크는 잘 모르겠습니다..
    참고로, '합의'를 말씀하셨는데요.. 다수의 피어로 이루어진 p2p상황에서 공통의 일을 하려면 노드들이 합의를 해야 하는데요.. 개인적으로 합의라는 의미를 '다수'를 말하는 것으로 해석하여서 블럭 작성권한의 판단기준을 '다수'를 기준으로 정했던 것입니다.. 이런 부분이 보안상 문제가 될 수는 있겠죠.. 이것이 아톰님과 같은 것에 대해서 말하고 있는지는 모르겠습니다.


    4) 네.. 감사합니다.
    pos는 개인적으로 공부를 하지 못했습니다. 자료도 잘 없고요..
    그냥 개인적으로 추론하여 이렇게 되어 있겠구나라는 추측성 지식일 뿐이었니다.

    그래서 pos에 대해서 배웠습니다.
    그러면, 저는 pos의 타켓값이 어떻게 정해지는지가 궁금하기도 합니다.


    5) 네.. db에 대한 제 추측성 지식이 틀렸군요..


    6) ip는 mk님의 댓글에서 긍정적으로 말씀을 하셔서 적었던 것인데요.. 제 촛점은 노드당 하나의 기회를 준다는 의미였습니다. 그 외의 것은 잘 모릅니다. 그리고, ip 때문에 다수의 지적을 받기도 했서요.. ip 관련 글은 다 지웠는 줄 알았는데 남아있었군요.. 언급한 부분은 지우지 못한 것 같습니다.
    개인적으로는 ip문제는 좀 뜬금없어 보이기도 합니다. 왜냐면,, 기준이 어떻다는 것을 몇번 강조해서 이야기했거든요..
  • 그리고 저의 글의 태도가 좀 공격적이고 논쟁적이 되었는데, 의문점이나 논의점을 좀 더 극적으로 부각시키기 위함이었음을 말씀드립니다.
  • ?
    @atomrigs
    네..
    감사합니다.

    좀 논쟁적으로 적기는 했지만, 그래도 근거를 적으셔서.. 생산적인 논의가 된 듯합니다.
  • ?
    어렵네요
  • ?
    좋은 글입니다.
  • 정말 좋은글입니다.
  • @말똥이
    2014년에 쓴 글을 아직도 읽는 분이 있다는 것만으로 영광입니다. 감사합니다. 글 내용을 보니 3-4년이 지난 지금에도 합의 알고리듬에서의 진척은 많지 않은 것 같습니다.
default debug random = 0 / type = READ / detected = READ

List of Articles
번호 분류 제목 추천 수 조회 수 글쓴이 날짜
101 개발 [엑스코인]함께할 개발자님들을 모집합니다. 안녕하세요 엑스코인의 왕건일입니다. 엑스코인에서 대한민국 비트코인 시장에 한 획을 긋고 싶은 열정있는 개발자님들을(6분) 모집합니다. 땡글인일경우, 비트코인에 대한 열정과 개발에 대한 ... 3 2893
COINKING
2015.02.09
100 개발 node.js 에서 콜백지옥이 어떨때 발생하는건가요? for(var i=0;i<10;i++){ console.log(i); } for(var a=0;a<10;a++){ console.log(a); } console.log('end'); 이렇게 돌려봐도 첫번째 두번째 for문이 순차적으로 실행되는데 비동기식 코딩에서... 4 0 6452
지우긩
2015.02.01
99 개발 Gateway 구축비용 리플코인은 Ripple Trade 안에서 모든 거래(시장형성)가 진행되도록 만들어 놓았는데요,  Pax Moneta 는 반(Half) 독립적이며 자동 입출금 시스템으로 운영하고 리플마켓코리아는 리플트레이드에... 4 2 2918
V.June
2015.01.31
98 개발 redis 에 배열 자체를 담을수있나요? redis 에 key value 를 담아 배열처럼쓰는게아닌 a[0]='a'; a[1]='b'; 이 a 배열변수자체를 redis에 통째로담을수있나요? 1 0 2798
지우긩
2015.01.30
97 개발 timestamp 에 관해.. 안녕하세요 반갑습니다 늦게 프로그래밍이란걸 접하게되어 하나하나 배워가고있는 초짜입니다. 다름이아니라 서버와 클라이언트 사이의 시간을 동기화시키고싶은데요. 서버의 위치가 클라이언트... 3 0 1972
지우긩
2015.01.22
96 개발 파이썬 교재입니다. 파이썬 교재입니다. 제목은 "정보교육을 위한 파이썬"입니다. 교재로써 도움이 될까 해서 올립니다. 우리나라 두분이 번역해 주신것입니다. 첨부파일로 올리니 다운받으시면 됩니다. 파이선교재.... 9 file 6 8941
서울코인
2015.01.21
95 개발 프로그래밍 입문 - 무얼 어떻게 공부해야 할까요? 안녕하세요. @V.June 님 질문 보고 좀 자세히 여쭈어 보려고 합니다. 코인을 만들고 그와 관련된 생태계를 직접 꾸며보고 싶습니다. 코인(256D/스트립트/POS 등등) 을 만들고, 지갑을 만들고, 홈... 6 3 3935
음교수
2015.01.20
94 개발 프로그래밍 입문 안녕하세요,  프로그래밍에 너무도 관심이 많은 일반인 입니다.  지식이라면 거의 '0'에 가깝다고 볼 수 있습니다. 제가 모르는 영역이기에 시간을 두고 배우고 싶은데요, 궁극적인 목적이 '간단... 9 3 2334
V.June
2015.01.20
93 개발 서버에 지갑을 싱크해봤는데 트래픽이 어마어마하네요... 개인적으로 IDC에 테스트용 서버를 한 대 가지고 있어서 로컬에 있는 지갑 몇개를 서버로 옮겨봤습니다. 국제 트래픽이 20GB까지 무료인데, 싱크 띄워놓으니 하루만에 무료트래픽 다 털리는군요 ... 14 0 3412
디지털디자인
2015.01.19
92 개발 socket.io 사용하다 생긴 궁금증.. socket.io 로 웹서비스 하나 제작해보려 하는데 벌써부터 김칫국 마시는건 아닌지는 모르겠습니다만 나중에 해결못할 궁금증이 생겨 이렇게 질문올려봅니다. 바로 질문들어가겠습니다 socket.io ... 3 0 3249
지우긩
2015.01.18
91 개발 웹소켓 질문 있습니다 질문 1 : 웹소켓 타임아웃 보통 몇 초 정도로 하는게 적당할까요? 계속 데이터가 들어와야 되는 시스템인데.. 무한으로 설정해도모 큰 문제는 없을까요? 질문 2: 소켓 onClose 시에 재 접속을 시... 8 0 2941
메슬렁
2015.01.16
90 개발 갑자기 문득. 유레카! 그동안 사실, A 라는 사용자가 B 라는 사용자에게 코인을 보내기 위해 QR 코드를 오픈하는것만으로 코인을 전송하는 방법이 없을까.. 혹은 기존과 조금은 다른 결제 방법이 없을까.. 고민을 조금... 27 4 3846
calmlake79
2015.01.16
89 개발 비트코인(Bitcoin) 시스템 분석 노트 - kt 경제경영연구소 비트코인 공부할 때 찾아놓았던 자료입니다. 정리는 굉장히 잘 되어 있습니다. 비트코인 알고리즘에 관심이 있다면 읽어볼만한 자료입니다. 혹시 이 자료가 이전에 올라왔던 자료인지는 확인을 ... 7 file 18 9059
loum
2014.12.20
88 개발 Coinone API 오픈했습니다 안녕하세요. 코인원 입니다. Coinone API를 오픈하게 되어서 글을 남기게 되었습니다. https://coinone.co.kr/developer/ 앞으로 코인원이  다양한 아이디어를 구현할 수 있는 플랫폼으로 성장하... 2 10165
Coinone
2014.12.09
87 개발 주식 자동 매매 프로그램 이번 주는 많이 바빴습니다. 회사 업무도 있었지만, 프로그램 만드는 일도 몇 일 걸렸습니다. ETF(Exchange Traded Fund) 자동 매매 프로그램입니다. 저가에 매수하고, 고가에 매도하는 전략이... 28 file 11 25625
drjoon
2014.11.21
86 개발 공짜 파이썬 강의 듣기 파이썬(Python) 언어가 여러분야에 많이 쓰이고 있지요. Ethereum 가 파이썬을 지원하고 있고, 카운티파티 같은 경우는 전체가 파이썬으로 짜여있더군요. 영어공부도 할겸 파이썬도 배우고 싶다... 6 file 13 10179
atomrigs
2014.11.19
85 개발 우분 dd 5 0 2472
구스터(°͜ʖ°)
2014.11.18
84 개발 bitcoin rpc sendtoaddress method질문입니다 구조가 아래와 같은데요 sendtoaddress  하면서 전송 수수료를 설정으로 못하나요? 예를들어서 sendtoaddress  xxxx 0.1 이렇게하면 전송수수료 0.0001 이 나가거든요 이 전송수수료를 0으로 해... 5 0 2469
메슬렁
2014.11.18
83 개발 [JS] 개발자 분들 도와주십시오! 수고하십니다. 나이먹을만큼 먹고 자바스크립트 책을 5권이나사서 몇달째 공부중인 사람입니다. 다름이아니라 화폐를 단위별로 잘라야하는데.. 도저히 감이 잘안와서 혹시 땡글분들중에 알려주... 7 0 3850
지우긩
2014.11.14
82 개발 네트워크 부담이 없는 합의 알고리즘 저의 이전 글(http://www.ddengle.com/bitcoindeveloper/889821)에서 몇분이 네트워크 부담을 이야기하셔서 네트워크 부담이 없는 합의 알고리즘을 다시 만들었습니다. 일단 제 눈에는 이것이 PO... 47 3 5481
loum
2014.10.29
Board Pagination Prev 1 ... 83 84 85 86 87 88 89 90 91 92 93 Next
/ 93
default debug random = 0 / type = READ / detected = READ