[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(하드포크)가 필요하다고 결론지었다. 



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

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

# Ravencoin Devs Meeting(06 Dec 2019) 


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

□ Analysis of the meeting by subject 

 ㅇBounty program
  - Tron said devs have talked about extending the deadline because Bounty program currently ends on Dec 19th because they haven't received much feedback yet.

 ㅇEmail List
  - Tron said he just sent out an update and there has beent about 380 sign-ups. He also introduced the imbedded code of the email list for those who run the site.
   1) General update : <iframe src="https://cdn.forms-content sg-form.com/8ec7a872-d599-11e9-ada2-7a44cc589a29"/>
   2) Development update: <iframe src="https://cdn.forms-content sg-form.com/96861d25-0b10-11ea-b9d3-a63f003f1823"/>

  - Tron also mentioned a website that contains relevant information for those who have not yet applied for an email list.
   * https://rvn.postach.io/

 ㅇDevelopment status
  - Blondfrogs said they are going to implent features such as restricted assets, essaging and tags on mainnet by Jan 3rd, 2020 at the latest, but will not rush ahead before Christmas and the year-end holiday season. He also said devs are will working on the wallet GUI update and starting to release smaller updates that will include small GUI additions, hoping to get feedback as the new GUI  is built.
  - WuKong said there are a lot of activities from Asia, especially S. Korea because we're building up Bigger companies by good leaders by good working. And he asked y what features will be on the mainnet for the upcoiming update. Tron, in response, said the network upgrade will include six features, with four features which arerestricted assets, messaging, tags and memos needing forks, while the rest of dividends, rewards don't need forks.


□ Personal Comments

 ㅇNetwork upgrade is coming soon!
  - There is a high possibility that the next network upgrade, originally scheduled for mid-December, will be delayed to January next year. Because currently, restricted assets, messaging, tags, memos, dividends, and rewards are on testnet and bounty program might be extended. Plus, Christmas and year-end holidays are ahead. This network upgrade is very important because it embodies the major features of Raven platform on mainnet and we hope that they will be implemented well without any problems even if there is a delay.
  - In the past, I had many complaints about delays in the implementation schedule of projects that I was also interested in. So I began to go through their devs meetings to find out the reason of delays, and I thought it was natural to delay it in the end. Because many people are cooperating little by little because of the nature of open source, it is difficult to even set a deadline, let alone meet the deadline technically and timing. Of course, 'delay for delay' should be avoided, but 'delay for better tests' should be accepted naturally by the community.

 ㅇRaven flies away in 2020!
  - Bitcoin, which was created based on blockchain at a time when the U.S. took the lead in printing money after the 2008 global financial crisis, came into the world in early January 2009 when it was in the midst of a global Great Recession. Nine years later, Raven was born by diverging from Bitcoin in early January 2018 during the Great Recession of coinmarket, which came after the all-time coin boom in 2017. Just as Bitcoin was launched during the global Great Recession to replace existing currencies and systems, Raven came with great potential to expand the base of blockchain and cryptocurrency, as did Bitcoin and Ethereum before.
  - Those great coin projects have been developed as assets of tremendous value, with enthusiastic developers and their users and supporters who have recognized their values, even if the beginning was feeble. Raven will implement key features on mainnet later this year or early next year, and will be judged on how much potential it will emit afterwards. As it has been, it may face many obstacles as it grows bigger, but it is hoped that devs, users and communities will gather to maximize its potential 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.


(한국어 버전)

□ 소재별 회의 내용

 ㅇ바운티 프로그램
  - Tron은 바운티 프로그램이 현재로써는 12월 19일에 마감하지만 아직 많은 피드백을 받지 않았기 때문에 마감시한을 연장하는 것에 대해 논의했다고 말했다.

 ㅇ이메일 리스트
  - Tron은 레이븐 이메일 리스트를 전송하고 있으며 약 380명이 구독신청했다고 말했다.
I just sent out an update. There's about 380 sign-ups
    또한 그는 사이트를 운영하는 이들을 위하여 이메일 리스트 삽입코드를 안내했다.
   1) 일반 업데이트 : <iframe src="https://cdn.forms-content.sg-form.com/8ec7a872-d599-11e9-ada2-7a44cc589a29"/>
   2) 개발 업데이트 : <iframe src="https://cdn.forms-content.sg-form.com/96861d25-0b10-11ea-b9d3-a63f003f1823"/>
  - 아울러 Tron은 이메일 리스트를 미처 신청하지 못한 이들을 위해 관련 정보를 한데 모은 사이트*를 소개했다.
   * https://rvn.postach.io/

 ㅇ개발 현황
  - Blondfrogs는 현재 테스트넷에서 검토중인 제한자산, 메시징, 태그 등의 기능은 늦어도 2020년 1월 3일까지 메인넷에 구현하도록 노력하겠지만 크리스마스와 연말 휴가 시즌 이전에 급박하게 추진하지 않을것이라고 말했다. 또한 그는 현재 작업중인 지갑GUI업데이트에 대해서도 사소한 업데이트를 먼저 시행할것이며 많은 피드백을 받기를 바란다고 말했다.
  - WuKong은 아시아, 특히 한국에서 레이븐 활성화를 위한 많은 활동들이 있다고 말하면서 훌륭한 리더들덕분에 커뮤니티가 계속 커지고 있다고 말했다. 또한 그는 정확히 다가오는 네트워크 업그레이드에 어떤 기능들이 포함되는지 물었다. 이에 Tron은 이번 네트워크 업그레이드에 6개의 기능이 포함될것이며 제한자산, 메시징, 태그, 메모 등 4개 기능은 포크가 필요하고 나머지 배당, 보상 기능은 포크가 필요하지 않다고 말했다.

□ 개인 논평

 ㅇ 네트워크 업그레이가 다가온다
  - 당초 12월 중순으로 예정된 차기 네트워크 업그레이드가 내년 1월로 지연될 가능성이 높아졌다. 왜냐면 현재 제한자산, 메시징, 태그, 메모, 배당, 보상 등의 기능은 문제없이 검토중이지만 12월 19일에 마감될 바운티 프로그램이 연장될수도 있고 크리스마스와 연말 휴가를 앞두고 있기 때문이다. 이번 네트워크 업그레이드는 레이븐 플랫폼의 주요 기능들을 메인넷에 구현하는 것이기 때문에 매우 중요하며 지연을 하더라도 문제없이 잘 이행되기를 바란다.
  - 한때는 필자도 관심있는 프로젝트의 추진 일정이 매번 지연되는 것에 대해 불만이 많았다. 그래서 그 사유를 알아보기위해 개발자 회의나 개발 내용을 나름대로 찾아봤는데 결국엔 지연되는게 어쩌면 당연하다는 생각이 들었다. 왜냐면 오픈소스의 특성상 여러 사람들이 조금씩 협업을 하고 있기때문에 시기적으로나 기술적으로 마감기한을 지키기는 커녕 그 마감기한을 정하는 것조차 어렵기때문이다. 물론 개발자들은 '지연을 위한 지연'은 지양해야겠지만 '더 나은 검증을 위한 지연'은 커뮤니티가 자연스럽게 받아들여야한다고 생각한다.

 ㅇ2020년 레이븐의 비상
  - 2008년 글로벌 금융위기 이후 미국을 필두로 하여 화폐를 마구 찍어내던 시기에 블록체인을 기반으로 탄생한 비트코인은 글로벌 대침체기에 한창이던 2009년 1월 초에 세상에 나왔다. 그리고 그로부터 9년뒤 레이븐은 2017년 역대급 코인붐이후 찾아온 코인시장 대침체기가 한창이던 2018년 1월 초에 비트코인으로부터 분기되어 탄생하였다. 비트코인이 글로벌 대침체기때 기존 화폐와 시스템을 대안하기 위해 출시된것처럼 레이븐은 코인시장 대침체기때 비트코인, 이더리움이 그랬듯이 블록체인과 암호화폐의 저변을 확대할수 있는 엄청난 잠재력을 안고 출시되었다.
  - 그 위대한 프로젝트들은 비록 시작은 미약했을지라도 열정적인 개발자들과 그것들의 가치를 알아본 채굴자, 사용자, 지지자들이 모여 엄청난 가치를 지닌 자산으로 거듭났다. 레이븐은 올해말이나 내년초에 주요 기능을 메인넷에 구현할것이고 이후 그 잠재력이 얼마나 발산할지 심판을 받을 것이다. 여태 그랬듯이 더 크게 성장하면서 많은 장애물을 마주할수도 있지만 앞으로도 개발자, 사용자, 커뮤니티가 뜻을 모아 그 잠재력이 극대화되길 바란다.
 

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

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

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