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

DCR meaning : Digital Currency Revolution !!

this coin is maded only for strong hands and long investors....

Thank you for the meaningful detailed and informative update Decred team. You guys encouraged me more to have a long term investment in DCR.

Very nice coding Decred, good work

Thanks for another great update Decred team...

Keep up the awesome work 

One of the only altcoins that is worth investing. Nice work guys.

This development dispatch covers work completed since the Decred v0.1.3 release from April 10th, 2016. Since then, developers have merged 89 pull requests of code into 8 software repositories. New repositories were created and populated for an automated smart ticket purchaser known as dcrticketbuyer and extensive Decred documentation known as dcrdocs (https://docs.decred.org). During this period, a total of 129 commits occurred in these repositories and represent modifications to the effect of 36,730 lines of code added to and 6,882 lines removed from the Decred codebase.

A series of RFP milestones were achieved and paid for from the development subsidy. Milestones paid for include (See: Status and Expenditures):

• RFP-1: The proposed design is integrated into a single view (e.g. the Account Summary view) (bebd22a)
• RFP-1: The proposed design style is integrated into the entire application, including a stake ticket purchase view (56889f0)

A number of stake pools have come online in geographically diverse locations to support the network, which means users are no longer required to solo stake mine and can instead use a dedicated pool managed by skilled operators. These are, in alphabetical order:

• https://dcr.stakeminer.com
• https://dcr.stakepool.net
• http://pool.d3c.red
• http://stakepool.eu
• https://stakepool.dcrstats.com

Two new RFPs were opened for proposals and closed for review. RFP-7 will establish Decred's identity, align its different platforms according to that identity, and redesign its landing site. RFP-8 will bring a higher level language for Decred's transaction scripting system, which will enable users to create transaction scripts, such as smart contracts.

Binaries: https://github.com/decred/decred-release/releases/tag/v0.1.4

dcrd

• Synced a large number of fixes, improvements, and optimizations from upstream through July (163-b0255e0, 164-a3ff9f1), August (166-1da2845, 172-bee3c25), September (174-885070a, 175-d5144c5, 177-2cc7e75, 178-28f5ce5, 180-8ff81ff), October (202-415ad8f, 205-85d85e8, 206-e8e81fe), and November (212-4bffbb1, 217-e955b1f, 218-a98085e, 219-ab38a2c, 220-0dd5db0) 2015
• Very old votes are now rejected from the memory pool by default (168-ebade40)
• Votes are now checked by the tickets they spend rather than the vote hashes, which fixes a cached block template issue (169-33dc0c7)
• Adjusted the getblockheader result to reflect changes required by the upstream sync (170-d293c9b)
• Improved memory usage when the sighashall optimization is set in chaincfg/params.go (171-653e13d)
• Fixed a legacy address encoding issue (179-118f795)
• Improved test coverage (181-4e14b54, 210-c052ff9, 214-001ecad)
• Changed the order of service flags to ensure their human-readable representation and to allow for the output to be deterministically tested (182-9c238a8)
• Fixed an issue where searchrawtransactionsresult missed various components of transactions (183-ac0d8fb)
• Added a reverse order option to the searchrawtransactions RPC command (185-718f0f4)
• Improved garbage collection percentage (187-f1f1933)
• Integrated a valid ECDSA signature cache in order to mitigate a certain DoS attack and as a performance optimization (189-e310d1d)
• Added a checkpoint for block 24,480 (190-aac2928)
• Updated the getinfo RPC command to include errors in the result (191-577f33c)
• Corrected verifymessage hash generation (192-9798cde)
• Added a new --minrelaytxfee option to allow the user to specify the minimum transaction fee in DCR/KB in which the fee is considered a non-zero fee (194-096e77d)
• Majorly refactored peer code into its own package and introduced a number of fixes, improvements, and optimizations (197-756eff2)
• Improved heap sorting (199-c3d7ede)
• Moved non-mempool specific functions to a new file (203-29a04bc)
• Added an optional locktime parameter to createrawtransaction (204-1987376)
• Moved DNS seed to chaincfg (209-1cd79a4)
• Fixed various issues with the peer and server packages (211-a27dc48, 215-619de72)
• Reworked and improved efficiency of stake submission (216-3799575)
• Improved error handling (222-708b400)
• Updated configuration (193-0c883ff), documentation (201-40d778d), initial protocol versioning (195-cb9d07a), and versioning (221-f3e603a)

dcrwallet

• Improved block timestamping (240-e4ebb93)
• Disabled ticket purchase by default in preparation for dcrticketbuyer (244-4950977)
• Enabled stake pool mode for mainnet (245-61c3979)
• Added a guide that explains how to spend from a cold wallet while offline and added a utility called movefunds to sign offline transactions (252-7190018)
• Fixed an issue with fee calculation for revocations so that fees for revocations are now calculated on a per kilobyte basis. The wallet now also triggers winner and missed ticket notifications on start up, so that revocations for tickets that were missed while the wallet was offline will be triggered when the wallet is started (254-fa736fd)
• Updated documentation (243-222b7de), logging (246-c48265a), configuration (247-d5c9a96), and versioning (253-c9476fa)

dcrrpcclient

• Synced from upstream through August (20-06e2185), 2015
• Fixed ticket fee info command handling (23-0e48ddc)
• Added an optional locktime parameter to createrawtransaction (24-7df7e90)
• Added a filteraddr parameter to searchrawtransactions (25-231790f)
• Updated documentation (21-51f8ef1) and RPC commands (22-3f0eb39)

dcrutil

• Synced from upstream through July (10-b1f27b6), 2015
• Updated documentation (11-85fac3a)

dcrticketbuyer

• Added a new user interface that shows the number of tickets purchased, fee prices, ticket prices, and the number of tickets in mempool. A sample configuration file is also included (1-471c747)

gominer

• Fixed an issue with shutting down the miner (4-b935bbd)
• Removed unused constants (5-6a7a59b)
• Added a tunable intensity parameter (6-6b8bb1f)

Paymetheus

• Synced with upstream (6-aabe292)

Developer Notes
General use instructions for dcrticketbuyer

dcrticketbuyer helps solve many of the current issues affecting ticket purchase in Decred, such as stabilizing the stake difficulty and ensuring that tickets have adequate fees at low difficulties. It is intended to be a powerful, set-and-forget replacement for the default ticket purchasing code in dcrwallet that does not take into account things such as recently purchased ticket fees, the next estimated stake difficulty prices, and the number of tickets currently in mempool. It automatically provides an advantage to those purchasing tickets at lower stake difficulties by intelligently setting ticket fees and ticket expiry. Larger stake miners may use it to ensure smaller swings in the ticket price, which will enable all users to better purchase tickets at the average ticket price.

An explanation of the features of dcrbuytickets is supplied in the sample configuration file distributed with the binary, or located here: https://github.com/decred/dcrticketbuyer/blob/master/ticketbuyer-example.conf

Those who purchase small amounts of stake tickets will want to disable minpricescale and maxpricescale by commenting it out and setting a reasonable maxpriceabsolute. For persons with larger amounts of stake, it is recommended to have the price scaling features enabled.

dcrticketbuyer requires the following:

• dcrticketbuyer binary
• The webui/ folder included with the binaries to be located in the same directory as the binary from 1
• dcrd and dcrwallet set up and running. dcrwallet will need to be unlocked and contain funds for ticket purchases

Information about how to build the tool can be found here: https://github.com/decred/dcrticketbuyer

A thread for discussion of the tool can be found here: https://forum.decred.org/threads/dcrticketbuyer-new-tool-for-automatic-ticket-purchase.3548/

A sample configuration file has been provided. If you wish to use the tool on mainnet, you will need to change at minimum the following parameters in the sample file:


Comment out features you do not wish to enable by adding a hash tag (#) in front of them. Setup this file carefully if you are using coins on mainnet.

To start dcrticketbuyer with a configuration file, execute:


If the HTTP monitoring server is available, you will be able to see a live chart feed of information about ticket purchasing that is updated every block. The default HTTP server port specified in the sample configuration is accessible in a browser at: http://localhost:7770

A review of activity will be posted next week so we can take stock of where we're at as a project. v0.1.4 is being prepared right now, which includes a ton of work that isn't quite obvious to the public eye, unless you read Github development activity, as it involves pulling in a large number of fixes, improvements, and optimisations. There are also a number of distinct packages that have emerged for inclusion in the v0.1.4 release and will be documented in the development dispatch that accompany it. RFP-7 and 8 are also getting ready for announcement, so work can begin on those, which will have very visible impact on Decred. And of course, the GUI is progressing too with extra effort.

These are good milestones for review and then forecasting the project's activity based on what we've seen and done. It's important to remember that Decred did not set out with an explicit roadmap, so that users' desires and needs could be taken into account, rather than enforcing a strict policy of where we're going as a project and community. As these views develop organically in the user base, there comes a point where it's time to develop them into a framework and draft a defined proposed route. It may seem chaotic at times without a formal structure for it yet, but everything posted is reviewed and factor into that process. It wouldn't be very open and democratic if it's dictated down, instead of being built up, but there does need to be some actionable direction to make sure the ship is steered. That is the fine balance the project is still learning and adapting to, despite consistent and high development output, with phenomenal people getting involved in Decred.

The v0.1.4 release will mark a good point to document this progress, and paint a realistic future based on activity. The feeling is that it's better to forecast the shorter-term, to allow for continued community and development input, rather than trying to forecast so far into the future that none of those lofty goals are met. Next week will mark a good point to engage in that discussion and put something clear and actionable on the table for the next period.

where a roadmap?

98% of your tickets gets a call for a vote during 28 days. If you have bad luck and your ticket won't get selected for a vote, the ticket will expire after 142 days and you will get the coins back. I did many votes so far, none of my tickets became expired.

you can be voted before.
From the 63 tickets that I bought last week, 13 already have been voted.
The average is around one month so that almost all be voted

I believe the same, Decred is a great coin and technic. Staking long-term and waiting for success =)

But that's not very strange... all coins do that mate.
Invest for the long term
I think this coin will take 1 year before we really see its potential

These coin is very strange I had lost 5 btc I buy it at 2.5 and now is 1.5

$1.29, is this a new low?

Voting is like a lottery. There is no fixed time.

Do I understand it correct? If I buy a ticket, I'll have to wait 142 days, to get my coins back?

Simplified calculation - ideal conditions:
you have: 1000dcr
price per ticket (retargets every 144 blocks==roughly every 12hrs) - example: 14.8dcr/ticket + ticketfee (0.01) + txfee (0.01) = 15dcr/ticket
you can buy: 1000/15 == 66 tickets
POS reward per ticket: 1.78drc
So per 66 tickets you may get max. 66 x 1.78 == 117drc, at current price of 0,00305dcr/btc you may gain roughly 0.35btc. The soonest all your tickets can vote is around 28 days.

The process:
You buy tickets. Tickets will be moved to mempool. From the mempool POW miners will mine max. 20 tickets per block. If your ticket tx (sstx) gets mined and included in the block while the price of tickets you've paid lasts (remember it changes every 144 blocks), your ticket changes status to "immature". It will sit in the blockchain for 256 blocks (roughly 24hrs) before it can vote. After 24hrs, ticket changes status to "live" and from that moment can be selected to vote. Once that happens, you will get back price you have paid for the ticket + reward (1.78drc/ticket recently). So per ticket (bought for 15dcr), your reward will be around 11% per ticket.
Tickets are choosen to vote randomly. If the ticket is not selected to vote in roughly 140 days, it will get revoked and price you've paid will be returned minus tx fee.

The reality:
1. Price of tickets changes every roughly 12hrs + price of ticket reward every +-20days. Obviously, you want to buy at cheapest price possible to booster your gains. You can keep an eye on stats on Dyrk's https://dcrstats.com. As it stands now, ticket price swings from low (below 20dcr/ticket) to highs every roughly 3 days. So it is best to watch the swing and once you see wildly high price to get ready to buy on next retarget. Once price is too high nobody will buy tickets in that 144 blocks period, so the diff will swing down wildly, usually below 15drc/ticket (see POS historical price change graph on Dyrk's dcrstats page).
2. Expect 5-10% of your live tickets to not vote (either because they get revoked, missed or just expire)
3. To keep steady reward income from POS, you need to smoothen the variance by constantly adding to your live tickets pool. Which means you have to buy and rebuy once in a while when the ticket price is low to keep your percentage share in stakepool at +-constant level. E.g.:
StakePool size now (total live tickets num.) is roughly: 42300tickets
So if you want to calculate how much you might get per month for 1000dcr, you would go like this:
Max. tickets that can vote per 24hrs: 12*24*5 == 1440 votes
Max reward per 24hrs from POS: 1440 x 1.78dcr == 2563dcr
If you have initially bought 66 tickets at 15dcr using those 1000dcr == you now hold 66/42300 == 0.15% of the whole stakepool. So you may expect around 0.15%*daily POS reward (2563dcr) == 3.8dcr/day (or around 3.8/1.78 == 2 tickets per day will vote). But to smoothen the variance and get steady rewards, you need to maintain this share of stakepool. Stakepool size keeps changing (up or down) during ticket price retargets based on interest of people buying tickets. So my advice is get additional 500dcr, buy on low ticket price using your 1000dcr and then keep rebuying additional tickets on low price during the month using those 500dcr to keep your share in the stakepool. If you maintain the share, then the calculations might be good. Otherwise, it is mostly guesswork

yes my math was based on 10-20 decred as the amount needed to buy a ticket, now it's 30 or more


1000 decred give you around 20-25 ticket, let's assume 25 ticket

each ticket can give you 1.8 decred on a average 28 days, so around 0.15 per month

before the price was 10-20 so it was double of this, and the value was almost double, so the result was 4x, so around 0.6 per month, which was really good for a pos coin

dev when gui wallet coming.

Two additional stake pools are ready to support the network! Check out pool.d3c.red and stakepool.dcrstats.com. You can also look at their dedicated threads on the forum (pool.d3c.red and dcr.stakepool.net). OP text has been updated with links to these stake pools.