Dd-1: V0.0.5 (02/28/16)

Discussion in 'Development Dispatches' started by tacotime, Feb 27, 2016.

  1. 2017/12/15 - Decred v1.1.2 released! → Release Notes  → Downloads
  1. tacotime

    tacotime Hero Member

    Dec 7, 2015
    #1 tacotime, Feb 27, 2016
    Last edited: Feb 29, 2016

    This development dispatch covers work completed since the initial Decred commits on February 8th, 2016. Since then, developers have merged 83 pull requests of code into 10 software repositories. During this period, a total of 139 commits occurred in these repositories and represent modifications to the effect of 5,499 lines of code added to and 1,952 lines removed from the codebase. In addition, a native Windows wallet GUI is being ported to Decred. Finally, 5 requests for proposals (RFPs) were opened to involve new developers in Decred's development.

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

    • Improved getwork RPC handling (13-42ae03b)
    • Added command and result interfaces for incoming new RPC call for wallet (16-3968690)
    • Reduced amount of fees required before a transaction is considered free (20-5d04f47)
    • Improved the use of analysis tools in goclean.sh (24-1954bf2) and resolved issues caught (28-14769a7)
    • Added getcoinsupply RPC call to track total coin supply (30-c77e541), cached its results (34-2edc483), and fixed issues (55-aa21c12)
    • Added JSON handling for per ticket manipulation of the VoteBits field in wallet (31-2f9fc2d)
    • Completed the framework to enable the address indexer for the memory pool by default (35-9740110)
    • Modified JSON framework to enable two new RPC calls (existsliveticket, getstakeinfo) (38-3f706d2)
    • Changed CheckpointConfirmations to 4,096 (39-0e60dff)
    • Added an initial blockchain checkpoint (44-203be41)
    • Increased the default number of outbound peers from 3 to 8 (46-5e0163f)
    • Modified getrawmempool to allow for the selection of specific transaction types from the mempool (51-18acc11)
    • Avoid possible false hits within the templatePool map (48-638fff6)
    • Added framework handling to the new listscripts JSON RPC call for wallet (54-f001389)
    • Fixed issues with documentation (19-7e1e205), address indexer (01e9bfd), RPC call results (36-4868ed4), btcsuite artifacts (21-1e22c04), notifications (45-1652a0d), configuration files (23-33ff72f), stack tests (12-4d5ee10), error handling (18-01e9bfd, 60-bc44bcf), and RPC help (61-4c24488)
    • Updated versioning (62-fbede49, 22-1b42b87, 56-33ff4be)
    Credits: @ay-p, @ceejep, @dhill, @davecgh, @frankbraun, @jcv, @kefkius, @SG-O

    • Fixed a rare panic that could occur when importing multisignature scripts found in the blockchain that were unconfirmed (27-7ea5117)
    • Allowed wallet to accept hex or words as seed (31-2a407e4)
    • Added getwalletfee RPC call to show fee while creating transactions (32-414c03d)
    • Added per-ticket setting of the VoteBits field so that different VoteBits settings can be user-selected at stake pools via the RPC (38-6a938f9)
    • Corrected fee estimation for general transactions (37-4bdb6ac)
    • Added better tracking of the address index in the wallet (41-93408e9)
    • Fixed references to removed dcrjson results for single fields (42-b47feed)
    • Added getstakeinfo command to the wallet to give various statistics, such as the number of tickets it has in mempool, the number of tickets it has that are mature or live, the number of votes it has cast, and the total rewards earned by the wallet (44-f2d928b)
    • Disabled unsafe RPC calls on mainnet that allowed the removal of unencrypted private data from the wallet (dumpprivkey, getseed) and fixed extended pubkey storage (45-28b1bf0)
    • Improved performance of the getstakeinfo RPC call (47-e875bf3)
    • Fixed a bug in multisignature handling that would occasionally cause the inappropriate failing of transactions being added to the transaction manager (54-9d1ed9d, 55-8d41590)
    • Fixed a panic occurring from TxResults response (49-6d8f657)
    • Added listscripts RPC call to allow a user to dump the redeem scripts contained in the wallet (56-d3ebcbb)
    • Corrected storing of votes and revocations in the case of redundant wallets (57-9c1e89f, 58-ddb741a)
    • Added automatic pruning of old tickets and expired transactions from the internal memory pool (59-04a75c0)
    • Fixed issues with documentation (36-cc4956b) and rare panics (43-76bd7bd)
    • Updated versioning (63-ee2a72a)
    Credits: @ay-p, @ceejep, @frankbraun, @jcv, @jrick

    • Added getticketvotebits and setticketvotebits to the wallet RPC client (1-17bbf91)
    • Fixed issues with address functions (2-8ec8807)
    • Added functionality required to support getstakeinfo and call it, and two new wrappers for daemon RPC functions (missedtickets, existsliveticket) (3-2d67a90)
    • Added GetBalanceMinConfType to specify balance type (4-c222e4a)
    • Added TxType flags to getrawmempool access, so that a user may specify which type of transaction they would like returned from the mempool (5-680d8ff)
    Credits: @ay-p, @ceejep, @dhill

    cgminer (v0.0.5)
    • Fixed difficulty on front end UI (1-d7751bb)
    • Addressed compilation issues and allow ATI/AMD OpenCL toolkits via environment variables (2-4adc167, 3-bceed92)
    • Added a --cert option that allows a user to supply a self-signed certificate for the RPC server (6-27fb09d)
    • Changed Autoconf to address cross-compilation without breaking native Linux building (9-7bd2c58)
    • Assigned a 64-bit per-work unique ID to each work order, ensuring that GPUs ran in cgminer instances will never repeat the same work (10-d701a89)
    • Added an include in a header check for adl_sdk.h to work (12-72afa18)
    • Reverted cgminer difficulty calculation (16-4291617)
    Credits: @ceejep, @chappjc, @davecgh, @Wolf

    Web Wallet
    • Fixed issues with fee calculation (1-f80e2fe), language (5-1b50a7b)
    • Fixed JavaScript unit tests to use PhantomJS (12-8476a19)
    • Fixed fee to send all and make sure it does not go below min fee (13-a583538)
    Credits: @ay-p, jzbz, @Neurosploit

    Block Explorer
    • Added getcoinsupply RPC (1-e578aa9) and recognized it (1-52fc02e)
    • Fixed block reward calculation to be more accurate for non-critical information (2-2a8e57d)
    • Added votes and freshstake to block lists and front page (3-b3cd6da, 8-06ba621)
    • Displayed available supply on status page (4-411d6f5)
    • Switched from dbits to atoms as the unit choice (5-0f648f9)
    • Hardcoded checks for block version and block 0/1 (5-6d50513)
    • Fixed issues with Bitcoin artifacts (6-fd58b9b), block reward aesthetics (9-9576ec5), and block reward calculations (4-8a58c40)
    Credits: @ay-p, @dhill, @jcv, jzbz

    • Added RFP0001: Windows Wallet UI/UX Overhaul (1-d4f53d1, 2-02d3441)
    • Added RFP0002: Web Wallet Ticket and Stake Pool Support (3-bdf7edf, 4-e7f95c3)
    • Added RFP0003: Network Status Dashboard (5-cd2f31e, 6-de6a0ee)
    • Added RFP0004: Refactor and Update Wiki Documentation (7-3aa1d0c)
    • Added RFP0005: Mining Protocol Development And Pool Integration (10-698224f)
    Credits: @ay-p, @davecgh, @jcv, @jolan, @jrick
    Reynold, maxfunky, goofoff and 15 others like this.
  2. chappjc

    chappjc Full Member
    Developer Pool Operator (PoS)

    I do love release notes. Thanks for the communication and all the great work!
  3. Dyrk

    Dyrk Sr. Member

    Jan 7, 2016
    #3 Dyrk, Feb 28, 2016
    Last edited: Feb 28, 2016
    @ay-p How is coinsupply calculated?
    Right now getcoinsupply returns: 182612312361055
    It is ~ 1 826 123 DCR, right?
    While on dcrstats we have: 1 823 812.
    So we have this difference - 2 311 DCR.

    On dcrstats I'm decreasing supply for each missed ticket starting from 4096 block. ( -20% for PoW & dev parts, and -6% of total block reward for PoS).
    But I still assume that all votes are "yes". So probably final coin supply should be even smaller, than on dcrstats.

    PS: here they have also different coinsupply value (But only because it is cached, usually difference with dcrstats < than 5 blocks): http://coinmarketcap.com/currencies/decred/ - so I'm trying to understand where exactly we have mistake in calculations.
    sambiohazard likes this.
  4. adam2312

    adam2312 Jr. Member

    Jan 11, 2016
    I like the choice to move from dbits to atoms.

    Thank you for the updates!
  5. ay-p

    ay-p Full Member

    Dec 7, 2015
    So as of ~ 0022 GMT 2/29 I see both dcrstats and https://mainnet.decred.org/status showing a coin supply of 1829003

    Here is the current code to calculate the coinsupply from 0:


    Your numbers look right, but just to be clear for every missed ticket it should be -20% for all subisidy portions (where 6% of total subsidy == that 20% reduction of PoS). So 4 vote block == 24.9566 and 3 vote block == 18.7174, so 6.2392 down for every missed vote (which is also 20% total current subisdy level) I just tweaked the code this past week to fix it and added some debugs to track that 3 and 4 vote blocks were correctly calculated. Everything looked good on my end, but please review handleGetCoinSupply, if you feel like my calculations are in error. I can review tomorrow to confirm as well. Thanks for the note
  6. Dyrk

    Dyrk Sr. Member

    Jan 7, 2016
    Thanks for the response. It seems that there are still few problems:
    1. In the blockchain explorer block reward is still 31.1958, but it was adjusted starting from 6144 block to 31.1958 * 100/101 = 30.88.
    2. Did I understand right, that you look only at number of votes, but not at the sbits value "yes" / "no" when calculating supply? Because in case of "no" vote only (work + tax) should be reduced; for stake reward "no" vote is ok.
  7. ay-p

    ay-p Full Member

    Dec 7, 2015
    1) Yah that is being fixed with an update this morning... annoying node not catching undef vars
    2) Hmmm thats a good point. The situation you mention sounds like the accurate way to calculate. Let me dig through some of the code and hopefully figure out an easy way to accommodate the "no" vote (and not just assume the missing vote).
  8. ay-p

    ay-p Full Member

    Dec 7, 2015
    Ok so after discussing with devs, figured out why I was so confused....

    So "no" votes do not effect the current block subsidy. Only missing votes reduce current block subsidies. This is to ensure that PoW miners cannot pick and choose which votes to include based on which way the votes are. Plus votes are to judge the previous block's construction.

    The total supply calculation is correct in that sense, but you did reveal another issue: when a block has 3+ no votes we must then subtract that previous block's entire subsidy from the total supply. https://github.com/decred/dcrd/issues/67 I don't think there have been any invalidated blocks, so that number should be accurate until that occurs, but I'll fix after I get some more pressing issues with wallet we are having.
  9. Dyrk

    Dyrk Sr. Member

    Jan 7, 2016
    Sorry, but now I am confused. If votes judge previous block's construction, why PoW miner may want to not include "no"-vote to his block? Doing this, he try to save previous block, which he probably don't care about, but he will loose 20% of his reward for each not included vote.
  10. davecgh

    davecgh Hero Member
    Developer Organizer

    Dec 31, 2015
    United States
    There are various reasons why they'd want to do it when it's only regarding the validity of the previous block, but keep in mind that voting applies to much more than just the validity of the previous block. In particular, a vote also will include voting on specific agendas. If a miner were not punished for failing to include a vote, they could simply choose to ignore votes which didn't conform to their specific agenda in an effort to skew the results for zero cost.

    Under the design in Decred, a miner has to suffer a hefty penalty to try and skew results like that. One thing that has been learned from Bitcoin, and various alts, is that incentives and disincentives are a powerful motivator to encourage appropriate behavior and discourage inappropriate behavior. In this case, miners are incentivized to include all votes through a higher subsidy, even if they don't particularly agree with a vote's agenda, and are disincentivized from not including a vote through a penalty in the form of a reduced subsidy.
  11. jy-p

    jy-p Sr. Member

    Jan 2, 2016
    I think you have it either mostly or entirely right, but I'll state it a bit more clearly:
    • A PoW miner's subsidy depends on 2 factors (1) how many votes they include in that block and (2) whether a majority of votes on the next block approve your block.
    • In the case of including votes in the current block (factor 1 above), the subsidy scales linearly in number of votes, e.g. 3 votes means 60% subsidy, 4 votes 80% and 5 votes 100%.
    • If a majority of votes cast in the block after the one you mine are "no" (factor 2 above), you can have your entire PoW subsidy stripped. Any number of "no" votes >= 50% of the total votes included in the next block are sufficient to invalidate the PoW subsidy from the block before it.
    This system was put into place to (A) incentivize PoW miners to include all the votes that are cast, irrespective of whether they are "yes" or "no", and (B) to punish PoW miners that have a majority of votes cast against their blocks. The expectation is that (A) will encourage PoW miners to include all votes on every block they mine, but that (B) will encourage PoW miners to not do anything that makes >= 50% of the voters vote "no" on their blocks.

Share This Page