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

Wow! Loving the changes to Decredition. So so happy to be a hodler 

I think this is good for both short and long term. Really interested!

That's quite an amazing update for the 1.2.0 release. Very impressive, but i guess that's just how Decred rolls

EDITED: some links were wrong and have been fixed now

NEW WALLET!
https://forum.decred.org/threads/dd-28-v1-2-0-04-26-18.5978/




This development dispatch covers work completed since the Decred v1.1.2 release on December 15th, 2017.

Decrediton (OSX, Linux) GUI wallet installers:
Decrediton v1.2.0 Linux 64-bit https://github.com/decred/decred-binaries/releases/download/v1.2.0/decrediton-v1.2.0.tar.gz
Decrediton v1.2.0 macOS 64-bit https://github.com/decred/decred-binaries/releases/download/v1.2.0/decrediton-v1.2.0.dmg
Decrediton v1.2.0 Windows 64-bit https://github.com/decred/decred-binaries/releases/download/v1.2.0/decrediton-v1.2.0.exe

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

All the various binaries except for dcrinstall:
All v1.2.0 binaries and release noteshttps://github.com/decred/decred-binaries/releases/tag/v1.2.0

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

Instructions on how to verify the release binaries using GPG can be found here. https://github.com/decred/decred-binaries/blob/v1.2.0/README.md#verifying-binaries

dcrd

This release of dcrd contains significant performance enhancements, infrastructure improvements, improved access to chain-related information for providing better SPV (Simplified Payment Verification) support, and other quality assurance changes.

A significant amount of infrastructure work has also been done this release cycle towards being able to support several planned scalability optimizations.

Downgrade Warning

The database format in v1.2.0 is not compatible with previous versions of the software. This only affects downgrades as users upgrading from previous versions will see a one time database migration.

Once this migration has been completed, it will no longer be possible to downgrade to a previous version of the software without having to delete the database and redownload the chain.

Notable Changes

Significantly Faster Startup

The startup time has been improved by roughly 17x on slower hard disk drives (HDDs) and 8x on solid state drives (SSDs).

In order to achieve these speedups, there is a one time database migration, as previously mentioned, that will likely take a while to complete (typically around 5 to 6 minutes on HDDs and 2 to 3 minutes on SSDs).

Support For DNS Seed Filtering

In order to better support the forthcoming SPV wallets, support for finding other peers based upon their enabled services has been added. This is useful for both SPV wallets and full nodes since SPV wallets will require access to full nodes in order to retrieve the necessary proofs and full nodes are generally not interested in making outgoing connections to SPV wallets.

Committed Filters

With the intention of supporting light clients, such as SPV wallets, in a privacy-preserving way while still minimizing the amount of data that needs to be downloaded, this release adds support for committed filters. A committed filter is a combination of a probabilistic data structure that is used to test whether an element is a member of a set with a predetermined collision probability along with a commitment by consensus-validating full nodes to that data.

A committed filter is created for every block which allows light clients to download the filters and match against them locally rather than uploading personal data to other nodes.

A new service flag is also provided to allow clients to discover nodes that provide access to filters.

There is a one time database update to build and store the filters for all existing historical blocks which will likely take a while to complete (typically around 2 to 3 minutes on HDDs and 1 to 1.5 minutes on SSDs).

Updated Atomic Swap Contracts

The standard checks for atomic swap contracts have been updated to ensure the contracts enforce the secret size for safer support between chains with disparate script rules.

RPC Server Changes

New getchaintips RPC
A new RPC named getchaintips has been added which allows callers to query information about the status of known side chains and their branch lengths. It currently only provides support for side chains that have been seen while the current instance of the process is running. This will be further improved in future releases.


dcrwallet

This release provides bug fixes for issues reported by users as well as new RPC features and additions which are required for Decrediton and Politeia. SPV work is ongoing but these changes will not land until a future release and after most of the network nodes are running with committed filter support.

This release contains a database upgrade and once upgraded it is not possible to downgrade to previous wallet releases without performing a seed restore with the old version.

Bug fixes
Orphan votes (votes which have become invalid for the new main chain tip block after a reorg or missed vote) are now rejected from reentering the wallet if still notified by dcrd.
Watching only wallets are now usable again, after a breaking change to them introduced in the 1.1.2 release.
The transaction fee when purchasing tickets with the purchaseticket JSON-RPC and WalletService.PurchaseTickets gRPC methods will now fallback to the wallet's configured fee rate if not specified by the RPC request.
Various gRPC methods which allowed specifying 0 DCR as a target amount (e.g. WalletService.FundTransaction) now follow their documentation and will return or use as many unspent outputs as possible.
Outputs of transactions with an expiry set are not spendable by consensus rules until having reached coinbase maturity. These outputs are no longer returned or used when selecting previous outputs to create new transactions.

New features
A new gRPC method WalletService.UnspentOutputs has been added to return a stream of all wallet unspent outputs. Outputs may be filtered by their associated account and required confirmations, as well as stopping once a total target amount has been reached or exceeded.
A new gRPC method WalletService.BestBlock has been added which will return the hash and height of the current main chain tip block. Previously, this information was only available as a unary RPC with the WalletService.Accounts method.
The gRPC method WalletService.GetTickets will paginate results if called with a new target ticket count parameter.
A new gRPC method WalletService.CommittedTickets has been added to find ticket purchase hashes specified by the request where the largest P2PKH commitment amount is controlled by the wallet. The commitment address is additionally returned by the result.
A new gRPC method WalletService.SignMessages has been added to sign multiple messages at a time without needing to unlock and lock the wallet before and after each call.
The gRPC BlockDetails and BlockInfoResponse messages now include a new field which specifies whether votes in the block disapprove of the parent block.
A new JSON-RPC method publishunminedtransactions has been added which resends all unmined transactions of the wallet.
A new JSON-RPC method sweepaccount has been added which can be used to move as much value as possible from an account to either (possibly the same) account or an address. This RPC can be used in place of the consolidate method but without knowing and specifying exactly how many inputs to use.
The new JSON-RPC methods startautobuyer and stopautobuyer have been added which can start and stop the automatic ticket purchaser over JSON-RPC, similar to the already existing StartAutoBuyer and StopAutoBuyer gRPC methods of the TicketBuyerService.
The JSON-RPC method getbalance now returns aggregate balances for all accounts if called with the special * account name.

Other improvements
The sendtosstx, sendtossgen, and sendtossrtx JSON-RPC methods have been removed. These RPCs were intended to manually send ticket purchases, votes, and revocations manually, but were unimplemented and would cause crashes if used.
Transaction size estimation has been improved to more accurately estimate fees, in particular when redeeming with pay-to-script-hash redeem scripts.
The help JSON-RPC method text for the getbalance RPC has been updated to reflect the changes made to the returned object.
Users are now informed with log messages to configure their public passphrase or enter it on startup if the wallet is encrypted with one but it was not specified.
Script execution errors during sanity checks after signing inputs now record additional information about the failure including the previous output and script being spent and the signature script used by the input.

decrediton

This release of decrediton adds some major changes to the wallet startup, overview page and adds the first round of statistics for better user information. Now that the overall look and feel designed by Eeter has been implemented we will be focusing on refinement and adding improved responsiveness (e.g. dark mode, resolving to various media widths).

Launcher has been redesigned to provide the user with a more intuitive startup experience. In normal working mode, the daemon (of the chosen network) will begin to sync and become operational while the user completes wallet creation/selection. Then once both the wallet is ready and the daemon has synced the wallet will fully load.

A tutorial, release notes, settings and logs have all been added to the launcher for the user to utilize whilst they may be waiting for their daemon to sync. Hopefully this will allow the user to more seamlessly create wallets with less confusion or require any additional support.

The wallet creation by seed has received a substantial update as well. We now allow the user to copy seeds (if they complete a warning screen) and also paste seeds. And for confirmation for new wallets only requires the user to complete 1/3 of the words to confirm storage of wallet's seed.

Overview has been redesigned to give the user more information about their wallet's current situation and to guide them where to find various features of their wallet. Basic graphs covering balances, tickets and transactions have been added. All recent transactions and recent ticket activity can be found below the overview graphs. We will be adding more features to the overview page as we gauge user interest and feedback on existing additions.

Introductory data preparation and statistics have been implemented for this release. For now we are providing a small window of lookback for transactions, staking and other information. The reduced window size is mostly an issue with unsatisfactory performance. When this performance improves, we will be adding custom windows and window lengths for custom graphing and exporting options.


New features
Validate Addresses - a form to validate addresses has been added to the Security Center. This will allow users to test addresses to confirm address ownership and/or validity.
Filter by address - now transactions can be filtered by address in History. When the user enters a string into the address filter form, it will show any address that has an output with a matching address.
Charts - we have decided to use recharts as our first charting solution.
Import wallet from hex seed - instead of entering in the 33 word mnemonic, they are now able to use the hex representation of their seed.
Export data to CSV - we now all users to export various types of data to csv. These options are found under the Transactions page.
Show logs - logs can now be found on the launcher and on the help page. For now, we only show the logs of the current instance of wallet and daemon. This is mostly due to performance with pulling in thousands of lines of text.

Contributors

We would like to thank our contributors for their work this release:
Andrew Chiw, ay-p, brunobraga, cipherzzz, davecgh, dhill, dnldd, githubsands, go1dfish, Federico Gimenez, jolan, jrick, maicalal, marco, Markus Richter, matheusd, peterzen, shweini, sndurkin, StabbarN, Javed Khan, Victor Oliveira, Daniel Krawsiz, Jon Gillham, Ryan Vacek

For every coin they have a price.
The decred dev team refuses to pay to be listed on an exchange for ethical reasons.

Do  you need to pay to get listed there?

Wrong. You just can't follow instructions, so you're butthurt.  https://bitcointalksearch.org/topic/m.22659558

You are doing a great job! Have a nice day for the project

Decred are bittrex insiders/scammers binance don't want the SEC up their ass with the shitstorm about to hit Decred/Bittrex fraud :\ meh

Cant we make a proposal covering the listing fees and other requirements? Decred should be up there we need more availability and liquidity.

I also think we are one of the few that can make it to gdax/coinbase

Amazing project decred.
Applied for aidrop with reference to my previous coin developed.

Thanks! Any chance you know of an online public api? 

if Decred gets listed on binance, we can expect huge volume and increase in price for it

I can confirm that i receive my coin from Evo.

Contact them through the mail and they answer it nicely. Such a great support.

If anyone still having trouble with evo, just email them.

Thanks

Sure, try: https://explorer.dcrdata.org/

Anyone know if the Halong B25? or something? 10k decred miners have hit the world yet? Supposedly I saw a ship date of March 30th 2018 but that don't seem likely

the batch of decred miners for siatech obelisk dr-1's are June 30th, 2018 with Aug 30th 2018 for the 2nd batch of decred miners..

As far as lot size goes...the Halong B?? was like 2100gh I think for the 10k about...the obelisk decred miners were around 3,600 each batch I think?

so anyway, will this stuff have any effect on hash rate etc....or at those numbers not a big deal? (also got bitmain may release some in that time frame if so it will

be at 15,000 units is the norm for them)

anyway, just tossing it out here in the community...on what you think....etc with ASIC's coming

brad

Read a little about the project ... you sound like a trolling ... dev funds are how Decred works as an "independent funding project" versus the type of ICO project. 10% of each gift block falls into the wallet and is used to pay for development and other needs.

Anyone know of some public APIs for Decred? Something that will give me balances given wallet addresses?

As far as I know, there are no pools that behave like that. For sure, none of the pools listed here require trust (sharing/giving away your private key): https://dcrstats.com/

The Evolution service wasn't actually its own pool. It was just an application that handled auto-purchasing tickets for you. It just happened to use a PoS pool (of course, so it *could* buy tickets). So it was the Evo service, not the pool itself which you were having to trust when you used it. 

Hi IncludeBeer,

that is some interesting information as I was completely wrong about it all the time obviously. Does the delegation of the voting right apply to every POS pool or are there also pools where you do give away your private keys?