[ANN][DCR] Decred - Community Governance | Bitcoin Devs | Lightning Network

[_ingsoc]

I will be setting up POS DCR SOLO mining on a raspberry pi 3.  Stay tuned.  Only $0.25 USD in electricity per month to run Raspberry pi 3, that is only 0.0005495 BTC per month.

I will write a Raspberry pi guide to.

Definitely check out how other users have progressed on the Raspberry Pi 2 if you want to write a guide. There's a tutorial available for running the software on a RPI 2. That may be of some assistance.

[1714246584]

1714246584

[1714246584]

1714246584

[1714246584]

1714246584

[1714246584]

1714246584

[1714246584]

1714246584

[nrvasquez]

Nice I just got 4 votes today, that is 7.2 DCR

[decred]

This development dispatch covers work completed since the Decred v0.1.1 release from April 25th, 2016. Since then, developers have merged 37 pull requests of code into 7 software repositories. New repositories were created created and populated for a consolidated miner known as gominer as part of RFP-5 and a statistical dashboard known as dcr-netstats as part of RFP-3 (in addition to decred-dashboard that is hosted at https://dcrstats.com). During this period, a total of 19 commits occurred in these repositories and represent modifications to the effect of 3,777 lines of code added to and 920 lines removed from the Decred codebase (dcrd, dcrwallet, dcrprclient, gominer). 25 commits also occurred in other Decred repositories (dcr-netstats, ccminer, cgminer).

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

• RFP-6: Pool has been successfully tested for 1 week on testnet and configuration verified (x2) (1c640e9, ef20c2e)

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

dcrd

• getstakedifficulty now returns the calculated stake difficulty of the next block. When the next block is a stake difficulty readjustment, users will now see the upcoming stake difficulty (137-8207e4d)
• Improved fee handling (139-c9a0afa)
• Moved non-mempool specific functions to a new file and added more test coverage (140-14c7cc9)
• Fixed an issue with mempool fees where the memory pool would incorrectly eliminate transactions sent over sendrawtransaction that had high fees while also always rejecting high priority transactions (141-4328736)
• Added a new estimatestakediff RPC command to estimate the minimum and maximum next stake difficulty. The caller can also estimate a new difficulty given a passed number of tickets to be mined in the remaining difficulty period (143-7fd213b)
• Added two new RPC commands designed for wallets running stake pools (stakepooluserinfo and addticket) (144-f1796b0, 148-084edf8)
• Added two new RPC commands to calculate the volume weighted average price of tickets (ticketvwap) and to get the transaction fee information for regular transactions in blocks, the mempool, and a height range (txfeeinfo) (145-29f116c)
• Updated documentation (147-5623458) and versioning (150-f93cb9f)

dcrwallet

• Added a non-default allowhighfees flag to wallet that enables users to send transactions that are not safety checked for high fees (214-ec2c1c2)
• Fixed an issue that could cause lock-ups in wallet (219-0e7558d)
• Improved error handling (224-d4ea045)
• Updated versioning (225-e545bec)

dcrrpcclient

• Added a number of new RPC commands (addticket, estimatestakediff, settxfee, stakepooluserinfo, ticketpoolvalue, ticketfeeinfo, ticketvwap, txfeeinfo) (16-a5a51f5)

gominer

• Enabled TLS, improved configuration, added a sample config file, and updated licensing (3-39550c6)
• Updated configuration (1-d43cd3e, 2-43e6a84)

ccminer/cgminer

• Deliverables from RFP-5 were released as updated miner binaries of ccminer (NVIDIA) and cgminer (AMD) for Windows and Linux (v0.1.0) (See: New Miner Binaries Now Available)

Developer Notes
Added stake pool fee functionality

We have added new config flags for dcrwallet. Let's go over each option to make crystal clear its usage:

stakepoolcoldextkey

When this option is set it turns on stake pool functionality for wallet. When stake pool is enabled for wallet, there are a series of transaction checks to verify whether this wallet will vote for a ticket that has used this stake pool's address as the ticketaddress. This option requires the extended public key of the stake pool's cold wallet that will receive the pool's fees. So on simnet for instance this option looks like this:

Code:

--stakepoolcoldextkey=spubVWAdividNTiSM9SdLRA5JX6LYNwt58cd51TFnpnULGQ8oqNMNskfkQwU7rjWMCY7phBguVr4XTmAWyDVRKpo2dFyjFb6QG4ihB8w64UPNuu:1000

The first portion (spub..., or dpub... on mainnet) is the extended public key and the second (1000) is the number of addresses to derive. Every user of the pool gets their own cold fee wallet address derived, so we recommend using at least 1000 in anticipation of the relative number of users in the stake pool. When a vote is created by the stake pool to vote on a ticket that has been given voting rights, it pays the pool fee to the address derived for the cold wallet from this extended public key.

pooladdress

This is for use by the stake pool user. It will be an address provided to the user by the stake pool. If set, this address is used during ticket purchase and will commit to a small output in the ticket that gives the stake pool its required fees.

ticketaddress

Same as the old option. This is the address that the stake pool user is giving the ticket's voting rights to.

poolfees

This is the required ticket fee as requested by the stake pool. The value set by the user needs to be greater than or equal to that of the pool. The fee is a percentage based fee, based on the stake subsidy. Here is a concrete example from simnet:

The ticket price of this ticket was 46.0551008, and the ticket relay fees were 0.00000100 per kB. The pool fees were set to 1.00%. The subsidy on simnet at this block height is approximately 29.40888 Coins per vote. This is the ticket as purchased by the user:

Code:

"vin": [
   ... ,
],
"vout": [
   {
     "value": 46.0551008,
     "n": 0,
     "version": 0,
     "scriptPubKey": {
       ... ,
       "reqSigs": 1,
       "type": "stakesubmission",
       "addresses": [
         "SsYZMHeeixdNRTkk6afzHBPL4unYDsFNd4r"
       ]
     }
   },
   {
     "value": 0,
     "n": 1,
     "version": 0,
     "scriptPubKey": {
       ... ,
       "type": "sstxcommitment",
       "addresses": [
         "Ssghjx8PvQVV3FM3w5FcGi9kWGvDpDkQDTV"
       ],
       "commitamt": 0.17948021
     }
   },
   {
     ... ,
   },
   {
     "value": 0,
     "n": 3,
     "version": 0,
     "scriptPubKey": {
       ... ,
       "type": "sstxcommitment",
       "addresses": [
         "SsYUi5tbXfqHnTPgvHcajNW4yiGeSP6n7Xq"
       ],
       "commitamt": 45.87562609
     }
   },
   {
     ... ,
   }
],

And here's the vote that the stake pool created for that user's ticket:

Code:

"vin": [
   {
     ... ,
   },
   {
     ... ,
   }
],
"vout": [
   {
     ... ,
   },
   {
     ... ,
   },
   {
   "value": 0.2940888,
   "n": 2,
   "version": 0,
     "scriptPubKey": {
       ... ,
       "type": "stakegen",
       "addresses": [
         "Ssghjx8PvQVV3FM3w5FcGi9kWGvDpDkQDTV"
       ]
     }
   },
   {
     "value": 75.16989347,
     "n": 3,
     "version": 0,
     "scriptPubKey": {
       ... ,
       "type": "stakegen",
       "addresses": [
         "SsYUi5tbXfqHnTPgvHcajNW4yiGeSP6n7Xq"
       ]
     }
   }
]

As you can see '"n": 2,', the third output, is the stake pool fee of 0.2940888. This is 1% of the vote reward at that point (0.2940888/29.40888). The remaining subsidy and the original coins are returned to the take pool user in output '"n": 3,'. For more information about stake fees, please refer to dcrwallet/wallet/txrules/doc.go.

[dygus]

What about GUI wallet?

[frostminer]

What about GUI wallet?

Considering how few nerds there are vs newbs ... GUI wallet is a huge tool to get group 2 on team.

Or you can stick with the hardcore nerds comfy with command lines

[_ingsoc]

What about GUI wallet?

RFP-1 is progressing. A bit slower than people would like, but it's happening. Lots of improvements rolling into the software under the hood, which isn't always that visible, but it means once the GUI wallet is slapped on top of it, it'll likely be a much better user experience. By that time, Decred should have a number of mainnet stake pools ready and operational as well, which would move everyone closer to the important goal of decentralised voting.

[rajeshgarnaik]

very much needed gui wallet. Dev any progress

[dygus]

very much needed gui wallet. Dev any progress

Read above

[decred]

Quoting here for visibility since we rolled over to a new page right after posting.

This development dispatch covers work completed since the Decred v0.1.1 release from April 25th, 2016. Since then, developers have merged 37 pull requests of code into 7 software repositories. New repositories were created created and populated for a consolidated miner known as gominer as part of RFP-5 and a statistical dashboard known as dcr-netstats as part of RFP-3 (in addition to decred-dashboard that is hosted at https://dcrstats.com). During this period, a total of 19 commits occurred in these repositories and represent modifications to the effect of 3,777 lines of code added to and 920 lines removed from the Decred codebase (dcrd, dcrwallet, dcrprclient, gominer). 25 commits also occurred in other Decred repositories (dcr-netstats, ccminer, cgminer).

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

• RFP-6: Pool has been successfully tested for 1 week on testnet and configuration verified (x2) (1c640e9, ef20c2e)

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

dcrd

• getstakedifficulty now returns the calculated stake difficulty of the next block. When the next block is a stake difficulty readjustment, users will now see the upcoming stake difficulty (137-8207e4d)
• Improved fee handling (139-c9a0afa)
• Moved non-mempool specific functions to a new file and added more test coverage (140-14c7cc9)
• Fixed an issue with mempool fees where the memory pool would incorrectly eliminate transactions sent over sendrawtransaction that had high fees while also always rejecting high priority transactions (141-4328736)
• Added a new estimatestakediff RPC command to estimate the minimum and maximum next stake difficulty. The caller can also estimate a new difficulty given a passed number of tickets to be mined in the remaining difficulty period (143-7fd213b)
• Added two new RPC commands designed for wallets running stake pools (stakepooluserinfo and addticket) (144-f1796b0, 148-084edf8)
• Added two new RPC commands to calculate the volume weighted average price of tickets (ticketvwap) and to get the transaction fee information for regular transactions in blocks, the mempool, and a height range (txfeeinfo) (145-29f116c)
• Updated documentation (147-5623458) and versioning (150-f93cb9f)

dcrwallet

• Added a non-default allowhighfees flag to wallet that enables users to send transactions that are not safety checked for high fees (214-ec2c1c2)
• Fixed an issue that could cause lock-ups in wallet (219-0e7558d)
• Improved error handling (224-d4ea045)
• Updated versioning (225-e545bec)

dcrrpcclient

• Added a number of new RPC commands (addticket, estimatestakediff, settxfee, stakepooluserinfo, ticketpoolvalue, ticketfeeinfo, ticketvwap, txfeeinfo) (16-a5a51f5)

gominer

• Enabled TLS, improved configuration, added a sample config file, and updated licensing (3-39550c6)
• Updated configuration (1-d43cd3e, 2-43e6a84)

ccminer/cgminer

• Deliverables from RFP-5 were released as updated miner binaries of ccminer (NVIDIA) and cgminer (AMD) for Windows and Linux (v0.1.0) (See: New Miner Binaries Now Available)

Developer Notes
Added stake pool fee functionality

We have added new config flags for dcrwallet. Let's go over each option to make crystal clear its usage:

stakepoolcoldextkey

When this option is set it turns on stake pool functionality for wallet. When stake pool is enabled for wallet, there are a series of transaction checks to verify whether this wallet will vote for a ticket that has used this stake pool's address as the ticketaddress. This option requires the extended public key of the stake pool's cold wallet that will receive the pool's fees. So on simnet for instance this option looks like this:

Code:

--stakepoolcoldextkey=spubVWAdividNTiSM9SdLRA5JX6LYNwt58cd51TFnpnULGQ8oqNMNskfkQwU7rjWMCY7phBguVr4XTmAWyDVRKpo2dFyjFb6QG4ihB8w64UPNuu:1000

The first portion (spub..., or dpub... on mainnet) is the extended public key and the second (1000) is the number of addresses to derive. Every user of the pool gets their own cold fee wallet address derived, so we recommend using at least 1000 in anticipation of the relative number of users in the stake pool. When a vote is created by the stake pool to vote on a ticket that has been given voting rights, it pays the pool fee to the address derived for the cold wallet from this extended public key.

pooladdress

This is for use by the stake pool user. It will be an address provided to the user by the stake pool. If set, this address is used during ticket purchase and will commit to a small output in the ticket that gives the stake pool its required fees.

ticketaddress

Same as the old option. This is the address that the stake pool user is giving the ticket's voting rights to.

poolfees

This is the required ticket fee as requested by the stake pool. The value set by the user needs to be greater than or equal to that of the pool. The fee is a percentage based fee, based on the stake subsidy. Here is a concrete example from simnet:

The ticket price of this ticket was 46.0551008, and the ticket relay fees were 0.00000100 per kB. The pool fees were set to 1.00%. The subsidy on simnet at this block height is approximately 29.40888 Coins per vote. This is the ticket as purchased by the user:

Code:

"vin": [
   ... ,
],
"vout": [
   {
     "value": 46.0551008,
     "n": 0,
     "version": 0,
     "scriptPubKey": {
       ... ,
       "reqSigs": 1,
       "type": "stakesubmission",
       "addresses": [
         "SsYZMHeeixdNRTkk6afzHBPL4unYDsFNd4r"
       ]
     }
   },
   {
     "value": 0,
     "n": 1,
     "version": 0,
     "scriptPubKey": {
       ... ,
       "type": "sstxcommitment",
       "addresses": [
         "Ssghjx8PvQVV3FM3w5FcGi9kWGvDpDkQDTV"
       ],
       "commitamt": 0.17948021
     }
   },
   {
     ... ,
   },
   {
     "value": 0,
     "n": 3,
     "version": 0,
     "scriptPubKey": {
       ... ,
       "type": "sstxcommitment",
       "addresses": [
         "SsYUi5tbXfqHnTPgvHcajNW4yiGeSP6n7Xq"
       ],
       "commitamt": 45.87562609
     }
   },
   {
     ... ,
   }
],

And here's the vote that the stake pool created for that user's ticket:

Code:

"vin": [
   {
     ... ,
   },
   {
     ... ,
   }
],
"vout": [
   {
     ... ,
   },
   {
     ... ,
   },
   {
   "value": 0.2940888,
   "n": 2,
   "version": 0,
     "scriptPubKey": {
       ... ,
       "type": "stakegen",
       "addresses": [
         "Ssghjx8PvQVV3FM3w5FcGi9kWGvDpDkQDTV"
       ]
     }
   },
   {
     "value": 75.16989347,
     "n": 3,
     "version": 0,
     "scriptPubKey": {
       ... ,
       "type": "stakegen",
       "addresses": [
         "SsYUi5tbXfqHnTPgvHcajNW4yiGeSP6n7Xq"
       ]
     }
   }
]

As you can see '"n": 2,', the third output, is the stake pool fee of 0.2940888. This is 1% of the vote reward at that point (0.2940888/29.40888). The remaining subsidy and the original coins are returned to the take pool user in output '"n": 3,'. For more information about stake fees, please refer to dcrwallet/wallet/txrules/doc.go.

[ilia7777]

That said, I do have some ideas on how to commercilalize Decred blockchain but it would need to become permissioned one, it would have to let go the currency altogether and do some heavy very specialized development for our industry needs. I'm not even going to ask Decred developers if they are interested cause obviously the answer is going to be no.

Take your government cock-sucking regulatory permission ideas and shove them up your ass!

This post is reported to moderator. But I just want to say to everybody, make no mistake I'm not in favor of total gov-t regulation of everything and definitely support public blockchains. All I'm saying is that unfortunately the future is not going to be what we would've like it to be.

[ilia7777]

That said, I do have some ideas on how to commercilalize Decred blockchain but it would need to become permissioned one, it would have to let go the currency altogether and do some heavy very specialized development for our industry needs. I'm not even going to ask Decred developers if they are interested cause obviously the answer is going to be no.

It` clear that there is no biz plan for Decred. Do you have one to offer? Or do you have any ideas?

Why don't we let the public decide what to use public Decred blockchain for. When it comes to our company or any company in money transfer business in the world the chances of using unpermissioned blockchain for its business activities are zero.  That is unfortunate reality I repeat.

[ilia7777]

That said, I do have some ideas on how to commercilalize Decred blockchain but it would need to become permissioned one, it would have to let go the currency altogether and do some heavy very specialized development for our industry needs. I'm not even going to ask Decred developers if they are interested cause obviously the answer is going to be no.

I have to agree with myagui on this one. It wouldn't be difficult to hire your own blockchain specialist.  The real question I have would be why?  

From your statements it sounds like you want a private blockchain in addition to a permissioned one. What would a blockchain do for your industry that a database doesn't? Unless it is going to interact with another public chain such as bitcoin, decred, or even ethereum.

Regarding hiring blockchain specialist I've already started these discussions. With regards to the use of the blockchain for our industry. It is actually perfect we have tones of compliance related stuff for each and every money transfer occuring. Plus compliance on each and every partner that we do and we have more than 500 partners worldwide. Everybody is collecting their own copy of the same info, everybody is driving each other crazy to get the documents apostilled by the govt to verify that they are indeed original. I can go on and on. Blockchain is perfect solution. When it comes to the actual money transfer bypassing SWIFT and regular financial system altogether is also great idea to make it all cheaper. Collecting passports of the sender and recipient on the blockchain for every stakeholder to see is also very useful.

[ilia7777]

wow 10th/s network hashrate..

Seems like there is quite a bit of interest in DCR...hashrate keeps climbing.

It's almost the most profitable coin to mine, and now that there is the dualminer with ETH, which is the most profitable coin to mine, it makes sense that hashrate would rise. I wouldn't necessarily expect price to rise though, more likely to drop as farms and stuff dual-mine and dump.

At this price and that diff. it isn't even capable of covering the energy bill.

I got 5 GH/s at 1.000 Watt.

1 KW = 0,24€

1*24*30*0,24 = 172,80€ Energy costs

Outcome = 2,5 DCR / day

2,5*30*0,0035 = 0,2625 BTC / month

1 BTC = 400€

400*0,2625 = 105 € revenue


172,80 - 105 = 67,80€ loss / month

Completely different picture over here. Residential electricity 0.05 cents US. Commercial below 3 cents. So it is profitable and Decred will see some hashing power coming from Eastern Europe.

[magalhanze]

anyone else experiencing issues on yobit?

i have 80 dcr withdraw stuck for 2 days now...

[Praxis]

anyone else experiencing issues on yobit?

i have 80 dcr withdraw stuck for 2 days now...

Have you tried contacting Yobit? Open a ticket?

[Altcoin11]

anyone else experiencing issues on yobit?

i have 80 dcr withdraw stuck for 2 days now...

Have you tried contacting Yobit? Open a ticket?

LOL that's a good one. They do not care.

[frostminer]

anyone else experiencing issues on yobit?

i have 80 dcr withdraw stuck for 2 days now...

Have you tried contacting Yobit? Open a ticket?

LOL that's a good one. They do not care.

The forum if filling up with yobit complaints..


They've never responded to any of mine either.
And wallets are forever on "maintainance"  .. which seems to mean "out of sync and we are too lazy to fix"

[cohnhead]

anyone else experiencing issues on yobit?

i have 80 dcr withdraw stuck for 2 days now...

Have you tried contacting Yobit? Open a ticket?

LOL that's a good one. They do not care.

The forum if filling up with yobit complaints..


They've never responded to any of mine either.
And wallets are forever on "maintainance"  .. which seems to mean "out of sync and we are too lazy to fix"

did they ban you over there...
they seem to disable wallets that are functional everywhere else.
and of course not respond to tickets

[kahir]

I haven't been following dcr for some time now ... is the GUI windows wallet out there ... if yes does it support the staking feature

[danel]

I haven't been following dcr for some time now ... is the GUI windows wallet out there ... if yes does it support the staking feature

RFP-1 is progressing. A bit slower than people would like, but it's happening. Lots of improvements rolling into the software under the hood, which isn't always that visible, but it means once the GUI wallet is slapped on top of it, it'll likely be a much better user experience. By that time, Decred should have a number of mainnet stake pools ready and operational as well, which would move everyone closer to the important goal of decentralised voting.