Topic: [ANN][DCR] Decred - Community Governance | Bitcoin Devs | Lightning Network - page 223. (Read 1201380 times)

I don't know the Url but have a look on Facebook www.facebook.com/decredcash.

By the way, there is a guy that wants to buy 50Btc but doesn't know yet the floor... I suppose he is not the only one who wants to buy!

We could triple it today... I'll try to get an investor into digital currencies! And I suppose he knows a lot of people I'll do my best

where did you found this guy that you are reffering?

I don't know the Url but have a look on Facebook www.facebook.com/decredcash.

By the way, there is a guy that wants to buy 50Btc but doesn't know yet the floor... I suppose he is not the only one who wants to buy!

We could triple it today... I'll try to get an investor into digital currencies! And I suppose he knows a lot of people I'll do my best

They certainly are... 10btc put us up 20%.  When this goes... good luck not market buying.

Where is the best place to follow the project? Forum or slack?

Things are getting more interesting on the market...



 

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.

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? 

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.