Topic: [ANN][DCR] Decred - Community Governance | Bitcoin Devs | Lightning Network - page 224. (Read 1201708 times)
December 28, 2016, 06:20:57 PM
Things are getting more interesting on the market...
December 28, 2016, 04:05:07 PM
The rules for starting a new voting period can be reduced to asking a couple straightforward questions:
Did all the PoW miners upgrade to the latest dcrd release?
Did 75% or more of the stakeholders voting in the last stake version interval upgrade to the latest dcrwallet release?
If these 2 conditions are satisfied, the stake version is incremented and the next voting period begins. There is a third condition, but it is more technical and messy to explain, so I'll gloss over it.
If you have any further questions about the release, feel free to ask.
Did all the PoW miners upgrade to the latest dcrd release?
Did 75% or more of the stakeholders voting in the last stake version interval upgrade to the latest dcrwallet release?
If these 2 conditions are satisfied, the stake version is incremented and the next voting period begins. There is a third condition, but it is more technical and messy to explain, so I'll gloss over it.
If you have any further questions about the release, feel free to ask.
Thanks for the update! For those of us interested, can you explain the third condition? Or point to a thread/blog where it's already explained?
Sure thing, IncludeBeer. This may be more technical than some readers want, but it's necessary to explain why and how this 3rd condition works.
Since Decred's hybrid PoW/PoS system scales the block reward received by a PoW miner based on the number of PoS miners whose votes are included in that block, i.e. a block authored by a PoW miner that includes 3 of the 5 votes only receives 3/5 of the usual subsidy for mining that block, we cannot apply the same kind of enforcement, rejection and activation logic as Bitcoin uses for the block version to the stake version. If votes are rejected based on their version, e.g. full nodes start rejecting anything but v3 votes, it unfairly penalizes the PoW miner for that block due to a PoS miner not upgrading. Not rejecting votes creates an enforcement problem: it is not possible to guarantee a monotonic march to activation by rejecting older versions. Without rejecting older vote versions, it is possible to have the following scenario occur: during one stake version interval (SVI), the 75% threshold is crossed by a new version, then during the next SVI, that same version falls short of the 75% threshold. The 3rd condition is
* Instead of determining the stake version only based on the votes in that interval, we also check what version the last SVI was. If the previous SVI was some version, the current version must be that same version or greater.
By preventing the stake version from decreasing, we avoid other complex failure modes that could occur when the stake version goes from 3 to 2 or similar.
No worries, I work in development myself. This makes good sense imo. It sounds like a trivial check to make, and as you pointed out, does a good job of mitigating the risks of all those complex failure modes that otherwise could occur. Great work devs!
December 28, 2016, 09:08:03 AM
The rules for starting a new voting period can be reduced to asking a couple straightforward questions:
Did all the PoW miners upgrade to the latest dcrd release?
Did 75% or more of the stakeholders voting in the last stake version interval upgrade to the latest dcrwallet release?
If these 2 conditions are satisfied, the stake version is incremented and the next voting period begins. There is a third condition, but it is more technical and messy to explain, so I'll gloss over it.
If you have any further questions about the release, feel free to ask.
Did all the PoW miners upgrade to the latest dcrd release?
Did 75% or more of the stakeholders voting in the last stake version interval upgrade to the latest dcrwallet release?
If these 2 conditions are satisfied, the stake version is incremented and the next voting period begins. There is a third condition, but it is more technical and messy to explain, so I'll gloss over it.
If you have any further questions about the release, feel free to ask.
Thanks for the update! For those of us interested, can you explain the third condition? Or point to a thread/blog where it's already explained?
Sure thing, IncludeBeer. This may be more technical than some readers want, but it's necessary to explain why and how this 3rd condition works.
Since Decred's hybrid PoW/PoS system scales the block reward received by a PoW miner based on the number of PoS miners whose votes are included in that block, i.e. a block authored by a PoW miner that includes 3 of the 5 votes only receives 3/5 of the usual subsidy for mining that block, we cannot apply the same kind of enforcement, rejection and activation logic as Bitcoin uses for the block version to the stake version. If votes are rejected based on their version, e.g. full nodes start rejecting anything but v3 votes, it unfairly penalizes the PoW miner for that block due to a PoS miner not upgrading. Not rejecting votes creates an enforcement problem: it is not possible to guarantee a monotonic march to activation by rejecting older versions. Without rejecting older vote versions, it is possible to have the following scenario occur: during one stake version interval (SVI), the 75% threshold is crossed by a new version, then during the next SVI, that same version falls short of the 75% threshold. The 3rd condition is
* Instead of determining the stake version only based on the votes in that interval, we also check what version the last SVI was. If the previous SVI was some version, the current version must be that same version or greater.
By preventing the stake version from decreasing, we avoid other complex failure modes that could occur when the stake version goes from 3 to 2 or similar.
December 27, 2016, 07:14:17 PM
From Decred Forums:
It was mentioned on slack/IRC that this DD was technical and didn't make the release tangible for the layperson. Here's a breakdown of the most important parts of this release.
Stake version soft fork
In order to enable hard fork voting, we implement a soft fork that makes use of the existing block version in block headers, vote version and the stake version in block headers. Those familiar with Bitcoin may be aware that soft forks are implemented via the block version in the block header, where the network begins enforcing and rejecting blocks of lower version at certain activation thresholds, e.g. if 75% of the blocks in a trailing window of 1000 blocks are version 3, blocks with version less than 3 are rejected by the network. This process is entirely controlled by the PoW miners, so in Bitcoin, this process depends only on the PoW miners and not the rest of the network. In Decred, we require a second version in the block header to enable hard fork voting, called the stake version, and this version being incremented corresponds to the start of voting on a new set of issues that are encoded in votebits that are part of each vote cast by stakeholders. Decred uses the existing Bitcoin method for incrementing the block version in its block headers, but to increment the stake version, the block version must already be incremented and 75% or more of the votes cast in a stake version interval must be of a particular version, e.g. version 3. The rules for starting a new voting period can be reduced to asking a couple straightforward questions:
Did all the PoW miners upgrade to the latest dcrd release?
Did 75% or more of the stakeholders voting in the last stake version interval upgrade to the latest dcrwallet release?
If these 2 conditions are satisfied, the stake version is incremented and the next voting period begins. There is a third condition, but it is more technical and messy to explain, so I'll gloss over it.
If you have any further questions about the release, feel free to ask.
It was mentioned on slack/IRC that this DD was technical and didn't make the release tangible for the layperson. Here's a breakdown of the most important parts of this release.
Stake version soft fork
In order to enable hard fork voting, we implement a soft fork that makes use of the existing block version in block headers, vote version and the stake version in block headers. Those familiar with Bitcoin may be aware that soft forks are implemented via the block version in the block header, where the network begins enforcing and rejecting blocks of lower version at certain activation thresholds, e.g. if 75% of the blocks in a trailing window of 1000 blocks are version 3, blocks with version less than 3 are rejected by the network. This process is entirely controlled by the PoW miners, so in Bitcoin, this process depends only on the PoW miners and not the rest of the network. In Decred, we require a second version in the block header to enable hard fork voting, called the stake version, and this version being incremented corresponds to the start of voting on a new set of issues that are encoded in votebits that are part of each vote cast by stakeholders. Decred uses the existing Bitcoin method for incrementing the block version in its block headers, but to increment the stake version, the block version must already be incremented and 75% or more of the votes cast in a stake version interval must be of a particular version, e.g. version 3. The rules for starting a new voting period can be reduced to asking a couple straightforward questions:
Did all the PoW miners upgrade to the latest dcrd release?
Did 75% or more of the stakeholders voting in the last stake version interval upgrade to the latest dcrwallet release?
If these 2 conditions are satisfied, the stake version is incremented and the next voting period begins. There is a third condition, but it is more technical and messy to explain, so I'll gloss over it.
If you have any further questions about the release, feel free to ask.
Thanks for the update! For those of us interested, can you explain the third condition? Or point to a thread/blog where it's already explained?
December 27, 2016, 09:25:56 AM
slowly buying..
December 27, 2016, 07:38:37 AM
December 27, 2016, 02:59:45 AM
If I'm happily staking and buying tickets (manually) with 0.5 command Line wallet, is there a pressing need to update?
December 27, 2016, 02:28:35 AM
Good work! Decred is the star of 2017 ... we need implement smart contract 
December 26, 2016, 11:25:38 PM
From Decred Forums:
It was mentioned on slack/IRC that this DD was technical and didn't make the release tangible for the layperson. Here's a breakdown of the most important parts of this release.
Stake version soft fork
In order to enable hard fork voting, we implement a soft fork that makes use of the existing block version in block headers, vote version and the stake version in block headers. Those familiar with Bitcoin may be aware that soft forks are implemented via the block version in the block header, where the network begins enforcing and rejecting blocks of lower version at certain activation thresholds, e.g. if 75% of the blocks in a trailing window of 1000 blocks are version 3, blocks with version less than 3 are rejected by the network. This process is entirely controlled by the PoW miners, so in Bitcoin, this process depends only on the PoW miners and not the rest of the network. In Decred, we require a second version in the block header to enable hard fork voting, called the stake version, and this version being incremented corresponds to the start of voting on a new set of issues that are encoded in votebits that are part of each vote cast by stakeholders. Decred uses the existing Bitcoin method for incrementing the block version in its block headers, but to increment the stake version, the block version must already be incremented and 75% or more of the votes cast in a stake version interval must be of a particular version, e.g. version 3. The rules for starting a new voting period can be reduced to asking a couple straightforward questions:
Did all the PoW miners upgrade to the latest dcrd release?
Did 75% or more of the stakeholders voting in the last stake version interval upgrade to the latest dcrwallet release?
If these 2 conditions are satisfied, the stake version is incremented and the next voting period begins. There is a third condition, but it is more technical and messy to explain, so I'll gloss over it.
The purpose of this soft fork is to act as a signaling mechanism that indicates the network is ready to upgrade consensus. Since this soft fork behavior is fundamental to how Decred hard fork voting will work, we have exhaustively tested the various scenarios that can occur at the ends of stake version intervals. This work was completed by @moo1337 and @davecgh. The code to activate the soft fork was roughly 1500 lines, but the test coverage was roughly 2500 lines. These tests simulate an entire blockchain and ensure that stake version changes behave properly under all conditions, including both positive and negative tests and behavior under reorganizations. We will strive to maintain this level of test coverage for any future consensus changes that occur as part of hard fork voting. If you're interested in checking out the code, have a look at dcrd pull requests 524 (soft fork) and 526 (test coverage).
decrediton
As part of our effort to get a GUI wallet that runs on all major platforms, we started work on decrediton, which uses Electron, React and Redux frameworks. In a single release, @ay-p has gotten most of the basics working for decrediton. Despite being in a very much "alpha" state, it can create simple transactions, generate a new seed, restore from seed, and receive payments. It does have a notable deficiency with the transaction history, but fixing that requires some more substantial work on the gRPC decrediton uses to interact with dcrwallet. By the next release, decrediton should allow users to do most things they can already do with the command line wallet, dcrwallet. In the meantime, do understand this is very much a work-in-progress and there will be something more "beta" available by early February.
dcrticketbuyer
Some users may have noticed that dcrticketbuyer has been static for this release despite several open issues. This is because the code from dcrticketbuyer has been migrated to a separate package inside dcrwallet. This was done because in order to buy tickets, you need a wallet, so rather than require users to run 2 processes, a wallet for buying tickets and a ticket buyer, only 1 process is required. Another reason this was done is that automatic ticket purchasing in Paymetheus or decrediton creates a mess when using a standalone ticket buyer versus something integrated into wallet. The migration took @Javed Khan a while and it has now landed in dcrwallet.
If you have any further questions about the release, feel free to ask.
It was mentioned on slack/IRC that this DD was technical and didn't make the release tangible for the layperson. Here's a breakdown of the most important parts of this release.
Stake version soft fork
In order to enable hard fork voting, we implement a soft fork that makes use of the existing block version in block headers, vote version and the stake version in block headers. Those familiar with Bitcoin may be aware that soft forks are implemented via the block version in the block header, where the network begins enforcing and rejecting blocks of lower version at certain activation thresholds, e.g. if 75% of the blocks in a trailing window of 1000 blocks are version 3, blocks with version less than 3 are rejected by the network. This process is entirely controlled by the PoW miners, so in Bitcoin, this process depends only on the PoW miners and not the rest of the network. In Decred, we require a second version in the block header to enable hard fork voting, called the stake version, and this version being incremented corresponds to the start of voting on a new set of issues that are encoded in votebits that are part of each vote cast by stakeholders. Decred uses the existing Bitcoin method for incrementing the block version in its block headers, but to increment the stake version, the block version must already be incremented and 75% or more of the votes cast in a stake version interval must be of a particular version, e.g. version 3. The rules for starting a new voting period can be reduced to asking a couple straightforward questions:
Did all the PoW miners upgrade to the latest dcrd release?
Did 75% or more of the stakeholders voting in the last stake version interval upgrade to the latest dcrwallet release?
If these 2 conditions are satisfied, the stake version is incremented and the next voting period begins. There is a third condition, but it is more technical and messy to explain, so I'll gloss over it.
The purpose of this soft fork is to act as a signaling mechanism that indicates the network is ready to upgrade consensus. Since this soft fork behavior is fundamental to how Decred hard fork voting will work, we have exhaustively tested the various scenarios that can occur at the ends of stake version intervals. This work was completed by @moo1337 and @davecgh. The code to activate the soft fork was roughly 1500 lines, but the test coverage was roughly 2500 lines. These tests simulate an entire blockchain and ensure that stake version changes behave properly under all conditions, including both positive and negative tests and behavior under reorganizations. We will strive to maintain this level of test coverage for any future consensus changes that occur as part of hard fork voting. If you're interested in checking out the code, have a look at dcrd pull requests 524 (soft fork) and 526 (test coverage).
decrediton
As part of our effort to get a GUI wallet that runs on all major platforms, we started work on decrediton, which uses Electron, React and Redux frameworks. In a single release, @ay-p has gotten most of the basics working for decrediton. Despite being in a very much "alpha" state, it can create simple transactions, generate a new seed, restore from seed, and receive payments. It does have a notable deficiency with the transaction history, but fixing that requires some more substantial work on the gRPC decrediton uses to interact with dcrwallet. By the next release, decrediton should allow users to do most things they can already do with the command line wallet, dcrwallet. In the meantime, do understand this is very much a work-in-progress and there will be something more "beta" available by early February.
dcrticketbuyer
Some users may have noticed that dcrticketbuyer has been static for this release despite several open issues. This is because the code from dcrticketbuyer has been migrated to a separate package inside dcrwallet. This was done because in order to buy tickets, you need a wallet, so rather than require users to run 2 processes, a wallet for buying tickets and a ticket buyer, only 1 process is required. Another reason this was done is that automatic ticket purchasing in Paymetheus or decrediton creates a mess when using a standalone ticket buyer versus something integrated into wallet. The migration took @Javed Khan a while and it has now landed in dcrwallet.
If you have any further questions about the release, feel free to ask.
December 26, 2016, 07:29:40 PM
I do agree about "too much development" in the sense, that devs promised us a hardfork voting this year, but this is not happened. And it seems that we need few more months for this.
Meanwhile, they started this brand new GUI wallet trying to stabilise the exchange rate. It looks to me like some kind of "panic development" and it goes way far from the announced roadmap.
Meanwhile, they started this brand new GUI wallet trying to stabilise the exchange rate. It looks to me like some kind of "panic development" and it goes way far from the announced roadmap.
We have always said that we planned on a cross platform wallet. Paymetheus is very nice, but many of the devs (me for example) don't use windows at all so we've wanted a GUI on the OSes we use.
December 26, 2016, 03:15:36 PM
I do agree about "too much development" in the sense, that devs promised us a hardfork voting this year, but this is not happened. And it seems that we need few more months for this.
Meanwhile, they started this brand new GUI wallet trying to stabilise the exchange rate. It looks to me like some kind of "panic development" and it goes way far from the announced roadmap.
Meanwhile, they started this brand new GUI wallet trying to stabilise the exchange rate. It looks to me like some kind of "panic development" and it goes way far from the announced roadmap.
December 26, 2016, 01:46:33 PM
Decred v0.7.0 is out! See our forum for more details: https://forum.decred.org/threads/dd-20-v0-7-0-12-26-16.4702/
Nice! Cheers!
December 26, 2016, 01:37:02 PM
Can someone step out of these bushes and tell me why all of this is happening around there. Too much developments at once is not nice for a long-standing project, u should space ur milestones across the roadmap axis more equally.
Too much development? LOL that's a new one. Sounds like you want to manipulate the coin for the purpose of better appealing to investors to prop up the price. Shame shame.
December 26, 2016, 01:34:30 PM
There's no such thing as too much development.
The more, the better.
Congrats to Decred team on this important release!
The more, the better.
Congrats to Decred team on this important release!
December 26, 2016, 01:33:30 PM
Decred v0.7.0 is out! See our forum for more details: https://forum.decred.org/threads/dd-20-v0-7-0-12-26-16.4702/
GUI wallets for mac and linux!
December 26, 2016, 12:23:27 PM
Maybe we have the cross-platform wallet with 0.7.0 release:
Decrediton : https://github.com/decred/decrediton/milestone/2
Main release : https://github.com/decred/dcrd/milestone/12
Decrediton : https://github.com/decred/decrediton/milestone/2
Main release : https://github.com/decred/dcrd/milestone/12
100%
Cross platform node.js wallet is 0.8.0
An initial preview version of Decrediton (the node.js wallet) is coming out in 0.7.0. Not quite ready for prime time yet, but it will be there to play with. Should be much more complete in 0.8.0 and hopefully we'll have windows builds for it then too.
Can someone step out of these bushes and tell me why all of this is happening around there. Too much developments at once is not nice for a long-standing project, u should space ur milestones across the roadmap axis more equally.
You mean a cross platform wallet? Look out guys too much development better slow down...
December 26, 2016, 11:36:01 AM
Maybe we have the cross-platform wallet with 0.7.0 release:
Decrediton : https://github.com/decred/decrediton/milestone/2
Main release : https://github.com/decred/dcrd/milestone/12
Decrediton : https://github.com/decred/decrediton/milestone/2
Main release : https://github.com/decred/dcrd/milestone/12
100%
Cross platform node.js wallet is 0.8.0
An initial preview version of Decrediton (the node.js wallet) is coming out in 0.7.0. Not quite ready for prime time yet, but it will be there to play with. Should be much more complete in 0.8.0 and hopefully we'll have windows builds for it then too.
Can someone step out of these bushes and tell me why all of this is happening around there. Too much developments at once is not nice for a long-standing project, u should space ur milestones across the roadmap axis more equally.
December 26, 2016, 11:17:04 AM
Decred v0.7.0 is out! See our forum for more details: https://forum.decred.org/threads/dd-20-v0-7-0-12-26-16.4702/
Are there any incompatibilities with the previous dcrwallet?
December 26, 2016, 11:11:17 AM
Good work!
December 26, 2016, 10:58:44 AM
Decred v0.7.0 is out! See our forum for more details: https://forum.decred.org/threads/dd-20-v0-7-0-12-26-16.4702/
Jump to: