[Ravencoin] Ravencoin Devs Meeting(20 Dec 2019) // 12월 20일 레이븐 개발자 회의 분석 및 논평 v1.0

# Ravencoin Devs Meeting(20 Dec 2019) 


English Version(한국어 버전은 하단에)

□ Analysis of the meeting by subject 

 ㅇProposal of new algorithm
   - Jeroz shared a link* to the next algorithm proposal for ASIC resistance written by Playhard and Whitefire.
    * Playhard's : https://github.com/Alterhash-Sandbox/RVN-v3/blob/master/whitepaper/Alterhash%20-%20XDag16R%20v1.0.pdf
      Whitefire's : https://drive.google.com/file/d/1w-Sfk9bjRBfAGyBoM277kz_0ifD7kVEZ/view

   - Playhard said his proposal requires proper understanding first and Tron said Playhard's proposal addressed the SPV* wallet issue, adding that we can't require a phone to have 2GB dedicated to validating blocks.
    * SPV(Simplified Payment Verification: A node that stores block and transaction verification itself(Full nodes) by storing all blocks from genesis block to the current block, which is 1 to 3% as compared to a full node without its transactions, but requires the help from full nodes when verifying transactions

 ㅇBug bounty
   - As for bug bounty closed on Dec 19, Tron said we haven't gotten much feedback, good or bad, and no consensus bugs were reported that he's aware of.
   - Push argued that we should extend the bug bounty period because there may be problems we overlooked and there are not enough people looking at yet. Tron added that we could extend the bounty if we think that more time is warranted and are trying to catch bugs before we launch.

 ㅇThe upcoming fork schedule
   - Tron said we will likely set the date to the Jan 3rd, but release binaries on the 6th.
   - Jeroz said he couldn't understand the difference between January 3 and January 6. Then, Tron further explained that the fork will occur after exchanges and clients follows it after the announcement of the binary release on January 6.
   - Tron also set the supporting rate for the miners needed to push for the fork at 1612 blocks(=80%) out of the 2016 blocks, and other devs agreed.

 ㅇLegal fund
   - liqdmetal said he needed a bug reward or legal funding for security audits (if problems with coding causes damage to tokenized assets). Tron explained that legal funds are also needed when lawyers argue ravencoin will not be considered as a security for listing in exchanges.
   * Legal fund: fund that attoneys or lawyers receive for legal action and legal advice. Some legal professionals received some amount of Raven or consulted for free when they claimed that Ravencoin was not a security to be listed in Bittrex.

□ Personal comments

 ㅇRaven Coin Development Roadmap
   - There are a total of seven steps in the development of Ravencoin, which are as follows.
    1) Stage 1: Releasing Ravencoin mainnet - Completed on January 3, 2018
    2) Step 2: Implementing "Assts" -Completed on November 5, 2018
    3) Step 3: Implementing "Dividends/Rewards"
    4) Step 4: Implementing "Subassets & Unique Assets" -Completed on 5 November 2018
    5) Step 5: Implementing "Messaging, OIP and Restricted Assets functions"
    6) Step 6: Implementing "Voting"
    7) Step 7: Compatible mode

   - Except for steps 1, 2, and 4 completed so far and the maintenance steps 7, only steps 3, 5 and 6 will remain. And steps 3 and 5 will be implemented on the main net through the upcoming fork. Considering that the remaining step 6 will be implemented in the first half of 2020, it seems that development of Ravencoin will be almost done in near future. Therefore, the next fork is very important and I will explain once again the fork process described in the November 22 devs meeting.

 ㅇFork process
   - A project that follows Bitcoin Implementation Proposals(BIP), such as Bitcoin and Ravencoin, shall follow BIP9 when soft/hard fork is performed. BIP9 is how it is defined when upgrading to a new version and how much it is supported by the miners, which the network participants can interpret as a vote on a new upgrade. Note that RIP2 has the same function as BIP9 in Ravencoin.
   - Forks according to BIP9/RIP2 have a total of four stages, which are as follows.

   1) Define stage: Devs define the version bits to be planted on the blockheader for signalling and define how many blocks to be supported.
   => The versionbit to be planted on the blockheader for the next fork in RavenCoin is set at 7, and it has yet to be determined how many blocks to which it will be supported.

   2) Start stage: When various criteria are defined in Define stage, a vote is started to check whether support is supported. For your information, voting will be conducted from N Block to N+2016 blocks, taking into account the adjustment of mining difficulty for each block of 2016. Note that if you receive more than 65% of support under RIP2, testnet is activated, and if you receive more than 80%, mainnet is activated.
    => The '1612 block' referred to by Tron at this meeting represents the minimum number of support blocks for fork activation among the 2016 blocks 
for which mining difficulty is adjusted, 80%. In other words, if the binary is announced later and exchanges and clients are ready to upgrade to the latest version, the voting will begin on a specific N block and the primary fork will be completed when the N+2016 block is reached.

   3) Lock-in Phase: With 80 percent (or 65 percent) of support, new upgrade will be locked during another 2016 block for mainnet (or test net) release.
    => Once sufficient support has been obtained from the miners who are participants in Ravencoin network, the final verification period is set through the final cycle, 2016block.

   4) Activate Step: If there is nothing special in Lock-in, the network upgrade is completed as mainnet is activated.
    => If no bug or attack is found during the final verification period, the fork is completed as soon as the last 2016 block is passed.

 ㅇThe expected timing and significance of the next fork
   - Given all this, I expect the next fork to be in February 2020. This is because after the binary was announced on January 6, exchanges and clients prepare for the latest version for three to six weeks, and four-step fork process with a ready-to-up period to upgrade for about three days. The fork schedule has been somewhat delayed, but I hope the fork will be implemented without any further problems.
   - The fork process may not yet be clearly understood, even though I explained twice. Even if you couldn't understand, the more important thing is to support it as a member of the community until the fork. It is very surprising and difficult to develop the network and community in a way that network participants vote directly, compared to the practice of representative democracy in most countries through congress in our real world. We are doing this amazing and difficult task now. That is why we should take seriously the next fork, whose main functions will be implemented on its mainnet soon.


Disclaimer: Since this post was written for the purpose of providing information for investment, please be careful in your investment decision. You cannot copy, distribute, or edit the contents without my permission because it was made based on my own judgment based on the reference data.



(한국어 버전)


□ 소재별 회의 내용

 ㅇ차기 알고리듬 제안
   - Jeroz는 Playhard와 Whitefire가 작성한 ASIC저항을 위한 차기 알고리듬 제안서의 링크*를 공유했다.
    * Playhard's : https://github.com/Alterhash-Sandbox/RVN-v3/blob/master/whitepaper/Alterhash%20-%20XDag16R%20v1.0.pdf
      Whitefire's : https://drive.google.com/file/d/1w-Sfk9bjRBfAGyBoM277kz_0ifD7kVEZ/view
    - Playhard는 그의 제안서에 대하여 우선적으로 올바른 이해가 필요하다고 말했고 Tron은 Playhard의 제안서는 SPV*지갑의 중요성을 일깨웠다면서 모바일로는 블록검증을 위해 2GB는 무리라고 말했다.
    * SPV(Simplified Payment Verification) : 제네시스 블록부터 현재 블록까지 모든 블록을 저장하여 블록 및 트랜잭션의 검증을 자체 수행하는 풀노드(Full nodes)와는 달리 트랜잭션을 제외한 블록헤더만을 저장한 노드로 풀노드 대비 1~3%의 크기를 가져 휴대성이 높지만 트랜잭션 검증때 풀노드의 도움이 필요함

 ㅇ버그 바운티
   - 12월 19일에 마감된 버그바운티에 대해서 Tron은 좋은쪽으로든 나쁜쪽으로든 많은 피드백을 받지 못했고 합의에 대한 버그가 보고되지 않았다고 말했다.
   - push는 우리는 우리가 간과하고 있는 문제가 있을수 있고 아직 충분히 많은 사람들이 살펴보지 않았기 때문에 버그 바운티 기간을 연장해야한다고 주장했다. 이에 Tron은 우리가 더 많은 시간이 필요하다고 생각하면 연장가능하다고 언급하면서 차기 포크 이전에 우리는 버그를 해결해야한다고 첨언했다.

 ㅇ차기 포크 일정
   - Tron은 아직까지는 차기 포크일을 1월 3일로 유지하지만 바이너리(최신버전 프로그램 실행파일)은 1월 6일에 출시할거라고 말했다.
   - 이에 Jeroz는 1월 3일과 1월 6일에 대한 차이점을 이해할수 없다고 말했고
Tron은 잠정적으로 1월 3일이 차기 포크일이나 1월 6일 바이너리 발표 이후 거래소가 그것을 따르고 난 이후에 포크가 일어날거라고 추가설명했다.
   - 아울러 Tron은 포크를 추진하기 위해 필요한 채굴자들의 지지율을 2016블록 중 1612블록(=80%)로 정하였고 다른 개발자들도 동의했다.

 ㅇ법률 자금
   - liqdmetal은 (코드의 문제가 생겨 토큰화된 자산에 피해가 있을 경우) 버그 현상금이나 보안 감사를 위한 법률자금*이 필요하다고 말했고
Tron은 법조인이 레이븐코인이 거래소상장시 증권으로 간주되지 않기 위한 변론을 펼칠때도 법률 자금이 필요하다고 설명했다.
    * 법률자금(Legal fund) : 법정소송, 법률자문 등 법정 비용을 지불하기 위한 자금으로 레이븐이 비트렉트 상장을 위해 증권이 아님을 주장할때 일부 법조인들이 일정 수량의 레이븐을 받거나 무료로 법률자문을 한 바 있음


□ 개인 논평

 ㅇ 레이븐코인 개발 로드맵
   - 레이븐코인 개발에는 총 7개 단계가 있으며 그것은 다음과 같다.
    1) 1단계 : 레이븐코인 메인넷 출시 -2018년 1월 3일 완료
    2) 2단계 : 자산(Assts) 기능 구현 -2018년 11월 5일 완료
    3) 3단계 : 배당/보상(Dividends/Rewards) 기능 구현
    4) 4단계 : 보조자산 & 고유자산(Subassets & Unique assets) 기능 구현 -2018년 11월 5일 완료
    5) 5단계 : 메시징(Messaging), OIP, 제한자산(Restricted Assets) 기능 구현
    6) 6단계 : 투표(Voting) 기능 구현
    7) 7단계 : 호환 모드
 
   - 현재까지 완료된 1, 2, 4단계와 사실상 유지관리 단계인 7단계를 제외하면 3, 5, 6단계가 남아있으며 3단계와 5단계는 다가오는 포크를 통해 메인넷에 구현될 예정이다. 나머지 6단계도 2020년 상반기에 구현될 것을 감안하면 개발측면에서는 레이븐코인이 9부능선을 넘었다고 봐도 무방하다. 따라서 차기 포크는 매우 중요하며 지난 11월 22일 회의 논평에 설명한 포크 과정에 대해서 다시 한번 설명하겠다.

 ㅇ차기 포크 과정
   - 비트코인, 레이븐코인 등 BIP(Bitcoin Imporvement Proposals, 비트코인 개선안)를 따르는 프로젝트는 소프트/하드포크를 할 경우 BIP9를 따른다. BIP9란 새로운 버전으로 업그레이드시 그것을 어떻게 정의하고 채굴자들로부터 그것을 얼마나 지지받는지 확인받는 것으로 네트워크 참여자가 새로운 업그레이드에 대한 투표로 해석하면 된다. 참고로 레이븐코인에도 BIP9와 같은 기능을 지닌 RIP2가 존재한다.
   - BIP9/RIP2에 따른 포크는 총 4단계가 있으며 그것은 다음과 같다.

  1) Define단계 : 개발자들은 지지여부(Signaling)를 위하여 블록헤더에 심을 버전비트를 정하고, 몇 블록부터 몇 블록까지 지지여부를 확인할것인지 정의한다.
   => 레이븐코인의 차기 포크를 위하여 블록헤더에 심을 버전비트는 7로 설정된 상태이며 아직 몇 블록부터 몇 블록까지 지지여부를 확인할것인지 정해지지 않았다.

  2) Start단계 : Define단계에서 여러 기준이 정의되면 지지여부를 확인하는 투표가 시작된다. 참고로 2016블록마다 채굴난이도가 조정되는 것을 감안하여 N블록에서 N+2016블록까지 투표가 진행된다. 참고로 RIP2에 따라 65% 이상의 지지를 받으면 테스트넷이 활성화되고, 80% 이상의 지지를 받으면 메인넷이 활성화된다.
   => 이번 회의에서 Tron이 언급한 1612블록은 채굴난이도가 조정되는 2016블록 중에서 포크추진을 위한 최소 지지블록수를 의미하는 것으로 80%이다. 즉, 추후 바이너리가 발표되고 거래소와 클라이언트가 최신버전 업그레이드 준비가 될경우 특정N블록에서 투표가 시작되고 N+2016블록에 이르면 1차적인 포크가 완료된다.

  3) Lock-in단계 : 80%(또는 65%)의 지지를 받으면 메인넷(또는 테스트넷) 출시를 위해 또다른 2016블록기간동안 새로운 업그레이드를 걸어잠근다.
   => 레이븐코인의 네트워크 참여자인 채굴자들로부터 충분한 지지를 받고나면 마지막 사이클인 2016블록을 거치면서 최종 검증 기간을 둔다.

  4) Activate단계 : Lock-in단계에서 특이사항이 없으면 비로소 메인넷이 활성화되면서 네트워크 업그레이드가 완료된다.
   => 최종 검증 기간에 어떠한 버그나 공격이 발견되지 않으면 마지막 2016블록이 지나자마자 포크가 완료된다.

 ㅇ차기 포크의 예상시점과 의의
   - 이 모든 것을 감안했을때 필자는 차기 포크 시점이 2020년 2월로 예상하고 있다. 1월 6일 바이너리가 발표되고 3주에서 6주동안 거래소와 클라이언트가 최신버전을 업그레이드할 준비기간을 갖고 3일간의 4단계 포크과정이 필요하기 때문이다. 포크 일정이 다소 지연되었지만 아무 문제없이 포크가 이행되길 바란다.
   - 2주전 논평과 이번 논평에 걸쳐 설명했음에도 불구하고 아직 포크과정이 확실히 이해되지 않을수도 있다. 설령 이해되지 않는다해도 중요한것은 포크시점까지 커뮤니티의 일원으로서 그것에 대해 관심을 갖고 지지하는 것이다. 현실세계에서는 대부분의 국가에서 의회를 통해 대의민주주의를 시행하고 있는 것과 비교할때 네트워크 참여자들이 직접 투표하는 방식으로 해당 네트워크와 커뮤니티를 발전시키는 것은 매우 놀라우면서 어려운 일이다. 그 놀랍고 어려운 작업을 우리는 지금 하고 있다. 그 점이 바로 우리가 주요 기능이 메인넷에 구현될 차기 포크를 진지하게 대해야 하는 이유이자 책무이다.


법적 고지 : 본 게시글은, 투자를 위한 정보제공을 목적으로 작성되었기에 투자결정은 신중을 기하여 주시기 바라며, 참고자료를 토대로 본인 판단하에 내용을 추가, 편집 등 작성되었기에 본인의 허락없이 복사, 배포, 편집 등을 할 수 없습니다.

[Ethereum] '제77차 이더리움 개발자 회의' 분석 및 개인 논평(12월 13일) // #77 Devs Meeting Review(13 Dec 2019) v1.0

#77 Devs Meeting Review(13 Dec 2019)


 - Related link : https://github.com/ethereum/pm/issues/140



English Version(한국어 버전은 하단에)

□ Istanbul HF Updates

  ㅇ Istanbul HF completed
    - Hudson mentioned the Istanbul HF successfully completed several days ago, and according to Ethernode, 97% of the nodes are updated. 



□ Muir Glacier Updates

  ㅇ Concern about the difficult bomb
    - Hudson said that Muir glaacier is in last call and we will change that to final, adding the review ended yesterday and no one raised any concerns. 
Tim said some in the Magician pointed out that 4 million blocks daly was too far, and Peter also believed that someone think we all of a sudden delay Ethereum 2.0 by delaying difficult bomb. 

    - Hudson dismissed such comments as misunderstanding of Ethereum 2.0 and said we should mark Muir Glacier EIP final. 
Peter also said it was too late to to start the debate on weather 4 mil or 3.9 mil or however much would be more appropriate, suggesting that we go ahead and it's completely fine to adjust in the next work, if someone is really opposed to it for some reason. 

    - Hudson suggested that since Muir glacier HF will happen on December 31 or January 1 next year, there should be even a light meeting in two weeks.
Peter said let's wait two more days to accurate the forecast of when Muir glacier HF goese, and Hudson said to post about the HF next Thursday. 



□ Berlin HF tentatively accepted EIPs review

  ㅇ EIP-1559*
   * EIP-1559: Away from current inefficient and unnecessary gas costs, this will adjust basic network charges according to network demand, increase cost efficiency, and increase user convenience in gas charge.

    - Rick explained this EIP proposed by Vitalik as follows; It increases stability in gas pricing, has some other useful side effects in terms of removing zero fee transaction, and sets additional gas charges under consensus over basic fee. 
It also simplifies the user experience to facilitate the determination of total gas costs in advance. 

    - When Martin asked about the subject of the base fee, Rick answered that the base fee targets the half-full block. Peter then questioned what would happen if we were to remove the limit on mainnet, saying that there was a gaslimit fixed at 10 million per block on Ethereum mainnet and that it would be likely that the miners keep growing the block under the basic fare system. Rick answered that the gas cost can be adjusted without block gaslimit, and Peter said that it should be important to touch on what happens on a network where we don't have this limit even if we keep the gaslimit for now.

  ㅇ EIP-1962* and EIP-1057**
   * EIP-1962: Proposal to the definition and combination of elliptical arithmetic and runtime, an extension to EIP-1829 and lower working costs than the STATICCAL opcode in EIP-1109.
   ** EIP-1057: It is called ProgPoW and is modified to make the most of commercial GPU resources in order to reduce ASIC's improved efficiency.

    - Devs had technical discussions on the two EIPs and EIP-1962 continued to be discussed in EthMagician and EIP-1057 concluded that HF(Hardfork) was needed in the future.


Disclaimer: Since this post was written for the purpose of providing information for investment, please be careful in your investment decision. You cannot copy, distribute, or edit the contents without my permission because it was made based on my own judgment based on the reference data.




(한국어 버전)

□ 이스탄불HF 업데이트

  ㅇ 이스탄불HF 완료
    - Hudson은 12월 8일 성공적으로 완료된 이스탄불HF에 대해 언급했고, Ethernode에 따르면 97%노드가 업데이트를 완료했다고 전했다. 


□ 뮤어 빙하 업데이트 

  ㅇ 난이도 폭탄 연기에 대한 우려
    - Hudson은 우리가 뮤어 빙하에 대한 검토를 마쳤고 Ethereum Magician에서 의문을 제기하지 않았으므로, 뮤어빙하HF의 EIP를 '마지막승인(Last call)'단계에서 '승인확정(Final)'단계로 바꿀거라고 말했다. 이에 Tim은 Magician에서 몇몇이 4백만 블록 연기가 너무 과한 조치라고 지적했고, Peter 역시 누군가가 뮤어 빙하를 통한 난이도 폭탄 연기를 이더리움2.0연기로 이어질거라고 간주했다고 전했다. 

    - Hudson은 그런 의견들에 대하여, 이더리움2.0에 대한 오해라고 일축했고 뮤어 빙하 EIP에 대해 승인확정을 하자고 말했다. Peter 역시 난이도 폭탄을 연기시킬 블록에 대한 것이나 4백만 블록 연기가 맞는지에 대한 것이나 그것을 논의하기에는 매우 늦었다고 말하면서, 일단 뮤어빙하HF를 진행하되 누군가 근거있는 반박을 하면 향후 조치하면 될것이라고 제안했다. 

    - Hudson은 뮤어빙하HF가 12월 31일이나 내년 1월 1일에 일어날것이므로, 2주 후에 가벼운 회의라도 해야한다고 제안했다. Peter는 뮤어빙하HF가 일어나는 시점의 예측도를 높이기 위해 2일 더 기다려보자고 말했고, Hudson은 뮤어빙하에 대한 글을 다음주 목요일에 게시하자고 말했다.    


□ 베를린HF 잠정승인EIP 리뷰 

  ㅇ EIP-1559*
   * EIP-1559: 현재의 비효율적이고 불필요한 가스비가 드는 방식을 벗어나, 네트워크 수요에 따라 기본 네트워크 요금을 조정하고 비용 효율성을 높이며 가스비지불에 있어 사용자 편의성을 높임.

    - Rick은 비탈릭이 제안한 이 EIP에 대해 다음과 같이 설명했다; 가스비 책정에 안정성을 높이고, 수수료없는 트랜잭션을 없애되 기본요금을 두고 합의하에 추가 가스비를 정한다. 또한 사용자경험을 단순화하여 사전에 총 사용가스비 책정을 용이하게 한다.   

    - Martin이 기본요금의 부과대상에 대해 묻자, Rick은 블록의 절반에 부과된다고 답변했다. 그러자 Peter는 이더리움 메인넷에서는 1000만으로 고정된 블록당 가스상한제한이 있고 또한 기본요금제에서는 블록을 계속 키우는게 채굴자에게 이익이 될거라면서, 블록가스제한이 없어지게된다면 무슨일이 벌어지는지 의문을 제기했다. 그 의문에 Rick은 블록가스제한없이 가스비를 조정하면 된다고 답했고, Peter는 블록가스제한을 유지한다해도 그 블록가스제한이 없을때 네트워크에 어떤일이 발생할지 분석하는게 중요하다고 말했다. 


  ㅇ EIP-1962* 및 EIP-1057
   * EIP-1962: 타원 산술 및 런타임 정의와 결합에 대한 개선안으로, EIP-1829에 대한 확장안이며 EIP-1109에서의 STATICCAL opcode보다 작업비용이 더 저렴.
   ** EIP-1057: ProgPoW로 불리며, ASIC의 향상된 효율성을 반감시키위하여, 상용GPU자원을 최대한 활용되도록 수정.

    - 개발자들은 두 EIP에 대한 기술적 논의를 했고 EIP-1962는 EthMagician에서 계속 논의하고 EIp-1057은 향후 HF(하드포크)가 필요하다고 결론지었다. 



법적 고지 : 본 게시글은, 투자를 위한 정보제공을 목적으로 작성되었기에 투자결정은 신중을 기하여 주시기 바라며, 참고자료를 토대로 본인 판단하에 내용을 추가, 편집 등 작성되었기에 본인의 허락없이 복사, 배포, 편집 등을 할 수 없습니다.

[Bitcoin] 비트코인의 흥망성쇠(3부작) 1부 "역대 주요이슈 분석" // Bitcoin's Rise & Fall(Trilogy) Part1 v1.5

비트코인의 흥망성쇠 (興亡盛衰) □ 에필로그   ㅇ 분석에 앞서     - 그동안 분석가로서 블록체인과 암호화폐가 지닌 기술 위주의 기본적 분석을 해왔으나, 투자자로서 유의미한 시세변동, 시세에 영향을 끼치는 이슈 등에 대한 분석글 작...