develop custom_top_html:no
default debug random = 0 / type = READ / detected = READ
저의 이전 글(http://www.ddengle.com/bitcoindeveloper/889821)에서 몇분이 네트워크 부담을 이야기하셔서 네트워크 부담이 없는 합의 알고리즘을 다시 만들었습니다.

일단 제 눈에는 이것이 POS와 비슷하게 보이는 부분도 있습니다..

일단 POS의 coinday를 없애고 이를 코인데이 대신에 지갑의 주소에 일정량 이상 (예로, 만개 이상)의 코인이 있는 주소가 '기준해쉬'에 가까운지를 가려서 누가 블럭을 만들지를 정하는 방법입니다.

당연히 지갑에 코인이 많으면 여러 개의 주소로 코인을 분산을 시키면 그만큼 블럭을 생성할 기회가 많이 주어지게 됩니다.



****************
네트워크 부담이 없는 합의 알고리즘


* 개념.
1) POW와 같이 네트워크에 부담이 없고, POW와 달리 해쉬경쟁을 하지 않는 것이 목적임.
2) 이를 위해서, POW의 타겟값과 비슷한 역할을 하는 기준값을 만들고 이를 ‘기준 해쉬’라고 한다면, 다음의 기준 해쉬는 예측이 불가능해야 함. 


* 방법
1) 바로 전 블록의 해쉬를 ‘기준 해쉬’로 정함. (블럭에는 거래 정보가 포함되기 때문에 다음에 생성될 기준 해쉬는 예측이 불가능함). 물론 이전 블록의 해쉬값을 다시 한번 해쉬로 바꾸어 사용할 수도 있음.

2) 각 노드는 자체적으로 코인을 일정량 이상을 가지고 있는 지갑의 주소에 대해서 이 지갑 주소를 해쉬함수에 입력하여 해쉬값을 만듬.

이때 각 노드의 지갑은 자체적으로 블록체인을 스캔한 db(즉, 마지막 블록까지 각 지갑주소의 코인보유량이 기록된 DB)를 가지고 있어서 일정향 이상의 코인보유량을 즉각적으로 확인이 가능함.

예로, 전체 코인 중에서 0.001% 이상을 가진 지갑의 주소만 블록을 생성할 기회를 주는 것으로 정할 수 있고, 이 코인 이상을 가진 주소는 해쉬함수의 특성 때문에 동일한 블록생성 기회를 가지는 것이 가능함.

3) 따라서 모든 노드는 이 db를 참조하여 어느 주소가 일정량 이상의 코인을 가지고 있는지 바로 확인이 가능하고, 이 주소를 해쉬함수에 입력하여 각 주소에 대한 해쉬값을 구함.

4) 각 노드는 각 주소의 이 해쉬값과 기준 해쉬값을 비교하여서 가장 가까운 해쉬값을 가진 주소에게 블록을 생성할 권한을 부여함.

* 기존의 POS와의 차이점
1) 일정량 이상의 코인을 가지고 있으면 동일한 블럭 생성기회를 줌.



추가부분1
***************************************

기준 해쉬까지는 같습니다.

기준해쉬와 가까운 주소로 정렬하여서 해쉬값의 리스트를 만듭니다.
1등 기준해쉬와 제일 가까운 주소의 해쉬값
2등 기준해쉬와 2번째 가까운 주소의 주소 해쉬값
..... 등으로 리스트가 만들어질 것입니다.

이것을 '기준해쉬 리스트'라고 부르도록 합시다.

그리고, 각 지갑의 코인수가 많은 순서로 정렬하여서 리스트를 만듭니다.
제일 많은 코인을 가진 지갑주소가 1등이 되고, 두번째 많은 코인을 가진 지갑주소가 2등이 됩니다.

1등 코인이 제일 많은 주소
2등 코인이 두번째로 많은 주소
.... 등으로 리스트를 만들고 이를 '코인수 리스트'라고 합시다.

그리고 '기준해쉬 리스트'와 '코인수 리스트'에서 같은 주소에 있는 등수를 더합니다.

즉, 특정 주소의 경우 '기준해쉬 리스트'에서 3등이고, '코인수 리스트'에서는 10등이라면 이 주소는 3+10 = 13입니다.
이와 같이, 다른 특정 주소의 경우, '기준해쉬 리스트'는 1등이고, '코인수 리스트'에서는 100등이라면 이 주소는 1+ 100 = 101이 됩니다.

또한 두 리스트에 가중치를 다르게 할 수 있습니다. 
즉, 지갑을 여러개로 쪼개면 불이익이 가도록 코인수 리스트의 등수에 0.9를 곱하여서, 코인수 리스트가 더 중요하게 만드는 것입니다.

이런 방법으로 위의 13, 101을 정렬하여 작은순으로 '최종 순위리스트'를 만들고, 이 중에서 가장 작은 값을 가진 주소가 블럭을 만드는 것입니다.

이런 방법은 코인을 많이 가진 지갑이 더 많은 블럭 생성기회를 얻을 수 있고, 더불어 지갑을 여러 개로 쪼개는 것이 좋지 않은 결과가 되도록 한 것입니다.



추가부분2
*************************************

51% 공격을 완전히 방어할 수 있는 추가 알고리즘.

기존 알고리즘은 동일하다.

1) 단지 51% 공겍에 대한 방어를 위해서 코인을 생성할 때 만약 1억개의 코인을 발행할 것이라면, 2억 1개를 발행하고, 1억개는 유통이 가능한 코인으로 정하고, 나머지 1억 1개는 유통이 불가능한 코인으로 정한다.

2) 2억 1개를 가진 지갑은 블럭생성에만 참여하고, 나머지 유통, 전송 등의 기능은 전혀 없도록 코딩한다.

3) 2억 1개를 가진 지갑은 블럭생성시 이자를 받지 않도록 하거나, 이자를 받더라도 태워없애는 BURN을 시킨다.

즉 50%의 코인을 가진 지갑은 단지, 블럭생성에만 참여하여서 보안을 높이는 수단으로 사용한다.
POW와 같이 해쉬경쟁을 하는 것은 이런 방법이 소용없지만, POS 계열은 코인수로 블럭생성권한을 주게 되므로 이런 방식을 51% 공격을 완전하게 방어할 수 있습니다.


추가부분 3
*************************************

본 방법에서는 이전 블럭의 해쉬값을 '기준해쉬'로 정하는데.. 
이때 이 기준해쉬가 랜덤성이 부족하다는 의견이 제시되었습니다.

즉, 블럭을 만든 노드가 거래 데이터를 자기가 원하는 것을 선택하여서 자기가 원하는 블럭해쉬값을 만들 가능성이 있게 됩니다.
다시 말하자면, 거래 데이터의 순서 또는 개수를 조정하여 자신에게 유리한 블럭 해쉬값을 선택할 수 있는 여지가 있다는 것입니다.
물론 이 주장은 타당하지만, 노드가 이렇게 바꿀 수 있는 여지를 줄여나간다면 큰 문제는 없어보입니다.

그 이유는 해쉬값의 집합은 거의 무한대(찾아보지는 않았음)에 가깝고, 블럭을 만들 수 있는 노드가 선택할 수 있는 해쉬값의 가지수는 예로 몇 만개 정도라고 가정을 하더라도 이것은 거의 랜덤하다고 볼 수 있습니다.

따라서 랜덤성을 확보하기 위해서, 노드가 생성하려는 블럭의 해쉬값을 임의로 바꿀 수 없도록 하는 장치가 필요하게 됩니다.

이를 위해서,
1) 펜딩된 거래 데이터를 블럭에 기록할 때 코인 수에 따라서 정렬하여 기록하게 한다. (위치를 바뀌게 되면 머클트리가 바뀌고 따라서 블럭의 해쉬값이 바뀌는 것을 예방하기 위함입니다.)
2) 펜딩된 거래 데이터를 노드가 임의로 선택하여 블럭에 기록하지 못하게 특정 조건을 만족하는 펜딩 거래는 반드시 블럭에 기록하게 강제한다.

그 외에 조금 더 제한 사항을 만들면, 기준해쉬가 거의 안전하고 만족하는 랜덤성을 가질 수가 있을 것입니다. 



기존 방법의 단점 및  본인 방법의 장점 비교.
**************************************

1) 기존 방법의 단점.

  - pow, pos는 경쟁 방식으로 블럭생성권한을 주기 때문에 항상 포크(FORK)의 가능성이 열려있음.
  - pos는 coinage를 사용하여서 timestamp 또는 지갑을 일정시간 꺼놓고 있는 등의 방법으로 코인 생성권한을 원하는 시간에 얻을 가능성이 있음

   -  dpos의 단점.
        (1) 101개의 delegate(대표)는 모두 똑 같은 블럭생성권한을 가짐
             이 때문에, 제 방법과 비교하면, 제 방법은 코인 수에 따라서 블럭생성권한이 달라짐
             따라서, 101개에게 동일한 블럭생성권한을 주는 것보다 제 방법이 조금이 더 보안성이 있음
             (즉, 더 높은 블럭생성권한을 얻기 위해서는 더 많은 투자를 해야한다는 것임)

         (2) 추천을 해주는 방법에 문제점이 있음.
              일반적으로 다른사람에게 추천을 잘 해주지는 않을 것 같음
              이와 달리, dpos는 한사람이 여러 개의 주소를 만들고 서로 추천을 해주게 되면 이 들이 모두 블럭생성권한을 얻을 수 있음.
              더욱 무서운 것은 이들이 거의 비슷한 추천수를 가지기 때문에 연속적으로 블럭을 생성할 기회를 얻을 수 있어도 보임. 
              예로, 10%의 지분을 가진 사람이 0.1%씩 100개의 지갑을 만들고 서로 추천을 하면 100개의 10%추천을 가진 주소를 만들 수 있음.

2)본인 방법의 장점.

 (1) pow와 pos와 달리 블럭생성권한이 비경쟁방식이므로, 일반적으로 포크가 생기지 않는다. (예외적으로 네트워크가 분리된 경우를 제외함)
 (2) pow와 달리, 경쟁적인 계산을 하지 않음.
 (3) dpos의 추천의 추천을 사용하는 것이 아니라, 이전 블럭의 해쉬값을 이용하여 이전해쉬값 + 코인수로 블럭생성권한을 주는 방식이므로 dpos보다 우수한 보안성을 가짐.
 (4) 51% 공격을 막기 위해서, 약 50%의 지분을 가진 블럭생성권한만(코인의 이동을 원천적으로 막는다)을 가진 지갑을 생성하고 유지함.

일단, 제 방법은 코인수에 따라서 블럭생성기회가 다르기 때문에 이점은 pos와 비슷함.
하지만, 제 방법은 랜덤성 + 코인수에 따라서 블럭생성 권한이 분배된다는 차이는 있음.


2

loum님의 서명

 

 
 
 
댓글 47
  • ?
    전체 코인의 50% 이상을 가진 사람은 어택이 가능할 것 같습니다.
    물론 50% 이상 가진 사람이 어택하는 것은 지눈 지가 찌르는 꼴이지만요.
  • ?
    @drjoon
    네..

    의견 감사합니다.

    컨펌 시간을 작게하고,, 컨펌 수를 크게 늘리는 방법이 있을 듯하고요..

    원리적으로는 처음에는 발행자가 가장 많이 가지고 있을 것 같아서.. 이 부분은 초기에는 문제가 안 생길 것 같은데요..
    나중에 코인 발행자가 아닌 분이 50% 가지고 어택을 하면 그분이 손해가 되기 때문에 그런 면에서 방어가 될 것 같습니다.

    dpos, pos, pow 등도 정도는 차이가 있더라도 비슷한 문제를 가진 것으로 보입니다. 그래서 컨펌 수를 많이 해야 하는 것 같습니다.
  • 코인들이 생성하는 노운 중 가장 낮은값이 '참'이 된다는 이야기신게 맞나요?

    그렇다면 말씀하신대로 '검증을 위한 단계' 즉 컴펌수가 일정이상인 경우엔 대부분의 문제가 괜찮아지겠습니다.

    1. 지갑의 갯수가 증가해도 '블럭생성속도'가 느려지지 않을까?

    2. 지갑의 주인이 지갑을 켜두지 않아도 블럭생성이 가능한가?

    2개의 궁금증이 생깁니다.

    매우 재밌는 접근방법인 것 같습니다^^
  • @지구밖으로행군
    오랫만이십니다. ^^
  • ?
    @쌍둥아빠
    시험은 잘 보셨나요?
    한약방 차리시면, 이용해야 겠네요.
  • @loum
    저 한의대입니다만....

    한의사입니다. 한약사 아니에요. ㅠㅠ
  • ?
    @쌍둥아빠
    한의사는 한의원을 개설합니다.
    한약사는 한약국을 개설합니다.
    한약방은 한약업사에 의해 개설됩니다.

    일반적으로요..
  • @은빛늑대
    추천합니다. ㅋㅋ
  • @쌍둥아빠
    엥..
    한약방과 한약국은 다른거였나요!
  • ?
    @calmlake79
    쌍둥아빠는 한의대 ->국가고시 합격 후 보건복지부 장관이 발급하는 한의사 "면허" 취득 이후 한의사가 되시어 한의원 또는 병원에서 일하시게 되구요.
    한약사는 약대 한약학과 졸업생 (뭐 과도기를 거치며 말은 좀 많습니다만 현재는 이렇게 고정 된 것으로 알고 있습니다.)이 한약사 국가고시 합격한 후 보건복지부 장관이 발급하는 한약사 "면허"를 가지고 한약국을 개업합니다.
    한약방은 한약업사 시험에 합격하여 시장, 군수, 구청장에 의해 한약업사 "자격증"을 취득한 사람이 개설할 수 있습니다. 따로 교육 과정에 대한 내용은 없는 것으로 알고 있습니다.

    면허는 국가 인증, 한약업사는 시, 구, 군의 장에 의해 인정이구요. 한약방의 경우 해당 지역에서만 인증받은 것이기에 지역 이전의 제약 등이 있습니다.
  • @쌍둥아빠
    솔직히 쌍둥아빠님 훌륭한 한의사가 되시는게 왠지 좀 불편하게 생각하는 한사람입니다.
    한의사로서의 자질은 제가 보지를 못해서 알지 못하지만,
    커뮤니티 리더로서의 자질이나, 코인계의 위치로 보자면 한의사계에 그냥 쉽게 보내드려서는 안될 것 같다는 생각마저...
  • @atomrigs
    과찬의 말씀 부끄럽습니다.

    제마나인에서도 커뮤니티 리더로서 열심히 한의계 확장을 위해 고민하고 있는 중입니다. ^^
  • ?
    @쌍둥아빠
    네.. ㅎㅎ
  • ?
    @지구밖으로행군
    주소를 해쉬값을 변환한 주소해쉬값은 변하지 않게 되고, 기준해쉬이 매 블럭에서 변하게 됩니다.

    이때 누가 블럭을 생성할 권리를 주는냐는 것은 여러 기준을 정할 수 있는데요.. 일단 두 값이 가장 비슷한 것을 찾는 방식으로 하면 될 것습니다.

    1) 지갑의 개수가 늘어도, 크게 문제를 발생시킬 것 같지는 않습니다. 왜냐면 이때 문제가 되는 부분이 db도 용량인데, db 용량이 그리 크지 않을 것 같구요.. 즉, db는 각 주소와 그 주소가 가진 코인수를 저장하고 있기만 하면 되니까요.

    2) 지갑은 켜두어야 계속 블럭생성 기회를 얻을 수 있을 것 같습니다. 왜냐면, 블럭을 생성해서 네트워크에 전파를 해야 하니까요.. 만일 블럭 생성 권한이 있는 주소가 블럭을 생성하지 못하면 다음 순서의 주소가 그 권한을 얻을 것입니다.

    취직도 결혼도 하셨나요... 많이 축하드립니다.
  • 어제밤에 좀 더 생각해보니 새 모델에도 문제점이 더 있을 것 같군요.
    자꾸 문제만 제기해서 죄송합니다.

    1) 한번 블럭생성권을 획득하면 다음번 블럭생성권은 쉽게 획득할 수 있습니다.

    블럭생성권자를 결정하는 기준해쉬값이 이전 블럭해쉬값(또는 재해쉬한 값)인데, 어택커가 일단 한번 블럭생성권을 획득한다면, 이번 블럭을 만들 때 이 블럭의 해쉬값(또는 재해쉬값)이 자신이 가지고 있는 다른 주소의 해시값 (노드 주소 해쉬값) 과 가장 가깝도록 이미 네트워크에 올라와 있는 펜딩 트랜잭션들 중에 일부만 골라서 집어 넣거나, 새로운 트랜잭션을 만들어서 집어 넣을 수 있습니다. 마치 빗코의 마이너가 난스값을 계속 증가시켜서 타겟 패턴에 맞을 때까지 해쉬작업을 하는 것처럼, 이 경우에는 트랜잭션 조합을 계속 변화시켜서 원하는 블럭해쉬값을 찾을 수 있습니다. 따라서 다음번 블럭생성권도 자신의 주소중 하나가 받아 올 수 있고, 계속적으로 자기가 원하는 블럭해시값을 생성시켜 나갈 수 있습니다.
    이것을 방지하기 매우 까다로운 것이 다른 랜덤한 난스값을 블럭해쉬를 만들 때 섞는다고 해도, 어짜피 마이너가 트랜잭션의 머클트리 루트해쉬값을 콘트롤 할 수 있기 때문에, 일단 난스값이 정해지면, 다시 머클트리해쉬값을 조절해서 원하는 블럭해쉬값을 구할 수 있습니다. 그렇다고 트랜잭션 머클트리 루트해쉬값을 블럭해쉬를 구하는 인풋에서 빼버리면, 트랜잭션의 정합성이 보장되지 않으므로 그것도 문제이고, 또한 트랜잭션쪽 변수가 빠지면 기준해쉬가 그자체로 예측가능해져 버립니다.

    2) 액티브한 지갑의 디텍션문제

    각 노드가 다음 블럭을 생성할 주소를 판단하는 로직이 이전과는 다릅니다.
    이전에는 각 노드가 노드해쉬값을 매 블럭 생성때마다 보내오고, 이중에서 기준해쉬값에 가장 가까운 노드해쉬값을 선택해서 이 노드로 부터 블럭이 오기를 기다리는 로직이었는데, 이 때 노드해쉬값을 직접 보내온 것으로 보아서, 이 노드가 현재 액티브하다고 가정할 수 있을 것 같습니다. 물론 그 와중에도 디액티브해질 수 있지만 상대적으로 가능성이 많이 낮겠지요.
    하지만 새로직에서는, 각자의 노드가 다른 노드의 해쉬값을 db에서 직접구하고, 또 이 노드해쉬값은 블럭에 상관없이 고정되어 있는 값입니다. 이 때 문제는 각 노드가 db에 노드해쉬값을 가지고 있는 주소들중 누가 액티브한지 알 수가 없습니다.
    로움님은 위에서 첫번째 지갑후보가 믈럭을 생성하지 못하면 그 다음으로 넘어간다고 말씀하셨는데 이게 이전모델보다 훨씬 심각해보입니다.
    예를 들어 봅시다.

    A 라는 노드가 현재의 기준해쉬값을 가지고 자신의 db 를 조사해보니 블럭하이트 100인 블럭 생성을 위해 주소 B, C, D, E, F 가 가장 기준해쉬값에 가까운 주소해쉬값을 가지고 있다는 것을 알았다고 가정해 봅시다.

    그래서 첫번째로 B 주소의 프라이빗키로 사인된 블럭이 오기를 기다립니다. 타임아웃이 있겠지요 예를 들어 10초.
    일단 여기서도 지난번 글에서 말씀드렸듯이 기다리는 시작시간이 노드마다 차이가 날 수 있기 때문에 타임싱크 문제가 있구요.

    불행히도 B는 오프라인이었다고 칩시다. 모든 노드들이 10초 타임아웃을 기다리다 다시 C 주소가 사인한 블럭이 오기를 기다리겠지요 그런데 이 C 가 좀 불안정한 네트웤에 있어서 8초가 지난다음에야 블럭을 네트웤에 전파하기 시작합니다.

    A는 C가 전파한 블럭을 받지 못했고, 다시 D가 보낼 블럭을 기다립니다. 하지만 D 는 다행히 C가 보낸 블럭을 받았고, 따라서 블럭100은 생성은 끝났다고 보고 블럭을 생성하지 않습니다. 그리고 자기의 db 를 들여다 보니 새 블럭101 생성에 A 의 주소 해시값이 새 블럭해쉬에 가장 근접한 값이라고 판단을 내립니다. 따라서 D는 A 가 사인한 블럭101 이 오기를 기다립니다.
    이렇게 되면 A는 D에서 블럭100이 오기를 기다리고, D는 A에서 블럭101이 오기를 기다립니다. C 가 생성한 블럭 100이 다행히 A의 타임아웃이 또 끝나기 전에 A에게 도착하면 이 긴장을 해소할 수 있지만, 여기서 C 가 우선 타임아웃전에 자기 블럭을 생성했었는지 확인해야 하는 문제가 또 생깁니다. C 가 선언한 타임스팸프값을 어떻게 신뢰할 수 있는가 하는 거죠. 예를 들어 B는 아까 분명히 타임아웃 시간이 지나도록 블럭을 생성하지 않고 오프라인이었다고 했는데, 10초가 지나서 온라인이 되고, 자신이 타임아웃이 지났다는 것을 알았음에도 불구하고 자긴의 타임스팸프를 속여서 네트웤에 블럭100를 퍼뜨립니다. E는 네트웤에 지금까지 오프라인 되어 있다 지금 온라인 되었는데, 아직 블럭 101을 받지 못했습니다. 그래서 블럭100 을 생성할 노드주소를 보니 B 였습니다. 그런데 마침 B에서 사인한 블럭이 도착했고, B가 선언한 타임스탬프를 믿고 새 블럭101를 생성할 주소는 F 라고 판단합니다. 하지만 F는 C가 생성한 블럭 100의 체인을 따르고 있습니다. 그러니 F가 블럭 101를 생성하지 않을 것이고, E 는 또 타임아웃에 걸립니다.

    이런식으로 각 노드마다 블럭을 생성할 주소가 오프라인 되어 있어서 블럭을 못받을 확률이 높고, 이 때마다 타임아웃이 걸리고 이 타임아웃 구간마다 일부는 받고 일부는 못 받고 하는 과정에서 서로 물리고 물리는 경우까지 생길 수가 있습니다. 의도적으로 타임스탬프를 속여서 들어오는 어택커도 있어서 문제는 더욱 복잡해집니다.
    이 와중에서 여기저기 타임아웃 홀드되고, 올펀일어나고 하겠지요. 오프라인되어 있는 노드수가 많을수록 이 문제는 기하급수적으로 증폭되겠지요.

    여기서 그럼 단순하게 각 노드가 받은 여러가지의 블럭들중에 하이트가 제일 높은 것을 계속 고르면 자동적으로 합의가 이루어지지 않을까 생각할 수도 있습니다. 하지만 같은 하이트의 여러 블럭해쉬값들이 동시에 존재할 수 있고, 이 중에서 누구를 선택해야 하는가 하는 기준이 여전히 대단히 애매합니다. 위의 예에서 현재 네트웤에 블럭100의 해쉬값으로 B 가 만든 것과 C가 만든 것이 경쟁하고 있을 때, A의 경우에 원래의 기준값으로 본다면 B 가 가장 우선순위이지만 A 의 입장에서는 B 는 타임아웃된 대상이니 제외되어야한다고 생각할것이기 때문에 C를 선택하는 반면, E는 B가 여전히 우선순위라고 믿기 때문에 B가 생성한 블럭을 선택할 것입니다. 이렇게 되면 여전히 포크된 체인은 합의에 이르지 못합니다.

    어떤 한쪽으로 수렴시키는 임의의 강제적인 기준을 만들면 되지 않을까 생각해보았지만, 이렇게 되면 이런 기준을 맞추어서 블럭생성권을 획득하려는 어뷰즈가 또 일어날 수 있습니다.

    아니면 하나의 블럭하이트에 있는 다수의 블럭중 하나늘 선택할 때, 각 노드가 전체 노드의 의견을 물어서 다시 다수결로 가면 어떻겠냐 하는 생각이 있을 수 있겠는데, 이렇게 되면 이것은 이전모델로 유사하게 갈 것 같습니다. 여기저기 불일치가 생길 때마다 다른 노드들에 대한 전수조사(또는 과반조사)를 해야하니까요.

    =======

    그런데 위의 대부분의 문제들은 불특정 노드들이 합의해야 하는 과정이 아닌, 제한된 클로즈된 비교적 소수의 노드들간의 합의과정으로 만들어 놓으면 해결이 됩니다.
    그래서 다시 DPOS 이야기가 되고 맙니다. 매블럭마다 전수합의가 되니 올펀이 생길 일도, 컨펌을 할 필요도 없어져 버리니까요. 반대로 DPOS 의 논리적 결함이 무엇일까에 대해 생각해보게 됩니다.
  • ?
    @atomrigs
    네..

    저는 좀 더 큰 틀에서 얘기한 것이고요..
    구체적으로 들어가면 얘기할 것이 있습니다.

    1) '기준 해쉬'를 변하는 것을 사용해서 문제를 삼으신 듯합니다.
    그렇다면, '기준해쉬'를 블럭높이(height)를 해슁한 값을 정하면 되는 문제입니다.

    그렇지 않다고 해도, 같은 주소가 블럭을 만들 수 있는 기간을 정해야겠지요.. 블럭을 만든 주소는 최소 500개의 블럭이 생성된 후에 블럭생성권한을 주는 방식입니다.

    그리고, 펜딩된 거래데이터를 임의로 순서를 바꾸는 행위는 나쁜 것입니다. 이에 대해서 어떤 기준을 만들어서.. 펜딩된 거래 데이터에 순서를 주고 이 순서를 따를지 않으면 안되도록 하는 어떤 보안 알고리즘이 더 들어갈 것입니다.

    이런 부분은 좀 세부적인 것이고, 만일 이런 문제는 인식하고만 있다면 여러 수단으로 해결이 가능할 것입니다.


    2) 이 문제는 dpos도 동일하게 가지고 있는 문제입니다.
    제 글에 다른 분의 답글로 달아놓은 것을 읽어보지 않으셨군요..

    이것도 여러가지 해결방안이 있습니다. 각 노드는 자신이 블럭을 생성할 권한이 있다는 블럭이 생성되면 바로 알 수 있습니다.

    이때 이전 블럭이 생성되자마자, 권한이 있는 순서대로 상위에 있는 노드 중에서 예로 10개가 자신이 살아 있다는 것을 네트워크에 전파를 하는 방법으로 해결을 하면 될 듯 싶습니다.



    3) dpos를 이 시스템으로도 비슷하게 만들 수 있습니다.

    일단 db가 있기 때문에, 코인 수가 많은 상위 몇개를 정해서, 순서대로 블럭생성권한을 줄 수가 있습니다. 아주 쉽게 dpos와 유사한, 물론 추천 개념은 배제된 dpos가 되겠네요..

    참고로, 주소 중에서 거래량이 특히 많은 주소는 거래소 주소이니, 거래소 주소는 빼는 것도 한 방법일 수 있습니다.

    아니면, 코인 수 상위 몇개(예로 100개, '상위그룹'로 칭함)와 그 다음 100개('다음그룹'으로 칭함)를 만들어서, 처음은 상위 그룹이 순서대로 한 후 모두 다하면, 두 그룹 중에서 어느 그룹이 다음 100개의 블럭을 생성할지를 100개 중 마지막 블럭의 해쉬값을 홀수/짝수 형태로 변경하여 홀수 이면 상위그룹이 다음 100개를 생성하고, 짝수이면 다음그룹이 생성하는 방식도 가능할 것입니다.

    이런 융통성은 db를 가지고 있기 때문에 생기는 이점입니다.

    감사합니다.
  • @loum
    좀 너무 쉽게 문제가 있는 것은 쉽게 다 해결된다 이렇게 보시는 것 같습니다.

    1) 하나의 주소만 가지고 어택하지는 않지요. 어택커가 주소를 수천개, 수만개 미리 만들어 놓는건 스크립트 조그만 다룰 줄 아는 사람도 쉽게 만들 수 있습니다. 팬딩된 트랜잭션들을 선택하는 것은 지금도 빗코 마이너 마다 기준이 틀립니다. 트랜잭션 피의 양에 따라 우선순위를 주기도 하고, 스탠다드가 아닌 것은 리젝트하는 마이너도 있습니다. 메모리에 팬딩되어 있는 트랜잭션들은 모든 마이너들에 걸쳐 동일하다는 보장도 없습니다. 또한 필요하면 마이너가 임의로 새 트랜잭션을 얼마든지 추가해서 블럭해쉬값을 바꿀 수 있습니다. 마이너가 새로 추가하는 트랜잭션에 대해 잘못되었다고 볼 수 있는 어떤 근거도 없습니다. 이렇게 트랜잭션 트리 해쉬값을 바꾸면서 이전 블럭해쉬값을 해쉬하던 하이트값을 해쉬하던 얼마든지 이에 제일 근접한 값을 미리 만들어놓은 수천, 수만개의 주소에서 찾을 수 있게 만들 수 있습니다.
    기준해시를 블럭하이트를 해쉬하는 것이라면 이것은 더 문제입니다. 매 블럭마다 미리 기준을 다 계산할 수 있으니, 어택커는 더 많은 시간을 들여서 이에 근접하는 주소를 찾아서 등록시켜 놓으면 될 것이기 때문입니다.

    현재의 pow 나 pos 가 돌아가는 실제의 메카니즘에 대해 좀 더 공부를 하시는 것도 도움이 될 듯합니다.

    2) 어떻게 "각 노드는 자신이 블럭을 생성할 권한이 있다는 블럭이 생성되면 바로 알 수" 있는지 모르겠지만, 제 상식으로는 네트웤 전파과정에서 상당한 딜레이가 생길 수도 있고, 아예 드랍될 수도 있습니다. 자기가 살아 있다는 것을 계속 전파하면 되겠지만 역시 이런 사전 노티스를 기다려야 하는 시간이 필요해집니다.
    DPOS 도 논리적으로 똑같은 문제를 가지고 있지만, 총 모집단 노드수가 101 개 밖에 안되고 블럭생성 순서까지 미리 정해져 있기 때문에, 문제처리가 훨씬 쉽고 간단해지게 되는 것이죠. 아마 DPOS 의 딜리게이트수가 1천개만 되어도 지금처럼 10초마다 블럭생성하는 것은 불가능해질 겁니다.

    3) 저도 지적했듯이, 노드생성권을 수백개 이하로 한정지으면, 여러가지 방식으로 노드생성권 순위를 쉽게 정할 수 있고 포크도 없고, 컨펌필요성도 다 없앨 수 있습니다. DPOS 는 이것을 101개의 노드로 한정해 놓되, 나머지 노드들에게 투표권을 줌으로써, 직접민주주의는 아니더라도, 최소한 어떤 의사표시 통로는 만들어 준 것이지요.
    DPOS 의 투표대신에 랜덤하게 미리 제한된 노드수가 정해지는 또 다른 로직이 있다면 또 다른 유형의 모델이 가능해진다고 봅니다.

    저역시 DPOS 의 운용메카니즘에 대한 연구를 더 할 필요성을 많이 느끼고 있습니다. 또한 이씨리움의 합의방식에 대한 논의도 꽤 논리적 깊이가 있는 것 같습니다. 새로운 솔루션은 기존에 나와있는 여러가지 방법론들에 대한 좀 더 구체적이고 체계적인 검토위에 나와야 더 생산적이지 않을까도 생각합니다.
  • ?
    @atomrigs
    네..
    그래도 이렇게 토론을 이어주시니 감사합니다.

    어떤 것이든 문제가 없는 방법은 없습니다.
    문제를 최소화시키는 것이 제가 자연에서 배운 지식입니다.
    따라서 제 방법에도 어떤 문제가 있을 수 있습니다...

    1) 주소를 여러 개를 만드는 것은 쉽게 가능합니다.

    하지만 알고리즘에 일정 시간동안 코인을 가지고 있어야 한다는 등을 제한 사항을 집어 넣으면 어느 정도 해결이 되는 문제로 보입니다.
    즉, 예를 들자면 주소가 코인을 가지고 있은지 최소 일주일은 지나야 블럭 생성기회를 주는 방법입니다.
    이럴 경우 제기하신 문제는 거의 사라집니다.

    이것을 회피하기 위해서, 해커가 수십만개의 주소를 미리 만들어서 코인을 넣어둘 수는 있습니다.
    이것도 블럭 생성하기 위한 최소 코인 수를 높게 설정한다면 회피할 수 있습니다.

    아. 그리고, 블럭높이로 기준해쉬를 정하는 것이 더 문제를 유발시킬 수 있다는 것은 맞습니다.

    물론 제 방법에 알려지지 않은 문제가 있어서, 어떤 다른 문제를 야기할 수는 있습니다.

    이때는 어떤 제한사항을 주어서 이를 해결하는 수밖에 없습니다.
    그렇지 않으면 완전히 새로운 알고리즘을 만들어야 됩니다.

    따라서, 제 방식은 새로운 방식이므로, 보안을 위해서 어떤 제한을 계속 붙여나가는 방법을 사용해야 합니다.

    실제, dpos도 이런 과정으로 만들어진 것일테니까요..

    저의 특징은 남의 것의 큰 특징을 파악해서, 다른 것을 만드는데 익숙합니다..
    뭐 구체적인 것도 잘하지요..

    pos에 대해서 큰 그림은 대충 파악한 듯 싶습니다.
    물론pos에 대한 지식이 짧아서 좀 틈도 있습니다.

    제 글에 관심을 가져주셔서 감사합니다.
  • @loum
    제가 지적한 내용들이 제대로 전달이 안되는 것 같지만, 저의 이야기도 어짜피 별 돈벌이가 되지는 안될 듯하여 이만 줄일까 합니다. 좋은 아이디어 잘 이용하여 성공하시길 바랍니다.
  • ?
    @atomrigs
    네.. 감사합니다.
    지적해주신 것이 유용했습니다.
    혹시 시간이 나시면 댓글로 전달이 안 된 부분도 알려주세요..

    궁금하기도 합니다.
  • @loum
    POS 연구하는 것이 돈이 안되는 거라 안하겠다는 말씀은 삭제하셨군요.
    지금 코인계에서 돈되는 일 하는 사람 몇이나 될지 모르겠습니다. 뭔가 큰 새로운 것이 나오면 처음에 그것을 먼저 활용하는 사람들에게는 어드밴티지가 있고, 돈 벌 기회가 상대적으로 더 많은 법인데, 코인바닥은 별로 안그런 것 같습니다. 남아 있으면 있을수록 뭔가 계속 비생산적인 돈 안되는 것에만 시간을 쏟아 붇고 있다는 자괴감이 커지네요. 그래도 좋은 아이디어와 추진력이 있는 사람들은 언젠가는 빛 볼날이 올 수도 있겠지요.

    =============

    제 이야기를 좀 더 들어주시겠다고 하니 덧붙이겠습니다.

    모든 새로운 솔루션들은 처음에는 여기 저기 많은 헛점들과 문제들이 있겠지요. 그래서 가능하면 여러 사람들이 검토해보고 문제를 지적하고 또 그걸 해결하는 방법들을 찾아보고 하는 과정에서 완성도가 올라 갈 겁니다. 그런데 이런 문제들중에는 비교적 손쉽게 간단한 방법으로 해결할 수 있는 문제들도 있겠지만, 매우 근본적으로 새로운 방법론을 도입해야 해결되는 문제들도 있을 수도 있겠지요. 어떤 문제에 대해 어떤 수준의 해결이 필요할지는 왜 그런 문제가 생기는지에 대한 근본적인 원인파악이 되어야 판가름이 됩니다.

    예를 들어 위에서 제가 제기한 문제중 하나를 살펴봅시다.

    "한번 블럭생성권을 획득하면 다음번 블럭생성권은 쉽게 획득할 수 있습니다."

    이 문제에 대해 로움님은 몇가지 구제척인 조건만 걸면 거의 대부분 다 해결될 수 있는 단순하고 쉬운 문제로 보고 있습니다. 하나의 주소가 한번 블럭을 만들면 그 다음 500 개 블럭은 못 만들게 막는다던지, 블럭을 만들 수 있는 권리를 얻으려면 일정코인 이상을 일정기간 이상 가지고 있게 하면 된다던지 이런 식의 구체적인 조건들을 계속 붙여가면 해결될 성질의 문제라는 거죠.

    하지만 제가 볼 때는 이 문제는 이렇게 노드에게 제한을 가하는 조건들을 계속 붙여가는 방법으로 근본적으로 해결될 성질의 문제가 아니라는 것입니다. 왜냐하면 이 문제가 생기는 원인은 현재 블럭을 만드는 노드가 블럭해쉬값을 콘트롤 할 수 있고, 이 블럭해쉬값에 의해 다음번 블럭생성권 주소의 기준값이 결정되는 구조 자체이기 때문입니다.

    즉 랜덤한 값이 아닌 콘트롤 될 수 있는 값을 기준으로 정한 값에 가까운 값을 랜덤이라고 전제해야 하는 구조적 모순이 있기 때문입니다.

    이 구조하에서는 어떤 구체적인 조건을 달아도 새로 부가되는 구체적인 조건들을 다시 콘트롤할 수 있는 방법들이 나옵니다. 물론 극단적인 조건들을 달면 논리적으로 가능할 수 있을지는 모르겠지만, 이것은 정상적인 주기적 블럭생성을 불가능하게 하거나, 기존의 PoS 가 블럭생성권 획득을 위해 거는 조건들과 별반 다를게 없게 되어 버리게 때문에, 애초에 설정한 새로운 합의구조 방식을 만든다는 목적 자체를 별 의미없게 만들어 버릴 수도 있습니다.

    제시하신 몇가지 해결방법들을 봅시다.

    - 하나의 주소가 한번 블럭을 만들면 그 다음 500번은 참여하지 못하게함.
    ==> 어택커는 미리 500개 이상의 주소만 만들어 놓으면 됩니다. 1000번을 못하게 한다면, 1000개의 주소를 만들어 놓으면 됩니다. 이 숫자를 계속 크게 증가시키면 해결이 될까요? 이 숫자를 크게 하면 할수록 반대로 선의의 액티브한 노드숫자도 그 만큼 많아져야 블럭생성이 가능합니다. 숫자를 늘리는 것이 어택커에게는 큰 부담이 안되지만, 반대로 요구되는 선의의 노드수를 충족하는 것은 더 힘들어집니다.

    - 블럭을 만들 수 있는 권리를 얻으려면 일정코인 이상을 일정기간 이상 가지고 있게 하면 됨
    ==> 최소코인수를 얼마이상으로 높여야 할까요? 얼마 이상동안 가지고 있게 해야 될까요? 물론 이경우에도 최소 1% 이상의 코인을 가진 주소만 블럭을 생성할 수 있다고 조건지우면 해킹을 어렵게 하기는 하지만 그렇게 하면 블럭생성권을 가지는 최대 지값숫자는 100개에 불과해집니다. 하지만 이 경우에도 1% 코인수를 가진 지갑 6개만 가지면, 즉 6%만 소유하고 있으면 6개의 블럭을 연달아 생성할 수 있습니다. 그리고 이런 식으로 블럭생성권을 코인소유량과 소유기간에 의해 제한해가다 보면 그냥 DPOS 나 POS 방식의 부분적인 변형모델이 되고 맙니다. 기존방식에 비해 보안성이 높아진다면 모르겠지만, 지금까지 내용으로봐서는 오히려 더 낮아진다고 판단됩니다.


    따라서 이 문제를 해결하려면 논리적으로 이런 것들을 생각해 볼 수 있습니다.

    (1) 블럭을 만드는 노드가 블럭해쉬값을 결정할 수 없도록 하는 것.
    => 제 머리속에는 방법이 떠오르지 않습니다. 특정한 해쉬패턴이나 타겟을 주어서 이 타겟에 만족하는 해쉬값을 주어진 블럭생성시간동안 몇개 이상 구할 수 없게 하는 방법을 생각해 볼 수 있으나, 이것은 결국 PoW 으로 되돌아 갈 것 같구요. 사실 PoW 를 하면서도 빗코의 무한적인 해쉬경쟁을 막을 수 있는 방법을 연구해 보는 것도 흥미로울 것 같습니다.

    (2) 기준해쉬값을 예측불가능한 완전히 랜덤한 방법에 의해 구하는 방법
    ==> 하나의 노드가 랜덤한 값을 생성시키는 것은 쉬우나, 어떻게 모든 노드가 같은 랜덤값을 가질 수 있게 할지가 어렵습니다. 여기서 일종의 투표모델을 또 생각해봐야 하는데 로움님의 이전모델로 되돌아가겠지요.


    =====

    여기서 애초에 랜덤한 방식을 도입을 해서 해결하려는 문제가 무엇인가를 다시한번 요약해 봅시다.

    PoW의 무제한적 해쉬경쟁에 의한 제반 문제들, 코인 소유량에 따라 결정되는 "불평등한" POS 블럭생성권.

    이런 문제들을 극복하기 위한 수단으로서

    어떤 기준값에 가장 가까운 값을 정답으로 고르는 "랜덤한" 결정방법을 사용했습니다.

    하지만 정답/오답으로 바로 각 노드가 결정할 수 있는 기존의 방법대신에 전수(또는 과반수)를 조사해야 답을 정할 수 있는 "가장 가까운 값" 을 고르는 방식을 채택했기 때문에, 이로부터 비롯되는 합의과정에서 비효율성의 문제가 초래됩니다. 또한 무엇을 기준으로 삼아야 하는지에 따른 각종 보안상의 취약점도 추가적으로 노출되고, 그 해결 또한 답이 잘 보이지 않습니다.

    이런 문제들을 극복하기 위해서 계속 여기저기 부분적인 제한 조건을 붙이다보면 결국은 도대체 무엇이 "랜덤"한 것인지, 왜 그것이 랜덤해야 좋은 것인지조차 불분명해집니다.

    또한 "랜덤결정을 통한 합의구조" 모델이 왜 지금까지 제시된 다른 솔루션들, 예를 들어 DPOS, 또는 제한된 PoW+PoS 하이브리드 모델보다 왜 더 나은 것인지가 설득이 안됩니다.

    이 모델도 작동한다는 것을 논증하기도 어렵겠지만, 그것만 가지고도 안됩니다. 이미 여러가지 솔루션들이 나와 있는 마당에 왜 자신의 솔루션이 기존의 것보다 왜 더 우월한지 예를 들어 보안성이 더 높다던가, 더 빠른 블럭생성주기를 만들 수 있다던가, 더 네트웤 안정성이 높다던가 하는 기능적 장점들을 보여줄 수 있는 근거가 있어야 합니다.

    그렇지 않다면 그냥 DPOS 의 로직을 일부만 수정해도 애초에 설정했던 문제의식은 충분히 실현할 수 있고, 기존에 투자된 많은 다른 개발자의 노력을 쉽게 가져다 쓸 수 있을텐데 말입니다.

    하지만 로우님의 제시안을 통해 p2p 네트웍상의 합의구조에 대해 좀 더 심각하게 고민해 볼 수 있는 좋은 기회가 되었다고 생각합니다. 특히 p2p 상의 합의가능한 랜덤성은 참 재미있는 주제입니다.
    그런 점을 감사하게 생각하고 있고, 저 또한 이렇게 돈 안되는 일에 계속 시간을 쓰고 있는 이유이기도 합니다.

    긴글 읽어주셔서 감사합니다.
  • ?
    @atomrigs
    네 글 감사합니다.

    글을 읽고 바로 생각난 것만 적어 보겠습니다.

    문제를 제기하신 "한번 블럭생성권을 획득하면 다음번 블럭생성권은 쉽게 획득할 수 있습니다."라는 것에 저는 기본적으로 큰 문제가 안 된다고 보았습니다.

    구체적으로 살펴보겠습니다.

    일단, 한번 블럭생성에 참여한 주소는 그 후 2~3일 후부터 블럭생성에 참여할 수 있다고 정합시다.
    그리고, 컨펌시간은 약 20~30초, 거래확정을 위한 최소 컨펌수는 약 150개 정도로 생각을 하겠습니다.

    현재는 이 컨펌시간에 도착한 거래데이터가 많아야 100개 정도일 것입니다. 이 중에서 최소 네트워크 전파시간을 2초라고 생각하면 컨펌 전 약 5초 동안 도착한 펜딩 거래는 다른 노드에게 전파되었는지 확인을 못할 수도 있기 때문에 이는 블럭의 tx 부분에 넣을 수 없다고 생각해 보겠습니다.

    그 나머지 부분의 거래는 대부분 블럭에 포함을 시키는 것이 일반적일 것입니다. 단지, 포크 등 여러 원인에 의한 부분이 있을 수도 있습니다.. 이런 부분에 대한 것은 자세히는 모르지만 네트워크에 전파되었다면 어떤 규정에 의해서 이 거래 데이터를 블럭에 포함하는지에 대한 판단 기준이 이미 있을 것을 것으로 추측을 해봅니다.

    이 경우 블럭을 만드는 주소는 임의대로 블럭에 들어가는 거래데이터를 취사선택할 수 없습니다. 어떤 정해진 방법에 따라서 거래 데이터를 블럭에 작성을 해야 합니다. 물론 네트워크가 불안하니까 정해진 방법의 약 80~90%의 거래 데이터를 포함해야 한다는 규정이 필요하겠지만요.. 따라서 주소가 임의로 선택할 수 있는 거래 데이터의 수는 한정이 되기 때문에 제기하신 것이 큰 문제가 안 될 것으로 본 것입니다.

    또한, 이런 문제 때문에 컨펌시간을 최대한 짧게 정하고, 거래확정 컨펌수를 최대한 많이 정한다면 이런 문제들이 크게 중요한 것이 아니라고 보았던 것이기도 합다. 또한 제 방법이 컨펌시간을 짧게하는데 이점이 있기도 합니다.

    물론 문제 제기하신 것이 극복할 과제이긴 합니다. 좀 더 생각을 해보겠습니다.

    그리고 말씀하신 '블럭을 만드는 노드가 블럭해쉬값을 결정할 수 없도록 하는 것"은 생각해 볼 여지는 있어보입니다. 말씀하신대로 하면 해결방법이 쉽지는 않겠지만, 좀 뒤틀어서 생각해볼 여지는 있다고 봅니다..

    그리고,, 나머지 부분은 제가 좀 더 생각을 한 다음에 답변을 하도록 해보겠습니다.
  • @loum
    직접 마이닝 한번 해보시고, 또 메모리에 로드된 트랜잭션이 어떤 것이 올라와 있는지도 한번 보시고, 이런 트랜재션들이 다른 마이너들에게 올라와 있는지도 보시고, 또 멀티시그 같은 트랜잭션이 마이너마다 받아들여지는지 안되는지도 한번 보시구요.
    그리고 블럭생성주기를 20초로 잡으면, 하루에 필요한 블럭수가 4320 개인데 한번 블럭을 생성한 후 이틀을 기다려야 된다면 8640개의 액티브한 노드가 있어야 지속적인 블럭이 생성되겠지요. 현재 왜 꽤 인기 있는 코인들 액티브한 지갑수가 몇개나 된다고 봅니까? 저의 잭팟지갑은 하루에 수십개의 블럭을 생성합니다. 블럭 리워드도 주는데 왜 제 지갑이 이렇게 많은 블럭을 생성해야 할까 한번 생각해 봐 주세요.
    새로운 솔루션 만들기전에 PoW, PoS 마이닝도 직접 해보시고 계산도 해보시길 권합니다.
    p2p 네트웤 전파속도가 2초일까요? 보통 1라운드 퍼지는데 10초가 마의 벽이라고 합니다.
    누누히 이야기하지만, 마이너가 블럭을 만들 때 새 트랜재션 추가시키는게 얼마나 쉬운지 한번 해보세요. 블럭해쉬값을 새 트랜잭션 집어 넣어서 콘트롤 하는 것은 기존 PoW 에서 난스값 변화시키는 것이랑 거의 동일한 난이도 정도 수준입니다.
    새로운 합의구조 알고리듬을 만들려면 p2p 환경에 대한 보다 더 구체적인 이해와, 기존 PoW,, PoS 에 대한 좀 더 심도 깊은 연구가 선행되어야 할 것 같습니다.
  • ?
    @atomrigs
    네..

    네.. POW, pos 마이닝은 직접 해보았습니다.
    물론 거래데이터는 실시간으로 체크는 안해보았습니다.

    "마이너가 블럭을 만들 때 새 트랜재션 추가시키는게 얼마나 쉬운지 한번 해보세요. "라고 하셨는데..
    제 의견은 이 부분에 제한을 주자는 것인데.. 한계가 있다고 말씀하시는 군요..

    네 그렇다면, 트랜재션과 상관이 없는 어떤 랜덤한 것으로 해야 한다는 것으로 이해하겠습니다.

    일단 현재 방법으로 대안으로 dpos와 같이 그룹을 만들어서 순차적으로 진행하는 것이 방법이 될 수는 있겠네요.

    그리고,

    좀 정중하게 말씀해주시면, 대화하는데.. 좀 편하겠습니다.

    듣기에 따라서는 상당히 기분나쁘게 들리네요..!

    대화를 하고자 한다면 문제점을 구체적으로 적어주시기를 바래봅니다.

    이것을 해보고 애기하라는 이야기는 논쟁으로 끝이납니다.

    데이터로 얘기를 해야합니다.
  • @loum
    기분나쁘게 생각하셨다면 죄송합니다.

    하지만 너무 그냥 쉽게 이렇게만 하면 다 해결된다 이렇게 생각하기전에 논리적으로 자신의 주장이 어떤 문제가 없는지 헛점이 없는지 조금 더 생각해 보시라는 겁니다. 그리고 그렇게 쉽게 생각하시는게 마이닝 과정에 대한 보다 구체적인 이해가 없기 때문이 아닌가 의심도 드는 것이구요.

    예를 들어
    "일단, 한번 블럭생성에 참여한 주소는 그 후 2~3일 후부터 블럭생성에 참여할 수 있다고 정합시다.
    그리고, 컨펌시간은 약 20~30초, 거래확정을 위한 최소 컨펌수는 약 150개 정도로 생각을 하겠습니다."

    어떻게 이런 가정을 그냥 쉽게 합니까? 이런 가정을 만족하기 위해서 액티브한 마이너 수가 몇개 필요한지 조그만 노력을 들여도 확인가능한데 그 정도의 마이너가 그리 쉽게 얻어질 수 있는 숫자가 아니라는 것은 현재 상황을 조금만 이해하고 있어도 금방 알아차릴 수 있는데, 그런 감 조차 공유가 안되니 드리는 말씀입니다. 거래확정을 위한 최소 컨펌수를 150개라고 설정하시면서 여기에 대해서 조금도 이상한 감이 안드신다는게 저로서는 이해가 안됩니다.
    제가 블럭을 만들 때 임의의 새로운 트랜잭션을 삽입하는게 아무런 문제가 안된다고 계속 지적을 해도,
    " 따라서 주소가 임의로 선택할 수 있는 거래 데이터의 수는 한정이 되기 때문에 제기하신 것이 큰 문제가 안 될 것으로 본 것입니다"

    이렇게 아무런 문제가 안됨. 결론을 내리시면 더이상 저도 어떻게 논리적으로 설명을 드릴 방법이 없네요. 본인이 직접 블럭을 만들어 보고 여기에 추가로 새로운 트랜잭션을 넣어 보는 테스트를 해보는 수밖에 없지 않겠습니까? 그래서 이 새로운 트랜잭션의 추가에 따른 루트해쉬값의 변화와 블럭해쉬값의 변화를 확인해보는 수밖에 없지 않겠습니까?

    예를 들어 잭팟코인의 경우에도 중간에 올펀 블럭 많습니다. 이 올펀 블럭조사해보면 여기에는 이 트랜잭션이 있고, 저기엔 없는 경우도 많습니다.
    더블 스팬딩 테스트해보려고 하나의 아웃풋을 가지고 이쪽 마이너에 이 트랜잭션을 다른 쪽 마이너엔 다른 트랜잭션을 넣어 보기도 합니다. 누가 억셉트되고 누가 리젝트되는지, 한쪽에 피를 더주고 다른 쪽에 덜 주면 어떻게되는지 그런 테스트도 합니다. 각 마이너에 올라와 있는 팬딩트랜잭션들이 다른 모든 마이너에도 올라와 있는지 확인하지도 않고, 또 개별마인너가 별도로 로컬에서 만든 트랜잭션을 추가하는 것에 대해서 다른 노드가 시비를 걸 기준도 이유도 없습니다.

    이런 설명을 아무리 반복해도, 답은 그냥 마이너도 임의로 선택할 수 있는 트랜잭션은 한정되어 있으니 문제없다 이렇게 하시면, 도대체 누가 현실과 데이타를 외면하는 사람입니까?

    저 역시 점점 더 무의미한 공허함이 쌓이는군요.
  • ?
    @atomrigs
    네.
    감사합니다.

    지적하신 면이 제게 있었네요.
    좀 쉽게 보였거든요.

    몇번 이런 대화를 더 하면, 뭐가 나올 것 같습니다.
    님이 공격을 하면 제가 회피할 대안을 내보죠.

    지금은 바빠서요.
    다른 대안을 생각해보고 올리겠습니다.
  • ?
    @atomrigs
    잠시 생각을 해보았습니다.

    님이 말씀하신 "(1)블럭을 만드는 노드가 블럭해쉬값을 결정할 수 없도록 하는 것."과 "(2) 기준해쉬값을 예측불가능한 완전히 랜덤한 방법에 의해 구하는 방법"은 이전 블럭을 만든 주소를 하면 됩니다.

    즉 이전 블럭을 만든 주소를 해쉬값으로 변환하여 이것을 기준해쉬로 사용하면 됩니다.
    기준해쉬를 이전 블럭의 해쉬값이 아닌, 이전 블럭을 만든 주소를 가지고 만드는 방법입니다.

    이경우, 주소는 바꿀 수도 없고, 또한 블럭을 만드는 주소가 랜덤하게 변하게 되니 랜덤성도 가지고 있어서 좋게 보이는 군요..

    어떻게 보시는가요?
  • @loum
    쉽게 해킹이 됩니다.
    어택커가 셋트로 주소그룹을 만들면 되기 때문입니다.
    첫번째 블럭을 만든 주소가 다시 기준해시값의 인풋이 되니,
    이에 맞게 주소를 시리얼로 생성해두면 됩니다.
    마찬가지로 각 블럭에 들어갈 트랜잭션은 어택커가 미리 조립한 것을 집어 넣으면 되구요.
  • ?
    @atomrigs
    음..
    좀 더 생각을 해보고요..
  • ?
    @atomrigs
    일단 얘기를 종합해보면,

    다음 블럭을 만드는 지갑 주소가 이전 블럭의 해쉬값 또는 주소로 랜덤하게 선정이 된다고 해도,
    1) 블럭을 만드는 주소를 무한대로 만들 수 있기 때문에 다음 블럭을 만드는 주소를 연달아 만들어 놓을 수 있고, (물론 일정 코인 수를 일정기간 예치해야 하지만요..)
    2) 다음 블럭을 만드는 지갑주소도 거래데이터를 추가하는 방법으로 자기 지갑의 주소에 유리한 블럭해쉬값을 만들 수 있어서 같은 노드에 있는 주소가 연달아 블럭을 만들 가능성이 있다는 것으로 생각됩니다.

    * 해결방법 1.
    위 문제 중 특히 1)번이 문제가 되는 것으로 이야기를 하신 것으로 보입니다. 이를 해결하기 위해서,
    1)먼저 db에서 블럭에 참여할 수 있는 주소 중 약 2~3배정도가 자신이 하나의 노드이다는 것을 확인할 수 있는 UUID, 또는 CPU 번호 등을 네트워크에 전파를 함.

    노드당 하나의 주소만 블럭생성에 참여하기 위한 제한조건임

    하나의 노드를 특정할 수 있는 것이면 UUID 또는 CPU 번호 등 어떤 것 중에서 하나를 네트워크에 전파를 시키면 됨

    2) db는 네트워크에서 전파된 주소의 UUID 등을 기록해두고, 노드의 지갑에서 가장 많은 코인을 가진 단 하나의 주소만이 블럭생성에 참여하는 권한을 줌.

    어떤 문제점이 있을까요?
  • @loum
    UUID, CPU 번호등 노드쪽에서 변조해서 보낼 수 있는 것으로 알고 있습니다.
    설사 아니라고 해도 클라우드에서 노드하나 만든는데 몇불안됩니다.
  • ?
    @atomrigs
    그렇다면, 저는 dpos도 pos도 이런 특성을 비슷하게 가지고 있는 것으로 생각하고 있었는데요.
    아닌가요? 이들은 이런 위험이 제 방식보다 적나요?
  • ?
    @atomrigs
    네..

    감사합니다.

    좀 더 방법을 연구해보겠습니다.
  • ?
    @atomrigs
    해결 방안을 잠깐 생각해보았습니다.

    제 알고리즘에서 문제가 생긴 부분은 '일정량의 코인에게 블럭 생성기회를 준다'는 곳에 있는 것이라는 잠정 결론이 생각이 났습니다.

    따라서 알고리즘을 바꾸어서, 코인수가 많은 지갑의 주소에게 블럭 생성기회를 더 주는 것으로 바꾸어보았습니다.

    이것은 지갑을 임의적으로 만들 필요를 없애기 위한 방법이며, 임의적으로 여러개의 지갑을 유지하면 불리하게도 할 수 있습니다. (아래 부분 참조)

    기준 해쉬까지는 같습니다.


    바뀐부분
    ************

    기준해쉬와 가까운 주소로 정렬하여서 해쉬값의 리스트를 만듭니다.
    1등 기준해쉬와 제일 가까운 주소의 해쉬값
    2등 기준해쉬와 2번째 가까운 주소의 주소 해쉬값
    ..... 등으로 리스트가 만들어질 것입니다.

    이것을 '기준해쉬 리스트'라고 부르도록 합시다.

    그리고, 각 지갑의 코인수가 많은 순서로 정렬하여서 리스트를 만듭니다.
    제일 많은 코인을 가진 지갑주소가 1등이 되고, 두번째 많은 코인을 가진 지갑주소가 2등이 됩니다.

    1등 코인이 제일 많은 주소
    2등 코인이 두번째로 많은 주소
    .... 등으로 리스트를 만들고 이를 '코인수 리스트'라고 합시다.

    그리고 '기준해쉬 리스트'와 '코인수 리스트'에서 같은 주소에 있는 등수를 더합니다.

    즉, 특정 주소의 경우 '기준해쉬 리스트'에서 3등이고, '코인수 리스트'에서는 10등이라면 이 주소는 3+10 = 13입니다.
    이와 같이, 다른 특정 주소의 경우, '기준해쉬 리스트'는 1등이고, '코인수 리스트'에서는 100등이라면 이 주소는 1+ 100 = 101이 됩니다.

    또한 두 리스트에 가중치를 다르게 할 수 있습니다.
    즉, 지갑을 여러개로 쪼개면 불이익이 가도록 코인수 리스트의 등수에 0.9를 곱하여서, 코인수 리스트가 더 중요하게 만드는 것입니다.

    이런 방법으로 위의 13, 101을 정렬하여 작은순으로 '최종 순위리스트'를 만들고, 이 중에서 가장 작은 값을 가진 주소가 블럭을 만드는 것입니다.

    이런 방법은 코인을 많이 가진 지갑이 더 많은 블럭 생성기회를 얻을 수 있고, 더불어 지갑을 여러 개로 쪼개는 것이 좋지 않은 결과가 되도록 한 것입니다.

    어떻게 생각하시는지 알고 싶습니다.
  • @loum
    점점 더 POS 의 기본 출발점에 접근하시는 것 같군요.

    "블럭생성권을 가질 확률은 코인지분율에 비래한다"

    이것을 어떻게 구현할지 또 어떤 조건을 더할지에 따라 여러가지의 POS 모델들이 나오겠지요.
    DPOS 로 POS 의 한 형태이구요.

    제안하신 방법들에 대해 더 구체적인 논의를 하기 이전에 왜 이런 모델을 개발해야 하는지 또 목표가 무엇인지가 분명해져야 될 것 같습니다.

    기존에 나와 있는 솔루션들보다 개념적으로 왜 보안성과 효율성면에서 이 방법이 더 나은것인지를 다시 한번 정립해보시기를 권합니다.

    만일 비교출발점을 DPOS 로 잡는다면
    DPOS 가 10초마다 블럭을 생성하고 추가적인 컨펌수가 전혀 없이 거래를 완료할 수 있는 반면, 새로 만들려는 모델은 추가적인 컨펌없이 이 시간을 더 단축할 수 있는지.
    또는 DPOS 의 보안성의 취약점은 이러한 것이 있는데, 새 방법은 이것을 줄일 수 있는지.
    앞으로 트랜잭션들이 급격히 늘어날때 스케일링면에서 더 유리한 이유가 있는지,
    등등에 대한 개념적 검토가 필요하다고 생각합니다.
    DPOS 역시 완벽하지도, 가장 이상적인 모델도 아니고, 그 외에 여러가지 방식으로 POW/POS를 개선하는 모델들과 실험들이 많은데, 이런 기존의 시도들과 비교한 경쟁포인트가 있어야 의미가 있지 않을까요?

    ====================

    그리고 위에서 다시 재정리한 모델은 여전히 더 생각해야 될 점들이 있습니다.

    1) 기준해시값 설정문제가 여전히 해결되지 않고 있습니다.
    블럭설정권이 코인보유량에 비례한다는 로직때문에 이전보다는 해킹이 더 어려워졌지만, 지금도 기준해시값을 미리 예상하거나 콘트롤 할 수 있다면, 51% 보다 훨씬 적은 코인량으로도 연속적 블럭생성을 할 수 있을 것 같습니다.
    얼만큼의 코인이 필요할지는 코인의 분포에 따라 다르겠지요.
    기준과 비교해서 가장 가까운 값을 구한다는 이 방법론이 저는 근본적으로 문제를 어렵게 만든다고 봅니다.

    2) 액티브한 노드선정문제
    블럭생성시 불필요하게 액티브하지 않는 노드로부터 블럭을 기다리다 타임아웃되는 가능성을 최대한 낮추려면, 위의 순위표가 작성될 때 액티브한 노드도 추정되는 것들로만 구성하는 것이 바람직하겠지요.
    상위권에 있는 노드들이 일정한 주기로 블럭체인에 자신이 액티브하다는 것을 표시할 수 있는 빈 트랜잭션을 날려주면 되지 않을까도 싶습니다. DPOS에서 delegate 의 activity 를 어떻게 추적하는지 살펴볼 필요가 있을 것 같네요.
    delegate 마다 reliability를 트랙킹도 합니다.
  • ?
    @atomrigs
    네..
    POW, POS는 알고리즘 상으로 누가 빠른가라는 경쟁을 해서, 포크의 가능성이 항상 열려있습니다.
    또한 pos는 coinage를 사용하기 때문에 timestamep의 변조가능성이 열려 있는 것으로 보입니다. (확실치 않음)

    이런 면에서는 제 방법은 dpos에 좀 가까운 방법입니다.
    제 방법은 다음의 특징이 있습니다.
    1) 일반적으로 포크가 생기지 않는다. (예외적으로 네트워크가 분리된 경우를 제외함)
    2) 경쟁적인 계산을 하지 않는다.
    3) 블럭의 용량이 적다. (이것은 DPOS의 raw 데이터를 보면 좀 리던던시가 있어보입니다.)

    일단, 제 방법은 코인수에 따라서 블럭생성기회가 다르기 때문에 이점은 pos와 비슷합니다.
    하지만, 제 방법은 랜덤성 + 코인수에 따라서 블럭생성 권한이 분배된다는 차이는 있습니다.

    그리고, dpos는 순서대로 블럭을 생성하므로, 저와 같이 코인수에 따라서 블럭생성기회에 차이가 나지 않습니다.

    제 방법이 비교를 통해서 하기 때문에 랜덤성이 일부 제한된다는 것에는 동의합니다.
    따라서, 랜덤성 + 변조가능성이 없는 기준점을 찾는 노력은 계속할 것입니다.

    하지만, 저는 제 방법이 해킹에 대한 방어는 성공한 것에 만족을 하고 있습니다.
    이것이 제일 원칙이기 때문입니다.
  • ?
    @loum
    아래는 mkimid님이 저의 제안서에 다신 댓글입니다.
    지금 하고 계신 작업(PoS 비슷한 알고리즘)에 도움이 될 듯하여 첨부합니다.


    ============================================================================



    어떠한 P2P 컨셉을 써도 51% 어택을 피할수 없습니다. 단지, 51%를 확보하기 쉬울지 아닐지가 이슈일 뿐이라고 생각합니다.
    마스터 노트 형태로 승인 서버를 줄이는 일은 오히려 어택 가능성을 높이게 됩니다, 단지, 서버를 랜덤으로 롤링해서 최대한 어택을 어렵게하는 방법만 있습니다.
    예를 들어 승인 서버를 6개를 요구하고 현재 동작 서버가 100개라면 랜덤롤링에 의해서 6/100*5/99*4/98*3/97*2/96*1/95= 1/60M 수준으로 낮출수는 있습니다. 물론 해당 서버수가 적다면 예를 들어 20개? 그럼 1/20만 정도로 확율이 낮아지죠. 만약, 해커가 랜덤 VPN과 다중 어드레스로 가상 대몬을 수십게 만들어 버리면 어택은 너무나 쉬워집니다.
    이게 기존의 PoS 또는 슈퍼노드의 단점이고 이 때문에 매이져코인들은 PoS 자체를 신뢰하지도 지원하지도 않습니다.
    결국은 공인(?)된 제삼자가 시그니쳐를 완성해줌으로해서 코인이 유효하게 된다라는 것입니다.
    결국 소위 익스체인진와 차이가 없는다는 점이 어려운점 같습니다.
  • @drjoon
    어떤 로직도 51% 어택은 막을 수 없다는 것은 논리적으로 너무나 당연한 것 아닙니까?
    그 51%가 어떤 51%인지가 문제고 말씀대로 얼마나 획득이 쉬운가가 문제죠.
    사실 빗코도 51% 보다 더 작은 해쉬로도, 또 PoS 코인들도 51% 보다 더 작은 지분으로도 공격이 가능할 수 있는가 아닌가가 더 현실적인 문제일 것 같습니다.
  • ?
    @drjoon
    감사합니다.

    "서버를 랜덤으로 롤링해서 최대한 어택을 어렵게하는 방법"이란 부분이 제가 접근했던 방법인듯합니다.
    그런데.. 이 랜덤성이 가능할까라는 것에 촛점이 있습니다.
  • @loum
    특징이라고 말씀하신 내용을 보면, DPOS 에 비교한 경쟁우위가 분명히 보이지 않습니다.
    저 역시 DPOS 에 대해 비교적 최근에 접해서 좀 더 구체적인 내용을 살펴봐야 더 확실한 이야기를 할 수 있을 것 같습니다.
    해킹에 대한 방어는 성공했다고 생각하시는 이유도 잘 모르겠습니다.
  • ?
    @atomrigs
    네..
    제가 일단, dpos와 비슷하게 볼 여지가 있다는 것은 지갑의 코인수를 바탕으로 블럭생성권한을 준다는 것인데요..
    하지만, 블럭생성권한을 주는 알고리즘은 완전히 다른 것입니다.
    랜덤성은 dpos가 가진 특성은 아닙니다. 물론 님은 불완전한 랜덤성이라고 보지만요..

    개인적으로 코인수를 블럭생성권한을 위한 기준으로 추가해서 불완전한 랜덤성도 상당부분 개선이 될 것으로 봅니다.

    개인적으로, 해킹에 대한 것은 '어느 정도' 성공했다고 본 것입니다.

    일단, 지갑의 코인수를 바탕으로 하지않으면, 여러 허점이 생기지 않을까는 생각이 들었습니다.
    일단 dpos와 비슷한 정도의 수준은 되지 않을까라고 조심스럽게 생각을 해봅니다.
  • ?
    @atomrigs
    dpos에 관해서 생각을 해보았습니다.

    제 방법 대비 dpos의 단점은
    1) 101개의 delegate(대표)는 모두 똑 같은 블럭생성권한을 가진다.
    이때문에, 제 방법과 비교하면, 제 방법은 코인 수에 따라서 블럭생성권한이 달라집니다.
    따라서, 101개에게 동일한 블럭생성권한을 주는 것보다 제 방법이 조금이 더 보안성이 있습니다. (즉, 더 높은 블럭생성권한을 얻기 위해서는 더 많은 투자를 해야한다는 것입니다.

    2) 추천을 해주는 방법인데요..
    일반적으로 다른사람에게 추천을 잘 해주지는 않을 것 같습니다.
    이와 달리, dpos는 한사람이 여러 개의 주소를 만들고 서로 추천을 해주게 되면 이 들이 모두 블럭생성권한을 얻을 수 있습니다.
    더욱 무서운 것은 이들이 거의 비슷한 추천수를 가지기 때문에 연속적으로 블럭을 생성할 기회를 얻을 수 있어도 보입니다.
    예로, 10%의 지분을 가진 사람이 0.1%의 지갑을 100개를 만들어서 서로 추천을 하면 10%의 추천을 가진 100개의 지갑을 만들 수 있습니다.

    또한, 제 방법이 이전 블럭해쉬값을 이용하는 것은 일정정도 램덤성을 제한받기는 하지만, 크게 제한받지는 않는 것 같습니다.


    *******
    51% 공격을 완전히 방어할 수 있는 추가 알고리즘.

    기존 알고리즘은 동일하다.

    1) 단지 51% 공겍에 대한 방어를 위해서 코인을 생성할 때 만약 1억개의 코인을 발행할 것이라면, 2억 1개를 발행하고, 1억개는 유통이 가능한 코인으로 정하고, 나머지 1억 1개는 유통이 불가능한 코인으로 정한다.

    2) 2억 1개를 가진 지갑은 블럭생성에만 참여하고, 나머지 유통, 전송 등의 기능은 전혀 없도록 코딩한다.

    3) 2억 1개를 가진 지갑은 블럭생성시 이자를 받지 않도록 하거나, 이자를 받더라도 태워없애는 BURN을 시킨다.

    즉 50%의 코인을 가진 지갑은 단지, 블럭생성에만 참여하여서 보안을 높이는 수단으로 사용한다.
    POW와 같이 해쉬경쟁을 하는 것은 이런 방법이 소용없지만, POS 계열은 코인수로 블럭생성권한을 주게 되므로 이런 방식을 51% 공격을 완전하게 방어할 수 있습니다.
  • ?
    @atomrigs
    말씀하신 "첫번째 블럭을 만든 주소가 다시 기준해시값의 인풋이 되니"라는 부분을 좀더 자세히 알려주실 수 있나요?
  • @loum
    기준해쉬값을 이전 블럭을 만든 주소를 해쉬해서 만든다는 내용을 지적한 것입니다.
  • ?
    @atomrigs
    말씀하신 "첫번째 블럭을 만든 주소가 다시 기준해시값의 인풋이 되니,
    이에 맞게 주소를 시리얼로 생성해두면 됩니다."라는 것이 주소만드는 프로그램으로 인접한 주소를 만든다는 것입니까?
  • @loum
    주소값이 서로 인접하다는 뜻이 아니고,
    기준해쉬값 1 = 해쉬함수(주소1)
    주소2 =기준해쉬값 1
    기분해쉬값 2 = 해쉬함수(주소2)
    주소3 = 기준해쉬값2

    이런식으로 주소1, 주소2, 주소3 을 만듭니다.
    주소1이 블럭 생성권을 확보하면,
    주소2의 기준해시값 비교순위에서는 1워를 할테니까, 주소2의 밸런스의 다른 경쟁주소들과 비교해서 밸런스경쟁 순위 몇위를 해야 합계 1위를 할 수 있는지 계산을 해낼수 있을 겁니다. 주소2의 밸런스의 요규량이 그렇게 크지 않아도 될 것으로 생각합니다.
  • ?
    참고로, dpos 지갑을 켜놓으면, 제 노트북에서 팬 돌아가는 소리가 막나요.. 무슨 계산을 하느지도 몰라도 계산량이 좀 되는 것 같습니다. 분명, 블럭생성을 위한 계산은 전혀 아니겠죠.. 제가 delegate 조건이 안되거든요..
default debug random = 0 / type = READ / detected = READ

List of Articles
번호 분류 제목 추천 수 조회 수 글쓴이 날짜
101 개발 [엑스코인]함께할 개발자님들을 모집합니다. 안녕하세요 엑스코인의 왕건일입니다. 엑스코인에서 대한민국 비트코인 시장에 한 획을 긋고 싶은 열정있는 개발자님들을(6분) 모집합니다. 땡글인일경우, 비트코인에 대한 열정과 개발에 대한 ... 3 2894
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
개발 네트워크 부담이 없는 합의 알고리즘 저의 이전 글(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