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

Sorry if this has already been asked and answered but the thread is very long. On Paymetheus Wallet how can I view all receive addresses generated? I don't like generating and address and having it never be used. I like to use them in order. But I cannot find a way to view addresses shown to me so far.

Also, this wallet is a pig when you first set it up. It was hosing my GPU cores and increased the power consumption of my computer by 150 watts when it was downloading the blockchain. Never had a wallet do this to my computer before. CPU got so hot computer was beeping a warning. Usually CPU runs very cool. Now it is back to normal but that was very disconcerting.

Disabled getblocktemplate? Seriously?

1.0.1 has been released to fix various bugs that were causing headaches.

https://forum.decred.org/threads/dd-22-v1-0-0-04-25-17.5312/#post-25147

The links in the OP have been updated.

https://dcr.suprnova.cc also on 1.0.0

The POS pool stake.decredbrasil.com already on v1.0



You need to be up to date to be able to vote on currency decisions.




If they are blocked on the POS mining, they will only be unblocked after being voted.

It will be once enough people upgrade.

Is there a way to unlock my DCR on paymentpytheus wallet?

Is 1.0 version a madatory update?

Scanning/syncing for the first time can take a few hours depending on your machine.

It's asking you for the Public Passphrase, which you probably didn't set and can press the button without entering anything.

Yeep. I was told to post on Github:
https://github.com/decred/Paymetheus/issues/251
 

Might have better luck posting this at forum.decred.org

Ok, bitcoin is gold. But...
DCR - better and more secure smart contracts.
DCR - better and more secure currency
DCR - inovative privacy system based on ZK
ICO = scam. Not on DCR
Marketplace? I prefer ebay
DCR - decentralised governance. What the community wants will be implemented

Yeep. There are several icons to confuse.

https://s16.postimg.org/e594n5jdx/pay_icon.jpg

In version 1.0, there are still problems on the home screen in Paymetheus, which makes it impossible to spend the coins to buy tickets, send, etc.
I have solved this:

https://s7.postimg.org/qxu3ouoob/Paymetheus_en.jpg
I spend several hours waiting for download again.

So i have a suggestion that is simple to implement until can resolve the bugs:

https://s13.postimg.org/kl6s1dgwn/suggestion.jpg

Sorry but have to say it,

Paymetheus wallet is serieusly the worst wallet i ever had, and trust me i owned around 20.
At first the blockchain downloading keeps stuck and when you restart the wallet it ask for the passphrase and give a standard incorrect passphrase error.
And yes im typing the right one, cause i did it 3 times now and im 100% sure its the right one.

So again restarting it with the same seed to recover and after putting in the seed it again start downloading the blocks and after scanning the blocks.
And guess what scanning stuck, again have to restart and guess what again incorrect passphrase.

Serieus i wanted to stake this coin and keep it but after a morning fight with this wallet i dont even know if i want it to work anymore.

I'd like to start using the Paymetheus wallet. I've always used the CLI wallet so far, so how do I migrate those accounts/wallets to Paymetheus? If I choose the restore option, it asks for a seed. How can I get that seed through the CLI?

Looks like more dumping coming!!

Decred - Automated Governance

is there any reason at all that you disabled copy/paste/crtl+v  of the seed into the new 1.0 version? I mean a whole paragraph of text i have to manually retype in and make sure its 100% accurate... Seriously?

Icon

Gyes   

In simple words like I’m five years old

Bitcoin – first crypto and digital gold
Etherium – smart contracts
Dash – currency
Monero – anonimus currency
Stratis – smart contracts for b2b
Waves – platform for ico
Bitshares – decenterliesed marketplace
And so on

what is Decred for?

From: https://forum.decred.org/threads/dd-22-v1-0-0-04-25-17.5312/




This development dispatch covers work completed since the Decred v0.8.0 release on February 13th, 2017. Since then, developers have merged over 250 pull requests into 11 repositories.

Here are direct links to the Paymetheus (Windows) GUI wallet installers:
Paymetheus v1.0.0 64-bit https://github.com/decred/decred-binaries/releases/download/v1.0.0/decred_1.0.0-release_x64.msi
Paymetheus v1.0.0 32-bit https://github.com/decred/decred-binaries/releases/download/v1.0.0/decred_1.0.0-release_x86.msi

decrediton (OSX, Linux) GUI wallet installers:
decrediton v1.0.0 Linux 64-bit https://github.com/decred/decred-binaries/releases/download/v1.0.0/decrediton-1.0.0.tar.gz
decrediton v1.0.0 OS X 64-bit https://github.com/decred/decred-binaries/releases/download/v1.0.0/decrediton-1.0.0.dmg

dcrinstall cross-platform text-based CLI installers:
dcrinstall v1.0.0 All platforms https://github.com/decred/decred-release/releases/tag/v1.0.0

all the various binaries except for dcrinstall:
all v1.0.0 binaries https://github.com/decred/decred-binaries/releases/tag/v1.0.0

NOTE: All Windows binaries only support Windows 7 and newer.

In the last 2.5 months since the release of 0.8.0, Decred has seen another substantial increase in its exchange rate, which went from DCR/BTC of 0.0025 to an all-time-high of 0.0218 and settled above 0.01, and a corresponding surge of new users, based on GitHub downloads of 0.8.2 binaries increasing by over 100% relative to 0.7.0. While this improvement in the exchange rate and community engagement is great news, what we're most excited about is hard fork voting being put into production on mainnet with this 1.0.0 release. The introduction of hard fork voting on mainnet means that the stakeholders will be able to vote on major decisions, referred to as agendas, that affect the future of Decred.

Hard Fork Voting on mainnet

The 1.0.0 release of Decred includes the first 2 such agendas that will be voted upon:
whether or not to use a new ticket price algorithm
whether or not to begin development work to support the Lightning Network (“LN” for short)
The ticket price algorithm change will be a substantial improvement over the existing one, based on the simulations posted on GitHub. If stakeholders vote yes and signal they want LN support, the developers can begin working to accomplish that with confidence the code changes will be voted in and activated in the future. It is expected that voting on and activation of these agendas will take 3-4 months:
roughly 1 month for miners and stakeholders to update to version 1.0.0, which signals support for the new block version, vote version and then stake version
up to 3 weeks to wait until vote tallying begins
4 weeks for votes to be tallied, at the end of which, any agenda receiving over 75% 'yes' votes is locked-in for activation, any agenda receiving over 75% 'no' votes is marked as failed, and all other agendas roll over to be voted on in the next 4 week voting interval
4 weeks for locked-in agendas to become active and have their changes enforced on mainnet
It is worth noting that Decred not only allows its stakeholders to vote on these critical changes, but these changes are activated via a pre-coded mechanism in the software. Decred's consensus daemon, dcrd, comes with these conditional consensus changes pre-coded and ready to activate once stakeholders vote them in.
This release is a notable milestone since it is the first step in disintermediating politics within Decred. We aim to “share the wheel” with our stakeholders to both eliminate conflicts of interest present with having an elected or appointed representative, such as myself, and because we believe we can make better decisions for Decred as a group than individually. Some modern governance organizations take a similar approach by episodically holding referendums on important issues. Consensus changes can have wide ranging consequences for Decred, so it is only fair to solicit the opinion of our stakeholders as part of this process.

It is worth noting that the LN support agenda is not a consensus change, but we have still added it as an agenda. If the results indicate strong stakeholder support for supporting LN, that work can begin with minimal risk before the vote has completed. In the future, hard fork voting will almost exclusively relate to consensus changes, to keep on-chain data to a minimum, but we wanted to assess stakeholder sentiment for this before work begins. Voting on decisions that do not affect consensus code would be better handled somewhere off-chain, which we will be working towards after this release.

GUI Wallet Voting and Staking

Both Paymetheus and decrediton have added support for setting voting preferences at a user's stakepool. Setting your voting preferences with your stakepool requires that the stakepool support the new v2 stakepool API, so it may take a few weeks to get this supported across all stakepools. Setting voting preferences is an action that a user will typically perform only once during a giving voting cycle, so this only needs to be done once every several months, as opposed to manually for every vote cast.

decrediton now supports several staking features previously only available in Paymetheus, along with automatic ticket buying, which Paymetheus does not yet support. Users can now connect to their stakepool using the API, manually purchase tickets, and also automatically purchase tickets. It is recommended that users take caution when setting up automatic ticket buying since its increase in convenience is accompanied by heightened security risks and requires episodic human supervision.

Wallet Infrastructure

A couple major changes have been made to dcrwallet's infrastructure that should be mostly transparent to users. As part of our initial release, a concept of "address pools" was added to dcrwallet that solved some short-term issues, but this has led to several problems once it was in production. Address pools have been removed and a look-ahead buffer for addresses has been added in its place. This properly implemented look-ahead buffer has the benefit of allowing users to use multiple wallets with the same seed without event, unless wallets that share a seed are concurrently attempting to create transactions.

The second major change addresses wallet database versioning and error handling: the various components of the database are now coherently versioned and error handling has been simplified. With the previous database versioning scheme, there was potential for database corruption as a result of version mishandling, but this is now properly versioned and unified, along with the error handling.

Required gominer Update

As part of the fix for the recent proof-of-work mining pool "outage", users of gominer must upgrade to the latest version, unless they are mining in solo mode. This is required due to the fixes made to ensure that the stake version is set properly by mining pool software.

Re-architected dctstakepool

Stakepools have been running on mainnet for over a year now, and as part of supporting hard fork voting, we have re-architected the stakepool software, dcrstakepool. After receiving feedback from stakepool operators, we decided that changing the architecture made sense. The old architecture had a stakepool update votebits on every individual ticket on every voting wallet when users of the pool updated their voting preferences. Prior to the start of hard fork voting, users would not regularly change their votebits, but now that this action will occur more frequently, stakepools need to efficiently handle these user changes.

To compensate for the increase in frequency of users changing their voting preferences, a new daemon, stakepoold, has been added to the configuration that mediates the setting of ticket votebits according to each user's preferences. Instead of pushing all the votebit setting and ticket management to voting wallets, stakepoold watches for notifications for votes and new pool tickets, then it tells the wallet how to create each vote according to its owner's voting preferences. This avoids all the churn and load associated with setting individual ticket votebits across several voting wallets, and sets the votebits according to user preferences "just in time".

We have been testing the current dcrstakepool code on testnet for a couple weeks now, and it has worked without serious event thus far. Prior to this release, we were able to perform a preliminary deslugging of the code, but we have not completed this process and performance tested relative to the old architecture. Voting is a latency-sensitive operation, so in order for mainnet stakepools to upgrade with confidence, we must verify the latency of this configuration is sufficiently low. There will likely be one or more patch releases of dcrstakepool as part of upgrading existing mainnet stakepools to the new version. In the meantime, stakepool operators can start to prepare for the upgrade using this release.

Next Steps

Now that we have covered what this release accomplishes, it is instructive to consider what kinds of decisions are not a good fit for the on-chain voting process. Decred, as an organization, must make many types of different decisions in order to continue building its infrastructure, expanding its user base, and increasing its utility to its users. If we voted on every single minor decision, not only would it take a long time to get anything done, it would lead to a lot of on-chain bloat, along with several other negative side effects. With these considerations in mind, we will begin work on a new tool that allows users to construct an ongoing record of off-chain data that is anchored into the Decred chain episodically, creating a time-ordered set of records. In the context of Decred governance, we will build a proposal system using this tool, with the following properties:
the proposal records will be publicly available
users can submit proposals via the system
submissions will have an associated fee to prevent spam, which can be refunded under certain conditions
the records are episodically anchored into the Decred chain to create a time-ordering
Once this tool has been developed, we can begin the process of disintermediating the other smaller decisions that occur within Decred. For example, future consensus changes will be submitted via the proposal system, and after assessing stakeholder sentiment, can be put to an on-chain vote. The goal is to have all decisions that relate to funding and voting route through this proposal infrastructure. A proposal system as described should be able to handle most of the smaller decisions that Decred needs to make on an ongoing basis.

The medium term goal I have for Decred is to replace myself with a collection of minimally-complex non-Turing complete smart contracts. Once that process is complete, Decred will have a robust governance system with minimal conflicts of interest, which can control the development subsidy and direct the project as stakeholders see fit.

Public keys

The file cmd/dcrinstall/pubkey.go contains the decred public key which is used to check the signed manifest in the release. You can compare the contents of this file to what you get from a keyserver to confirm that dcrinstaller is using the proper key.

Contributors

And a big thank you to everyone who contributed to this release: @davecgh, @moo1337, @jrick, @ay-p, @jolan, @jcv, @dhill, @raedah, @javed-khan, @karamble, @linnutee, sander, @gratefulcheddar, @Shadowlance, jholdstock, boblin, Baggins800, Kmaschta, @chappjc, @peterzen, captain-redbeard, @girino