What is Decred? The Most Comprehensive Guide Ever!
Decred is one of the most promising and undervalued projects out there. While we have many interesting cryptocurrencies out there, the majority of them suffer from governance issues. Decred (short for Decentralized Credit) brings with it decentralized governance and decision-making on the blockchain and is built to evolve according to the improvements voted on by the miners AND the holders.
Governance Issues with Bitcoin
Bitcoin is an open-sourced protocol, where any developer can volunteer to manage and improve upon the protocol. Theoretically speaking, users can choose whether or not they want to go with the protocol that the developers have created. Whichever version gets the most user support, becomes the main protocol.
In reality, though, it is the miners who tend to define the flow of the protocol. The reason why this happens is that of the proof-of-work (POW) model (more on that later). In a POW model, miners find new blocks and they get 100% of the full block reward, leaving nothing for the users.
There is another major problem.
For a decentralized peer-to-peer network like Bitcoin, hashing power is absolutely critical for its long-time survival. Hashing power or hash rate is basically the number of computational powers that the network has. More the hashing power, more the computational power and hence more the security, speed, and efficiency of the network.
In an ideal scenario, the hashrate of a decentralized system should be more or less evenly distributed. Let’s check the hashrate distribution pie-chart of Bitcoin:
Wow… that doesn’t look ideal.
70% of the network’s hashrate is distributed between 5 mining pools. 3 mining pools can combine their resources and launch a 51% attack on the network!
That adds further fuel to two facts:
- Bitcoin is not as decentralized as we want it to be
- The mining pools and hence the companies behind these pools have a tremendous amount of power in the overall direction of the bitcoin.
The blocksize debate has shown this time and time again. If not satisfied with the protocol, then a group of miners can get together and simply fork off from the main chain to create their own version of Bitcoin.
A Slight Detour: What are forks?
Before we continue, we realized that we have used the term “forks” a lot already. For those who are in the know, you can skip this section.
A fork is a condition whereby the state of the blockchain diverges into chains where a part of the network has a different perspective on the history of transactions than a different part of the network. That is basically what a fork is, it is a divergence in the perspective of the state of the blockchain.
As we have discussed before, there are two kinds of forks:
- Soft Fork.
- Hard Fork.
What Is A Soft Fork?
Whenever a chain needs to be updated there are two ways of doing that: a soft fork or a hard fork. Think of soft fork as an update in the software which is backward compatible. What does that mean? Suppose you are running MS Excel 2005 on your laptop and you want to open a spreadsheet built in MS Excel 2015, you can still open it because MS Excel 2015 is backward compatible.
BUT, having said that there is a difference. All the updates that you can enjoy the newer version won’t be visible to you in the older version. Going back to our MS excel analogy again, suppose there is a feature which allows to put in GIFs in the spreadsheet in the 2015 version, you won’t see those GIFs in the 2005 version. So basically, you will see all text but won’t see the GIF.
What Is A Hard Fork?
The primary difference between a soft fork and hard fork is that it is not backward compatible. Once it is utilized there is absolutely no going back whatsoever. If you do not join the upgraded version of the blockchain then you do not get access to any of the new updates or interact with users of the new system whatsoever. Think Playstation 3 and Playstation 4. You can’t play PS3 games in PS4 and you can’t play PS4 games in PS3.
Andreas Antonopoulos describes the difference between hard and soft fork like this: If a vegetarian restaurant would choose to add pork to their menu it would be considered to be a hard fork. if they would decide to add vegan dishes, everyone who is vegetarian could still eat vegan, you don’t have to be vegan to eat there, you could still be vegetarian to eat there and meat eaters could eat there too so that’s a soft fork.
Ok, so now you must know what forks, hard forks, and soft forks are. Let’s continue now.
Governance Issues with Bitcoin (cont.)
Over the last year Bitcoin has experienced numerous forks. Majority of these forks have been centered around the blocksize debate.
When bitcoin was first created, the developers put the 1mb size limit by design because they wanted to cut down on the spam transactions which may clog up the entire bitcoin network.
However, as the number of Bitcoin transactions increased by leaps and bounds, the rate at which the blocks filled up were increasing as well. More often than not, people actually had to wait till new blocks were created so that their transactions would go through. This created a backlog of transactions, in fact the only way to get your transactions prioritized is to pay a high enough transaction fee to attract and incentivize the miners to prioritize your transactions.
This issue split up the Bitcoin community.
There was one group (mainly miners) who wanted a higher blocksize limit, while there was another group that wanted to keep the blocksize as is before a better innovation can be implemented.
The most successful fork that came out of this debacle was Bitcoin Cash.
This is how Bitcoin Cash project website is defining itself: “Bitcoin Cash is peer-to-peer electronic cash for the Internet. It is fully decentralized, with no central bank and requires no trusted third parties to operate.” Did you notice the emphasis on the words “peer-to-peer electronic cash”?
It is done by design because the primary motivation of bitcoin cash’s existence depends solely on carrying out more transactions as Jimmy Song points out in his Medium article.
Bitcoin Cash (BCH) is a lot like Bitcoin but has some very noticeable differences:
- The blocksize is 8 mb.
- It won’t have Segwit.
- It won’t have the “replace by fee” feature.
- It will have replay and wipeout protection.
- It offers a way to adjust the proof-of-work difficulty quicker than the normal 2016 block difficulty adjustment interval found in Bitcoin.
Problem with Repeated Hard Forks.
The problem with this repeated forking is that these chains have billions of dollars stored and invested inside them. Firstly, they are extremely harmful to investor sentiment and fractures the Bitcoin community.
Secondly, the newly forked coins are vulnerable to attacks. On 29th May, Bitcoin gold, a fork of the original Bitcoin blockchain, became the largest public blockchain to be hit by the 51% attack. The attacker took temporary control of the blockchain and was able to double-spend their transactions. Approximately 388,000 BTG (worth $17.8 million at the time) were stolen.
However, the worst thing is that it completely undermines the economic aspect of cryptocurrencies.
As the blockchain director at Loomia, Sol Lederer puts it, “These forks are very bad for bitcoin. Saturating the market with different versions of bitcoin is confusing to users, and discredits the claim that there are a limited number of bitcoins — since you can always fork it and double the supply.”
Decred aims to reduce or eliminate hard forks, especially ones that divide the community. While a hard fork is possible on Decred, and in fact Decred recently navigated the first fully user-driven hard fork, Decred’s voting protocol makes it so that users can vote on changes before activation.
We are going to go through the various mechanisms that Decred is looking to implement for smooth, efficient, and fair governance.
Decred and the POW-POS Hybrid
Decred uses a proof-of-stake and proof-of-work hybrid mechanism. Proof-of-work and proof-of-stake are pretty much the two most popular consensus mechanisms out there. In order to understand why Decred opted for a hybrid method, let’s look at both of them individually.
Proof of Work
First let’s look into POW. Miners in POW chains have the responsibility of growing the blockchain by continuously finding newer blocks. The way they discover or “mine” for these blocks is by doing continuous computation which requires a lot of processor speed.
They take the hash of the block and append a “nonce” to it. The nonce is a random hexadecimal value. The resultant string is then hashed again. This new hashed value must be less than a pre-determined value which is called “difficulty.” The miners must keep on continuously changing the value of the nonce until they get the required result.
IF a miner somehow finds a block then they must present the newly found block to the network along with the nonce. The network can then simply append the two values and hash it to check the validity of the claim.
This is the essence of proof-of-work:
- Solving the possible and finding the right nonce should be extremely difficult.
- Checking whether the nonce is correct or not should be easy.
The proof-of-work mechanism definitely answered a lot of questions when it came to solving the Byzantine General’s Problem, but unfortunately, there are some issues with proof-of-work.
- First and foremost, proof of work is an extremely inefficient process because of the sheer amount of power and energy that it eats up.
- People and organizations that can afford faster and more powerful ASICs usually have a better chance of mining than the others.
- As we have already seen, POW results in a centralized distribution of the hashrate.
Proof-of-work definitely has a proven track record and it shows a novel way of creating a consensus mechanism where the participants (miners) have to act in an honest manner. However, as we have seen before, it is not a great governance system because it puts too much power on the hands of the miners.
Now let’s look into Proof of Stake.
Proof of Stake
Proof of Stake of POS has gained a lot of attention lately because of Ethereum, who are looking to transition from POS to POW.
Proof of stake will make the entire mining process virtual and replace miners with validators.
This is how the process will work:
- The validators will have to lock up some of their coins as stake.
- After that, they will start validating the blocks. Meaning, when they discover a block which they think can be added to the chain, they will validate it by placing a bet on it.
- If the block gets appended, then the validators will get a reward proportionate to their bets.
As you can see, the POS protocol is a lot more resource-friendly than POW. In POW you NEED to waste a lot of resources to go along with the protocol, it is basically resource wastage for the sake of resource wastage.
POS, however, is not without its weakness.
Consider this scenario for a moment:
Suppose we have a situation like the one above. There are a main blue chain and a red chain which sort of branches from the main itself. What is there to stop a malicious miner from mining on the red blocks and force a hard for?
In a proof-of-work(POW) system, this action will have heavy consequences.
Suppose malicious miner Alice wants to mine on the red chain. Even if she dedicates all of her hash power to it, she won’t get any other miner to join her on the new chain. Everyone else will still continue to mine on the blue chain because it is more profitable and risk-free to mine on the longer chain.
Now, remember, POW is extremely expensive resource-wise.
It makes no sense for a miner to waste so much resource on a block that will be rejected by the network anyway. Hence chain splits are avoided in a proof of work system because of the amount of money that the attacker will have to waste.
However, things look a little different when you bring in POS.
If you are a validator, then you can simply put your money in both the red chain and blue chain without any fear of repercussion at all. No matter what happens, you will always win and have nothing to lose, despite how malicious your actions may be.
This is called the “Nothing at Stake” problem.
Ethereum plans to get rid of this problem via the implementation of the Casper protocol, which will straight up slash away the validator’s stake in case they don’t act in the interest of the system. However, it may across as too harsh. What if the validator had a genuine reason to not be present during the time of his validation? What if they made an honest mistake?
Surely slashing away their stake is too harsh a punishment?
This why Decred chose to go with a hybrid POW-POS solution which:
- Gives the validators a voice in the system and not just the miners.
- Makes sure that the participants have “skin in the game.”
How does the Hybrid POW-POS work?
The basic mechanism of the hybrid POW-POS system is this:
- Miners mine for a block in the Decred system using POW.
- 5 Validators with stake in the system and randomly chosen to verify the block.
- If 3 out of the 5 validators consent to the validity of the block, then it gets added to the blockchain.
- 60% of the block reward goes to the miners, 30% goes to the validators, and 10% goes to a Decred project fund for further protocol improvement.
Technically, if >=3 out of 5 validators voted (either yes/no), the block will get added to the chain. The PoW reward scales with the number of votes (miners are encouraged to include 5 votes if they can). If there is no >60% majority of yes votes, the block is disregarded and then the miner won’t get any rewards.
60% of the block reward goes to the miners, 30% goes to the validators,
The POW part works the same way as Bitcoin.
The POS part however, requires a little explanation. Anyone who owns DCR can be part of the staking system. This is how it works:
- DCR holders can buy tickets using their tokens which allows them to be part of the system.
- Each block can only take 20 tickets at a time. You may have to wait to get mined in the block. If you want to get mined quicker then you will have pay some fees.
- Once mined, your ticket will be considered “immature” and held outside the lottery pool until 256 blocks, which is roughly 20 hours, have passed.
- When your ticket enters the lottery pool, you will need to wait your chance to be one of the 5 validators who are randomly chosen to take part in the validation process.
- The system is designed such that a ticket has a 50% chance of being chosen within 28 days and 99.5% of being chosen before it expires (~4 months).
The Decred staking system is also less harsh. Validators can become part of staking pools. So, in case a validator can’t make it in time to be part of the validation process they can simply tell their pool to validate for them.
As you can see, Decred gives a voice to both users and miners to take part in the system. Why does this hybrid system ensure that Decred doesn’t get taken over by miners which may result in multiple hard-forks?
If a miner does mine a malicious block, i.e. something that is not part of the main chain and attempts a fork, the validators can simply reject the block. Since POW takes so much computational power, the miners simply don’t have the incentive to keep gunning for a fork which won’t be approved by the validators.
Security of POS/POW Hybrid
How secure is the POS/POW hybrid?
Zubair Zia, in his article, wanted to test the security of the Decred when compared to a purely POW chain like Bitcoin. He wanted to check which chain will be easier to take over via the 51% attack.
For his calculations, he stated that he will use BITMAIN’s Antminer s9i’s, which hashes at around 14 TH/s and costs around 837$. This is the result of his calculations:
Turns out, it is nearly 22 times as expensive to launch a 51% attack on Decred as compared to Bitcoin.
Governance of the Decred System
Alright, now that we know about one of the pillars of the Decred ecosystem i.e. the POW-POS hybrid, let’s come over to the second one. One of the main features that makes Decred special is its elegant governance mechanism. Firstly, let’s talk about the funding.
Decred has never done an ICO nor does it take any fundings from private organizations. What it does do, is follow a self-funding model (similar to Dash.) As we have already mentioned, 10% of every block reward goes into development. This ensures that there is constant liquidity present for future development.
Currently the funds are in the control of Decred Holdings Group LLC and is centralized, however, the Decred community is planning to decentralize these funds via DAOs (Decentralized Autonomous Organizations). A DAO is an entity that can run by itself without human intervention (except in the beginning) via smart contracts. A DAO is basically an automated, self-governing and non-corruptible organization. Decred plans to hand over the responsibility of fund distribution to the stakeholders.
This is a general overview of how future protocol improvement will work:
- Anyone in the Decred community can submit a DIP (Decred Improvement Proposal) for a small fee (to reduce spam).
- Stake holders can then vote on the proposals that they want to fund.
- Once approved, users can create decentralized autonomous entity (DAEs) to release the required funds.
Decred’s project lead, Jake Yocom-Piatt , explains it thus, “For most practical purposes, you can consider a DAO and a DAE to be identical in function. For Decred, there will be the project-level Decred DAO, which is effectively a government entity whose actions are dictated by the stakeholders, and then individual users can form their own DAEs, similar to how you or I could form a C-corporation or LLC here in the U.S. to start a business.”
The DAO and DAEs will exist on-chain, however, the proposals will NOT be submitted on-chain. This is where we come into another interesting Decred feature, the “Politeia.”
What is the Politeia?
Politeia is an ancient Greek word used in Greek political thought, especially that of Plato and Aristotle. Derived from the word polis (“city-state”), it has a range of meanings from “the rights of citizens” to a “form of government”.
Decred’s Politeia, a proposed system that is part of Decred’s governance system. It combines the idea of a git repository with cryptographic hash functions. Politeia doesn’t exist on the Decred blockchain but is anchored to it via time stamps (more on this later).
You are probably asking, why isn’t the data stored on the blockchain? The reason is that it doesn’t need to be.
Most of this content will be pretty contentious, so there is no need to overload the blockchain with the data. If we store all these several proposals in the blockchain, it will just lead to unnecessary bloating. Which also means that very few people will be able to run a full node, and hence Decred will become more centralized.
We don’t need to decentralize something just for the sake of decentralization. However, accountability needs to be there which is why Politeia anchors the proposals with cryptographic time-stamps. Think of Decred as a country and Politeia as a government website where the citizens can submit their proposals for improvement.
So, how does this work?
According to Wikipedia, “Git” is a version control system for tracking changes in computer files and coordinating work on those files among multiple people. So, if you are open-sourcing your software, Git is a great place for several software developers all over the world to work together on developing your software”.
There is one little problem though.
Note: The Decred youtube channel explains this issue quite brilliantly. You can checkout the video here.
Suppose a software developer posts a proposal on Git asking for some funding. They can easily change the timestamp of their proposal with a single command. Now, why is this bad?
A malicious developer can get their proposal funded, and then change the proposal, and change the timestamp as well. This can make it seem like the changes were introduced before the community voted to get his proposal funded. This can open a potential Pandora’s box. Imagine how many malicious elements will simply not give out all the details of their proposal to make sure that they get a higher funding.
Politeia needed a system where everyone can know what exactly was voted on and to make sure that the proposals weren’t tampered with in any way. This is where the concept of “dcrtime” time comes in, which is based on the open timestamps project.
The purpose of dcrtime is pretty simple. Verify the authenticity of the documents using blockchain, without storing those documents on the blockchain.
How do we do that?
Enter cryptographic hash functions and Merkle trees.
What is Hashing?
In simple terms, hashing means taking an input string of any length and giving out an output of a fixed length. In the context of cryptocurrencies like bitcoin, the transactions are taken as an input and run through a hashing algorithm (bitcoin uses SHA-256) which gives an output of a fixed length.
Let’s see how the hashing process works. We are going to put in certain inputs. For this exercise, we are going to use the SHA-256 (Secure Hashing Algorithm 256).
As you can see, in the case of SHA-256, no matter how big or small your input is, the output will always have a fixed 256-bits length. This becomes critical when you are dealing with a huge amount of data and transactions. So basically, instead of remembering the input data which could be huge, you can just remember the hash and keep track. Before we go any further we need to first see the various properties of hashing functions and how they get implemented in the blockchain.
Cryptographic Hash Functions
A cryptographic hash function is a special class of hash functions which has various properties making it ideal for cryptography. There are certain properties that a cryptographic hash function needs to have in order to be considered secure. Let’s run through them one by one.
Property 1: Deterministic
This means that no matter how many times you parse a particular input through a hash function you will always get the same result. This is critical because if you get different hashes every single time it will be impossible to keep track of the input.
Property 2: Quick Computation
The hash function should be capable of returning the hash of an input quickly. If the process isn’t fast enough then the system simply won’t be efficient.
Property 3: Pre-Image Resistance
What pre-image resistance states is that given H(A) it is infeasible to determine A, where A is the input and H(A) is the output hash. Notice the use of the word “infeasible” instead of “impossible”. We already know that it is not impossible to determine the original input from its hash value. Let’s take an example.
Suppose you are rolling a dice and the output is the hash of the number that comes up from the dice. How will you be able to determine what the original number was? It’s simple all that you have to do is to find out the hashes of all numbers from 1-6 and compare. Since hash functions are deterministic, the hash of a particular input will always be the same, so you can simply compare the hashes and find out the original input.
But this only works when the given amount of data is very less. What happens when you have a huge amount of data? Suppose you are dealing with a 128-bit hash. The only method that you have to find the original input is by using the “brute-force method”. Brute-force method basically means that you have to pick up a random input, hash it and then compare the output with the target hash and repeat until you find a match.
So, what will happen if you use this method?
Best case scenario: You get your answer on the first try itself. You will seriously have to be the luckiest person in the world for this to happen. The odds of this happening are astronomical.
Worst case scenario: You get your answer after 2^128 – 1 times. Basically, it means that you will find your answer at the end of all the data.
Average scenario: You will find it somewhere in the middle so basically after 2^128/2 = 2^127 times. To put that into perspective, 2^127 = 1.7 X 10^38. In other words, it is a huge number.
So, while it is possible to break pre-image resistance via brute force method, it takes so long that it doesn’t matter.
Property 4: Small Changes In The Input Changes the Hash.
Even if you make a small change in your input, the changes that will be reflected in the hash will be huge. Let’s test it out using SHA-256:
You see that? Even though you just changed the case of the first alphabet of the input, look at how much that has affected the output hash. This is a critical function because this property of hashing leads to one of the greatest qualities of the blockchain, its immutability (more on that later.)
Property 5: Collision Resistant
Given two different inputs A and B where H(A) and H(B) are their respective hashes, it is infeasible for H(A) to be equal to H(B). What that means is that for the most part, each input will have its own unique hash. Why did we say “for the most part”? In order to understand that, we need to know what “The Birthday Paradox” is.
What is the Birthday Paradox?
If you meet any random stranger out on the streets the chances are very low for both of you to have the same birthday. In fact, assuming that all days of the year have the same likelihood of having a birthday, the chances of another person sharing your birthday is 1/365 which is a 0.27%. In other words, it is really low.
However, having said that, if you gather up 20-30 people in one room, the odds of two people sharing the exact same birthday rises up astronomically. In fact, there is a 50-50 chance for 2 people sharing the same birthday in this scenario!
Why does that happen? It is because of a simple rule in probability which goes as follows. Suppose you have N different possibilities of an event happening, then you need square root of N random items for them to have a 50% chance of a collision.
So applying this theory for birthdays, you have 365 different possibilities of birthdays, so you just need Sqrt(365), which is ~23~, randomly chosen people for 50% chance of two people sharing birthdays.
What is the application of this in hashing?
Suppose you have a 128-bit hash which has 2^128 different possibilities. By using the birthday paradox, you have a 50% chance to break the collision resistance at the sqrt(2^128) = 2^64th instance.
As you can see, it is much easier to break collision resistance than it is to break pre-image resistance. No hash function is collision free, but it usually takes so long to find a collision. So, if you are using a function like SHA-256, it is safe to assume that if H(A) = H(B) then A = B.
Property 6: Puzzle Friendly
Now, this is a very fascinating property, and the application and impact that this one property has had on cryptocurrency is huge (more on that later when we cover mining and crypto puzzles). First let’s define the property, after that we will go over each term in detail.
For every output “Y”, if k is chosen from a distribution with high min-entropy it is infeasible to find an input x such that H(k|x) = Y.
That probably went all over your head! But it’s ok, let’s now understand what that definition means.
What is the meaning of “high min-entropy”?
It means that the distribution from which the value is chosen is hugely distributed so much so that us choosing a random value has negligible probability. Basically, if you were told to chose a number between 1 and 5, that’s a low min-entropy distribution. However, if you were to choose a number between 1 and a gazillion, that is a high min-entropy distribution.
What does “k|x” mean?
The “|” denotes concatenation. Concatenation means adding two strings together. Eg. If I were to concatenate “BLUE” and “SKY” together, then the result will be “BLUESKY”.
So now let’s revisit the definition.
Suppose you have an output value “Y”. If you choose a random value “k” from a wide distribution, it is infeasible to find a value X such that the hash of the concatenation of k and x will give the output Y.
Once again, notice the word “infeasible”, it is not impossible because people do this all the time. In fact, the whole process of mining works upon this (more on that later).
Examples of cryptographic hash functions
- MD 5: It produces a 128-bit hash. Collision resistance was broken after ~2^21 hashes.
- SHA 1: Produces a 160-bit hash. Collision resistance broke after ~2^61 hashes.
- SHA 256: Produces a 256-bit hash. This is currently being used by bitcoin.
- Keccak-256: Produces a 256-bit hash and is currently used by Ethereum.
What are Merkle Trees?
Image Courtesy: Wikipedia
The above diagram shows what a Merkle tree looks like. In a Merkle tree, each non-leaf node is the hash of the values of their child nodes.
Leaf Node: The leaf nodes are the nodes in the lowest tier of the tree. So wrt the diagram above, the leaf nodes will be L1, L2, L3, and L4.
Child Nodes: For a node, the nodes below its tier which are feeding into it are its child nodes. Wrt the diagram, the nodes labeled “Hash 0-0” and “Hash 0-1” are the child nodes of the node labeled “Hash 0”.
Root Node: The single node on the highest tier labelled “Top Hash” is the root node.
So what does a Merkle Tree have to do with blockchains?
Each block contains thousands and thousands of transactions. It will be very time inefficient to store all the data inside each block as a series. Doing so will make finding any particular transaction extremely cumbersome and time-consuming. If you use a Merkle tree, however, you will greatly cut down the time required to find out whether a particular transaction belongs in that block or not.
Let’s see this in an example. Consider the following Merkle tree:
Image courtesy: Coursera
Now suppose I want to find out whether this particular data belongs in the block or not:
Instead of going through the cumbersome process of looking at each individual hash and seeing whether it belongs to the data or not, you can simply track it down by following the trail of hashes leading up to the data:
Doing this significantly reduces the time taken.
Back to dcrtime and Politeia
So, now that you know what Hashing and Merkle Tree means. Let’s go back to dcrtime and Politeia.
The dcrtime will have two sides to it: the client side and the server side. If you want to timestamp a submitted proposal, you need to use the dcrtime client to convert the file into a hash and submit it to the dcrtime server. The dcrtime server is a centralized server which is controlled by Decred. The server’s job is to collect all these hashes and convert all these hashes into a Merkle tree and store the Merkle root onto the Decred blockchain.
Using this, one can easily check the authenticity of the documents by tracing down from the Merkle Root.
Politeia Use Cases
Politeia’s main use case in Decred will be in a public capacity since it will provide a public record of proposals, comments and stakeholder votes. However, the concept of versioned and timestamped data has numerous other use cases. It can be used in record storage, the reputation industry and in identity systems.
In fact, Decred also held the Politeia Platform Challenge which was a competition designed to discover alternate uses for the Politeia codebase.
Innovations on Decred
Politeia is just one of the several innovations that are going on with Decred. The following two proposals are particularly exciting:
#1 Lightning network
We have covered lightning network in length before.
To give you a brief overview, the lightning network is an off-chain micropayment system which is designed to make transactions work faster in the blockchain.
#2 Atomic Swaps
Atomic swap enables cross-chain exchange of coins without the need of a third party. Eg. If Alice had 1 bitcoin and she wanted 100 litecoins in return, she would normally have to go to an exchange and pay certain fees to get it done.
With the implementation of Atomic Swaps, suppose Alice has 1 LTC and Bob has 100 DCR, they could simply swap their coins with each other, without going to through an exchange and paying any unnecessary transaction fees.
Atomic swaps work by utilizing Hashed timelock contracts(HTLC). (Note: HTLCs are required to run the lightning network as well.)
On September 20th, Decred and Litecoin managed to complete across atomic swap.
Image Credit: Decred Twitter
The reason why we think that Decred is a great project is that they have a great governance mechanism in place. For future adoption of cryptocurrencies, we need to have more projects with well-defined governance which won’t be ripped apart by petty and squabbling cabals.
However, there is another reason why Decred is such a brilliant and underrated project. The company behind Decred, Company 0, mostly comprises of the original developers of “btcsuite” and, as such, are extremely well-regarded in the community. Since the project has such a solid core philosophy and the team behind it is so amazing, we definitely believe that Decred deserves more attention and respect.