Bitcoin Mining - The Byzantine Generals Problem

Bitcoin Newcomers FAQ - Please read!

Welcome to the /Bitcoin Sticky FAQ

You've probably been hearing a lot about Bitcoin recently and are wondering what's the big deal? Most of your questions should be answered by the resources below but if you have additional questions feel free to ask them in the comments.
It all started with the release of the release of Satoshi Nakamoto's whitepaper however that will probably go over the head of most readers so we recommend the following videos for a good starting point for understanding how bitcoin works and a little about its long term potential:
Some other great resources include Lopp.net, the Princeton crypto series and James D'Angelo's Bitcoin 101 Blackboard series.
Some excellent writing on Bitcoin's value proposition and future can be found at the Satoshi Nakamoto Institute.
Some Bitcoin statistics can be found here and here. Developer resources can be found here. Peer-reviewed research papers can be found here.
Potential upcoming protocol improvements and scaling resources here and here.
The number of times Bitcoin was declared dead by the media can be found here (LOL!)

Key properties of Bitcoin

Where can I buy bitcoins?

Bitcoin.org and BuyBitcoinWorldwide.com are helpful sites for beginners. You can buy or sell any amount of bitcoin (even just a few dollars worth) and there are several easy methods to purchase bitcoin with cash, credit card or bank transfer. Some of the more popular resources are below, also check out the bitcoinity exchange resources for a larger list of options for purchases.
Here is a listing of local ATMs. If you would like your paycheck automatically converted to bitcoin use Bitwage.
Note: Bitcoins are valued at whatever market price people are willing to pay for them in balancing act of supply vs demand. Unlike traditional markets, bitcoin markets operate 24 hours per day, 365 days per year. Preev is a useful site that that shows how much various denominations of bitcoin are worth in different currencies. Alternatively you can just Google "1 bitcoin in (your local currency)".

Securing your bitcoins

With bitcoin you can "Be your own bank" and personally secure your bitcoins OR you can use third party companies aka "Bitcoin banks" which will hold the bitcoins for you.
Note: For increased security, use Two Factor Authentication (2FA) everywhere it is offered, including email!
2FA requires a second confirmation code to access your account making it much harder for thieves to gain access. Google Authenticator and Authy are the two most popular 2FA services, download links are below. Make sure you create backups of your 2FA codes.
Google Auth Authy OTP Auth
Android Android N/A
iOS iOS iOS

Watch out for scams

As mentioned above, Bitcoin is decentralized, which by definition means there is no official website or Twitter handle or spokesperson or CEO. However, all money attracts thieves. This combination unfortunately results in scammers running official sounding names or pretending to be an authority on YouTube or social media. Many scammers throughout the years have claimed to be the inventor of Bitcoin. Websites like bitcoin(dot)com and the btc subreddit are active scams. Almost all altcoins (shitcoins) are marketed heavily with big promises but are really just designed to separate you from your bitcoin. So be careful: any resource, including all linked in this document, may in the future turn evil. Don't trust, verify. Also as they say in our community "Not your keys, not your coins".

Where can I spend bitcoins?

Check out spendabit or bitcoin directory for millions of merchant options. Also you can spend bitcoin anywhere visa is accepted with bitcoin debit cards such as the CashApp card. Some other useful site are listed below.
Store Product
Gyft Gift cards for hundreds of retailers including Amazon, Target, Walmart, Starbucks, Whole Foods, CVS, Lowes, Home Depot, iTunes, Best Buy, Sears, Kohls, eBay, GameStop, etc.
Spendabit, Overstock and The Bitcoin Directory Retail shopping with millions of results
ShakePay Generate one time use Visa cards in seconds
NewEgg and Dell For all your electronics needs
Bitwa.la, Coinbills, Piixpay, Bitbill.eu, Bylls, Coins.ph, Bitrefill, LivingRoomofSatoshi, Coinsfer, and more Bill payment
Menufy, Takeaway and Thuisbezorgd NL Takeout delivered to your door
Expedia, Cheapair, Destinia, Abitsky, SkyTours, the Travel category on Gyft and 9flats For when you need to get away
Cryptostorm, Mullvad, and PIA VPN services
Namecheap, Porkbun Domain name registration
Stampnik Discounted USPS Priority, Express, First-Class mail postage
Coinmap and AirBitz are helpful to find local businesses accepting bitcoins. A good resource for UK residents is at wheretospendbitcoins.co.uk.
There are also lots of charities which accept bitcoin donations.

Merchant Resources

There are several benefits to accepting bitcoin as a payment option if you are a merchant;
If you are interested in accepting bitcoin as a payment method, there are several options available;

Can I mine bitcoin?

Mining bitcoins can be a fun learning experience, but be aware that you will most likely operate at a loss. Newcomers are often advised to stay away from mining unless they are only interested in it as a hobby similar to folding at home. If you want to learn more about mining you can read more here. Still have mining questions? The crew at /BitcoinMining would be happy to help you out.
If you want to contribute to the bitcoin network by hosting the blockchain and propagating transactions you can run a full node using this setup guide. If you would prefer to keep it simple there are several good options. You can view the global node distribution here.

Earning bitcoins

Just like any other form of money, you can also earn bitcoins by being paid to do a job.
Site Description
WorkingForBitcoins, Bitwage, Cryptogrind, Coinality, Bitgigs, /Jobs4Bitcoins, BitforTip, Rein Project Freelancing
Lolli Earn bitcoin when you shop online!
OpenBazaar, Purse.io, Bitify, /Bitmarket, 21 Market Marketplaces
/GirlsGoneBitcoin NSFW Adult services
A-ads, Coinzilla.io Advertising
You can also earn bitcoins by participating as a market maker on JoinMarket by allowing users to perform CoinJoin transactions with your bitcoins for a small fee (requires you to already have some bitcoins.

Bitcoin-Related Projects

The following is a short list of ongoing projects that might be worth taking a look at if you are interested in current development in the bitcoin space.
Project Description
Lightning Network Second layer scaling
Blockstream, Rootstock and Drivechain Sidechains
Hivemind and Augur Prediction markets
Tierion and Factom Records & Titles on the blockchain
BitMarkets, DropZone, Beaver and Open Bazaar Decentralized markets
JoinMarket and Wasabi Wallet CoinJoin implementation
Coinffeine and Bisq Decentralized bitcoin exchanges
Keybase Identity & Reputation management
Abra Global P2P money transmitter network
Bitcore Open source Bitcoin javascript library

Bitcoin Units

One Bitcoin is quite large (hundreds of £/$/€) so people often deal in smaller units. The most common subunits are listed below:
Unit Symbol Value Info
bitcoin BTC 1 bitcoin one bitcoin is equal to 100 million satoshis
millibitcoin mBTC 1,000 per bitcoin used as default unit in recent Electrum wallet releases
bit bit 1,000,000 per bitcoin colloquial "slang" term for microbitcoin (μBTC)
satoshi sat 100,000,000 per bitcoin smallest unit in bitcoin, named after the inventor
For example, assuming an arbitrary exchange rate of $10000 for one Bitcoin, a $10 meal would equal:
For more information check out the Bitcoin units wiki.
Still have questions? Feel free to ask in the comments below or stick around for our weekly Mentor Monday thread. If you decide to post a question in /Bitcoin, please use the search bar to see if it has been answered before, and remember to follow the community rules outlined on the sidebar to receive a better response. The mods are busy helping manage our community so please do not message them unless you notice problems with the functionality of the subreddit.
Note: This is a community created FAQ. If you notice anything missing from the FAQ or that requires clarification you can edit it here and it will be included in the next revision pending approval.
Welcome to the Bitcoin community and the new decentralized economy!
submitted by BitcoinFan7 to Bitcoin [link] [comments]

Avalanche has no place in a Bitcoin based system.

Avalanche is a permission based system, unlike Bitcoin. Signing votes is essential with Avalanche. It is necessary even when identity is provided by the communications media, otherwise horrendously inefficient overhead is required. Compare, for example, the overhead of Leslie Lamport’s original solution to the Byzantine general’s problem with exponential overhead in the number of nodes, vs. the improved solution with digital signatures. Both of these versions were for permissioned systems.
Bitcoin mining is not permissioned and this is a key part of building a censorship proof system. Any new miner or group of miners can come in and a would be censor has no way of knowing whom to attack. Once a fixed group of players is required, the basis for Avalanche, this changes. Now all kinds of new attacks by state actors become possible. It is not just the cost and risks of signatures, it is the attack surface. This is true if Avalanche uses proof of work or proof of stake, the problem comes because the power to write to the ledger is backward looking, unlike Nakamoto consensus which keeps no state as to who gets to decide. With proof of work would be attackers have no way of knowing which node to attack to block the system.
When you add Avalanche to Bitcoin in search of a small quantitative improvement, you break Bitcoin’s fundamental qualitative essence. Avalanche has no place in a Bitcoin based system. Avalanche is a fundamentally different animal.
submitted by tl121 to btc [link] [comments]

Round up of Cryptocurrency News #5 Week 03/08 - 09/08

Welcome again to another recap and the first full week of the new month after breaking the downward trend on the monthly!
 
Firstly, from last weeks uptrend we have seen the market consolidate at this level throughout the week with a steady upward climb at the start of the week to a balance out above $11.5k for Bitcoin towards the end. For the market we have a total increase of $17.5B over the week but a 1% decrease of btc dominance moving mainly toward Chainlink and other altcoins.
 
Closing the week we have had some altcoin action, Ethereum breaking $400 midweek but now staying back in a nice channel between $350-$410 since the start of August. But, Chainlink killing it after breaking $10 and currently sitting comfortably above $13!! Other altcoins that have reaped rewards and I'm keeping an eye on are:
I have picked these as i have noticed they are usually the first movers or the biggest gainers after the market goes red. Chasing those quick gains!
 
What about the news for this week?
 
DISCORD LINK: https://discord.gg/zxXXyuJ 🍕 Bring some virtual pizza to share 🍕
Come have a chat, stimulate a discussion, ask a question or share some knowledge. We are all friendly crypto enthusiasts up for a chat, supportive and want to help each other with knowledge and investments!
Big thanks to our Telegram and My Crypto HQ for the constant news updates! The Gravychain Collective: https://t.me/gravychain My Crypto HQ: https://t.me/My_Crypto_HQ
Links
Important/Notable/Highlights:
Special Mentions:
Other:
submitted by IOTAbesomewhere to Gravychain [link] [comments]

CoinEx Token Rating Report by TokenInsight

CoinEx Token Rating Report by TokenInsight
Written by TokenInsight
Published by tokenin.cn

EXECUTIVE SUMMARY

Advantages

  1. The team’s overall technical background is good, and the CTO and CEO of the project have rich experience in related industries;
  2. The current business scope of CoinEx has been expanded, and the development of the public chain has a decisive role in promoting the development of the exchange business;
  3. The project operation information is transparent, and the development process is consistent with the road map;
  4. The unlocking schedule is clear, and the token held by the team will be unlocked continuously in the next five years;
  5. The project uses POS consensus mechanism. At present, it has been launched on the main network, and the block time is stable, between 2–3 seconds.

Challenges

  1. It is not clear enough yet whether the trichain operation planning can achieve the project’s development goals;
  2. There is limited information on implementation details about cross-chain and other related technologies, and the development status needs to be assessed based on the later project development disclosure information;
  3. The team currently hold a large share of the token, hence the distribution of tokens is relatively concentrated;
  4. There are few application scenarios for project tokens, and more ecosystem scenarios need to be developed;
  5. As a deflationary token, CET needs to be balanced by dealing with the contradiction between public chain users and token holders.

Outlook

The development of CoinEx Chain contributes to the future development of CoinEx’s centralized and decentralized exchanges; the concept of trichain operation simplifies the functions of each chain, improving their performance. At present, there are few exchanges working on the public chain, and no fierce competition has occurred.

Conclusion

Considering the status and development prospects of the project, TokenInsight gives CoinEx a rating of BB with a stable outlook.

1. Multidimensional evaluation


2. Project analysis

CoinEx (CoinEx Technology Limited) was established in December 2017 and is headquartered in Hong Kong, China. It is a sub-brand of the ViaBTC mining pool. At present, CoinEx’s business scope includes CoinEx exchange, CoinEx public chain, and CoinEx decentralized exchange. The current development focus of the CoinEx platform are public chain and exchange. The main purpose of the public chain is to build a decentralized exchange (DEX) infrastructure and an ecosystem around DEX.

CoinEx business structure,Source: CoinEx; TokenInsight

2.1 Introduction

“ CoinEx Chain uses the parallel operation of three chains which are DEX, Smart, and Privacy, as well as cross-chain technologies to create a rich decentralized exchange ecosystem and blockchain financial infrastructure.
The core of CoinEx’s early business was the exchange, consisted of two major categories which were spot and derivatives trading. Currently, there are 123 trading currencies online, covering 302 trading pairs. On June 28, 2019, CoinEx released the CoinEx Chain public chain white paper, aiming to build a decentralized trading system (CoinEx DEX) with community-based operations and transparent transaction rules, and providing user-controlled asset trading scenario by the highest technical standards in the industry; CoinEx Chain has become another development focus of CoinEx. CoinEx Token (CET), which was originally a native token of the CoinEx exchange, will also be developed mainly as a built-in token of the public chain.
CoinEx Chain is a public chain based on the Tendermint consensus protocol and Cosmos SDK, and it uses POS mechanism. CoinEx Chain plans to support 42 nodes when the project starts, and any entity in the ecosystem can participate in the validator’s campaign by staking CET. CoinEx Chain will use the new block reward and the transaction fee contained in the block as the reward for running the node.
CoinEx Chain has developed three public chains with different positioning and different functions in order to meet the needs of blockchain transactions for transaction performance, smart contracts, and privacy protection at the same time. They operate in parallel and collaborate with each other through cross-chain technology. At present, the block time of the public chain is between 2–3 seconds. According to the observation of TokenInsight, the block time is stable, but the number of transactions through the CoinEx public chain is still low at present, the number of transactions in 24 hours is about 30,000; The TPS on public chain disclosed by CoinEx can reach up to 1500 per second.
CoinEx Chain uses a trichain parallel model to build a more vibrant ecosystem around DEX. The three chains are DEX public chain, Smart public chain, and Privacy public chain, respectively responsible for decentralized transactions, smart contracts, and on-chain privacy protection.
CETs that need to participate in complex financial contracts can be transferred to the Smart public chain through the DEX public chain, then moved back to the DEX public chain after that. CET tokens that need to participate in token confusion can also be carried out through the privacy transaction of the Privacy public chain, and can eventually be returned to the DEX public chain. The three public chains are responsible for their respective duties, and they are interconnected through the cross-chain technology through the relay mechanism. In addition to ensuring their respective transaction processing speed and functional attributes, they can also jointly provide richer and safer functions, and synergistically constitute the CoinEx decentralized public chain ecosystem.
In addition, CoinEx Chain also supports any participant to issue new tokens on the chain and create new trading pairs for the issued tokens. CoinEx Chain guarantees the circulation of new tokens by establishing a trading pair between the new token and CET.

2.2 Component architecture

“ Tendermint Core and Cosmos SDK have improved the performance and operation capability of the blockchain. The SDK packaging reduces the consideration of non-related logic, hence reducing the development complexity.
CoinEx Chain is based on Tendermint Core and Cosmos SDK, both of which have brought a big boost to the development of CoinEx public chain performance. Cosmos-SDK will implement the application logic of the blockchain. Together with the Tendermint consensus engine, it implements the three-layer architecture of the CoinEx public chain: the application layer, the consensus layer, and the network layer.
Tendermint
Tendermint is based on the state machine replication technology and is suitable for blockchain ledger storage. It is a list of transactions making consensus with Byzantine fault tolerance, the transactions are executed in the same order, and eventually the same state is obtained. Tendermint can be used to build various distributed applications.
Cosmos SDK
Cosmos-SDK is a blockchain framework that supports the construction of multiple assets with a consensus mechanism of POS (Proof of Stake) or POA (Proof of Authority). The goal of the Cosmos SDK is to allow developers to easily build custom blockchains from 0, while enabling the interaction with other blockchains.
Cosmos-SDK is a blockchain framework that supports the construction of multiple assets with a consensus mechanism of POS (Proof of Stake) or POA (Proof of Authority). The goal of the Cosmos SDK is to allow developers to easily build custom blockchains from 0, while enabling the interaction with other blockchains. The blockchain development framework Cosmos SDK implements general functions such as account management, community governance, and staking in a modular form. Therefore, using the Cosmos SDK to build a public chain can simplify development procedures and facilitate operation. Tendermint is a fixed protocol in a partially synchronized environment, which can achieve throughput within a delay range of the network and each process itself. The CoinEx public chain is developed based on both, improving the performance and operability of the blockchain. The SDK packaging further reduces considerations of non-related logic and reduces the complexity of developers creating. The two components of Tendermint and Cosmos SDK are connected and interacted through the Application Blockchain Interface.
Cosmos SDK and Tendermint interworking structure,Source:CoinEx; TokenInsight

2.3 Project public chain planning

The development plan of the CoinEx public chain is to create a series of public chains with specific application directions, including:
  1. DEX public chain: solve the problems of lack of security and opacity that are widely criticized by centralized exchanges at present; aim to build a transparent, safe, and permission-free financial platform; restore the experience of central exchanges to the greatest extent;
  2. Smart public chain: a public chain that specifically supports smart contracts and provides a platform for building complex financial applications;
  3. Privacy public chain: mainly provides transaction amount, account balance, and information protection and the hiding of both parties to the transaction.
In order to achieve the performance of each specific application public chain, each public chain in the CoinEx public chain focuses on the development of a certain function. For example, in order to improve the transaction processing speed of the DEX public chain, the DEX public chain only supports the necessary functions and does not support smart contracts. To achieve the smart contract function support, cross-chain connection between the DEX public chain and the Smart public chain is required.

2.4 Operation analysis

“ The CoinEx platform publishes monthly ecosystem reports with high transparency; but the monthly reports are limited to contents about transactions and development, and lack progress in ecosystem and community construction, making them relatively simple.
2.4.1 Disclosure of ecosystem information
Operational risks have a direct impact on platform users. Whether platform operations are smooth and whether there is transparency are issues that platform users care about.
The CoinEx platform was established in 2017 and has around 3 years of development. It is also one of the platforms that has been developing for a long time in the exchange industry. It has obtained a digital currency trading license issued by the Estonian Financial Intelligence Unit (FIU), and the platform’s compliance is guaranteed to some degree.
The actual operation of the CoinEx platform will be displayed in the form of ecosystem monthly reports. The monthly report contains various types of content such as online currencies, new activities, plans for the next month, and ecosystem dynamics. It involves multiple business dimensions including the CoinEx exchange, CoinEx Public Chain, and CET token.

https://preview.redd.it/4mt0999ere551.png?width=631&format=png&auto=webp&s=cba27a7c90275f4c033bdd2445a72e6f294265e8
Snippet of a CoinEx ecosystem monthly report,Source: CoinEx; TokenInsight
2.4.2 Roadmap
CoinEx Chain released its development roadmap for the four quarters of 2020 in January 2020. The roadmap shows that CoinEx Chain will undergo major updates on smart contracts and DEX hard fork upgrades. The project roadmap is basically planned on a monthly basis, with a clear plan and a clear direction of development.
CoinEx Public Chain 2020 Development Roadmap,Source: CoinEx; TokenInsight
In addition to the development route planned in the roadmap, CoinEx public chain also discloses its goals for next month in its monthly ecological report. The project’s main net was launched online in November 2019. According to TokenInsight’s review of the development of CoinEx public chain from January to April and the disclosure of the project’s ecosystem monthly report, the project’s plan about development of the smart contract Demo in February failed to be completed as planned; the project completed launching of the new version of the blockchain browser and the Asian Atlantis upgrade; the smart contract virtual machine development was planned to be completed in April, but the progress related to supporting cross-chain agreements was not disclosed yet.
Overall, the project’s development route planning is clear, and the project’s development schedule is consistent with the plan, but there are still some discrepancies. Operation and development information is disclosed every month, and information transparency is high.

3. Industry & Competitors

The earliest origin of the exchange layout in the public chain field began in early 2018 when Binance released an announcement to start the development of the Binance Public Chain officially. In June of the same year, Huobi announced at its brand upgrade conference that it will combine the technical capabilities of the Huobi technical team and the community developers to develop the Huobi public chain called “Huobi Chain”. In December of the same year, OK Group announced the launch of its self-developed public chain OKchain, dedicating to provide underlying technical support and services for startups stationed in B-Labs.
The successful launch of the public chain brings huge strategic significance to the exchange, which can not only improve the performance of the existing business of the exchange but also achieve further expansion of its influence. As one of the most important blockchain infrastructures, the public chain can benefit the exchanges behind it.
As a platform for developing public chain technology exchanges, CoinEx’s main competitors in the field of public chain development include Binance, Huobi, and OKEx. Although they are all exchange platforms for deploying public chains, the above four are different in terms of specific functions, economic models, and critical points of the public chain.

3.1 Development progress comparison

In 2019, Binance became the first exchange to launch a public chain among all digital asset exchanges, and its main product is Binance exchange (DEX). In April 2020, Binance announced the launch of a second smart contract chain, using Ethereum’s virtual machine, so that developers can build decentralized applications without affecting the performance and functionality of their original chain.
OKEx launched OKChain’s testnet in February 2020 and completed open source two months later. OKChain is designed as the basis of large-scale blockchain-driven business applications, with the characteristics of source code decentralization, point-to-point, irreversibility, and efficient autonomy.
Huobi released Huobi Chain for the first time in July 2019, the code is open source, and the testnet was released in February 2020. As a “regulator-friendly financial blockchain”, Huobi Chain focuses on providing compliance services for companies and financial institutions.
The CoinEx public chain officially completed the main online launch in November 2019 and completed the new block browser’s launch in March 2020. On April 3, 2020, CoinEx DEX uploaded the underlying code to Github to achieve open source. The CoinEx public chain is more inclined to build a full DEX ecosystem to achieve a one-stop solution for issuing, listing, storing, and trading. The long-term goal is to create a blockchain financial infrastructure.

3.2 Comparison of economic models

At present, the exchange is more inclined to use its existing platform currency as the native token of the public chain in the construction of public chain ecology. CoinEx’s CET, Binance’s BNB, and Huobi’s HT all fall into this category. OKEx is the only exchange that issues new tokens for its OKChain, which means OKT is the only ‘inflation token’ in the exchange’s public chain, while CET, HT, and BNB are all deflationary.

3.3 Decentralization of public chain

The initial number of CoinEx public chain verification nodes is 42, which is currently the most decentralized among all exchange public chains, and able to take both efficiency and decentralization into account; OKChain also currently has a relatively high degree of decentralization in the exchange public chain (21 verification nodes), its nodes have a high degree of autonomy; by contrast, Binance still firmly controls the operation of nodes and transactions; In terms of encourages cooperation between regulators and the private financial aspects, Huobi provides a lesser degree of decentralization. Huobi Chain uses a variant of the DPoS consensus algorithm to provide functions such as “supervision nodes”, allowing regulators to become validators.
Comparison of some dimensions of CoinEx, Huobi, Binance and OKEx public chain,Source: TokenInsight

4. Token Economy

CoinEx Token (CET) is a native token of the CoinEx ecosystem. It was issued in January 2018. Token holders can enjoy some user value-added services within the ecosystem. Currently, it is mainly used as a native token on the CoinEx Chain. As of 11 am on April 23, 2020, the current circulation of CET tokens in the market is 3,215,354,906.31, with a total of 5,842,177,609.53. CET tokens will not be further issued or inflated. Currently, daily repurchase and quarterly destruction are carried out. The repurchase destruction dynamics can now be tracked real-time on the CET repurchase system on the platform.

4.1 Token Distribution

The CET token used to be based on the ERC-20 token developed by Ethereum. Since the CoinEx Chain mainnet was launched in November 2019, some ERC-20 CET tokens have been mapped to the mainnet CET, and the rest of the CET will be mapped before November 10, 2020. CET holders need to deposit ERC-20 CET to the COinEX exchange, and the exchange will conduct the main network mapping.
At present, CET is mainly circulated in the form of mainnet tokens, and only a small portion of ERC-20 CET has not been mapped. The distribution of token holdings currently circulating on the mainnet can be seen in the figure below. At present, the number of tokens held by the top ten holders accounts for about 60.44% of all mainnet CET tokens.
Distribution of CET token holding addresses,Source: Etherscan; TokenInsight
The following figure shows the initial distribution of tokens after the mainnet mapping preset by CoinEx. From the initial distribution map of CET, it shows that, after mapping, a large portion of CET remains concentrated in the hands of the team (31%), and the actual number of CET circulating in the market only accounts for 49% of the total.
The initial distribution of CET token,Source: CoinEx; TokenInsight
After the main net mapping, the 31% of the total CET (1.8 billion) held by the team will be gradually unlocked in the five years from 2020 to 2024, and 360 million CET will be unlocked each year. By 2024, the CET held by the team will be completely unlocked. From the current CET dynamics, the CET share held by some teams has been used for destruction purposes to achieve the purpose of CET austerity. If the frozen 1.8 billion CET held by the team are used for similar purposes, the development of CET and its platform can benefit from it.
Team’s CET unlocking plan,Source: CoinEx; TokenInsight

4.2 Token economic model

4.2.1 Deflation mechanism
Since the CET token went online in January 2018, CoinEx has increased the circulation of CET through airdrops, transaction fee refunds, operation promotion, and team unlocking. As one of the existing platform coins with long development time, the deflation mechanism of CET token has undergone a series of changes with the development of the industry. In 2018, when the concept of coin-based mining prevailed, CET used transaction mining, stake mining, and pending order mining, which were cancelled in October, December and, April respectively of the following year.
The repurchase and destruction model currently used by CET was updated by CoinEx on April 11, 2020. The original CET quarterly repurchase and destruction policy of the platform will be adjusted to daily repurchase and quarterly destruction. After the implementation of the daily repurchase policy, CoinEx will take out 50% of the daily fee income for CET repurchase in the secondary market and implement quarterly destruction until the total remaining circulation is 3 billion (currently about 5.8 billion).
At the same time that CoinEx updated the repurchase and destruction plan on April 11, the platform also launched a page dedicated to displaying CET repurchase information, so that users can clearly understand the progress of CET repurchase and destruction.
As of April 23, 2020, the platform has destroyed 4,157,822,390.46 CET tokens, accounting for 41.6% of the initial total issuance. At the end of January 2019, it had destroyed 4 billion CETs (single destruction volume peak) at the end of this quarter. The number of CETs to be destroyed is 3,422,983.56.
CET historical destruction data,Source: CoinEx; TokenInsight
4.2.2 Application scenarios
The current usage scenarios of CET are discounted platform transaction fees, VIP services, special activities rights and interests, CoinEx Chain internal circulation fuel, and use of external scenarios.
Deduction and discount of platform transaction fees
CoinEx platform users can use CET to deduct transaction fees when conducting transactions within the platform. At the same time, using CET to pay transaction fees can enjoy the exclusive preferential rates provided by the platform.
CET fee discount amount,Source:CoinEx; TokenInsight
VIP service
Holding a certain number of CETs can make a user become a platform VIP user. Users can also use CET to purchase platform VIPs to obtain corresponding privileges such as discounted rates, accelerated withdrawals, and exclusive customers.
Special activity rights
CET holders can enjoy special rights and interests in platform marketing activities, such as participating in the airdrop of tokens on the platform or accelerating opportunities for high-quality projects.
CoinEx Chain built-in token
CET will serve as a native token of CoinEx Chain, circulate and serve as fuel in CoinEx Chain, and users can also use CET to invest or trade other digital assets. In addition, CET can also serve as transaction fees and function fees (issuing Token, creating new trading pairs, account activation), etc. in the platform, and users can also participate in the campaign of validators by staking CET tokens.
CET is currently used as a circulation token as well for CoinEx DEX to issue tokens, create orders, Bancor, address activation, set address aliases, and other application scenarios.
In general, the types of application scenarios of CET are not plenty enough. In order to better develop the internal ecosystem of the platform, it is necessary to design and develop more CET usage scenarios and incentive mechanisms to increase the retention rate of users while adding new users.
4.2.3 Token incentive
As the native token of the CoinEx public chain, CET will be used as a block incentive to increase community participation after the mainnet of the public chain launched. The 315 million CET held by the foundation in the total CET issuance will be used to incentivize initial verification nodes and Staking participants.
CET annual incentive information,Source:CoinEx; TokenInsight

5. Team & Partners

5.1 Core team members

Among the core team members of CoinEx, the technical members account for a relatively large proportion. The technical team’s overall ability is good and the team members have different technical experience backgrounds including cryptography, underlying protocols, marketing, and operations. The team has rich blockchain industry experience, especially the chief developer, who has about 13 years of development industry experience.

https://preview.redd.it/kd0z9q0ese551.png?width=785&format=png&auto=webp&s=7beff33e522165202f6a0b75dba70f32630d8656
https://preview.redd.it/s2klsatese551.png?width=1024&format=png&auto=webp&s=57f03219007d853d754883e2e07cd5eb2c8ed17d
https://preview.redd.it/kuyspmkfse551.png?width=978&format=png&auto=webp&s=fd9c808107d245047f7c74ef34fcf6a02965152c

5.2 Investment institutions and partners

CoinEx’s investment is led by Bitmain and its main partners include Matrixport, Bitcoin.com, CoinBull, Consensus Lab, BTC.com, BTC.top, Hoo Exchange, Wa Yi, ChainFor.com, etc.
Investment institutions and major partners have rich experience in the industry, which can promote the development of projects to a certain extent. However, the current industry involved by the partners is not wide enough, and it will have a limited role in promoting the future of CoinEx’s enriching business lines and increasing ecosystem functions.
https://preview.redd.it/zjgzvv6ise551.png?width=533&format=png&auto=webp&s=a3f7fe3abb2c2d522e289213ae6fbc4e899825e0

6. Community Analysis

According to TokenInsight’s research of the CoinEx platform community, as of April 23, 2020, its official Twitter has 19,800 followers and 932 tweets; the official Telegram has 45 official groups, 3 in Chinese and English, and the other is Korean, Arabic, Vietnamese, Indian and other small language groups, with a total number of 56088 people; the current number of followers on Facebook accounts is 3,107. The overall community followers still have a lot of room for improvement, and community activeness needs to be improved.
Number of followers on the CoinEx social platform,Source:TokenInsight
At present, the project’s search popularity and official website visits are both top-notch, and monthly visits have slowly returned to their previous visit levels after experiencing a significant decline in December 2019.
CoinEx visit popularity,Source: TokenInsight, Similarweb, Google
At present, the visitors of the CoinEx website are distributed in multiple countries, and there are no visits concentration from a single country or region. Therefore, CoinEx’s comprehensive global influence is widely distributed and has a reasonable degree of internationalization.

CoinEx official website’s top 5 countries by number of visitors,Source: CoinEx, TokenInsight
Original article
Click here to register on CoinEx!
submitted by CoinExcom to btc [link] [comments]

The Retrospect and Prospect of the Crypto Economy——The Development and Evolution of the Consensus Mechanism (Three)

The Retrospect and Prospect of the Crypto Economy——The Development and Evolution of the Consensus Mechanism (Three)

https://preview.redd.it/45wwtygv2rc51.png?width=567&format=png&auto=webp&s=a5f51ea3c620d478231c39e32f198eb64d801897
Foreword
The consensus mechanism is one of the important elements of the blockchain and the core rule of the normal operation of the distributed ledger. It is mainly used to solve the trust problem between people and determine who is responsible for generating new blocks and maintaining the effective unification of the system in the blockchain system. Thus, it has become an everlasting research hot topic in blockchain.
This article starts with the concept and role of the consensus mechanism. First, it enables the reader to have a preliminary understanding of the consensus mechanism as a whole; then starting with the two armies and the Byzantine general problem, the evolution of the consensus mechanism is introduced in the order of the time when the consensus mechanism is proposed; Then, it briefly introduces the current mainstream consensus mechanism from three aspects of concept, working principle and representative project, and compares the advantages and disadvantages of the mainstream consensus mechanism; finally, it gives suggestions on how to choose a consensus mechanism for blockchain projects and pointed out the possibility of the future development of the consensus mechanism.
Contents
First, concept and function of the consensus mechanism
1.1 Concept: The core rules for the normal operation of distributed ledgers
1.2 Role: Solve the trust problem and decide the generation and maintenance of new blocks
1.2.1 Used to solve the trust problem between people
1.2.2 Used to decide who is responsible for generating new blocks and maintaining effective unity in the blockchain system
1.3 Mainstream model of consensus algorithm
Second, the origin of the consensus mechanism
2.1 The two armies and the Byzantine generals
2.1.1 The two armies problem
2.1.2 The Byzantine generals problem
2.2 Development history of consensus mechanism
2.2.1 Classification of consensus mechanism
2.2.2 Development frontier of consensus mechanism
Third, Common Consensus System
Fourth, Selection of consensus mechanism and summary of current situation
4.1 How to choose a consensus mechanism that suits you
4.1.1 Determine whether the final result is important
4.1.2 Determine how fast the application process needs to be
4.1.2 Determining the degree to which the application requires for decentralization
4.1.3 Determine whether the system can be terminated
4.1.4 Select a suitable consensus algorithm after weighing the advantages and disadvantages
4.2 Future development of consensus mechanism
Last lecture review: Chapter 1 Concept and Function of Consensus Mechanism plus Chapter 2 Origin of Consensus Mechanism
Last lecture review: Chapter 3 Common Consensus Mechanisms

Chapter 3 Common Consensus Mechanisms (Part 2)
Figure 6 Summary of relatively mainstream consensus mechanisms

https://preview.redd.it/2yepvjjy2rc51.png?width=567&format=png&auto=webp&s=acaed31fa6106ac2f501fe2cb284f66bb2258a0e
Source: Hasib Anwar, "Consensus Algorithms: The Root Of The Blockchain Technology"
The picture above shows 14 relatively mainstream consensus mechanisms summarized by a geek Hasib Anwar, including PoW (Proof of Work), PoS (Proof of Stake), DPoS (Delegated Proof of Stake), LPoS (Lease Proof of Stake), PoET ( Proof of Elapsed Time), PBFT (Practical Byzantine Fault Tolerance), SBFT (Simple Byzantine Fault Tolerance), DBFT (Delegated Byzantine Fault Tolerance), DAG (Directed Acyclic Graph), Proof-of-Activity (Proof of Activity), Proof-of- Importance (Proof of Importance), Proof-of-Capacity (Proof of Capacity), Proof-of-Burn ( Proof of Burn), Proof-of-Weight (Proof of Weight).
Next, we will mainly introduce and analyze the top ten consensus mechanisms of the current blockchain.
》DBFT
-Concept:
Delegated Byzantine fault tolerance. The improved Byzantine fault-tolerant algorithm makes it suitable for blockchain systems. The system consists of nodes, delegators (who can approve blocks), and speakers (who proposes the next block). It is a consensus algorithm that guarantees fault tolerance implemented inside the NEO blockchain.
-Principle:
In this mechanism, there are two participants: the professional bookkeeper "bookkeeping node" and the ordinary users in the system.
Ordinary users vote based on the proportion of holding stake to determine the bookkeeping node. When a consensus is required, a spokesperson is randomly selected from these bookkeeping nodes to draw up a plan, and then other bookkeeping nodes will vote basing on the Byzantine fault tolerance algorithm.That is, majority principle. If more than 66% of the nodes agree to the spokesperson’ plan, a consensus is reached; otherwise, the spokesperson is re-elected and the voting process is repeated.
-Representative application: Neo, etc.
》PoA
-Concept:
Proof of authority. That is, certified by some accredited accounts, these accredited accounts are called "validators". The software that the verifier runs that supports the verifier to place transactions in blocks.
-Principle:
Three conditions:
  1. The identity must be formally verified on the chain, and the information can be cross-verified in a publicly available domain;
  2. The qualifications must be difficult to obtain, so that the rights of the verification block obtained are precious enough;
  3. The authoritative inspection and procedures must be completely unified.
With PoA, every individual has the right to become a verifier, so there is an incentive to maintain the position of the verifier once acquired. By attaching a reputation to the identity, the verifier can be encouraged to maintain the transaction process. Because the verifier does not want to gain a negative reputation, it will lose its hard-won verifier status.
-Representative applications: VeChain, etc.
》DAG
-Concept:
Directed acyclic graph. Each newly added unit in the DAG is not only added to the long chain block, but added to all the previous blocks, verifying each new unit and confirming its parent unit and the parent unit of the parent unit, and gradually confirming until the genesis unit. As the hash of its parent unit is included in its own unit, the blockchains of all transactions are connected to each other to form a graph-like structure with time.
-Principle:
In the DAG network, each node can be a trader and a validator, because the transaction processing in DAG is done by the transaction node itself. Taking IOTA as an example, IOTA’s Tangle led
ger does not need to pay transaction fees while ensuring high-speed transaction processing. However, it does not mean that the transaction is free, because in this ledger, the initiation of each transaction needs to verify the other two random transactions first, and connect the transaction initiated by itself to these two transactions, so the responsibility that miners on the blockchain bear is distributed to all traders. The DAG method of processing transactions can be called asynchronous processing mode.
Figure 10 The difference between the traditional blockchain structure and the DAG structure

https://preview.redd.it/1xfssxj03rc51.png?width=553&format=png&auto=webp&s=95c382f81943c9a188a89ac6b2dadf64446589e6
-Representative applications: IOTA, etc.
》PoET
-Concept:
Proof of elapsed time. That is, it is usually used in a permissioned blockchain network. It can determine the mining rights of the block holders in the network. The permissioned blockchain network requires any prospective participants to verify their identity before joining. According to the principles of the fair lottery system, each node is equally likely to become the winner.
-Principle:
Each participating node in the network must wait for a randomly selected period, and the first node to complete the set waiting time will get a new block. Each node in the blockchain network will generate a random waiting time and sleep for a set time. The node that wakes up first, that is, the node with the shortest waiting time, wakes up and submits a new block to the blockchain, and then broadcasts the necessary information to the entire peer-to-peer network. The same process will be repeated to find the next block.
Two factors:
  1. Participating nodes will naturally select a random time in nature, rather than deliberately;
  2. The winner did complete the waiting time.
-Representative application: HyperLedger Sawtooth, etc.
》PoSV
-Concept:
Proof of stake velocity. Proposed by Reddcoin, drawing on the concept of "money circulation speed" in economics, it mainly allocates bookkeeping rights based on the coin age of nodes participating in the competition.
-Principle:
PoSV also allocates accounting rights according to the coin age of the nodes participating in the competition, but modifies the coin age calculation formula to a function of exponential decay of growth rate. Taking Reddcoin as an example, Reddcoin sets the half-life of the coin age growth rate to 1 month. Assuming that the unit token can accumulate 1CoinDay coin age on the first day, only 0.5CoinDay coin age can be accumulated on the 31st day, and only 0.25CoinDay coin age can be accumulated on the 61st day, and so on. In this way, the nodes are encouraged to use the token to conduct a transaction after holding the token for a period of time, thereby restarting the calculation of the coin age and increasing the circulation speed of the token in the network.
-Representative applications: Reddcoin, etc.
Table 2 Comparison of the advantages and disadvantages of current mainstream consensus mechanisms

https://preview.redd.it/kb04i7eh3rc51.png?width=1236&format=png&auto=webp&s=42de13bc99afaf258c0a740a6618e2d579b59100
Source: network resources
Chapter 4 Summary of the Selection and Status Quo of Consensus Mechanism
4.1 How to choose a consensus mechanism that suits you
Step 1: Determine whether the final result is important
For some applications, the end result is very important. If you are building a new payment system that can support very small amounts, it is acceptable for the transaction result to change. Similarly, if you are creating a new distributed social network, 100% guarantee that the status is updated immediately is not particularly necessary. On the contrary, if you are creating a new distributed protocol, the final result is critical to the user experience. For example, Bitcoin has a final confirmation time of about 1 hour, Ethereum has a final confirmation time of about 6 minutes, and Tendermint Core only has a final confirmation time of 1 second.
Step 2: Determine how fast the application process needs to be
If you are building a game, is it reasonable to wait 15 seconds before each action? Due to the low block processing time of Ethereum, games built on it will cause poor user experience due to Ethereum's throughput. However, the application for the transfer of housing property rights can be run on Ethereum. Use the Cosmos SDK to build an application that allows developers to freely use Tendermint Core. It has a short block processing time and high throughput, and is capable of processing 10,000 transactions per second. You can reduce the required communication overhead and speed up the application by setting the maximum number of validators for the application.
Step 3: Determine the application's demand for decentralization
Some applications such as games may not require very high censorship resistance as a by-product of decentralization. In theory, does it really matter that the validator can create a cartel in the game and reverse the transaction result for profit? If it is not important, a blockchain such as EOS may be more suitable for your needs because of the fast transaction speed and free fees. However, some applications such as autonomous banks are more powerful and decentralized. Although Ethereum is considered to be decentralized, some supporters claim that Ethereum's mining pool is an important part of centralized platform, although there are actually only 11 validators (mining pools). One of the major benefits of building your own blockchain instead of building on a smart contract platform is that you can customize the way the application completes verification. However, it is difficult to build your own blockchain, so the Cosmos SDK is very useful, you can easily build your own blockchain and customize the degree of decentralization you need.
Step 4: Determine whether the system can be terminated
If you are building a new application similar to a distributed ride-sharing service, then ensuring 24/7 service must be the first priority, even if there are occasional errors in accounting similar to transactions. One of the properties of Tendermint Core is that if there is a disagreement between network validators, the network will suspend operations instead of proceeding erroneous transactions. Applications such as decentralized exchanges require correctness at all costs-if there is a problem, it is far better to suspend trading on the decentralized exchange than there may be trading problems.
Summary: Choose a suitable consensus algorithm after weighing the advantages and disadvantages
All in all, there is no single best consensus algorithm. Each consensus algorithm has its own value and advantages. You need to have your own judgments and choices. However, by understanding the relevant processes of the consensus mechanism, including proposals and agreements, and establishing a framework to consider the types of consensus algorithms that your application may require, you should be able to make wiser decisions.
4.2 Future development of consensus mechanism
The consensus algorithm is one of the core elements of the blockchain. Although there are more than 30 consensus mechanisms listed in the article, there are still many niche consensus mechanisms that may not be discussed. As the blockchain technology is gradually known and accepted by the public, more and more newer and better consensus algorithms may appear in the future, which may be brand-new consensus algorithms, and more should be improvement and optimization version based on the current consensus algorithm.
After 2016 and 2017 years’ fast development, the current consensus algorithm does not have a recognized evaluation standard, but is generally more biased towards fairness and decentralization, as well as some technical related issues, such as energy consumption and scalability , Fault tolerance and security, etc. However, blockchain technology must be combined with requirements and application scenarios, and the consensus mechanism algorithm and incentive mechanism are inseparable. How to customize a suitable consensus mechanism according to the characteristics of your own project and optimize the current consensus mechanism will become the future direction of consensus mechanism development
CelesOS
As the first DPOW financial blockchain operating system, CelesOS adopts consensus mechanism 3.0 to break through the "impossible triangle", which can provide high TPS while also allowing for decentralization. Committed to creating a financial blockchain operating system that embraces supervision, providing services for financial institutions and the development of applications on the supervision chain, and formulating a role and consensus ecological supervision layer agreement for supervision.
The CelesOS team is dedicated to building a bridge between blockchain and regulatory agencies/financial industry. We believe that only blockchain technology that cooperates with regulators will have a real future. We believe in and contribute to achieving this goal.
📷Website
https://www.celesos.com/
📷 Telegram
https://t.me/celeschain
📷 Twitter
https://twitter.com/CelesChain
📷 Reddit
https://www.reddit.com/useCelesOS
📷 Medium
https://medium.com/@celesos
📷 Facebook
https://www.facebook.com/CelesOS1
📷 Youtube
https://www.youtube.com/channel/UC1Xsd8wU957D-R8RQVZPfGA
submitted by CelesOS to u/CelesOS [link] [comments]

Review and Prospect of Crypto Economy-Development and Evolution of Consensus Mechanism (2)

Review and Prospect of Crypto Economy-Development and Evolution of Consensus Mechanism (2)

https://preview.redd.it/a51zsja94db51.png?width=567&format=png&auto=webp&s=99e8080c9e9b1fb5e11cbd70f915f9cb37188f81
Foreword
The consensus mechanism is one of the important elements of the blockchain and the core rule of the normal operation of the distributed ledger. It is mainly used to solve the trust problem between people and determine who is responsible for generating new blocks and maintaining the effective unification of the system in the blockchain system. Thus, it has become an everlasting research hot topic in blockchain.
This article starts with the concept and role of the consensus mechanism. First, it enables the reader to have a preliminary understanding of the consensus mechanism as a whole; then starting with the two armies and the Byzantine general problem, the evolution of the consensus mechanism is introduced in the order of the time when the consensus mechanism is proposed; Then, it briefly introduces the current mainstream consensus mechanism from three aspects of concept, working principle and representative project, and compares the advantages and disadvantages of the mainstream consensus mechanism; finally, it gives suggestions on how to choose a consensus mechanism for blockchain projects and pointed out the possibility of the future development of the consensus mechanism.
Contents
First, concept and function of the consensus mechanism
1.1 Concept: The core rules for the normal operation of distributed ledgers
1.2 Role: Solve the trust problem and decide the generation and maintenance of new blocks
1.2.1 Used to solve the trust problem between people
1.2.2 Used to decide who is responsible for generating new blocks and maintaining effective unity in the blockchain system
1.3 Mainstream model of consensus algorithm
Second, the origin of the consensus mechanism
2.1 The two armies and the Byzantine generals
2.1.1 The two armies problem
2.1.2 The Byzantine generals problem
2.2 Development history of consensus mechanism
2.2.1 Classification of consensus mechanism
2.2.2 Development frontier of consensus mechanism
Third, Common Consensus System
Fourth, Selection of consensus mechanism and summary of current situation
4.1 How to choose a consensus mechanism that suits you
4.1.1 Determine whether the final result is important
4.1.2 Determine how fast the application process needs to be
4.1.2 Determining the degree to which the application requires for decentralization
4.1.3 Determine whether the system can be terminated
4.1.4 Select a suitable consensus algorithm after weighing the advantages and disadvantages
4.2 Future development of consensus mechanism
Last lecture review: Chapter 1 Concept and Function of Consensus Mechanism plus Chapter 2 Origin of Consensus Mechanism
Chapter 3 Common Consensus Mechanisms (Part 1)
Figure 6 Summary of relatively mainstream consensus mechanisms
📷
https://preview.redd.it/9r7q3xra4db51.png?width=567&format=png&auto=webp&s=bae5554a596feaac948fae22dffafee98c4318a7
Source: Hasib Anwar, "Consensus Algorithms: The Root Of The Blockchain Technology"
The picture above shows 14 relatively mainstream consensus mechanisms summarized by a geek Hasib Anwar, including PoW (Proof of Work), PoS (Proof of Stake), DPoS (Delegated Proof of Stake), LPoS (Lease Proof of Stake), PoET ( Proof of Elapsed Time), PBFT (Practical Byzantine Fault Tolerance), SBFT (Simple Byzantine Fault Tolerance), DBFT (Delegated Byzantine Fault Tolerance), DAG (Directed Acyclic Graph), Proof-of-Activity (Proof of Activity), Proof-of- Importance (Proof of Importance), Proof-of-Capacity (Proof of Capacity), Proof-of-Burn ( Proof of Burn), Proof-of-Weight (Proof of Weight).
Next, we will mainly introduce and analyze the top ten consensus mechanisms of the current blockchain.
》POW
-Concept:
Work proof mechanism. That is, the proof of work means that it takes a certain amount of computer time to confirm the work.
-Principle:
Figure 7 PoW work proof principle
📷
https://preview.redd.it/xupacdfc4db51.png?width=554&format=png&auto=webp&s=3b6994641f5890804d93dfed9ecfd29308c8e0cc
The PoW represented by Bitcoin uses the SHA-256 algorithm function, which is a 256-bit hash algorithm in the password hash function family:
Proof of work output = SHA256 (SHA256 (block header));
if (output of proof of work if (output of proof of work >= target value), change the random number, recursive i logic, continue to compare with the target value.
New difficulty value = old difficulty value* (time spent by last 2016 blocks /20160 minutes)
Target value = maximum target value / difficulty value
The maximum target value is a fixed number. If the last 2016 blocks took less than 20160 minutes, then this coefficient will be small, and the target value will be adjusted bigger, if not, the target value will be adjusted smaller. Bitcoin mining difficulty and block generation speed will be inversely proportional to the appropriate adjustment of block generation speed.
-Representative applications: BTC, etc.
》POS
-Concept:
Proof of stake. That is, a mechanism for reaching consensus based on the holding currency. The longer the currency is held, the greater the probability of getting a reward.
-Principle:
PoS implementation algorithm formula: hash(block_header) = Coin age calculation formula: coinage = number of coins * remaining usage time of coins
Among them, coinage means coin age, which means that the older the coin age, the easier it is to get answers. The calculation of the coin age is obtained by multiplying the coins owned by the miner by the remaining usage time of each coin, which also means that the more coins you have, the easier it is to get answers. In this way, pos solves the problem of wasting resources in pow, and miners cannot own 51% coins from the entire network, so it also solves the problem of 51% attacks.
-Representative applications: ETH, etc.
》DPoS
-Concept:
Delegated proof of stake. That is, currency holding investors select super nodes by voting to operate the entire network , similar to the people's congress system.
-Principle:
The DPOS algorithm is divided into two parts. Elect a group of block producers and schedule production.
Election: Only permanent nodes with the right to be elected can be elected, and ultimately only the top N witnesses can be elected. These N individuals must obtain more than 50% of the votes to be successfully elected. In addition, this list will be re-elected at regular intervals.
Scheduled production: Under normal circumstances, block producers take turns to generate a block every 3 seconds. Assuming that no producer misses his order, then the chain they produce is bound to be the longest chain. When a witness produces a block, a block needs to be generated every 2s. If the specified time is exceeded, the current witness will lose the right to produce and the right will be transferred to the next witness. Then the witness is not only unpaid, but also may lose his identity.
-Representative applications: EOS, etc.
》DPoW
-Concept:
Delayed proof of work. A new-generation consensus mechanism based on PoB and DPoS. Miners use their own computing power, through the hash algorithm, and finally prove their work, get the corresponding wood, wood is not tradable. After the wood has accumulated to a certain amount, you can go to the burning site to burn the wood. This can achieve a balance between computing power and mining rights.
-Principle:
In the DPoW-based blockchain, miners are no longer rewarded tokens, but "wood" that can be burned, burning wood. Miners use their own computing power, through the hash algorithm, and finally prove their work, get the corresponding wood, wood is not tradable. After the wood has accumulated to a certain amount, you can go to the burning site to burn the wood. Through a set of algorithms, people who burn more wood or BP or a group of BP can obtain the right to generate blocks in the next event segment, and get rewards (tokens) after successful block generation. Since more than one person may burn wood in a time period, the probability of producing blocks in the next time period is determined by the amount of wood burned by oneself. The more it is burned, the higher the probability of obtaining block rights in the next period.
Two node types: notary node and normal node.
The 64 notary nodes are elected by the stakeholders of the dPoW blockchain, and the notarized confirmed blocks can be added from the dPoW blockchain to the attached PoW blockchain. Once a block is added, the hash value of the block will be added to the Bitcoin transaction signed by 33 notary nodes, and a hash will be created to the dPow block record of the Bitcoin blockchain. This record has been notarized by most notary nodes in the network. In order to avoid wars on mining between notary nodes, and thereby reduce the efficiency of the network, Komodo designed a mining method that uses a polling mechanism. This method has two operating modes. In the "No Notary" (No Notary) mode, all network nodes can participate in mining, which is similar to the traditional PoW consensus mechanism. In the "Notaries Active" mode, network notaries use a significantly reduced network difficulty rate to mine. In the "Notary Public Activation" mode, each notary public is allowed to mine a block with its current difficulty, while other notary public nodes must use 10 times the difficulty of mining, and all normal nodes use 100 times the difficulty of the notary public node.
Figure 8 DPoW operation process without a notary node
📷
https://preview.redd.it/3yuzpemd4db51.png?width=500&format=png&auto=webp&s=f3bc2a1c97b13cb861414d3eb23a312b42ea6547
-Representative applications: CelesOS, Komodo, etc.
CelesOS Research Institute丨DPoW consensus mechanism-combustible mining and voting
》PBFT
-Concept:
Practical Byzantine fault tolerance algorithm. That is, the complexity of the algorithm is reduced from exponential to polynomial level, making the Byzantine fault-tolerant algorithm feasible in practical system applications.
-Principle:
Figure 9 PBFT algorithm principle
📷
https://preview.redd.it/8as7rgre4db51.png?width=567&format=png&auto=webp&s=372be730af428f991375146efedd5315926af1ca
First, the client sends a request to the master node to call the service operation, and then the master node broadcasts other copies of the request. All copies execute the request and send the result back to the client. The client needs to wait for f+1 different replica nodes to return the same result as the final result of the entire operation.
Two qualifications: 1. All nodes must be deterministic. That is to say, the results of the operation must be the same under the same conditions and parameters. 2. All nodes must start from the same status. Under these two limited qualifications, even if there are failed replica nodes, the PBFT algorithm agrees on the total order of execution of all non-failed replica nodes, thereby ensuring security.
-Representative applications: Tendermint Consensus, etc.
Next Lecture: Chapter 3 Common Consensus Mechanisms (Part 2) + Chapter 4 Consensus Mechanism Selection and Status Summary
CelesOS
As the first DPOW financial blockchain operating system, CelesOS adopts consensus mechanism 3.0 to break through the "impossible triangle", which can provide high TPS while also allowing for decentralization. Committed to creating a financial blockchain operating system that embraces supervision, providing services for financial institutions and the development of applications on the supervision chain, and formulating a role and consensus ecological supervision layer agreement for supervision.
The CelesOS team is dedicated to building a bridge between blockchain and regulatory agencies/financial industry. We believe that only blockchain technology that cooperates with regulators will have a real future. We believe in and contribute to achieving this goal.

📷Website
https://www.celesos.com/
📷 Telegram
https://t.me/celeschain
📷 Twitter
https://twitter.com/CelesChain
📷 Reddit
https://www.reddit.com/useCelesOS
📷 Medium
https://medium.com/@celesos
📷 Facebook
https://www.facebook.com/CelesOS1
📷 Youtube
https://www.youtube.com/channel/UC1Xsd8wU957D-R8RQVZPfGA
submitted by CelesOS to u/CelesOS [link] [comments]

Review and Prospect of Crypto Economy-Development and Evolution of Consensus Mechanism (1)

Review and Prospect of Crypto Economy-Development and Evolution of Consensus Mechanism (1)

https://preview.redd.it/7skleasc80a51.png?width=553&format=png&auto=webp&s=fc18cee10bff7b65d5b02487885d936d23382fc8
Table 1 Classification of consensus system
Source: Yuan Yong, Ni Xiaochun, Zeng Shuai, Wang Feiyue, "Development Status and Prospect of Blockchain Consensus Algorithm"
Figure 4 Evolution of consensus algorithm

Figure 4 Evolution of consensus algorithm
Source: Network data

Foreword
The consensus mechanism is one of the important elements of the blockchain and the core rule of the normal operation of the distributed ledger. It is mainly used to solve the trust problem between people and determine who is responsible for generating new blocks and maintaining the effective unification of the system in the blockchain system. Thus, it has become an everlasting research hot topic in blockchain.
This article starts with the concept and role of the consensus mechanism. First, it enables the reader to have a preliminary understanding of the consensus mechanism as a whole; then starting with the two armies and the Byzantine general problem, the evolution of the consensus mechanism is introduced in the order of the time when the consensus mechanism is proposed; Then, it briefly introduces the current mainstream consensus mechanism from three aspects of concept, working principle and representative project, and compares the advantages and disadvantages of the mainstream consensus mechanism; finally, it gives suggestions on how to choose a consensus mechanism for blockchain projects and pointed out the possibility of the future development of the consensus mechanism.
Contents
First, concept and function of the consensus mechanism
1.1 Concept: The core rules for the normal operation of distributed ledgers
1.2 Role: Solve the trust problem and decide the generation and maintenance of new blocks
1.2.1 Used to solve the trust problem between people
1.2.2 Used to decide who is responsible for generating new blocks and maintaining effective unity in the blockchain system
1.3 Mainstream model of consensus algorithm
Second, the origin of the consensus mechanism
2.1 The two armies and the Byzantine generals
2.1.1 The two armies problem
2.1.2 The Byzantine generals problem
2.2 Development history of consensus mechanism
2.2.1 Classification of consensus mechanism
2.2.2 Development frontier of consensus mechanism
Third, Common Consensus System
Fourth, Selection of consensus mechanism and summary of current situation
4.1 How to choose a consensus mechanism that suits you
4.1.1 Determine whether the final result is important
4.1.2 Determine how fast the application process needs to be
4.1.2 Determining the degree to which the application requires for decentralization
4.1.3 Determine whether the system can be terminated
4.1.4 Select a suitable consensus algorithm after weighing the advantages and disadvantages
4.2 Future development of consensus mechanism
Chapter 1 Concept and Function of Consensus Mechanism
1.1 Concept: The core rules for the normal operation of distributed ledgers
Since most cryptocurrencies use decentralized blockchain design, nodes are scattered and parallel everywhere, so a system must be designed to maintain the order and fairness of the system's operation, unify the version of the blockchain, and reward users maintaining the blockchain and punish malicious harmers. Such a system must rely on some way to prove that who has obtained the packaging rights (or accounting rights) of a blockchain and can obtain the reward for packaging this block; or who intends to harm , and will receive certain penalty. Such system is consensus mechanism.
1.2 Role: Solve the trust problem and decide the generation and maintenance of new blocks
1.2.1 Used to solve the trust problem between people
The reason why the consensus mechanism can be at the core of the blockchain technology is that it has formulated a set of rules from the perspective of cryptographic technologies such as asymmetric encryption and time stamping. All participants must comply with this rules. And theese rules are transparent, and cannot be modified artificially. Therefore, without the endorsement of a third-party authority, it can also mobilize nodes across the network to jointly monitor, record all transactions, and publish them in the form of codes, effectively achieving valuable information transfer, solving or more precisely, greatly improving the trust problem between two unrelated strangers who do not trust each other. After all, trusting the objective technology is less risky than trusting a subjective individual.
1.2.2 Used to decide who is responsible for generating new blocks and maintaining effective unity in the blockchain system
On the other hand, in the blockchain system, due to the high network latency of the peer-to-peer network, the sequence of transactions observed by each node is different. To solve this, the consensus mechanism can be used to reach consensus on transactions order within a short period of time to decide who is responsible for generating new blocks in the blockchain system, and to maintain the effective unity of the blockchain.
1.3 The mainstream model of consensus algorithm
The blockchain system is built on the P2P network, and the set of all nodes can be recorded as PP, generally divided into ordinary nodes that produce data or transactions, and"miner" nodes (denoted as M) responsible for mining operations, like verifying, packaging, and updating the data generated by ordinary nodes or transactions. The functions of the two types of nodes may be overlapped; miner nodes usually participate in the consensus competition process in general, and will select certain representative nodes and replace them to participant in the consensus process and compete for accounting rights in specific algorithms. The collection of these representative nodes is recorded as DD; the accounting nodes selected through the consensus process are recorded as AA. The consensus process is repeated in accordance with the round, and each round of the consensus process generally reselects the accounting node for the round . The core of the consensus process is the "select leader" and "accounting" two parts. In the specific operation process, each round can be divided into four stages: Leader election, Block generation, Data validation and Chain updating namely accounting). As shown in Figure 1, the input of the consensus process is the transaction or data generated and verified by the data node, and the output is the encapsulated data block and updated blockchain. The four stages are executed repeatedly, and each execution round will generate a new block.
Stage 1: Leader election
The election is the core of the consensus process, that is, the process of selecting the accounting node AA from all the miner node sets MM: we can use the formula f(M)→f(M)→AA to represent the election process, where the function ff represents the specific implementation of the consensus algorithm. Generally speaking, |A|=1,|A|=1, that is, the only miner node is finally selected to keep accounts.
Stage 2: Block generation
The accounting node selected in the first stage packages the transactions or data generated by all nodes PP in the current time period into a block according to a specific strategy, and broadcasts the generated new block to all miner nodes MM or their representative nodes DD. These transactions or data are usually sorted according to various factors such as block capacity, transaction fees, transaction waiting time, etc., and then packaged into new blocks in sequence. The block generation strategy is a key factor in the performance of the blockchain system, and it also exposes the strategic behavior of miners such as greedy transactions packaging and selfish mining.
Stage 3: Verification
After receiving the broadcasted new block, the miner node MM or the representative node DD will verify the correctness and rationality of the transactions or data encapsulated in the block. If the new block is approved by most verification/representative nodes, the block will be updated to the blockchain as the next block.
Stage 4: On-Chain
The accounting node adds new blocks to the main chain to form a complete and longer chain from the genesis block to the latest block. If there are multiple fork chains on the main chain, the main chain needs to be based on the consensus algorithm judging criteria to choose one of the appropriate fork chain as the main chain.
Chapter 2 The Origin of Consensus Mechanism
2.1 The two armies problems and the Byzantium generals problem
2.1.1 The two armies


Figure 2 Schematic diagram of the two armed forces
Selected from Yuan Yong, Ni Xiaochun, Zeng Shuai, Wang Feiyue, "Development Status and Prospect of Blockchain Consensus Algorithm", Journal of Automation, 2018, 44(11): 2011-2022
As shown in the figure, the 1st and 2nd units of the Blue Army are stationed on two sides of the slope, and cannot communicate remotely between each other. While the White Army is just stationed in the middle of the two Blue Army units. Suppose that the White Army is stronger than either of the two Blue Army units, but it is not as strong as the two Blue Army units combined. If the two units of the Blue Army want to jointly attack the White Army at the same time, they need to communicate with each other, but the White Army is stationed in the middle of them. It is impossible to confirm whether the messengers of two Blue Army units have sent the attack signal to each other, let alone the tampering of the messages. In this case, due to the inability to fully confirm with each other, ultimately no effective consensus can be reached between the two Blue Army units, rendering the "paradox of the two armies".
2.1.2 The Byzantine generals problem


Figure 3 Diagram of the Byzantine generals' problem
Due to the vast territory of the Byzantine roman empire at that time, in order to better achieve the purpose of defense, troops were scattered around the empire, and each army was far apart, and only messengers could deliver messages. During the war, all generals must reach an agreement, or decide whether to attack the enemy based on the majority principle. However, since it is completely dependent on people, if there is a situation where the general rebels or the messenger delivers the wrong message, how can it ensure that the loyal generals can reach agreement without being influenced by the rebels is a problem which was called the Byzantine problem.
The two armies problems and the Byzantine generals problem are all elaborating the same problem: in the case of unreliable information exchange, it is very difficult to reach consensus and coordinate action. The Byzantine general problem is more like a generalization of the "paradox of the two armies".
From the perspective of the computer network, the two armies problem and the Byzantine problem are common contents of computer network courses: the direct communication between two nodes on the network may fail, so the TCP protocol cannot completely guarantee the consistence between the two terminal networks. However, the consensus mechanism can use economic incentives and other methods to reduce this uncertainty to a level acceptable to most people.
It is precisely because of the two armies problem and the Byzantine problem that the consensus mechanism has begun to show its value.
2.2 Development history of consensus mechanism
2.2.1 Classification of consensus mechanism
Because different types of blockchain projects have different requirements for information recording and block generation, and as the consensus mechanism improves due to the development of blockchain technology, there are currently more than 30 consensus mechanisms. These consensus mechanisms can be divided into two categories according to their Byzantine fault tolerance performance: Byzantine fault tolerance system and non-Byzantine fault tolerance system.

Table 1 Classification of consensus mechanism
Source: Yuan Yong, Ni Xiaochun, Zeng Shuai, Wang Feiyue, "Development Status and Prospect of Blockchain Consensus Algorithm"
2.2.2 Development frontier of consensus mechanism
-Development of consensus algorithm
According to the proposed time of the consensus algorithm, we can see relatively clearly the development of the consensus algorithm.
Source: Network data

Figure 4 Development frontier of consensus algorithm

Figure 5 Historical evolution of blockchain consensus algorithm
Source: Yuan Yong, Ni Xiaochun, Zeng Shuai, Wang Feiyue, "Development Status and Prospect of Blockchain Consensus Algorithm"
The consensus algorithm has laid the foundation for the blockchain consensus mechanism. Initially, the research of consensus algorithms was mainly used by computer scientists and computer professors to improve the spam problem or conduct academic discussions.
For example, in 1993, American computer scientist and Harvard professor Cynthia Dwork first proposed the idea of proof of work in order to solve the spam problem; in 1997, the British cryptographer Adam Back also independently proposed to solve the spam problem by use of the mechanism of proof of work for hashing cash and published officially in 2002; in 1999, Markus Jakobsson officially proposed the concept of "proof of work", which laid the foundation for the subsequent design of Satoshi Nakamoto's Bitcoin consensus mechanism.
Next lecture: Chapter 3 Detailed Explanation of Consensus Mechanism Technology
CelesOS
As the first DPOW financial blockchain operating system, CelesOS adopts consensus mechanism 3.0 to break through the "impossible triangle". It provides both high TPS and decentralization. Committed to creating a financial blockchain operating system that embraces regulation, providing services for financial institutions and the development of applications on the regulation chain, and developing a role and consensus eco-system regulation level agreement for regulation.
The CelesOS team is committed to building a bridge between blockchain and regulatory agencies / finance industry. We believe that only blockchain technology that cooperates with regulators will have a bright future and strive to achieve this goal.
📷Website
https://www.celesos.com/
📷 Telegram
https://t.me/celeschain
📷 Twitter
https://twitter.com/CelesChain
📷 Reddit
https://www.reddit.com/useCelesOS
📷 Medium
https://medium.com/@celesos
📷 Facebook
https://www.facebook.com/CelesOS1
📷 Youtube
https://www.youtube.com/channel/UC1Xsd8wU957D-R8RQVZPfGA
submitted by CelesOS to u/CelesOS [link] [comments]

Dive Into Tendermint Consensus Protocol (I)

Dive Into Tendermint Consensus Protocol (I)
This article is written by the CoinEx Chain lab. CoinEx Chain is the world’s first public chain exclusively designed for DEX, and will also include a Smart Chain supporting smart contracts and a Privacy Chain protecting users’ privacy.
longcpp @ 20200618
This is Part 1 of the serialized articles aimed to explain the Tendermint consensus protocol in detail.
Part 1. Preliminary of the consensus protocol: security model and PBFT protocol
Part 2. Tendermint consensus protocol illustrated: two-phase voting protocol and the locking and unlocking mechanism
Part 3. Weighted round-robin proposer selection algorithm used in Tendermint project
Any consensus agreement that is ultimately reached is the General Agreement, that is, the majority opinion. The consensus protocol on which the blockchain system operates is no exception. As a distributed system, the blockchain system aims to maintain the validity of the system. Intuitively, the validity of the blockchain system has two meanings: firstly, there is no ambiguity, and secondly, it can process requests to update its status. The former corresponds to the safety requirements of distributed systems, while the latter to the requirements of liveness. The validity of distributed systems is mainly maintained by consensus protocols, considering the multiple nodes and network communication involved in such systems may be unstable, which has brought huge challenges to the design of consensus protocols.

The semi-synchronous network model and Byzantine fault tolerance

Researchers of distributed systems characterize these problems that may occur in nodes and network communications using node failure models and network models. The fail-stop failure in node failure models refers to the situation where the node itself stops running due to configuration errors or other reasons, thus unable to go on with the consensus protocol. This type of failure will not cause side effects on other parts of the distributed system except that the node itself stops running. However, for such distributed systems as the public blockchain, when designing a consensus protocol, we still need to consider the evildoing intended by nodes besides their failure. These incidents are all included in the Byzantine Failure model, which covers all unexpected situations that may occur on the node, for example, passive downtime failures and any deviation intended by the nodes from the consensus protocol. For a better explanation, downtime failures refer to nodes’ passive running halt, and the Byzantine failure to any arbitrary deviation of nodes from the consensus protocol.
Compared with the node failure model which can be roughly divided into the passive and active models, the modeling of network communication is more difficult. The network itself suffers problems of instability and communication delay. Moreover, since all network communication is ultimately completed by the node which may have a downtime failure or a Byzantine failure in itself, it is usually difficult to define whether such failure arises from the node or the network itself when a node does not receive another node's network message. Although the network communication may be affected by many factors, the researchers found that the network model can be classified by the communication delay. For example, the node may fail to send data packages due to the fail-stop failure, and as a result, the corresponding communication delay is unknown and can be any value. According to the concept of communication delay, the network communication model can be divided into the following three categories:
  • The synchronous network model: There is a fixed, known upper bound of delay $\Delta$ in network communication. Under this model, the maximum delay of network communication between two nodes in the network is $\Delta$. Even if there is a malicious node, the communication delay arising therefrom does not exceed $\Delta$.
  • The asynchronous network model: There is an unknown delay in network communication, with the upper bound of the delay known, but the message can still be successfully delivered in the end. Under this model, the network communication delay between two nodes in the network can be any possible value, that is, a malicious node, if any, can arbitrarily extend the communication delay.
  • The semi-synchronous network model: Assume that there is a Global Stabilization Time (GST), before which it is an asynchronous network model and after which, a synchronous network model. In other words, there is a fixed, known upper bound of delay in network communication $\Delta$. A malicious node can delay the GST arbitrarily, and there will be no notification when no GST occurs. Under this model, the delay in the delivery of the message at the time $T$ is $\Delta + max(T, GST)$.
The synchronous network model is the most ideal network environment. Every message sent through the network can be received within a predictable time, but this model cannot reflect the real network communication situation. As in a real network, network failures are inevitable from time to time, causing the failure in the assumption of the synchronous network model. Yet the asynchronous network model goes to the other extreme and cannot reflect the real network situation either. Moreover, according to the FLP (Fischer-Lynch-Paterson) theorem, under this model if there is one node fails, no consensus protocol will reach consensus in a limited time. In contrast, the semi-synchronous network model can better describe the real-world network communication situation: network communication is usually synchronous or may return to normal after a short time. Such an experience must be no stranger to everyone: the web page, which usually gets loaded quite fast, opens slowly every now and then, and you need to try before you know the network is back to normal since there is usually no notification. The peer-to-peer (P2P) network communication, which is widely used in blockchain projects, also makes it possible for a node to send and receive information from multiple network channels. It is unrealistic to keep blocking the network information transmission of a node for a long time. Therefore, all the discussion below is under the semi-synchronous network model.
The design and selection of consensus protocols for public chain networks that allow nodes to dynamically join and leave need to consider possible Byzantine failures. Therefore, the consensus protocol of a public chain network is designed to guarantee the security and liveness of the network under the semi-synchronous network model on the premise of possible Byzantine failure. Researchers of distributed systems point out that to ensure the security and liveness of the system, the consensus protocol itself needs to meet three requirements:
  • Validity: The value reached by honest nodes must be the value proposed by one of them
  • Agreement: All honest nodes must reach consensus on the same value
  • Termination: The honest nodes must eventually reach consensus on a certain value
Validity and agreement can guarantee the security of the distributed system, that is, the honest nodes will never reach a consensus on a random value, and once the consensus is reached, all honest nodes agree on this value. Termination guarantees the liveness of distributed systems. A distributed system unable to reach consensus is useless.

The CAP theorem and Byzantine Generals Problem

In a semi-synchronous network, is it possible to design a Byzantine fault-tolerant consensus protocol that satisfies validity, agreement, and termination? How many Byzantine nodes can a system tolerance? The CAP theorem and Byzantine Generals Problem provide an answer for these two questions and have thus become the basic guidelines for the design of Byzantine fault-tolerant consensus protocols.
Lamport, Shostak, and Pease abstracted the design of the consensus mechanism in the distributed system in 1982 as the Byzantine Generals Problem, which refers to such a situation as described below: several generals each lead the army to fight in the war, and their troops are stationed in different places. The generals must formulate a unified action plan for the victory. However, since the camps are far away from each other, they can only communicate with each other through the communication soldiers, or, in other words, they cannot appear on the same occasion at the same time to reach a consensus. Unfortunately, among the generals, there is a traitor or two who intend to undermine the unified actions of the loyal generals by sending the wrong information, and the communication soldiers cannot send the message to the destination by themselves. It is assumed that each communication soldier can prove the information he has brought comes from a certain general, just as in the case of a real BFT consensus protocol, each node has its public and private keys to establish an encrypted communication channel for each other to ensure that its messages will not be tampered with in the network communication, and the message receiver can also verify the sender of the message based thereon. As already mentioned, any consensus agreement ultimately reached represents the consensus of the majority. In the process of generals communicating with each other for an offensive or retreat, a general also makes decisions based on the majority opinion from the information collected by himself.
According to the research of Lamport et al, if there are 1/3 or more traitors in the node, the generals cannot reach a unified decision. For example, in the following figure, assume there are 3 generals and only 1 traitor. In the figure on the left, suppose that General C is the traitor, and A and B are loyal. If A wants to launch an attack and informs B and C of such intention, yet the traitor C sends a message to B, suggesting what he has received from A is a retreat. In this case, B can't decide as he doesn't know who the traitor is, and the information received is insufficient for him to decide. If A is a traitor, he can send different messages to B and C. Then C faithfully reports to B the information he received. At this moment as B receives conflicting information, he cannot make any decisions. In both cases, even if B had received consistent information, it would be impossible for him to spot the traitor between A and C. Therefore, it is obvious that in both situations shown in the figure below, the honest General B cannot make a choice.
According to this conclusion, when there are $n$ generals with at most $f$ traitors (n≤3f), the generals cannot reach a consensus if $n \leq 3f$; and with $n > 3f$, a consensus can be reached. This conclusion also suggests that when the number of Byzantine failures $f$ exceeds 1/3 of the total number of nodes $n$ in the system $f \ge n/3$ , no consensus will be reached on any consensus protocol among all honest nodes. Only when $f < n/3$, such condition is likely to happen, without loss of generality, and for the subsequent discussion on the consensus protocol, $ n \ge 3f + 1$ by default.
The conclusion reached by Lamport et al. on the Byzantine Generals Problem draws a line between the possible and the impossible in the design of the Byzantine fault tolerance consensus protocol. Within the possible range, how will the consensus protocol be designed? Can both the security and liveness of distributed systems be fully guaranteed? Brewer provided the answer in his CAP theorem in 2000. It indicated that a distributed system requires the following three basic attributes, but any distributed system can only meet two of the three at the same time.
  1. Consistency: When any node responds to the request, it must either provide the latest status information or provide no status information
  2. Availability: Any node in the system must be able to continue reading and writing
  3. Partition Tolerance: The system can tolerate the loss of any number of messages between two nodes and still function normally

https://preview.redd.it/1ozfwk7u7m851.png?width=1400&format=png&auto=webp&s=fdee6318de2cf1c021e636654766a7a0fe7b38b4
A distributed system aims to provide consistent services. Therefore, the consistency attribute requires that the two nodes in the system cannot provide conflicting status information or expired information, which can ensure the security of the distributed system. The availability attribute is to ensure that the system can continuously update its status and guarantee the availability of distributed systems. The partition tolerance attribute is related to the network communication delay, and, under the semi-synchronous network model, it can be the status before GST when the network is in an asynchronous status with an unknown delay in the network communication. In this condition, communicating nodes may not receive information from each other, and the network is thus considered to be in a partitioned status. Partition tolerance requires the distributed system to function normally even in network partitions.
The proof of the CAP theorem can be demonstrated with the following diagram. The curve represents the network partition, and each network has four nodes, distinguished by the numbers 1, 2, 3, and 4. The distributed system stores color information, and all the status information stored by all nodes is blue at first.
  1. Partition tolerance and availability mean the loss of consistency: When node 1 receives a new request in the leftmost image, the status changes to red, the status transition information of node 1 is passed to node 3, and node 3 also updates the status information to red. However, since node 3 and node 4 did not receive the corresponding information due to the network partition, the status information is still blue. At this moment, if the status information is queried through node 2, the blue returned by node 2 is not the latest status of the system, thus losing consistency.
  2. Partition tolerance and consistency mean the loss of availability: In the middle figure, the initial status information of all nodes is blue. When node 1 and node 3 update the status information to red, node 2 and node 4 maintain the outdated information as blue due to network partition. Also when querying status information through node 2, you need to first ask other nodes to make sure you’re in the latest status before returning status information as node 2 needs to follow consistency, but because of the network partition, node 2 cannot receive any information from node 1 or node 3. Then node 2 cannot determine whether it is in the latest status, so it chooses not to return any information, thus depriving the system of availability.
  3. Consistency and availability mean the loss of the partition tolerance: In the right-most figure, the system does not have a network partition at first, and both status updates and queries can go smoothly. However, once a network partition occurs, it degenerates into one of the previous two conditions. It is thus proved that any distributed system cannot have consistency, availability, and partition tolerance all at the same time.

https://preview.redd.it/456x2blv7m851.png?width=1400&format=png&auto=webp&s=550797373145b8fc1471bdde68ed5f8d45adb52b
The discovery of the CAP theorem seems to declare that the aforementioned goals of the consensus protocol is impossible. However, if you’re careful enough, you may find from the above that those are all extreme cases, such as network partitions that cause the failure of information transmission, which could be rare, especially in P2P network. In the second case, the system rarely returns the same information with node 2, and the general practice is to query other nodes and return the latest status as believed after a while, regardless of whether it has received the request information of other nodes. Therefore, although the CAP theorem points out that any distributed system cannot satisfy the three attributes at the same time, it is not a binary choice, as the designer of the consensus protocol can weigh up all the three attributes according to the needs of the distributed system. However, as the communication delay is always involved in the distributed system, one always needs to choose between availability and consistency while ensuring a certain degree of partition tolerance. Specifically, in the second case, it is about the value that node 2 returns: a probably outdated value or no value. Returning the possibly outdated value may violate consistency but guarantees availability; yet returning no value deprives the system of availability but guarantees its consistency. Tendermint consensus protocol to be introduced is consistent in this trade-off. In other words, it will lose availability in some cases.
The genius of Satoshi Nakamoto is that with constraints of the CAP theorem, he managed to reach a reliable Byzantine consensus in a distributed network by combining PoW mechanism, Satoshi Nakamoto consensus, and economic incentives with appropriate parameter configuration. Whether Bitcoin's mechanism design solves the Byzantine Generals Problem has remained a dispute among academicians. Garay, Kiayias, and Leonardos analyzed the link between Bitcoin mechanism design and the Byzantine consensus in detail in their paper The Bitcoin Backbone Protocol: Analysis and Applications. In simple terms, the Satoshi Consensus is a probabilistic Byzantine fault-tolerant consensus protocol that depends on such conditions as the network communication environment and the proportion of malicious nodes' hashrate. When the proportion of malicious nodes’ hashrate does not exceed 1/2 in a good network communication environment, the Satoshi Consensus can reliably solve the Byzantine consensus problem in a distributed environment. However, when the environment turns bad, even with the proportion within 1/2, the Satoshi Consensus may still fail to reach a reliable conclusion on the Byzantine consensus problem. It is worth noting that the quality of the network environment is relative to Bitcoin's block interval. The 10-minute block generation interval of the Bitcoin can ensure that the system is in a good network communication environment in most cases, given the fact that the broadcast time of a block in the distributed network is usually just several seconds. In addition, economic incentives can motivate most nodes to actively comply with the agreement. It is thus considered that with the current Bitcoin network parameter configuration and mechanism design, the Bitcoin mechanism design has reliably solved the Byzantine Consensus problem in the current network environment.

Practical Byzantine Fault Tolerance, PBFT

It is not an easy task to design the Byzantine fault-tolerant consensus protocol in a semi-synchronous network. The first practically usable Byzantine fault-tolerant consensus protocol is the Practical Byzantine Fault Tolerance (PBFT) designed by Castro and Liskov in 1999, the first of its kind with polynomial complexity. For a distributed system with $n$ nodes, the communication complexity is $O(n2$.) Castro and Liskov showed in the paper that by transforming centralized file system into a distributed one using the PBFT protocol, the overwall performance was only slowed down by 3%. In this section we will briefly introduce the PBFT protocol, paving the way for further detailed explanations of the Tendermint protocol and the improvements of the Tendermint protocol.
The PBFT protocol that includes $n=3f+1$ nodes can tolerate up to $f$ Byzantine nodes. In the original paper of PBFT, full connection is required among all the $n$ nodes, that is, any two of the n nodes must be connected. All the nodes of the network jointly maintain the system status through network communication. In the Bitcoin network, a node can participate in or exit the consensus process through hashrate mining at any time, which is managed by the administrator, and the PFBT protocol needs to determine all the participating nodes before the protocol starts. All nodes in the PBFT protocol are divided into two categories, master nodes, and slave nodes. There is only one master node at any time, and all nodes take turns to be the master node. All nodes run in a rotation process called View, in each of which the master node will be reelected. The master node selection algorithm in PBFT is very simple: all nodes become the master node in turn by the index number. In each view, all nodes try to reach a consensus on the system status. It is worth mentioning that in the PBFT protocol, each node has its own digital signature key pair. All sent messages (including request messages from the client) need to be signed to ensure the integrity of the message in the network and the traceability of the message itself. (You can determine who sent a message based on the digital signature).
The following figure shows the basic flow of the PBFT consensus protocol. Assume that the current view’s master node is node 0. Client C initiates a request to the master node 0. After the master node receives the request, it broadcasts the request to all slave nodes that process the request of client C and return the result to the client. After the client receives f+1 identical results from different nodes (based on the signature value), the result can be taken as the final result of the entire operation. Since the system can have at most f Byzantine nodes, at least one of the f+1 results received by the client comes from an honest node, and the security of the consensus protocol guarantees that all honest nodes will reach consensus on the same status. So, the feedback from 1 honest node is enough to confirm that the corresponding request has been processed by the system.

https://preview.redd.it/sz8so5ly7m851.png?width=1400&format=png&auto=webp&s=d472810e76bbc202e91a25ef29a51e109a576554
For the status synchronization of all honest nodes, the PBFT protocol has two constraints on each node: on one hand, all nodes must start from the same status, and on the other, the status transition of all nodes must be definite, that is, given the same status and request, the results after the operation must be the same. Under these two constraints, as long as the entire system agrees on the processing order of all transactions, the status of all honest nodes will be consistent. This is also the main purpose of the PBFT protocol: to reach a consensus on the order of transactions between all nodes, thereby ensuring the security of the entire distributed system. In terms of availability, the PBFT consensus protocol relies on a timeout mechanism to find anomalies in the consensus process and start the View Change protocol in time to try to reach a consensus again.
The figure above shows a simplified workflow of the PBFT protocol. Where C is the client, 0, 1, 2, and 3 represent 4 nodes respectively. Specifically, 0 is the master node of the current view, 1, 2, 3 are slave nodes, and node 3 is faulty. Under normal circumstances, the PBFT consensus protocol reaches consensus on the order of transactions between nodes through a three-phase protocol. These three phases are respectively: Pre-Prepare, Prepare, and Commit:
  • The master node of the pre-preparation node is responsible for assigning the sequence number to the received client request, and broadcasting the message to the slave node. The message contains the hash value of the client request d, the sequence number of the current viewv, the sequence number n assigned by the master node to the request, and the signature information of the master nodesig. The scheme design of the PBFT protocol separates the request transmission from the request sequencing process, and the request transmission is not to be discussed here. The slave node that receives the message accepts the message after confirming the message is legitimate and enter preparation phase. The message in this step checks the basic signature, hash value, current view, and, most importantly, whether the master node has given the same sequence number to other request from the client in the current view.
  • In preparation, the slave node broadcasts the message to all nodes (including itself), indicating that it assigns the sequence number n to the client request with the hash value d under the current view v, with its signaturesig as proof. The node receiving the message will check the correctness of the signature, the matching of the view sequence number, etc., and accept the legitimate message. When the PRE-PREPARE message about a client request (from the main node) received by a node matches with the PREPARE from 2f slave nodes, the system has agreed on the sequence number requested by the client in the current view. This means that 2f+1 nodes in the current view agree with the request sequence number. Since it contains information from at most fmalicious nodes, there are a total of f+1 honest nodes that have agreed with the allocation of the request sequence number. With f malicious nodes, there are a total of 2f+1 honest nodes, so f+1represents the majority of the honest nodes, which is the consensus of the majority mentioned before.
  • After the node (including the master node and the slave node) receives a PRE-PREPARE message requested by the client and 2f PREPARE messages, the message is broadcast across the network and enters the submission phase. This message is used to indicate that the node has observed that the whole network has reached a consensus on the sequence number allocation of the request message from the client. When the node receives 2f+1 COMMIT messages, there are at least f+1 honest nodes, that is, most of the honest nodes have observed that the entire network has reached consensus on the arrangement of sequence numbers of the request message from the client. The node can process the client request and return the execution result to the client at this moment.
Roughly speaking, in the pre-preparation phase, the master node assigns a sequence number to all new client requests. During preparation, all nodes reach consensus on the client request sequence number in this view, while in submission the consistency of the request sequence number of the client in different views is to be guaranteed. In addition, the design of the PBFT protocol itself does not require the request message to be submitted by the assigned sequence number, but out of order. That can improve the efficiency of the implementation of the consensus protocol. Yet, the messages are still processed by the sequence number assigned by the consensus protocol for the consistency of the distributed system.
In the three-phase protocol execution of the PBFT protocol, in addition to maintaining the status information of the distributed system, the node itself also needs to log all kinds of consensus information it receives. The gradual accumulation of logs will consume considerable system resources. Therefore, the PBFT protocol additionally defines checkpoints to help the node deal with garbage collection. You can set a checkpoint every 100 or 1000 sequence numbers according to the request sequence number. After the client request at the checkpoint is executed, the node broadcasts messages throughout the network, indicating that after the node executes the client request with sequence number n, the hash value of the system status is d, and it is vouched by its own signature sig. After 2f+1 matching CHECKPOINT messages (one of which can come from the node itself) are received, most of the honest nodes in the entire network have reached a consensus on the system status after the execution of the client request with the sequence numbern, and then you can clear all relevant log records of client requests with the sequence number less than n. The node needs to save these2f+1 CHECKPOINTmessages as proof of the legitimate status at this moment, and the corresponding checkpoint is called a stable checkpoint.
The three-phase protocol of the PBFT protocol can ensure the consistency of the processing order of the client request, and the checkpoint mechanism is set to help nodes perform garbage collection and further ensures the status consistency of the distributed system, both of which can guarantee the security of the distributed system aforementioned. How is the availability of the distributed system guaranteed? In the semi-synchronous network model, a timeout mechanism is usually introduced, which is related to delays in the network environment. It is assumed that the network delay has a known upper bound after GST. In such condition, an initial value is usually set according to the network condition of the system deployed. In case of a timeout event, besides the corresponding processing flow triggered, additional mechanisms will be activated to readjust the waiting time. For example, an algorithm like TCP's exponential back off can be adopted to adjust the waiting time after a timeout event.
To ensure the availability of the system in the PBFT protocol, a timeout mechanism is also introduced. In addition, due to the potential the Byzantine failure in the master node itself, the PBFT protocol also needs to ensure the security and availability of the system in this case. When the Byzantine failure occurs in the master node, for example, when the slave node does not receive the PRE-PREPARE message or the PRE-PREPARE message sent by the master node from the master node within the time window and is thus determined to be illegitimate, the slave node can broadcast to the entire network, indicating that the node requests to switch to the new view with sequence number v+1. n indicates the request sequence number corresponding to the latest stable checkpoint local to the node, and C is to prove the stable checkpoint 2f+1 legitimate CHECKPOINT messages as aforementioned. After the latest stable checkpoint and before initiating the VIEWCHANGE message, the system may have reached a consensus on the sequence numbers of some request messages in the previous view. To ensure the consistency of these request sequence numbers to be switched in the view, the VIEWCHANGE message needs to carry this kind of the information to the new view, which is also the meaning of the P field in the message. P contains all the client request messages collected at the node with a request sequence number greater than n and the proof that a consensus has been reached on the sequence number in the node: the legitimate PRE-PREPARE message of the request and 2f matching PREPARE messages. When the master node in view v+1 collects 2f+1 VIEWCHANGE messages, it can broadcast the NEW-VIEW message and take the entire system into a new view. For the security of the system in combination with the three-phase protocol of the PBFT protocol, the construction rules of the NEW-VIEW information are designed in a quite complicated way. You can refer to the original paper of PBFT for more details.

https://preview.redd.it/x5efdc908m851.png?width=1400&format=png&auto=webp&s=97b4fd879d0ec668ee0990ea4cadf476167a2948
VIEWCHANGE contains a lot of information. For example, C contains 2f+1 signature information, P contains several signature sets, and each set has 2f+1 signature. At least 2f+1 nodes need to send a VIEWCHANGE message before prompting the system to enter the next new view, and that means, in addition to the complex logic of constructing the information of VIEWCHANGE and NEW-VIEW, the communication complexity of the view conversion protocol is $O(n2$.) Such complexity also limits the PBFT protocol to support only a few nodes, and when there are 100 nodes, it is usually too complex to practically deploy PBFT. It is worth noting that in some materials the communication complexity of the PBFT protocol is inappropriately attributed to the full connection between n nodes. By changing the fully connected network topology to the P2P network topology based on distributed hash tables commonly used in blockchain projects, high communication complexity caused by full connection can be conveniently solved, yet still, it is difficult to improve the communication complexity during the view conversion process. In recent years, researchers have proposed to reduce the amount of communication in this step by adopting aggregate signature scheme. With this technology, 2f+1 signature information can be compressed into one, thereby reducing the communication volume during view change.
submitted by coinexchain to u/coinexchain [link] [comments]

Bitcoin (BTC)A Peer-to-Peer Electronic Cash System.

Bitcoin (BTC)A Peer-to-Peer Electronic Cash System.
  • Bitcoin (BTC) is a peer-to-peer cryptocurrency that aims to function as a means of exchange that is independent of any central authority. BTC can be transferred electronically in a secure, verifiable, and immutable way.
  • Launched in 2009, BTC is the first virtual currency to solve the double-spending issue by timestamping transactions before broadcasting them to all of the nodes in the Bitcoin network. The Bitcoin Protocol offered a solution to the Byzantine Generals’ Problem with a blockchain network structure, a notion first created by Stuart Haber and W. Scott Stornetta in 1991.
  • Bitcoin’s whitepaper was published pseudonymously in 2008 by an individual, or a group, with the pseudonym “Satoshi Nakamoto”, whose underlying identity has still not been verified.
  • The Bitcoin protocol uses an SHA-256d-based Proof-of-Work (PoW) algorithm to reach network consensus. Its network has a target block time of 10 minutes and a maximum supply of 21 million tokens, with a decaying token emission rate. To prevent fluctuation of the block time, the network’s block difficulty is re-adjusted through an algorithm based on the past 2016 block times.
  • With a block size limit capped at 1 megabyte, the Bitcoin Protocol has supported both the Lightning Network, a second-layer infrastructure for payment channels, and Segregated Witness, a soft-fork to increase the number of transactions on a block, as solutions to network scalability.

https://preview.redd.it/s2gmpmeze3151.png?width=256&format=png&auto=webp&s=9759910dd3c4a15b83f55b827d1899fb2fdd3de1

1. What is Bitcoin (BTC)?

  • Bitcoin is a peer-to-peer cryptocurrency that aims to function as a means of exchange and is independent of any central authority. Bitcoins are transferred electronically in a secure, verifiable, and immutable way.
  • Network validators, whom are often referred to as miners, participate in the SHA-256d-based Proof-of-Work consensus mechanism to determine the next global state of the blockchain.
  • The Bitcoin protocol has a target block time of 10 minutes, and a maximum supply of 21 million tokens. The only way new bitcoins can be produced is when a block producer generates a new valid block.
  • The protocol has a token emission rate that halves every 210,000 blocks, or approximately every 4 years.
  • Unlike public blockchain infrastructures supporting the development of decentralized applications (Ethereum), the Bitcoin protocol is primarily used only for payments, and has only very limited support for smart contract-like functionalities (Bitcoin “Script” is mostly used to create certain conditions before bitcoins are used to be spent).

2. Bitcoin’s core features

For a more beginner’s introduction to Bitcoin, please visit Binance Academy’s guide to Bitcoin.

Unspent Transaction Output (UTXO) model

A UTXO transaction works like cash payment between two parties: Alice gives money to Bob and receives change (i.e., unspent amount). In comparison, blockchains like Ethereum rely on the account model.
https://preview.redd.it/t1j6anf8f3151.png?width=1601&format=png&auto=webp&s=33bd141d8f2136a6f32739c8cdc7aae2e04cbc47

Nakamoto consensus

In the Bitcoin network, anyone can join the network and become a bookkeeping service provider i.e., a validator. All validators are allowed in the race to become the block producer for the next block, yet only the first to complete a computationally heavy task will win. This feature is called Proof of Work (PoW).
The probability of any single validator to finish the task first is equal to the percentage of the total network computation power, or hash power, the validator has. For instance, a validator with 5% of the total network computation power will have a 5% chance of completing the task first, and therefore becoming the next block producer.
Since anyone can join the race, competition is prone to increase. In the early days, Bitcoin mining was mostly done by personal computer CPUs.
As of today, Bitcoin validators, or miners, have opted for dedicated and more powerful devices such as machines based on Application-Specific Integrated Circuit (“ASIC”).
Proof of Work secures the network as block producers must have spent resources external to the network (i.e., money to pay electricity), and can provide proof to other participants that they did so.
With various miners competing for block rewards, it becomes difficult for one single malicious party to gain network majority (defined as more than 51% of the network’s hash power in the Nakamoto consensus mechanism). The ability to rearrange transactions via 51% attacks indicates another feature of the Nakamoto consensus: the finality of transactions is only probabilistic.
Once a block is produced, it is then propagated by the block producer to all other validators to check on the validity of all transactions in that block. The block producer will receive rewards in the network’s native currency (i.e., bitcoin) as all validators approve the block and update their ledgers.

The blockchain

Block production

The Bitcoin protocol utilizes the Merkle tree data structure in order to organize hashes of numerous individual transactions into each block. This concept is named after Ralph Merkle, who patented it in 1979.
With the use of a Merkle tree, though each block might contain thousands of transactions, it will have the ability to combine all of their hashes and condense them into one, allowing efficient and secure verification of this group of transactions. This single hash called is a Merkle root, which is stored in the Block Header of a block. The Block Header also stores other meta information of a block, such as a hash of the previous Block Header, which enables blocks to be associated in a chain-like structure (hence the name “blockchain”).
An illustration of block production in the Bitcoin Protocol is demonstrated below.

https://preview.redd.it/m6texxicf3151.png?width=1591&format=png&auto=webp&s=f4253304912ed8370948b9c524e08fef28f1c78d

Block time and mining difficulty

Block time is the period required to create the next block in a network. As mentioned above, the node who solves the computationally intensive task will be allowed to produce the next block. Therefore, block time is directly correlated to the amount of time it takes for a node to find a solution to the task. The Bitcoin protocol sets a target block time of 10 minutes, and attempts to achieve this by introducing a variable named mining difficulty.
Mining difficulty refers to how difficult it is for the node to solve the computationally intensive task. If the network sets a high difficulty for the task, while miners have low computational power, which is often referred to as “hashrate”, it would statistically take longer for the nodes to get an answer for the task. If the difficulty is low, but miners have rather strong computational power, statistically, some nodes will be able to solve the task quickly.
Therefore, the 10 minute target block time is achieved by constantly and automatically adjusting the mining difficulty according to how much computational power there is amongst the nodes. The average block time of the network is evaluated after a certain number of blocks, and if it is greater than the expected block time, the difficulty level will decrease; if it is less than the expected block time, the difficulty level will increase.

What are orphan blocks?

In a PoW blockchain network, if the block time is too low, it would increase the likelihood of nodes producingorphan blocks, for which they would receive no reward. Orphan blocks are produced by nodes who solved the task but did not broadcast their results to the whole network the quickest due to network latency.
It takes time for a message to travel through a network, and it is entirely possible for 2 nodes to complete the task and start to broadcast their results to the network at roughly the same time, while one’s messages are received by all other nodes earlier as the node has low latency.
Imagine there is a network latency of 1 minute and a target block time of 2 minutes. A node could solve the task in around 1 minute but his message would take 1 minute to reach the rest of the nodes that are still working on the solution. While his message travels through the network, all the work done by all other nodes during that 1 minute, even if these nodes also complete the task, would go to waste. In this case, 50% of the computational power contributed to the network is wasted.
The percentage of wasted computational power would proportionally decrease if the mining difficulty were higher, as it would statistically take longer for miners to complete the task. In other words, if the mining difficulty, and therefore targeted block time is low, miners with powerful and often centralized mining facilities would get a higher chance of becoming the block producer, while the participation of weaker miners would become in vain. This introduces possible centralization and weakens the overall security of the network.
However, given a limited amount of transactions that can be stored in a block, making the block time too longwould decrease the number of transactions the network can process per second, negatively affecting network scalability.

3. Bitcoin’s additional features

Segregated Witness (SegWit)

Segregated Witness, often abbreviated as SegWit, is a protocol upgrade proposal that went live in August 2017.
SegWit separates witness signatures from transaction-related data. Witness signatures in legacy Bitcoin blocks often take more than 50% of the block size. By removing witness signatures from the transaction block, this protocol upgrade effectively increases the number of transactions that can be stored in a single block, enabling the network to handle more transactions per second. As a result, SegWit increases the scalability of Nakamoto consensus-based blockchain networks like Bitcoin and Litecoin.
SegWit also makes transactions cheaper. Since transaction fees are derived from how much data is being processed by the block producer, the more transactions that can be stored in a 1MB block, the cheaper individual transactions become.
https://preview.redd.it/depya70mf3151.png?width=1601&format=png&auto=webp&s=a6499aa2131fbf347f8ffd812930b2f7d66be48e
The legacy Bitcoin block has a block size limit of 1 megabyte, and any change on the block size would require a network hard-fork. On August 1st 2017, the first hard-fork occurred, leading to the creation of Bitcoin Cash (“BCH”), which introduced an 8 megabyte block size limit.
Conversely, Segregated Witness was a soft-fork: it never changed the transaction block size limit of the network. Instead, it added an extended block with an upper limit of 3 megabytes, which contains solely witness signatures, to the 1 megabyte block that contains only transaction data. This new block type can be processed even by nodes that have not completed the SegWit protocol upgrade.
Furthermore, the separation of witness signatures from transaction data solves the malleability issue with the original Bitcoin protocol. Without Segregated Witness, these signatures could be altered before the block is validated by miners. Indeed, alterations can be done in such a way that if the system does a mathematical check, the signature would still be valid. However, since the values in the signature are changed, the two signatures would create vastly different hash values.
For instance, if a witness signature states “6,” it has a mathematical value of 6, and would create a hash value of 12345. However, if the witness signature were changed to “06”, it would maintain a mathematical value of 6 while creating a (faulty) hash value of 67890.
Since the mathematical values are the same, the altered signature remains a valid signature. This would create a bookkeeping issue, as transactions in Nakamoto consensus-based blockchain networks are documented with these hash values, or transaction IDs. Effectively, one can alter a transaction ID to a new one, and the new ID can still be valid.
This can create many issues, as illustrated in the below example:
  1. Alice sends Bob 1 BTC, and Bob sends Merchant Carol this 1 BTC for some goods.
  2. Bob sends Carols this 1 BTC, while the transaction from Alice to Bob is not yet validated. Carol sees this incoming transaction of 1 BTC to him, and immediately ships goods to B.
  3. At the moment, the transaction from Alice to Bob is still not confirmed by the network, and Bob can change the witness signature, therefore changing this transaction ID from 12345 to 67890.
  4. Now Carol will not receive his 1 BTC, as the network looks for transaction 12345 to ensure that Bob’s wallet balance is valid.
  5. As this particular transaction ID changed from 12345 to 67890, the transaction from Bob to Carol will fail, and Bob will get his goods while still holding his BTC.
With the Segregated Witness upgrade, such instances can not happen again. This is because the witness signatures are moved outside of the transaction block into an extended block, and altering the witness signature won’t affect the transaction ID.
Since the transaction malleability issue is fixed, Segregated Witness also enables the proper functioning of second-layer scalability solutions on the Bitcoin protocol, such as the Lightning Network.

Lightning Network

Lightning Network is a second-layer micropayment solution for scalability.
Specifically, Lightning Network aims to enable near-instant and low-cost payments between merchants and customers that wish to use bitcoins.
Lightning Network was conceptualized in a whitepaper by Joseph Poon and Thaddeus Dryja in 2015. Since then, it has been implemented by multiple companies. The most prominent of them include Blockstream, Lightning Labs, and ACINQ.
A list of curated resources relevant to Lightning Network can be found here.
In the Lightning Network, if a customer wishes to transact with a merchant, both of them need to open a payment channel, which operates off the Bitcoin blockchain (i.e., off-chain vs. on-chain). None of the transaction details from this payment channel are recorded on the blockchain, and only when the channel is closed will the end result of both party’s wallet balances be updated to the blockchain. The blockchain only serves as a settlement layer for Lightning transactions.
Since all transactions done via the payment channel are conducted independently of the Nakamoto consensus, both parties involved in transactions do not need to wait for network confirmation on transactions. Instead, transacting parties would pay transaction fees to Bitcoin miners only when they decide to close the channel.
https://preview.redd.it/cy56icarf3151.png?width=1601&format=png&auto=webp&s=b239a63c6a87ec6cc1b18ce2cbd0355f8831c3a8
One limitation to the Lightning Network is that it requires a person to be online to receive transactions attributing towards him. Another limitation in user experience could be that one needs to lock up some funds every time he wishes to open a payment channel, and is only able to use that fund within the channel.
However, this does not mean he needs to create new channels every time he wishes to transact with a different person on the Lightning Network. If Alice wants to send money to Carol, but they do not have a payment channel open, they can ask Bob, who has payment channels open to both Alice and Carol, to help make that transaction. Alice will be able to send funds to Bob, and Bob to Carol. Hence, the number of “payment hubs” (i.e., Bob in the previous example) correlates with both the convenience and the usability of the Lightning Network for real-world applications.

Schnorr Signature upgrade proposal

Elliptic Curve Digital Signature Algorithm (“ECDSA”) signatures are used to sign transactions on the Bitcoin blockchain.
https://preview.redd.it/hjeqe4l7g3151.png?width=1601&format=png&auto=webp&s=8014fb08fe62ac4d91645499bc0c7e1c04c5d7c4
However, many developers now advocate for replacing ECDSA with Schnorr Signature. Once Schnorr Signatures are implemented, multiple parties can collaborate in producing a signature that is valid for the sum of their public keys.
This would primarily be beneficial for network scalability. When multiple addresses were to conduct transactions to a single address, each transaction would require their own signature. With Schnorr Signature, all these signatures would be combined into one. As a result, the network would be able to store more transactions in a single block.
https://preview.redd.it/axg3wayag3151.png?width=1601&format=png&auto=webp&s=93d958fa6b0e623caa82ca71fe457b4daa88c71e
The reduced size in signatures implies a reduced cost on transaction fees. The group of senders can split the transaction fees for that one group signature, instead of paying for one personal signature individually.
Schnorr Signature also improves network privacy and token fungibility. A third-party observer will not be able to detect if a user is sending a multi-signature transaction, since the signature will be in the same format as a single-signature transaction.

4. Economics and supply distribution

The Bitcoin protocol utilizes the Nakamoto consensus, and nodes validate blocks via Proof-of-Work mining. The bitcoin token was not pre-mined, and has a maximum supply of 21 million. The initial reward for a block was 50 BTC per block. Block mining rewards halve every 210,000 blocks. Since the average time for block production on the blockchain is 10 minutes, it implies that the block reward halving events will approximately take place every 4 years.
As of May 12th 2020, the block mining rewards are 6.25 BTC per block. Transaction fees also represent a minor revenue stream for miners.
submitted by D-platform to u/D-platform [link] [comments]

Consensus for Dummies - The Byzantine General's Problem The Byzantine Generals Problem - An Intro To Blockchain ... The Byzantine Generals Problem and Blockchain Consensus ... Bitcoin Q&A: Honest nodes and consensus Bitcoin einfach erklärt Teil 1 - Der byzantinische Fehler

Mining works on the “proof-of-work” principle. Proof-of-work, basically means this: Solving a problem must be extremely difficult, but once you solve it, proving that the solution is correct should be simple. WHY was proof-of-work was required in the first place? One of the ma . DARNLEY MINING® BITCOIN MINING AT ITS VERY BEST. Enquiries: +44 800 206 2265 (FREE CALL) WhatsApp: +44 7391 346 ... How Bitcoin Blockchain Solves This Problem. With Bitcoin, Byzantine Generals problem turns into an even more complicated beast. The number of generals increases, and now each one of them needs to communicate their intentions to every other general safely and quickly. At the same time the number of malicious players and possible traitors increases, meaning that every one of them needs to be ... The Byzantine Generals Problem is a computer-related problem consisting in finding an agreement by communicating through messages between the different components of the network. But Bitcoin solved it.. This is a problem that was theorised by the mathematicians Leslie Lamport, Marshall Pease and Robert Shostak in 1982, who created the metaphor of the generals. The problem of the Byzantine Generals. Prior to Bitcoin, this problem was considered perhaps impossible to solve. Computer scientists declared in 1982 that the generals’ problem can at most be ... Origin. Byzantine refers to the Byzantine Generals' Problem, an agreement problem (described by Leslie Lamport, Robert Shostak and Marshall Pease in their 1982 paper, "The Byzantine Generals Problem") in which a group of generals, each commanding a portion of the Byzantine army, encircle a city.

[index] [3144] [43560] [30628] [29632] [42] [5871] [18588] [46924] [321] [31653]

Consensus for Dummies - The Byzantine General's Problem

Close. This video is unavailable. To learn more about Blockchain, please visit the full district0x education portal here: https://education.district0x.io/ Learning about Blockchain, Bitcoin a... Byzantine Generals Problem / Solution Blockchain Technology Learn how you can purchase $25 dollars worth of mining hardware rental agreements that are in 156 week contracts that has seen as high ... Satoshi Nakamoto, the creator of Bitcoin, developed the Proof of Work Puzzle to tackle the Byzantine Generals’ Problem. The puzzle is a challenge where miners compete against each other to ... These questions are from the MOOC sessions 7.2, 8.2, and 9.2 covering the Byzantine Generals' Problem, which took place on February 26th 2017, September 15th 2017, and February 23rd 2018 ...

#