Topic: [ANN][GRS] Groestlcoin | 1st to activate Segwit | Building Lightning Network - page 23. (Read 558272 times)

This coin spiked back in 2017 like 1000% in a period of 1 week and then dumped and pumped again, It may be a good coin but it seems its good for only pump groups, What goes up like this always comes down badly ESPECIALLY when their is no mega news regarding why the price pumped out of nowhere which raises eyebrows and flags so I wouldn't fall a victim while some pump group is behind it.

---

---

In order to bring Groestlcoin to the mainstream masses the Groestlcoinomi Blackberry wallet (v1.5.29) is ready for testing. The app allows you to send and receive Groestlcoins on your device without syncing the blockchain. When using this app, please store your secret phrase and email them to yourself! Then your coins can be retrieved even if you loose your phone. Furthermore, this puts the user in total control of their funds at any given time.

Electrum-grs Blackberry implementations:
BIP-0032 to implement a hierarchical deterministic wallet
BIP-0039 to implement a mnemonic code of mnemonic sentence for the generation of deterministic wallets (process for turning in into a BIP-0032 seed)

Changelog Groestlcoinomi v1.5.29:
• Rebranded to Groestlcoinomi
• Updated Testnet logo

Changelog Groestlcoin Electrum GRS v1.5.28:
• Added testnet support and ability to switch between mainnet and testnet
• Added support to receive from non native segwit address
• Added more electrum-grs servers

Changelog Groestlcoin Electrum GRS v1.5.25:
• Improved UI for setting a BIP39 passphrase
• Fixed memory leak when restoring a wallet
• Fixed crashes on some devices
• Possibility to sign and verify messages
• Account details screen to view the public key
• Some UI optimizations
• Bug fixes
• Increase the default size of the recovery phrase
• Can set an amount in receive screen
• Small optimizations when handling the QR code and transactions
• Added ability to spend own unconfirmed change funds
• Support payment URIs requests from browsers and other apps

Features
• Exchange rates for various national currencies
• Manual receiving address management (enable in settings)
• Wallet only needs to be backed up once, on initial creation
• Wallet backup consists of simple list of 12 common words (BIP-0039)
• Empty the wallet with 1 click
• Automatic connectivity management with fast reconnects and detection of network change
• Password protect your recovery phrase
• Top security - Electrum-grs uses bank grade technology. Your money is kept safe by guaranteeing that your private keys will never leave your gadget. The user has absolute control
• Warning if there are no connections to the Electrum-GRS servers
• Click on any addresses to edit the label or copy it
• Support payment URIs requests from browsers and other apps

It is appreciated if feedback of the following is provided:
1.  Can you receive coins? (small amounts to avoid losing them)
2.  Can you send coins?
3.  Can you scan a QR code from another phone.
4.  Can you request coins via email or other Blackberry service?
5.  Does it calculate exchange rates properly?
6.  How fast is a transaction?

Important:
Store your secret phrase somewhere safe!

To close the app, simply press the back button until you reach your home screen.  The app will close itself (there is no need for a disconnect option). This application is licensed under the GPL version 3. There is no warranty and no party shall be made liable to you for damages. If you lose coins due to this app, no compensation will be given. Use this app solely at your own risk.

The application may have unfound bugs and problems. To leave feedback: 
1. PM hashengineering on bitcointalk: https://bitcointalksearch.org/user/hashengineering-155038
2. Email: [email protected]
3. Reports of errors can also be posted in this topic.

Groestlcoinomi Blackberry is available in the Blackberry World:
https://appworld.blackberry.com/webstore/content/59983243/

Source code:
https://github.com/Groestlcoin/groestlcoinj - Groestlcoin Java Library (for the Blackberry App and possibly other software)
https://github.com/Groestlcoin/android-electrum-grs - Groestlcoinomi

---

---

In order to bring Groestlcoin to the mainstream masses the Groestlcoinomi Android wallet (v1.5.29) is ready for testing. The app allows you to send and receive Groestlcoins on your device without syncing the blockchain. When using this app, please store your secret phrase and email them to yourself! Then your coins can be retrieved even if you loose your phone. Furthermore, this puts the user in total control of their funds at any given time.

Electrum-grs Android implementations:
BIP-0032 to implement a hierarchical deterministic wallet
BIP-0039 to implement a mnemonic code of mnemonic sentence for the generation of deterministic wallets (process for turning in into a BIP-0032 seed)

Changelog Groestlcoinomi v1.5.29:
• Rebranded to Groestlcoinomi
• Updated Testnet logo

Changelog Groestlcoin Electrum GRS v1.5.28:
• Added testnet support and ability to switch between mainnet and testnet
• Added support to receive from non native segwit address
• Added more electrum-grs servers

Changelog Groestlcoin Electrum GRS v1.5.25 :
• Improved UI for setting a BIP39 passphrase
• Fixed memory leak when restoring a wallet
• Fixed crashes on some devices
• Possibility to sign and verify messages
• Account details screen to view the public key
• Some UI optimizations
• Bug fixes
• Increase the default size of the recovery phrase
• Can set an amount in receive screen
• Small optimizations when handling the QR code and transactions
• Added ability to spend own unconfirmed change funds
• Support payment URIs requests from browsers and other apps

Features
• Exchange rates for various national currencies
• Manual receiving address management (enable in settings)
• Wallet only needs to be backed up once, on initial creation.
• Wallet backup consists of simple list of 12 common words (BIP-0039).
• Empty the wallet with 1 click
• Automatic connectivity management with fast reconnects and detection of network change
• Password protect your recovery phrase
• Top security - Electrum-grs uses bank grade technology. Your money is kept safe by guaranteeing that your private keys will never leave your gadget. The user has absolute control
• Warning if there are no connections to the Electrum-GRS servers
• Click on any addresses to edit the label or copy it
• Support payment URIs requests from browsers and other apps

It is appreciated if feedback of the following is provided:
1.  Can you receive coins? (small amounts to avoid losing them)
2.  Can you send coins?
3.  Can you scan a QR code from another phone.
4.  Can you request coins via email or other android service?
5.  Does it calculate exchange rates properly?
6.  How fast is a transaction?

Important:
Store your secret phrase somewhere safe!

To close the app, simply press the back button until you reach your home screen.  The app will close itself (there is no need for a disconnect option). This application is licensed under the GPL version 3. There is no warranty and no party shall be made liable to you for damages. If you lose coins due to this app, no compensation will be given. Use this app solely at your own risk.

The application may have unfound bugs and problems. To leave feedback: 
1. PM hashengineering on bitcointalk: https://bitcointalksearch.org/user/hashengineering-155038
2. Email: [email protected]
3. Reports of errors can also be posted in this topic.

Groestlcoinomi Android is available in the Google play store:
https://play.google.com/store/apps/details?id=hashengineering.groestlcoin.wallet.electrum

Source code:
https://github.com/Groestlcoin/groestlcoinj - Groestlcoin Java Library (for the Android App and possibly other software)
https://github.com/Groestlcoin/android-electrum-grs - Groestlcoinomi

---

---

The P2Pool software encodes the shares into what's called the share chain. This is very similar to the block chain used by Groestlcoin. This chain is built using the computational power miners use to find shares. All of the P2Pool nodes maintain a copy of the share chain for the current block and use it to determine payouts to miners. Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Groestlcoin and avoids the risk of hard to detect theft by pool operators. Because of the importance of strengthening Groestlcoin's decentralization, some Groestlcoin supporters donate to P2Pool miners, resulting in average returns above 100% of the expected reward.

Miners are configured to connect to a P2Pool node that can be run locally, alongside the miner. P2Pool users must run a full Groestlcoin node which serves the purpose of independently validating transactions and the Groestlcoin blockchain.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.
When you first start P2Pool claimed efficiency will be low and the error bounds on this estimate will be large, but as it runs the numbers will converge to their correct values. Due to the way the PPLN (Pay Per Last N Shares) payout system in P2Pool works, slow or very unlucky miners may not receive the first payout for up to 24 hours. However, once the first payout is received, the payout for the miner will grow to match the miner's mining speed. The system is designed to punish pool hoppers - miners who switch pools to get the maximum amount of shares. If your efficiency is unusually low, make sure your network connection isn't overloaded, that your miners support long polling and are not set to work for excessive amounts of time, and that your groestlcoind has multiple connections.

Features
• No registration required. To join a p2pool, all you need is your payout address
• The P2Pool network is DDOS resistant, if the node you are mining on is down, you can just switch to another node, without losing any shares
• If a node is compromised, the attacker cannot steal any of the worker's payouts
• Miners get higher payouts than normal pools because they receive transactions fees from block rewards
• SegWit compatibility
• CSV compatibility
• Bech32 compatibility
• p2sh-segwit compatibility
• BIP65 compatibility
• BIP66 compatibility
• Requires Groestlcoin >= 2.16.0
• Bootstrap address list
• Small statistical advantages increasing income
• Control over your own pool node
• No need to trust a pool operator
• Immediate payments
• Helps to protect and keep the groestlcoin testnet network decentralized
• Open source - Opensourced, written in Python

It is appreciated if feedback of the following is provided:
1. Can you mine with a legacy address?
2. Can you mine with a p2sh-segwit address?
3. Can you mine with a bech32 address?

P2pool is licensed under GNU. There is no warranty and no party shall be made liable to you for damages. If you lose coins due to p2pool testnet, no compensation will be given. Use p2pool testnet solely at your own risk.
 
The application may have unfound bugs and problems. To leave feedback: 
1. PM me
2. Email: [email protected]
3. Post reports of erros in this topic.

Groestlcoin testnet p2pool is available via http://testp2pool.groestlcoin.org:21330/static/

Source code: https://github.com/Groestlcoin/p2pool

---

---

Groestlsight Testnet REST API provides you with a convenient, powerful and simple way to read data from the groestlcoin testnet network and build your own services with it.

Features
• Support to verify signed messages online. Verify that a message comes from a specific Groestlcoin testnet address.
• Support to broadcast transactions online. Broadcast a raw transaction in hex format over the Groestlcoin testnet network.
• Multiple languages supported, including Japanese, German and Spanish.
• Fast - Fast navigation using client side javascript rendering with AngularJS.
• Mined by - Check which pool mined the block.
• Multiple platforms - Supports all browsers
• API - Complete REST and Websocket API for quering blocks, transactions, and addresses; and receiving live updates
• Light - Thin data model using groestlcoind RPC interfase to validate blockchain information. Fast groestlcoind blockchain syncronization (~1hrs for the entire livenet), using LevelDB for data storage and, optionally, raw groestlcoind data files processing.
• Exhaustive - Reports on double spend attempts, outpoints confirmations, outputs spend status reports. Input and Outputs hyperlinks in transactions. Extended view in transactions to show advance details.
• Open source - Opensourced, written in node.js and based on the powerful groestlcore nodejs library.

It is appreciated if feedback of the following is provided:
1. Can you verify signed messages?
2. Can you broadcast a raw transaction?

Groestlsight testnet is licensed under MIT. There is no warranty and no party shall be made liable to you for damages. If you lose coins due to groestlsight testnet, no compensation will be given. Use groestlsight testnet solely at your own risk.
 
The application may have unfound bugs and problems. To leave feedback: 
1. PM me
2. Email: [email protected]
3. Post reports of erros in this topic.

Groestlsight testnet is available via http://groestlsight-test.groestlcoin.org/

Source code: https://github.com/Groestlcoin/insight

---

---

If you're tired of the random, cryptic addresses generated by regular groestlcoin clients, then vanitygen is the right choice for you to create a more personalized address.

Changelog Groestlcoin Vanitygen v1.03b :
• Add compressed address support by salfter
• Add ocl compressed address support by scintill
• Add keyconv compressed suppport by ryancdotorg
• Apply bug fix by cmisare

Changelog Groestlcoin Vanitygen v1.02b :
• Improved UI for setting a BIP39 passphrase
• Signed Linux and Windows binaries available
• Multiple Makefile fixes
• Multiple OpenCL fixes
• Removed the need for using the -G flag
• Add keyconv support(encryption/decryption of private keys using password)
• Fix misleading error messages
• Bugfix for compiling kernel

Features
• Vanitygen accepts as input a pattern, or list of patterns to search for, and produces a list of addresses and private keys.
• Vanitygen's search is probabilistic, and the amount of time required to find a given pattern depends on how complex the pattern is, the speed of your computer, and whether you get lucky.
• Vanitygen includes components to perform address searching on your CPU (vanitygen) and your OpenCL-compatible GPU (oclvanitygen). Both can be built from source, and both are included in the Windows binary package.
• Upon finding a match for a given pattern, vanitygen will stop searching for additional matches for that pattern. To search for multiple matches for each pattern, use the -k option
• Prefixes are exact strings that must appear at the beginning of the address. When searching for prefixes, vanitygen will ensure that the prefix is possible, and will provide a difficulty estimate.  Exact prefixes are case-sensitive by default, but may be searched case-insensitively using the -i option
• The percentage displayed just shows how probable it is that a match would be found in the session so far. If it finds your address with 5% on the display, you are extremely lucky.  If it finds your address with 92% on the display, you are unlucky.  If you stop vanitygen with 90% on the display, restart it, and it finds your address with 2% on the display, your first session was unlucky, but your second session was lucky.
• Vanitygen uses the OpenSSL random number generator. This is the same RNG used by groestlcoin and a good number of HTTPS servers. It is regarded as well-scrutinized. On Linux, the RNG will be seeded from /dev/urandom. Guessing the private key of an address found by vanitygen will be no easier than guessing a private key created by groestlcoin itself. Nonetheless, if you feel the default RNG is unable to provide numbers that are sufficiently difficult to guess, vanitygen can be directed to seed the RNG from an external file using the -s option.
• To speed up address generation, vanitygen uses the RNG to choose a private key, and literally increments the private key in a loop searching for a match. As long as the starting point is not disclosed, if a match is found, the private key will not be any easier to guess than if every private key tested were taken from the RNG. Vanitygen will also reload the private key from the RNG after 10,000,000 unsuccessful searches (100M for oclvanitygen), or when a match is found and multiple patterns are being searched for.
• Free software - Gnu GPL v3. Anyone can audit the code.
• Written in C - The code is short, and easy to review.

To use vanitygen, you need to open a command line window and change to the directory where you extracted the vanitygen program.  An easy way to do this in Windows 7, hold down the shift key, right-click on the folder where you unzipped vanitygen, and select "Open command window here."  Then, you can type the vanitygen command at the prompt. Example how to use:

Generate an address using CPU(slower):
Linux: ./vanitygen Fgrs
Windows: vanitygen.exe Fgrs
Difficulty: 78508
Pattern: Fgrs
Address: Fgrsa16NshK1ua6KyBSXahz6D9PYUbvL3d
Privkey: 5JssG8to6x62vf9pC7ktJhXc3jJV31JR1Do7qLvQEx8wVUQ37op

Generate an address using GPU(faster):
Linux: ./oclvanitygen Fgrs
Windows: oclvanitygen.exe Fgrs
Difficulty: 78508
Pattern: Fgrs
Address: FgrsjEdkYaubKoxqKJ9uGP9pHxknhrn7Vj
Privkey: 5KHCnR5HAkdrePoQiXcvJh3ZADt1EymnryySi4tkqTArnQGTwQc

Password protected private keys:
Linux: ./vanitygen -e Fgrs
Windows: vanitygen.exe -e Fgrs
Difficulty: 19627
Enter new password:
Verifying - Enter new password:
Pattern: Fgrs
Address: FgRsguD6fqcHM7HXHG6WDqSg78NrdRB4Bz
Protkey: PsTaTXeXSLDrVc8bjJVg6uTvDhdziG5jHXyM6jC1j1wf4EFCt5n5djP5rBbtnztkvQLQ

Decrypting password protected private keys:
Linux: ./keyconv -d PsTaTXeXSLDrVc8bjJVg6uTvDhdziG5jHXyM6jC1j1wf4EFCt5n5djP5rBbtnztkvQLQ
Windows: keyconv.exe -d PsTaTXeXSLDrVc8bjJVg6uTvDhdziG5jHXyM6jC1j1wf4EFCt5n5djP5rBbtnztkvQLQ
Enter import password:
Address: FgRsguD6fqcHM7HXHG6WDqSg78NrdRB4Bz
Privkey: 5JvKJy4XSeGRHapyTich5oVYiwANPbzjvFiHXSafawU4eNcD5Wt

Note: Groestlcoin addresses consist of random digits and uppercase and lowercase letters, with the exception that the uppercase letter "O", uppercase letter "I", lowercase letter "l", and the number "0" are never used to prevent visual ambiguity.

It is appreciated if feedback of the following is provided:
1. Are you able to create vanity addresses for Groestlcoin?
2. Are you able to create a password protected private key?
3. Are you able to decrypt a password protected key?
4. Are you able to sweep the private keys (using any of our clients)?
5. Are you able to import the private keys (using any of our clients)?

This application is licensed under the GPL version 3. There is no warranty and no party shall be made liable to you for damages. If you lose coins due to this app, no compensation will be given. Use this app solely at your own risk.

The application may have unfound bugs and problems. To leave feedback: 
1.  PM ExploitAgency on bitcointalk: https://bitcointalksearch.org/user/exploitagency-951625
2.  Email: [email protected]
3.  Reports of errors can also be posted in this topic.

Download the Groestlcoin vanitygen here:
Linux: https://github.com/Groestlcoin/vanitygen/releases/download/1.03b/linux-binary.tar.gz
Windows: https://github.com/Groestlcoin/vanitygen/releases/download/1.03b/windows-binary.zip

Source code: https://github.com/Groestlcoin/vanitygen

---

---

If you are an ordinary user of Groestlcoin and simply want the convenience of a web wallet with the security of a real application and support for multi-signature, then Elecrum-GRS is the right choice for you.

Features
• Encrypted wallet - the file that contains your groestlcoins is protected with a password. You are protected from thieves.
• Deterministic key generation - If you lose your wallet, you can recover it from its seed. You are protected from your own mistakes.
• Instant on - the client does not download the blockchain, it requests that information from a server. No delays, always up-to-date.
• Freedom and Privacy - The server does not store user accounts. You are not tied to a particular server, and the server does not need to know you.
• No scripts - Electrum-GRS does not download any script. A compromised server cannot send you arbitrary code and steal your groestlcoins.
• No single point of failure - The server code is open source, anyone can run a server.
• Transactions are signed locally - Your private keys are not shared with the server. You do not have to trust the server with your money.
• Firewall friendly - The client does not need to open a port, it simply polls the server for updates.
• Free software - Gnu GPL v3. Anyone can audit the code.
• Written in Python - The code is short, and easy to review.
• User Friendly - Support for Groestlcoin URIs, signed URIs and Groestlcoin aliases
• No Lock-In - You can export your private keys and use them in other groestlcoin clients.
• No Downtimes - Electrum-GRS servers are decentralized and redundant. Your wallet is never down.
• Proof Checking - Electrum-GRS Wallet verifies all the transactions in your history using SPV.
• Cold Storage - Keep your private keys offline, and go online with a watching-only wallet. Sign transactions from a computer taht is always offline. Broadcast them from a machine that does not have your keys.
• Multisign - Split the permission to spend your coins between several wallets using parallel BIP32 derivations and P2SH addresses ("2 of 2", "2 of 3"). Compact serialization format for unsigned or partially signed transactions, that includes the BIP32 master public key and derivation needed to sign inputs. Serialized transactions can be sent to cosigners or to cold storage using QR codes

It is appreciated if feedback of the following is provided:
1. Can you receive coins with legacy addresses? (small amounts to avoid losing them)
2. Can you receive coins with bech32 addresses? (small amounts to avoid losing them)
3. Can you receive coins with legacy testnet addresses? (small amounts to avoid losing them)
4. Can you receive coins with bech32 testnet addresses? (small amounts to avoid losing them)
5. Can you send coins with legacy addresses? (small amounts to avoid losing them)?
6. Can you send coins with bech32 addresses? (small amounts to avoid losing them)?
7. Can you send coins with legacy testnet addresses? (small amounts to avoid losing them)?
8. Can you send coins with bech32 testnet addresses? (small amounts to avoid losing them)?
9. Does it automatically detect servers under Tools - Network?
10. Are you able to sweep private keys?
11. Are you able to sign/verify messages?
12. Are you able to encrypt/decrypt messages?

This application is licensed under the GPL version 3. There is no warranty and no party shall be made liable to you for damages. If you lose coins due to this app, no compensation will be given. Use this app solely at your own risk.

The application may have unfound bugs and problems. To leave feedback: 
1. PM me
2. Email: [email protected]
3. Post reports of erros in this topic.

Important:
Store your secret phrase somewhere safe!
The multi-signature and non native segwit addresses starts with a "3" and not with a "F".

Electrum-GRS is available in the Google play store:
https://play.google.com/store/apps/details?id=org.groestlcoin.electrumgrs

Source code:
GitHub Source server: https://github.com/Groestlcoin/electrumx-grs
Github Source server installer: https://github.com/Groestlcoin/electrumx-grs-installer
Github Source client: https://github.com/Groestlcoin/electrum-grs
Github Source Icons: https://github.com/Groestlcoin/electrum-grs-icons
Github Source locale: https://github.com/Groestlcoin/electrum-grs-locale

---

---

If you are an ordinary user of Groestlcoin and simply want the convenience of a web wallet with the security of a real application and support for multi-signature, then Elecrum-GRS is the right choice for you.

Changelog Electrum-GRS 3.1.2:
• Capital gains: For each outgoing transaction, the difference between the acquisition and liquidation prices of outgoing coins is displayed in the wallet history. By default, historical exchange rates are used to compute acquisition and liquidation prices. These values can also be entered manually, in order to match the actual price realized by the user. The order of liquidation of coins is the natural order defined by the blockchain; this results in capital gain values that are invariant to changes in the set of addresses that are in the wallet. Any other ordering strategy (such as FIFO, LIFO) would result in capital gain values that depend on the presence of other addresses in the wallet.
• Local transactions: Transactions can be saved in the wallet without being broadcast. The inputs of local transactions are considered as spent, and their change outputs can be re-used in subsequent transactions. This can be combined with cold storage, in order to create several transactions before broadcasting them. Outgoing
transactions that have been removed from the memory pool are also saved in the wallet, and can be broadcast again.
• Checkpoints: The initial download of a headers file was replaced with hardcoded checkpoints. The wallet uses one checkpoint per retargeting period. The headers for a retargeting period are downloaded only if transactions need to be verified in this period.
• The 'privacy' and 'priority' coin selection policies have been merged into one. Previously, the 'privacy' policy has been unusable because it was was not prioritizing confirmed coins. The new policy is similar to 'privacy', except that it de-prioritizes addresses that have unconfirmed coins.
• The 'Send' tab of the Qt GUI displays how transaction fees are computed from transaction size.
• The wallet history can be filtered by time interval.
• Replace-by-fee is enabled by default. Note that this might cause some issues with wallets that do not display RBF transactions until they are confirmed.
• Watching-only wallets and hardware wallets can be encrypted.
• The SSL checkbox option was removed from the GUI.
• The Trezor One and T hardware wallet is now supported.
• The Ledger hardware wallet is now supported.
• BIP84: native segwit p2wpkh scripts for bip39 seeds and hardware wallets can now be created when specifying a BIP84 derivation path. This is usable with Trezor and Ledger.
• Windows: the binaries now include ZBar, and QR code scanning should work.
• The Wallet Import Format (WIF) for private keys that was extended in 3.0 is changed. Keys in the previous format can be imported, compatibility is maintained. Newly exported keys will be serialized as "script_type:original_wif_format_key".
• BIP32 master keys for testnet once again have different version bytes than on mainnet. For the mainnet prefixes {x,y,Y,z,Z}|{pub,prv}, the corresponding testnet prefixes are {t,u,U,v,V}|{pub,prv}. Note that due to this change, testnet wallet files created with previous versions of Electrum must be considered broken, and they need to be recreated from seed words.
• A new version of the Electrum-GRS protocol is required by the client (version 1.2). Servers using older versions of the protocol will not be displayed in the GUI.

Changelog Electrum-GRS 3.0.6:
• Moved away from Linux binary file. Users must compile from source now.
• Moved away from electrum-grs-server codebase to electrumx-grs 1.2
• The source code is relicensed under the MIT Licence
• Separation between plugins and GUIs
• The command line uses jsonrpc to communicate with the daemon
• New command: 'notify

'
• Alternative coin selection policy, designed to help preserve user privacy. Enable it by setting the Coin Selection preference to Privacy.
• The install wizard has been rewritten and improved
• Support minikeys for private key import and sweeping
• QT: add colors to labels
• The wallet file format has been upgraded. This upgrade is not backward compatible, which means that a wallet upgraded to the 2.7 format will not be readable by earlier versions of Electrum-GRS. Multiple accounts inside the same wallet are not supported in the new format; the Qt GUI will propose to split any wallet that has several accounts. Make sure that you have saved your seed phrase before you upgrade Electrum-GRS.
• This version introduces a separation between wallets types and keystores types. 'Wallet type' defines the type of Groestlcoin contract used in the wallet, while 'keystore type' refers to the method used to store private keys.
• Replace-By-Fee: RBF transactions are supported in Qt. A warning is displayed in the history for transactions that are replaceable, have unconfirmed parents, or that have very low fees.
• Qt GUI:
   - A fee slider is visible in the in send tab
   - The Address tab is hidden by default, can be shown with Ctrl-A
   - UTXOs are displayed in the Address tab
• Seed phrases can be extended with a user-chosen passphrase. The length of seed phrases is standardized to 12 words, using 132 bits of entropy. In the wizard, the type of the seed is displayed in the seed input dialog.
• Add number of confirmations to request status.
• In the GUI, refer to passphrase as 'seed extension'.
• Wizard: Hide seed options in a popup dialog.
• Separate sign and broadcast buttons in Qt tx dialog
• Allow spaces in private keys
• Add size to transaction details window
• Move plot plugin to main code
• Merge exchange_rate plugin with main code
• Faster synchronization and transaction creation
• Use fee slider for static fees
• Add fee slider to RBF dialog
• Simplify fee preferences.
• Add Testnet support
• Allow daemon to be launched in the foreground
• Qt: use separate tabs for addresses and UTXOs
• Qt: update fee slider with a network callback
• Enforce https on exchange rate APIs
• Use hardcoded list of exchanges
• Move 'Freeze' menu to Coins (utxo) tab
• Wallet file encryption using ECIES: A keypair is derived from the wallet password. Once the wallet is decrypted, only the public key is retained in memory, in order to save the encrypted file.
• The daemon requires wallets to be explicitly loaded before commands can use them. Wallets can be loaded using: 'electrum-grs daemon load_wallet [-w path]'. This command will require a password if the wallet is encrypted.
• Invoices and contacts are stored in the wallet file and are no longer shared between wallets. Previously created invoices and contacts files may be imported from the menu.
• Fees improvements:
    - Child Pays For Parent (CPFP) dialog in the GUI.
    - RBF is automatically proposed for low fee transactions.
• The GUI shows a blue icon when connected using a proxy.
• Show paid invoices in history tab
• Improve CPFP dialog
• Multiple Chain Validation: Electrum-GRS will download and validate block headers sent by servers that may follow different branches of a fork in the Groestlcoin blockchain. Instead of a linear sequence,block headers are organized in a tree structure. Branching points are located efficiently using binary search. The purpose of MCV is to detect and handle blockchain forks that are invisible to the classical SPV model.
• The desired branch of a blockchain fork can be selected using the network dialog. Branches are identified by the hash and height of the diverging block. Coin splitting is possible using RBF transaction
• MultiGroestl, Groestlwallet, Simple Groestlcoin support: If the user enters a BIP39 seed, the full derivation path is configurable in the install wizard.
• Option to send only confirmed coins
• Qt GUI:
    - Network dialog uses tabs and gets updated by network events.
    - The gui tabs use icons
• Daemon: The wallet password can be passed as parameter to the JSONRPC API.
• Validate contacts on import
• Command-line option for locktime
• Force headers download if headers file is corrupted
• Add websocket to windows builds
• The project was migrated to Python3 and Qt5. Python2 is no longer supported. If you cloned the source repository, you will need to run "python3 setup.py install" in order to install the new dependencies.
• Segwit support:
    - Native segwit scripts are supported using a new type of seed. The version number for segwit seeds is 0x100. The install wizard will not create segwit seeds by default; users must opt-in with the segwit option.
    - Native segwit scripts are represented using bech32 addresses, following BIP173. Please note that BIP173 is still in draft status, and that other wallets/websites may not support it. Thus, you should keep a non-segwit wallet in order to be able to receive groestlcoins during the transition period. If BIP173 ends up being rejected or substantially modified, your wallet may have to be restored from seed. This will not affect funds sent to bech32 addresses, and it will not affect the capacity of Electrum-GRS to spend these funds.
    - The BIP32 master keys of segwit wallets are serialized using new version numbers. The new version numbers encode the script type, and they result in the following prefixes:
         * xpub/xprv : p2pkh or p2sh
         * ypub/yprv : p2wpkh-in-p2sh
         * Ypub/Yprv : p2wsh-in-p2sh
         * zpub/zprv : p2wpkh
         * Zpub/Zprv : p2wsh
These values are identical for mainnet and testnet; tpub/tprv prefixes are no longer used in testnet wallets.
    - The Wallet Import Format (WIF) is similarly extended for segwit scripts. After a base58-encoded key is decoded to binary, its first byte encodes the script type:
         * 128 + 0: p2pkh
         * 128 + 1: p2wpkh
         * 128 + 2: p2wpkh-in-p2sh
         * 128 + 5: p2sh
         * 128 + 6: p2wsh
         * 128 + 7: p2wsh-in-p2sh
The distinction between p2sh and p2pkh in private key means that it is not possible to import a p2sh private key and associate it to a p2pkh address.
• A new version of the Electrum-GRS protocol is required by the client (version 1.1). Servers using older versions of the protocol will not be displayed in the GUI.
• By default, transactions are time-locked to the height of the current block. Other values of locktime may be passed using the command line.
• Sweeping minikeys: search for both compressed and uncompressed pubkeys
• Qt GUI: sweeping now uses the Send tab, allowing fees to be set
• Windows: if using the installer binary, there is now a separate shortcut for "Electrum-GRS Testnet"
• OS notifications for incoming transactions
• Better transaction size estimation:
    - fees for segwit txns were somewhat underestimated
    - some multisig txns were underestimated
    - handle uncompressed pubkeys
• The JSONRPC interface is password protected
• JSONRPC commands are disabled if the GUI is running, except 'ping', which is used to determine if a GUI is already running

Changelog Electrum-GRS 2.5.4:
• Linux binary file included
• Fixed sweeping private keys
• Fixed signing/verifying messages
• Electrum-GRS servers updated to 2.5.4
• Installwizard: do not allow direct copy-paste of the seed
• The QT GUI supports multiple windows in the same process. When a new Electrum-GRS instance is started, it checks for an already running Electrum-GRS process, and connects to it.
• The network layer uses select(), so all server communication is handled by a single thread. Moreover, the synchronizer, verifier, and exchange rate plugin now run as separate jobs within the networking thread instead of as their own threads.
• Plugins are revamped
• Simplified Chinese wordlist
• Dynamic Fees: using estimatefee value returned by server
• Various GUI improvements
• Arbitrary m-of-n multisig wallets are supported (n<=15).
• Transaction fees set manually in the GUI are retained, including when the user uses the '!' shortcut.
• New 'email' plugin, that enables sending and receiving payment requests by email.
• improvements to the transaction dialog:
    - request password after showing transaction
    - show change addresses in yellow color
• Improved logic for the network layer.
• More efficient coin selection. Spend oldest coins first, and minimize the number of transaction inputs.
• The command line accepts the '!' syntax to send the maximum amount available. It can be combined with the '--from' option. Example: 'payto ! --from '
• The command line also accepts a '?' shortcut for private keys arguments, that triggers a prompt.
• Payment requests can be signed with a SSL certificate, and published as bip70 files in a public web directory.
• Show amounts (thousands separators and decimal point) according to locale in GUI
• Show unmatured coins in balance
• Faster startup, thanks to the following optimizations:
   1. Transaction input/outputs are cached in the wallet file
   2. Fast X509 certificate parser, not using pyasn1 anymore.
• The 'Invoices' and 'Send' tabs have been merged.
• Contacts are stored in a separate file, shared between wallets.
• A Search Box is available in the GUI (Ctrl-S)
• Own addresses are shown in green in the Transaction dialog.
• Address History dialog.
• The password dialog will ask for password again if the user enters a wrong password
• The Master Public Key dialog displays which keys belong to the wallet, and which are cosigners
• The transaction dialog will ask to save unsaved transaction received from cosigner pool, when user clicks on 'Close'
• The multisig restore dialog accepts xprv keys.

Features
• Encrypted wallet - the file that contains your groestlcoins is protected with a password. You are protected from thieves.
• Deterministic key generation - If you lose your wallet, you can recover it from its seed. You are protected from your own mistakes.
• Instant on - the client does not download the blockchain, it requests that information from a server. No delays, always up-to-date.
• Freedom and Privacy - The server does not store user accounts. You are not tied to a particular server, and the server does not need to know you.
• No scripts - Electrum-GRS does not download any script. A compromised server cannot send you arbitrary code and steal your groestlcoins.
• No single point of failure - The server code is open source, anyone can run a server.
• Transactions are signed locally - Your private keys are not shared with the server. You do not have to trust the server with your money.
• Firewall friendly - The client does not need to open a port, it simply polls the server for updates.
• Free software - Gnu GPL v3. Anyone can audit the code.
• Written in Python - The code is short, and easy to review.
• User Friendly - Support for Groestlcoin URIs, signed URIs and Groestlcoin aliases
• No Lock-In - You can export your private keys and use them in other groestlcoin clients.
• No Downtimes - Electrum-GRS servers are decentralized and redundant. Your wallet is never down.
• Proof Checking - Electrum-GRS Wallet verifies all the transactions in your history using SPV.
• Cold Storage - Keep your private keys offline, and go online with a watching-only wallet. Sign transactions from a computer taht is always offline. Broadcast them from a machine that does not have your keys.
• Multisign - Split the permission to spend your coins between several wallets using parallel BIP32 derivations and P2SH addresses ("2 of 2", "2 of 3"). Compact serialization format for unsigned or partially signed transactions, that includes the BIP32 master public key and derivation needed to sign inputs. Serialized transactions can be sent to cosigners or to cold storage using QR codes
• Cosigner Pool plugin - encrypted communication channel for multisign wallets, to send and receive partially signed transactions.
• Get noticed - Run a public Electrum-GRS server, publish your message and reach thousands of Groestlcoin users

It is appreciated if feedback of the following is provided:
1. Can you receive coins with legacy addresses? (small amounts to avoid losing them)
2. Can you receive coins with bech32 addresses? (small amounts to avoid losing them)
3. Can you receive coins with legacy testnet addresses? (small amounts to avoid losing them)
4. Can you receive coins with bech32 testnet addresses? (small amounts to avoid losing them)
5. Can you send coins with legacy addresses? (small amounts to avoid losing them)?
6. Can you send coins with bech32 addresses? (small amounts to avoid losing them)?
7. Can you send coins with legacy testnet addresses? (small amounts to avoid losing them)?
8. Can you send coins with bech32 testnet addresses? (small amounts to avoid losing them)?
9. Does the cosigner pool work when using a multi-signature wallet?
10. Does the virtual keyboard work when it asks to enter your wallet password?
11. Does it automatically detect servers under Tools - Network?
12. Are you able to sweep private keys?
13. Are you able to sign/verify messages?
14. Are you able to encrypt/decrypt messages?

This application is licensed under the GPL version 3. There is no warranty and no party shall be made liable to you for damages. If you lose coins due to this app, no compensation will be given. Use this app solely at your own risk.

The application may have unfound bugs and problems. To leave feedback: 
1. PM me
2. Email: [email protected]
3. Post reports of erros in this topic.

Important:
Store your secret phrase somewhere safe!
The multi-signature and non native segwit addresses starts with a "3" and not with a "F".
Electrum-GRS creates an encrypted filename default_wallet instead of wallet.dat (like in Groestlcoin Core)
• Location Windows: Navigate to C:\Users\USER NAME\AppData\Roaming\Electrum-grs\wallets (or open windows explorer and enter %appdata%\Electrum-grs\wallets) and back up your default_wallet file by making a copy of it and moving it to a secure location.
• Location Mac: Navigate to ~/Library/Application Support/Electrum-grs/wallets and back up your default_wallet file by making a copy of it and moving it to a secure location.

You can download it using the links below and be up and running with Groestlcoin in 5 minutes.

Download the OSX wallet here: https://github.com/Groestlcoin/electrum-grs/releases/download/v3.1.2/electrum-grs-v3.1.2.dmg
Note: The QR code scanner is not supported in OSX binary

Download Windows installer here: https://github.com/Groestlcoin/electrum-grs/releases/download/v3.1.2/electrum-grs-v3.1.2-setup.exe
Download Windows standalone wallet here: https://github.com/Groestlcoin/electrum-grs/releases/download/v3.1.2/electrum-grs-v3.1.2.exe
Download Windows portable version here: https://github.com/Groestlcoin/electrum-grs/releases/download/v3.1.2/electrum-grs-v3.1.2-portable.exe

Linux wallet instructions:
sudo apt-get install python3-setuptools python3-pyqt5 python3-pip python3-dev libssl-dev
sudo pip3 install groestlcoin_hash
sudo pip3 install https://github.com/Groestlcoin/electrum-grs/releases/download/v3.1.2/Electrum-grs-3.1.2.tar.gz
electrum-grs

Source code:
GitHub Source server: https://github.com/Groestlcoin/electrumx-grs
Github Source server installer: https://github.com/Groestlcoin/electrumx-grs-installer
Github Source client: https://github.com/Groestlcoin/electrum-grs
Github Source Icons: https://github.com/Groestlcoin/electrum-grs-icons
Github Source locale: https://github.com/Groestlcoin/electrum-grs-locale

---

---

v2.16.0 is now the official release version of Groestlcoin Core. On top of the new features, various bugfixes, updated translations and performance improvements. It is recommended to upgrade to this version as soon as possible.


All pools, services, exchanges are already upgraded.
We would like to thank everybody for a smooth and fast upgrade (in no particular order):
supernova
sistemkoin
crypto wolf
coinexchange
xchange.me
neraex
stocks.exchange
bittylicious
chainrift
barterdex
binance
upbit
bittrex
coinrail
easyrabbit
coinpayments
cryptopia
livecoin
flyp.me
cointopay
trade satoshi
buybitcoin.org.in
coinswitch (doesnt use wallet)
coinmine.pl
coinomi
miningpoolhub
coinwarz (windows)
litebit (windows)
fubt.top (windows)
blazepool
reddit/irc bot
ooobtc
dwarfpool
coindelta
godex
instaswap
chainrift
koinok


What's new in version v2.16.0?
This is a major release of Groestlcoin Core with many protocol level improvements and code optimizations, featuring the technical equivalent of Bitcoin v0.16.0 but with Groestlcoin specific patches. On a general level, most of what is new is the ability to send/receive to/from bech32 addresses.

Changelog:
• Default transaction version bumped from 1 to 2.
• Qt version upgraded.
• Updated splash screen for mainnet and testnet.
• Icons Groestlized.
• Translations updated.
• Minimal fee lowered.
• Static builds for all platforms will be compiled from this release on.
• Validation speed and network propagation performance have been greatly improved, leading to much shorter sync and initial block download times.
• The script signature cache has been reimplemented as a "cuckoo cache", allowing for more signatures to be cached and faster lookups.
• Assumed-valid blocks have been introduced which allows script validation to be skipped for ancestors of known-good blocks, without changing the security model.
• In some cases, compact blocks are now relayed before being fully validated as per BIP152.
• P2P networking has been refactored with a focus on concurrency and throughput. Network operations are no longer bottlenecked by validation. As a result, block fetching is several times faster than previous releases in many cases.
• The UTXO cache now claims unused mempool memory. This speeds up initial block download as UTXO lookups are a major bottleneck there, and there is no use for the mempool at that stage.
• Groestlcoin Core has supported automatically pruning the blockchain since 2.11.0 Pruning the blockchain allows for significant storage space savings as the vast majority of the downloaded data can be discarded after processing so very little of it remains on the disk. Manual block pruning can now be enabled by setting `-prune=1`. Once that is set, the RPC command `pruneblockchain` can be used to prune the blockchain up to the specified height or timestamp.
• The `getinfo` RPC command has been deprecated. Each field in the RPC call has been moved to another command's output with that command also givingadditional information that `getinfo` did not provide. The following tableshows where each field has been moved to:
   |`getinfo` field   | Moved to                                  |
   |------------------|-------------------------------------------|
   `"version"`      | `getnetworkinfo()["version"]`
   `"protocolversion"`| `getnetworkinfo()["protocolversion"]`
   `"walletversion"`  | `getwalletinfo()["walletversion"]`
   `"balance"`      | `getwalletinfo()["balance"]`
   `"blocks"`      | `getblockchaininfo()["blocks"]`
   `"timeoffset"`      | `getnetworkinfo()["timeoffset"]`
   `"connections"`      | `getnetworkinfo()["connections"]`
   `"proxy"`      | `getnetworkinfo()["networks"][0]["proxy"]`
   `"difficulty"`      | `getblockchaininfo()["difficulty"]`
   `"testnet"`      | `getblockchaininfo()["chain"] == "test"`
   `"keypoololdest"`  | `getwalletinfo()["keypoololdest"]`
   `"keypoolsize"`      | `getwalletinfo()["keypoolsize"]`
   `"unlocked_until"` | `getwalletinfo()["unlocked_until"]`
   `"paytxfee"`      | `getwalletinfo()["paytxfee"]`
   `"relayfee"`      | `getnetworkinfo()["relayfee"]`
   `"errors"`      | `getnetworkinfo()["warnings"]`
• Previously the ZeroMQ notification system was unavailable on Windows due to various issues with ZMQ. These have been fixed upstream and
now ZMQ can be used on Windows.
• The ability to nest RPC commands has been added to the debug console. This allows users to have the output of a command become the input to another command without running the commands separately. The nested RPC commands use bracket syntax (i.e. `getwalletinfo()`) and can be nested (i.e. `getblock(getblockhash(1))`). Simple queries can be done with square brackets where object values are accessed with either an array index or a non-quoted string (i.e. `listunspent()[0][txid]`). Both
commas and spaces can be used to separate parameters in both the bracket syntax and normal RPC command syntax.
• A RPC command and GUI toggle have been added to enable or disable all p2p network activity. The network status icon in the bottom right hand corner is now the GUI toggle. Clicking the icon will either enable or disable all p2p network activity. If network activity is disabled, the icon will  be grayed out with an X on top of it.
• Additionally the `setnetworkactive` RPC command has been added which does the same thing as the GUI icon. The command takes one boolean parameter, `true` enables networking and `false` disables it.
• When Groestlcoin Core is out-of-sync on startup, a semi-transparent information layer will be shown over top of the normal display. This layer contains details about the current sync progress and estimates the amount of time remaining to finish syncing. This layer can also be hidden and subsequently unhidden by clicking on the progress bar at the bottom of the window.
• Commands sent over the JSON-RPC interface and through the `groestlcoin-cli` binary can now use named arguments. This follows the [JSON-RPC specification](http://www.jsonrpc.org/specification) for passing parameters by-name with an object. `groestlcoin-cli` has been updated to support this by parsing `name=value` arguments when the `-named` option is given. Some examples:
  - src/groestlcoin-cli -named help command="help"
  - src/groestlcoin-cli -named getblockhash height=0
  - src/groestlcoin-cli -named getblock blockhash=0000000000000036ae5aabb18a2d345d19d60ba1927f071af2aa8eec7a27d41d
  - src/groestlcoin-cli -named sendtoaddress address="(snip)" amount="1.0" subtractfeefromamount=true
The order of arguments doesn't matter in this case. Named arguments are also useful to leave out arguments that should stay at their default value. The rarely-used arguments `comment` and `comment_to` to `sendtoaddress`, for example, can be left out. However, this is not yet implemented for many RPC calls, this is expected to land in a later release. The RPC server remains fully backwards compatible with positional arguments.
• The debug console maintains a history of previously entered commands that can be accessed by pressing the Up-arrow key so that users can easily reuse previously entered commands. Commands which have sensitive information such as passphrases and private keys will now have a `(...)` in place of the parameters when accessed through the history.
• After resetting the options by clicking the `Reset Options` button in the options dialog or with the `-resetguioptions` startup option, the user will be prompted to choose the data directory again. This is to ensure that custom data directories will be kept after the option reset which clears the custom data directory set via the choose datadir dialog.
• Multiple peers can now be selected in the list of peers in the debug window. This allows for users to ban or disconnect multiple peers simultaneously instead of banning them one at a time.
• An indicator has been added to the bottom right hand corner of the main window to indicate whether the wallet being used is a HD wallet. This icon will be grayed out with an X on top of it if the wallet is not a HD wallet.
• UTXO set query (`GET /rest/getutxos//-/-/.../-.`) responses were changed to return status code `HTTP_BAD_REQUEST` (400) instead of `HTTP_INTERNAL_SERVER_ERROR` (500) when requests contain invalid parameters.
• Since the changes in 2.13.3 to automatically limit the size of the mempool and improve the performance of block creation in mining code it has not been important for relay nodes or miners to set `-minrelaytxfee`. With this release the following concepts that were tied to this option have been separated out:
   - incremental relay fee used for calculating BIP 125 replacement and mempool limiting. (1000 gros/kB)
   - calculation of threshold for a dust output. (effectively 3 * 1000 gros/kB)
   - minimum fee rate of a package of transactions to be included in a block created by the mining code. If miners wish to set this minimum they can use the new `-     blockmintxfee` option.  (defaults to 1000 gros/kB)
The `-minrelaytxfee` option continues to exist but is recommended to be left unset.
• Since 2.13.3 fee estimation for a confirmation target of 1 block has been disabled. The fee slider will no longer be able to choose a target of 1 block. This is only a minor behavior change as there was often insufficient data for this target anyway. `estimatefee 1` will now always return -1 and `estimatesmartfee 1` will start searching at a target of 2.
• The default target for fee estimation is changed to 6 blocks in both the GUI (previously 25) and for RPC calls (previously 2).
• Peers manually added through the `-addnode` option or `addnode` RPC now have their own limit of eight connections which does not compete with other inbound or outbound connection usage and is not subject to the limitation imposed by the `-maxconnections` option.
• New connections to manually added peers are performed more quickly.
• A significant portion of the initial block download time is spent verifying scripts/signatures.  Although the verification must pass to ensure the security of the system, no other result from this verification is needed: If the node knew the history of a given block were valid it could skip checking scripts for its ancestors.
• A new configuration option 'assumevalid' is provided to express this knowledge to the software.  Unlike the 'checkpoints' in the past this setting does not force the use of a particular chain: chains that are consistent with it are processed quicker, but other chains are still accepted if they'd otherwise be chosen as best. Also unlike 'checkpoints' the user can configure which block history is assumed true, this means that even outdated software can sync more quickly if the setting is updated by the user.
• Because the validity of a chain history is a simple objective fact it is much easier to review this setting.  As a result the software ships with a default value adjusted to match the current chain shortly before release.  The use of this default value can be disabled by setting -assumevalid=0
• Before 2.16, `fundrawtransaction` was by default wallet stateless. In almost all cases `fundrawtransaction` does add a change-output to the outputs of the funded transaction. Before 2.16, the used keypool key was never marked as change-address key and directly returned to the keypool (leading to address reuse).  Before 2.16, calling `getnewaddress` directly after `fundrawtransaction` did generate the same address as the change-output address.
• Since 2.16, fundrawtransaction does reserve the change-output-key from the keypool by default (optional by setting  `reserveChangeKey`, default =`true`)
• Users should also consider using `getrawchangeaddress()` in conjunction with `fundrawtransaction`'s `changeAddress` option.
• Before 2.16, memory reserved for mempool (using the `-maxmempool` option) went unused during initial block download, or IBD. In 2.16, the UTXO DB cache (controlled with the `-dbcache` option) borrows memory from the mempool when there is extra memory available. This may result in an increase in memory usage during IBD for those previously relying on only the `-dbcache` option to limit memory during that time.
• In previous versions, getblocktemplate required segwit support from downstream clients/miners once the feature activated on the network. In this version, it now supports non-segwit clients even after activation, by removing all segwit transactions from the returned block template. This allows non-segwit miners to continue functioning correctly even after segwit has activated.
• Due to the limitations in previous versions, getblocktemplate also recommended non-segwit clients to not signal for the segwit version-bit. Since this is no longer an issue, getblocktemplate now always recommends signalling segwit for all miners. This is safe because ability to enforce the rule is the only required criteria for safe activation, not actually producing segwit-enabled blocks.
• Memory usage for the UTXO cache is being calculated more accurately, so that the configured limit (`-dbcache`) will be respected when memory usage peaks
during cache flushes.  The memory accounting in prior releases is estimated to only account for half the actual peak utilization.
• The default `-dbcache` has also been changed in this release to 450MiB.  Users who currently set `-dbcache` to a high value (e.g. to keep the UTXO more fully
cached in memory) should consider increasing this setting in order to achieve the same cache performance as prior releases.  Users on low-memory systems (such as systems with 1GB or less) should consider specifying a lower value for this parameter.
• Bundled miniupnpc was updated to 2.0.20170509. This fixes an integer signedness error (present in MiniUPnPc v1.4.20101221 through v2.0) that allows remote attackers
(within the LAN) to cause a denial of service or possibly have unspecified other impact. This only affects users that have explicitly enabled UPnP through the GUI
setting or through the `-upnp` option, as since the last UPnP vulnerability (in Groestlcoin Core 2.1.0.6) it has been disabled by default. If you use this option, it is recommended to upgrade to this version as soon as possible.
• The chainstate database (which is used for tracking UTXOs) has been changed from a per-transaction model to a per-output model . Advantages of this model are that it:
    - avoids the CPU overhead of deserializing and serializing the unused outputs;
    - has more predictable memory usage;
    - uses simpler code;
    - is adaptable to various future cache flushing strategies.
As a result, validating the blockchain during Initial Block Download (IBD) and reindex is ~30-40% faster, uses 10-20% less memory, and flushes to disk far less frequently. The only downside is that the on-disk database is 15% larger. During the conversion from the previous format a few extra gigabytes may be used.
• Earlier versions experienced a spike in memory usage while flushing UTXO updates to disk. As a result, only half of the available memory was actually used as cache, and the other half was reserved to accommodate flushing. This is no longer the case, and the entirety of the available cache (see `-dbcache`) is now actually used as cache. This reduces the flushing frequency by a factor 2 or more.
• In previous versions, signature validation for transactions has been cached when the transaction is accepted to the mempool. Version 2.16 extends this to cache the entire script validity. This means that if a transaction in a block has already been accepted to the mempool, the scriptSig does not need to be re-evaluated. Empirical tests show that this results in new block validation being 40-50% faster.
• LevelDB has been upgraded to version 1.20. This version contains hardware acceleration for CRC on architectures supporting SSE 4.2. As a result, synchronization and block validation are now faster.
• Refill of the keypool no longer flushes the wallet between each key which resulted in a ~20x speedup in creating a new wallet. Part of this speedup was used to increase the default keypool to 1000 keys to make recovery more robust.
• Fee estimation has been significantly improved in version 2.16, with more accurate fee estimates used by the wallet and a wider range of options for advanced users of the `estimatesmartfee` and `estimaterawfee` RPCs.
• Internally, estimates are now tracked on 3 different time horizons. This allows for longer targets and means estimates adjust more quickly to changes in conditions.
• Estimates can now be conservative or economical. Conservative estimates use longer time horizons to produce an estimate which is less susceptible to rapid changes in fee conditions. Economical estimates use shorter time horizons and will be more affected by short-term changes in fee conditions. Economical estimates may be considerably lower during periods of low transaction activity (for example over weekends), but may result in transactions being unconfirmed if prevailing fees increase rapidly.
• By default, the wallet will use conservative fee estimates to increase the reliability of transactions being confirmed within the desired target. For transactions that are marked as replaceable, the wallet will use an economical estimate by default, since the fee can be 'bumped' if the fee conditions change rapidly.
• Estimates can now be made for confirmation targets up to 1008 blocks (one day).
• More data on historical fee rates is stored, leading to more precise fee estimates.
• Transactions which leave the mempool due to eviction or other non-confirmed reasons are now taken into account by the fee estimation logic, leading to more accurate fee estimates.
• The fee estimation logic will make sure enough data has been gathered to return a meaningful estimate. If there is insufficient data, a fallback default fee is used.
• The `estimatefee` RPC is now deprecated in favor of using only `estimatesmartfee` (which is the implementation used by the GUI)
• The `estimatesmartfee` RPC interface has been changed:
    - The `nblocks` argument has been renamed to `conf_target` (to be consistent with other RPC methods).
    - An `estimate_mode` argument has been added. This argument takes one of the following strings: `CONSERVATIVE`, `ECONOMICAL` or `UNSET` (which defaults to             `CONSERVATIVE`).
    - The RPC return object now contains an `errors` member, which returns errors encountered during processing.
    - If Groestlcoin Core has not been running for long enough and has not seen enough blocks or transactions to produce an accurate fee estimation, an error will be returned (previously a value of -1 was used to indicate an error, which could be confused for a feerate).
• A new `estimaterawfee` RPC is added to provide raw fee data. External clients can query and use this data in their own fee estimation logic.
• Groestkcoin Core now supports loading multiple, separate wallets. The wallets are completely separated, with individual balances, keys and received transactions. Multi-wallet is enabled by using more than one `-wallet` argument when starting Groestlcoin, either on the command line or in the Groestlcoin config file. In Groestlcoin-Qt, only the first wallet will be displayed and accessible for creating and signing transactions. GUI selectable multiple wallets will be supported in a future version. However, even in 2.16 other loaded wallets will remain synchronized to the node's current tip in the background. This can be useful if running a pruned node, since loading a wallet where the most recent sync is beyond the pruned height results in having to download and revalidate the whole blockchain. Continuing to synchronize all wallets in the background avoids this problem. Note that while multi-wallet is now fully supported, the RPC multi-wallet interface should be considered unstable for version 2.16.0, and there may backwards-incompatible changes in future versions.
• When running Groestlcoin Core with a single wallet, there are no changes to the RPC interface or `groestlcoin-cli`. All RPC calls and `groestlcoin-cli` commands continue to work as before.
• When running Groestlcoin Core with multi-wallet, all node-level RPC methods continue to work as before. HTTP RPC requests should be send to the normal `:` endpoint, and `groestlcoin-cli` commands should be run as before. A node-level RPC method is any method which does not require access to the wallet.
• When running Groestlcoin Core with multi-wallet, wallet-level RPC methods must specify the wallet for which they're intended in every request. HTTP RPC requests should be send to the `:/wallet/` endpoint, for example `127.0.0.1:1441/wallet/wallet1.dat`. `groestlcoin-cli` commands should be run with a `-rpcwallet` option, for example `groestlcoin-cli -rpcwallet=wallet1.dat getbalance`.
• A new node-level `listwallets` RPC method is added to display which wallets are currently loaded. The names returned by this method are the same as those used in the HTTP endpoint and for the `rpcwallet` argument.
• Groestlcoin Core has supported creating opt-in replace-by-fee (RBF) transactions since version 2.13.3. In version 2.16, creating an opt-in RBF transaction and replacing the unconfirmed transaction with a higher-fee transaction are both supported in the GUI.
• The concept of *free transactions* has been removed. High Coin Age Priority transactions would previously be allowed to be relayed even if they didn't attach a miner fee. This is no longer possible since there is no concept of Coin Age Priority. The `-limitfreerelay` and `-relaypriority` options which controlled relay of free transactions have therefore been removed.
• The `-sendfreetransactions` option has been removed, since almost all miners do not include transactions which do not attach a transaction fee.
• The `-blockprioritysize` option has been removed.
• The `estimatepriority` and `estimatesmartpriority` RPCs have been removed.
• The `getmempoolancestors`, `getmempooldescendants`, `getmempoolentry` and `getrawmempool` RPCs no longer return `startingpriority` and `currentpriority`.
• The `prioritisetransaction` RPC no longer takes a `priority_delta` argument, which is replaced by a `dummy` argument for backwards compatibility with clients using positional arguments. The RPC is still used to change the apparent fee-rate of the transaction by using the `fee_delta` argument.
• `-minrelaytxfee` can now be set to 0. If `minrelaytxfee` is set, then fees smaller than `minrelaytxfee` (per kB) are rejected from relaying, mining and transaction creation. This defaults to 10000 gro/kB.
• The `-printpriority` option has been updated to only output the fee rate and hash of transactions included in a block by the mining code.
• Version 2.16 introduced mempool persistence across restarts (the mempool is saved to a `mempool.dat` file in the data directory prior to shutdown and restores the mempool when the node is restarted). Version 2.16 also allows this feature to be switched on or off using the `-persistmempool` command-line optio. By default, the option is set to true, and the mempool is saved on shutdown and reloaded on startup. If set to false, the `mempool.dat` file will not be loaded on startup or saved on shutdown.
• A number of changes to the way Groestlcoin Core deals with peer connections and invalid blocks have been made, as a safety precaution against blockchain forks and misbehaving peers.
• Unrequested blocks with less work than the minimum-chain-work are now no longer processed even if they have more work than the tip (a potential issue during IBD where the tip may have low-work). This prevents peers wasting the resources of a node.
• Peers which provide a chain with less work than the minimum-chain-work during IBD will now be disconnected.
• For a given outbound peer, we now check whether their best known block has at least as much work as our tip. If it doesn't, and if we still haven't heard about a block with sufficient work after a 20 minute timeout, then we send a single getheaders message, and wait 2 more minutes. If after two minutes their best known block has insufficient work, we disconnect that peer. We protect 4 of our outbound peers from being disconnected by this logic to prevent excessive network topology changes as a result of this algorithm, while still ensuring that we have a reasonable number of nodes not known to be on bogus chains.
• Outbound (non-manual) peers that serve us block headers that are already known to be invalid (other than compact block announcements, because BIP 152 explicitly permits nodes to relay compact blocks before fully validating them) will now be disconnected.
• If the chain tip has not been advanced for over 30 minutes, we now assume the tip may be stale and will try to connect to an additional outbound peer. A periodic check ensures that if this extra peer connection is in use, we will disconnect the peer that least recently announced a new block.
• The set of all known invalid-themselves blocks (i.e. blocks which we attempted to connect but which were found to be invalid) are now tracked and used to check if new headers build on an invalid chain. This ensures that everything that descends from an invalid block is marked as such.
• Though blockmaxweight has been preferred for limiting the size of blocks returned by getblocktemplate since 2.13.3, blockmaxsize remained as an option for those who wished to limit their block size directly. Using this option resulted in a few UI issues as well as non-optimal fee selection and ever-so-slightly worse performance, and has thus now been deprecated. Further, the blockmaxsize option is now used only to calculate an implied blockmaxweight, instead of limiting block size directly. Any miners who wish to limit their blocks by size, instead of by weight, will have to do so manually by removing transactions from their block template directly.
• The GUI settings will now be written to `guisettings.ini.bak` in the data directory before wiping them when the `-resetguisettings` argument is used. This can be used to retroactively troubleshoot issues due to the GUI settings.
• A hidden debug argument `-minimumchainwork` has been added to allow a custom minimum work value to be used when validating a chain.
• Groestlcoin Core 2.16.0 introduces full support for segwit in the wallet and user interfaces. A new `-addresstype` argument has been added, which supports `legacy`, `p2sh-segwit` (default), and `bech32` addresses. It controls what kind of addresses are produced by `getnewaddress`, `getaccountaddress`, and `createmultisigaddress`. A `-changetype` argument has also been added, with the same options, and by default equal to `-addresstype`, to control which kind of change is used.
• A new `address_type` parameter has been added to the `getnewaddress` and `addmultisigaddress` RPCs to specify which type of address to generate.
• A `change_type` argument has been added to the `fundrawtransaction` RPC to override the `-changetype` argument for specific transactions.
• All segwit addresses created through `getnewaddress` or `*multisig` RPCs explicitly get their redeemscripts added to the wallet file. This means that downgrading after creating a segwit address will work, as long as the wallet file is up to date.
• All segwit keys in the wallet get an implicit redeemscript added, without it being written to the file. This means recovery of an old backup will work, as long as you use new software.
• All keypool keys that are seen used in transactions explicitly get their redeemscripts added to the wallet files. This means that downgrading after recovering from a backup that includes a segwit address will work
• Note that some RPCs do not yet support segwit addresses. Notably, `signmessage`/`verifymessage` doesn't support segwit addresses, nor does `importmulti` at this time. Support for segwit in those RPCs will continue to be added in future versions.
• P2WPKH change outputs are now used by default if any destination in the transaction is a P2WPKH or P2WSH output. This is done to ensure the change output is as indistinguishable from the other outputs as possible in either case.
• Full support for native segwit addresses (BIP173 / Bech32) has now been added. This includes the ability to send to BIP173 addresses (including non-v0 ones), and generating these addresses.
• A checkbox has been added to the GUI to select whether a Bech32 address or P2SH-wrapped address should be generated when using segwit addresses. When launched with `-addresstype=bech32` it is checked by default. When launched with `-addresstype=legacy` it is unchecked and disabled.
• Due to a backward-incompatible change in the wallet database, wallets created with version 2.16.0 will be rejected by previous versions. Also, version 2.16.0
will only create hierarchical deterministic (HD) wallets. Note that this only applies to new wallets; wallets made with previous versions will not be upgraded to be HD.
• The send screen now uses RBF by default, regardless of `-walletrbf`. There is a checkbox to mark the transaction as final.
• The RPC default remains unchanged: to use RBF, launch with `-walletrbf=1` or use the `replaceable` argument for individual transactions.
• Groestlcoin Core now has more flexibility in where the wallets directory can be located. Previously wallet database files were stored at the top level of the groestlcoin data directory. The behavior is now:
  - For new installations (where the data directory doesn't already exist), wallets will now be stored in a new `wallets/` subdirectory inside the data directory by     default.
  - For existing nodes (where the data directory already exists), wallets will be stored in the data directory root by default. If a `wallets/` subdirectory already        exists in the data directory root, then wallets will be stored in the `wallets/` subdirectory by default.
  - The location of the wallets directory can be overridden by specifying a `-walletdir=` option where `` can be an absolute path to a directory or     directory symlink.
  Care should be taken when choosing the wallets directory location, as if it becomes unavailable during operation, funds may be lost.
• The minimum version of the GCC compiler required to compile Groestlcoin Core is now 4.8. No effort will be made to support older versions of GCC. The minimum version for the Clang compiler is still 3.3. Other minimum dependency versions can be found in `doc/dependencies.md` in the repository.
• Pruned nodes can now signal BIP159's NODE_NETWORK_LIMITED using service bits, in preparation for full BIP159 support in later versions. This would allow pruned nodes to serve the most recent blocks. However, the current change does not yet include support for connecting to these pruned peers.
• The SHA256 hashing optimizations for architectures supporting SSE4, which lead to ~50% speedups in SHA256 on supported hardware (~5% faster synchronization and block validation), have now been enabled by default. In previous versions they were enabled using the `--enable-experimental-asm` flag when building, but are now the default and no longer deemed experimental.
• Uses of "µGRS" in the GUI now also show the more colloquial term "groestls".
• The option to reuse a previous address has now been removed. This was justified by the need to "resend" an invoice, but now that we have the request history, that need should be gone.
• Support for searching by TXID has been added, rather than just address and label.
• A "Use available balance" option has been added to the send coins dialog, to add the remaining available wallet balance to a transaction output.
• A toggle for unblinding the password fields on the password dialog has been added.
• Safe mode is now disabled by default and must be manually enabled (with `-disablesafemode=0`) if you wish to use it. Safe mode is a feature that disables a subset of RPC calls - mostly related to the wallet and sending - automatically in case certain problem conditions with the network are detected. However, developers have come to regard these checks as not reliable enough to act on automatically. Even with safe mode disabled, they will still cause warnings in the `warnings` field of the `getneworkinfo` RPC and launch the `-alertnotify` command.
• The `share/rpcuser/rpcuser.py` script was renamed to `share/rpcauth/rpcauth.py`. This script can be used to create `rpcauth` credentials for a JSON-RPC user.
• A new field `iswitness` is True for P2WPKH and P2WSH addresses ("grs1..." addresses), but not for P2SH-wrapped segwit addresses.
• The existing field `isscript` will now also report True for P2WSH addresses.
• A new field `embedded` is present for all script addresses where the script is known and matches something that can be interpreted as a known address. This is particularly true for P2SH-P2WPKH and P2SH-P2WSH addresses. The value for `embedded` includes much of the information `validateaddress` would report if invoked directly on the embedded address.
• For multisig scripts a new `pubkeys` field was added that reports the full public keys involved in the script (if known). This is a replacement for the existing `addresses` field (which reports the same information but encoded as P2PKH addresses), represented in a more useful and less confusing way. The `addresses` field remains present for non-segwit addresses for backward compatibility.
• For all single-key addresses with known key (even when wrapped in P2SH or P2WSH), the `pubkey` field will be present. In particular, this means that invoking `validateaddress` on the output of `getnewaddress` will always report the `pubkey`, even when the address type is P2SH-P2WPKH.
• `importprunedfunds` only accepts two required arguments. Some versions accept an optional third arg, which was always ignored. Make sure to never pass more than two arguments.
• The first boolean argument to `getaddednodeinfo` has been removed. This is an incompatible change.
• RPC command `getmininginfo` loses the "testnet" field in favor of the more generic "chain" (which has been present for years).
• A new RPC command `preciousblock` has been added which marks a block as precious. A precious block will be treated as if it were received earlier than a competing block.
• A new RPC command `importmulti` has been added which receives an array of  JSON objects representing the intention of importing a public key, a private key, an address and script/p2sh.
• Use of `getrawtransaction` for retrieving confirmed transactions with unspent outputs has been deprecated. For now this will still work, but in the future it may change to only be able to retrieve information about transactions in the mempool or if `txindex` is enabled.
• A new RPC command `getmemoryinfo` has been added which will return information about the memory usage of groestlcoin Core. This was added in conjunction with optimizations to memory management.
• A new RPC command `bumpfee` has been added which allows replacing an unconfirmed wallet transaction that signaled RBF with a new transaction that pays a higher fee, and should be more likely to get confirmed quickly.
• The "currentblocksize" value in getmininginfo has been removed.
• `dumpwallet` no longer allows overwriting files. This is a security measure as well as prevents dangerous user mistakes.
• `backupwallet` will now fail when attempting to backup to source file, rather than destroying the wallet.
• `listsinceblock` will now throw an error if an unknown `blockhash` argument value is passed, instead of returning a list of all wallet transactions since the genesis block. The behaviour is unchanged when an empty string is provided.
• A new RPC `rescanblockchain` has been added to manually invoke a blockchain rescan. The RPC supports start and end-height arguments for the rescan, and can be used in a multiwallet environment to rescan the blockchain at runtime.
• A new `savemempool` RPC has been added which allows the current mempool to be saved to disk at any time to avoid it being lost due to crashes / power loss.
• The first positional argument of `createrawtransaction` was renamed from `transactions` to `inputs`.
• The argument of `disconnectnode` was renamed from `node` to `address`.
• `abortrescan` stops current wallet rescan, e.g. when triggered by an `importprivkey` call.
• `combinerawtransaction` accepts a JSON array of raw transactions and combines them into a single raw transaction.
• `estimaterawfee` returns raw fee data so that customized logic can be implemented to analyze the data and calculate estimates. See for full details on changes to the fee estimation logic and interface.
• `getchaintxstats` returns statistics about the total number and rate of transactions in the chain.
• `listwallets` lists wallets which are currently loaded.
• `uptime` returns the total runtime of the `groestlcoind` server since its last start.
• When using Groestlcoin Core in multi-wallet mode, RPC requests for wallet methods must specify the wallet that they're intended for.
• The new database model no longer stores information about transaction versions of unspent outputs. This means that:
  - The `gettxout` RPC no longer has a `version` field in the response.
  - The `gettxoutsetinfo` RPC reports `hash_serialized_2` instead of `hash_serialized`, which does not commit to the transaction versions of unspent outputs, but does
    commit to the height and coinbase information.
  - The `getutxos` REST path no longer reports the `txvers` field in JSON format, and always reports 0 for transaction versions in the binary format
• The `estimatefee` RPC is deprecated. Clients should switch to using the `estimatesmartfee` RPC, which returns better fee estimates. See for full details on changes to the fee estimation logic and interface.
• The `gettxoutsetinfo` response now contains `disk_size` and `bogosize` instead of `bytes_serialized`. The first is a more accurate estimate of actual disk usage, but is not deterministic. The second is unrelated to disk usage, but is a database-independent metric of UTXO set size: it counts every UTXO entry as 50 + the length of its scriptPubKey.
• `signrawtransaction` can no longer be used to combine multiple transactions into a single transaction. Instead, use the new `combinerawtransaction` RPC.
• `fundrawtransaction` no longer accepts a `reserveChangeKey` option. This option used to allow RPC users to fund a raw transaction using an key from the keypool for the change address without removing it from the available keys in the keypool. The key could then be re-used for a `getnewaddress` call, which could potentially result in confusing or dangerous behaviour.
• `estimatepriority` and `estimatesmartpriority` have been removed.
• The `listunspent` RPC now takes a `query_options` argument, which is a JSON object containing one or more of the following members:
  - `minimumAmount` - a number specifying the minimum value of each UTXO
  - `maximumAmount` - a number specifying the maximum value of each UTXO
  - `maximumCount` - a number specifying the minimum number of UTXOs
  - `minimumSumAmount` - a number specifying the minimum sum value of all UTXOs
• The `getmempoolancestors`, `getmempooldescendants`, `getmempoolentry` and `getrawmempool` RPCs no longer return `startingpriority` and `currentpriority`.
• The `dumpwallet` RPC now returns the full absolute path to the dumped wallet. It used to return no value, even if successful.
• In the `getpeerinfo` RPC, the return object for each peer now returns an `addrbind` member, which contains the ip address and port of the connection to the peer. This is in addition to the `addrlocal` member which contains the ip address and port of the local node as reported by the peer.
• The `disconnectnode` RPC can now disconnect a node specified by node ID (as well as by IP address/port). To disconnect a node based on node ID, call the RPC with the new `nodeid` argument.
• The second argument in `prioritisetransaction` has been renamed from `priority_delta` to `dummy` since Groestlcoin Core no longer has a concept of coin age priority. The `dummy` argument has no functional effect, but is retained for positional argument compatibility.
• The `resendwallettransactions` RPC throws an error if the `-walletbroadcast` option is set to false.
• The second argument in the `submitblock` RPC argument has been renamed from `parameters` to `dummy`. This argument never had any effect, and the renaming is simply to communicate this fact to the user (Clients should, however, use positional arguments for `submitblock` in order to be compatible with BIP 22.)
• The `verbose` argument of `getblock` has been renamed to `verbosity` and now takes an integer from 0 to 2. Verbose level 0 is equivalent to `verbose=false`. Verbose level 1 is equivalent to `verbose=true`. Verbose level 2 will give the full transaction details of each transaction in the output as given by `getrawtransaction`. The old behavior of using the `verbose` named argument and a boolean value is still maintained for compatibility.
• `getblock` now returns RPC_MISC_ERROR if the block can't be found on disk (for example if the block has been pruned). Previously returned RPC_INTERNAL_ERROR.
• `pruneblockchain` now returns RPC_MISC_ERROR if the blocks cannot be pruned because the node is not in pruned mode. Previously returned RPC_METHOD_NOT_FOUND.
• `pruneblockchain` now returns RPC_INVALID_PARAMETER if the blocks cannot be pruned because the supplied timestamp is too late. Previously returned RPC_INTERNAL_ERROR.
• `pruneblockchain` now returns RPC_MISC_ERROR if the blocks cannot be pruned because the blockchain is too short. Previously returned RPC_INTERNAL_ERROR.
• `setban` now returns RPC_CLIENT_INVALID_IP_OR_SUBNET if the supplied IP address or subnet is invalid. Previously returned RPC_CLIENT_NODE_ALREADY_ADDED.
• `setban` now returns RPC_CLIENT_INVALID_IP_OR_SUBNET if the user tries to unban a node that has not previously been banned. Previously returned RPC_MISC_ERROR.
• `removeprunedfunds` now returns RPC_WALLET_ERROR if `groestlcoind` is unable to remove the transaction. Previously returned RPC_INTERNAL_ERROR.
• `removeprunedfunds` now returns RPC_INVALID_PARAMETER if the transaction does not exist in the wallet. Previously returned RPC_INTERNAL_ERROR.
• `fundrawtransaction` now returns RPC_INVALID_ADDRESS_OR_KEY if an invalid change address is provided. Previously returned RPC_INVALID_PARAMETER.
• `fundrawtransaction` now returns RPC_WALLET_ERROR if `groestlcoind` is unable to create the transaction. The error message provides further details. Previously returned RPC_INTERNAL_ERROR.
• `bumpfee` now returns RPC_INVALID_PARAMETER if the provided transaction has descendants in the wallet. Previously returned RPC_MISC_ERROR.
• `bumpfee` now returns RPC_INVALID_PARAMETER if the provided transaction has descendants in the mempool. Previously returned RPC_MISC_ERROR.
• `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction has has been mined or conflicts with a mined transaction. Previously returned RPC_INVALID_ADDRESS_OR_KEY.
• `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction is not BIP 125 replaceable. Previously returned RPC_INVALID_ADDRESS_OR_KEY.
• `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction has already been bumped by a different transaction. Previously returned RPC_INVALID_REQUEST.
• `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction contains inputs which don't belong to this wallet. Previously returned RPC_INVALID_ADDRESS_OR_KEY.
• `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction has multiple change outputs. Previously returned RPC_MISC_ERROR.
• `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction has no change output. Previously returned RPC_MISC_ERROR.
• `bumpfee` now returns RPC_WALLET_ERROR if the fee is too high. Previously returned RPC_MISC_ERROR.
• `bumpfee` now returns RPC_WALLET_ERROR if the fee is too low. Previously returned RPC_MISC_ERROR.
• `bumpfee` now returns RPC_WALLET_ERROR if the change output is too small to bump the fee. Previously returned RPC_MISC_ERROR.
• The deprecated RPC `getinfo` was removed. It is recommended that the more specific RPCs are used: `getblockchaininfo` `getnetworkinfo` `getwalletinfo` `getmininginfo`
• The wallet RPC `getreceivedbyaddress` will return an error if called with an address not in the wallet.
• The wallet RPC `addwitnessaddress` was deprecated and will be removed in future version, set the `address_type` argument of `getnewaddress`, or option `-addresstype=[bech32|p2sh-segwit]` instead.
• `dumpwallet` now includes hex-encoded scripts from the wallet in the dumpfile, and `importwallet` now imports these scripts, but corresponding addresses may not be added correctly or a manual rescan may be required to find relevant transactions.
• The RPC `getblockchaininfo` now includes an `errors` field.
• A new `blockhash` parameter has been added to the `getrawtransaction` RPC which allows for a raw transaction to be fetched from a specific block if known, even without `-txindex` enabled.
• The `decoderawtransaction` and `fundrawtransaction` RPCs now have optional `iswitness` parameters to override the heuristic witness checks if necessary.
• The `walletpassphrase` timeout is now clamped to 2^30 seconds.
• Using addresses with the `createmultisig` RPC is now deprecated, and will be removed in a later version. Public keys should be used instead.
• Blockchain rescans now no longer lock the wallet for the entire rescan process, so other RPCs can now be used at the same time (although results of balances / transactions may be incorrect or incomplete until the rescan is complete).
• The `logging` RPC has now been made public rather than hidden.
• An `initialblockdownload` boolean has been added to the `getblockchaininfo` RPC to indicate whether the node is currently in IBD or not.
• `minrelaytxfee` is now included in the output of `getmempoolinfo`
• `-debuglogfile=` can be used to specify an alternative debug logging file.
• groestlcoin-cli now has an `-stdinrpcpass` option to allow the RPC password to be read from standard input.
• The `-usehd` option has been removed.
• groestlcoin-cli now supports a new `-getinfo` flag which returns an output like that of the now-removed `getinfo` RPC.
• Regtest support has been enabled and the JSON-RPC port is 18888.
• Segwit is always active in regtest mode by default.

It is appreciated if feedback of the following is provided:
1. Can you receive coins on a bech32 address? (small amounts to avoid losing them)
2. Can you receive coins on a legacy address? (small amounts to avoid losing them)
3. Can you receive coins on a p2sh-segwit address? (small amounts to avoid losing them)
4. Can you send coins on a bech32 address?
5. Can you send coins on a legacy address?
6. Can you send coins on a p2sh-segwit address?
7. Can you view your transaction on a third party blockexplorer (restart the client after entering the url of the blockexplorer) ?
8. Can you use the wallet with TOR?
9. Are you able to backup your wallet (wallet.dat) file?
10. Are you able to encrypt your wallet (wallet.dat) file?
11. Are you able to use watch-only function?
12. How long does it take to fully synchronize?
13. Are you able to sign/verify messages?
14. Are you able to see you send/receive addresses?
15. Are you able to use the wallet in your local language?

The application may have unfound bugs and problems. Please report using the issue tracker at github:
https://github.com/groestlcoin/groestlcoin/issues

Important:
• There is no warranty and no party shall be made liable to you for damages. If you lose coins due to this app, no compensation will be given. Use this app solely at your own risk.
• Encrypt your wallet. This can be done by clicking the settings menu from inside the wallet. Make sure your password is secure and do not forget it.
• Make a copy your wallet.dat file as a backup and move it to a secure location:
Location Windows: Navigate to C:\Users\Username\AppData\Roaming\groestlcoin\wallet.dat (or open windows explorer and enter %appdata%\Groestlcoin\wallet.dat)
Location Mac: Finder -> Go {Hold Option] -> Library -> groestlcoin -> wallet.dat (~/Library/Application Support/groestlcoin/wallet.dat)

WARNING:
While this branch has been extensively tested to be compatible with the existing Groestlcoin v2.11.0 and v2.13.3 network there is the possibility that we missed something. ALWAYS BACKUP YOUR GROESTLCOIN WALLET BEFORE UPGRADING.

How to Upgrade?
The first time you run version 2.16.0, your chainstate database will be converted to a new format, which will take anywhere from a few minutes to half an hour, depending on the speed of your machine.
Windows: If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer.
OSX: If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), run the dmg and drag Groestlcoin Core to Applications.
Ubuntu users: http://groestlcoin.org/forum/index.php?topic=441.0
Linux users: http://groestlcoin.org/forum/index.php?topic=97.0

Download the Windows Installer (64 bit) here: https://github.com/Groestlcoin/groestlcoin/releases/download/v2.16.0/groestlcoin-2.16.0-win64.msi
Download the Windows Installer (32 bit) here: https://github.com/Groestlcoin/groestlcoin/releases/download/v2.16.0/groestlcoin-2.16.0-win32.msi
Download the Windows binaries (64 bit) here: https://github.com/Groestlcoin/groestlcoin/releases/download/v2.16.0/groestlcoin-2.16.0-x86_64-w64-mingw32.zip
Download the Windows binaries (32 bit) here: https://github.com/Groestlcoin/groestlcoin/releases/download/v2.16.0/groestlcoin-2.16.0-i686-w64-mingw32.zip
Download the OSX Installer here: https://github.com/Groestlcoin/groestlcoin/releases/download/v2.16.0/groestlcoin-2.16.0-osx.dmg
Download the OSX binaries here: https://github.com/Groestlcoin/groestlcoin/releases/download/v2.16.0/groestlcoin-2.16.0-x86_64-apple-darwin11.tar.gz
Download the Linux binaries (64 bit) here: https://github.com/Groestlcoin/groestlcoin/releases/download/v2.16.0/groestlcoin-2.16.0-x86_64-linux-gnu.tar.gz
Download the Linux binaries (32 bit) here: https://github.com/Groestlcoin/groestlcoin/releases/download/v2.16.0/groestlcoin-2.16.0-i686-pc-linux-gnu.tar.gz
Download the ARM Linux binaries (64 bit) here: https://github.com/Groestlcoin/groestlcoin/releases/download/v2.16.0/groestlcoin-2.16.0-aarch64-linux-gnu.tar.gz
Download the ARM Linux binaries (32 bit) here: https://github.com/Groestlcoin/groestlcoin/releases/download/v2.16.0/groestlcoin-2.16.0-arm-linux-gnueabihf.tar.gz

SHA-256 hashes of the released files for verification:
groestlcoin-2.16.0-x86_64-linux-gnu.tar.gz 4e7683bbc6f3b7899761d1360f52a91f417e2b7e6c56b75b522d95b86ca46628
groestlcoin-2.16.0-aarch64-linux-gnu.tar.gz
a04c37bbc384387e1587ad7dd3c85cdfde71a351d9825cdc915898f943b8665c
groestlcoin-2.16.0-arm-linux-gnueabihf.tar.gz
1d0bec5e2073717d20aae63d957e9e404ce0ed26a8757a6cdd3ac68ee809ead6
groestlcoin-2.16.0-i686-pc-linux-gnu.tar.gz
ecd8b437995e1806138816a3dc20765058b8933bbdbfa5d87bcafe01b76f9324
groestlcoin-2.16.0-osx.dmg
fb2984cf2f27a2369bfcbe9674a3cc0f9a09835701372b7a51562b6f2d596729
groestlcoin-2.16.0-win64.msi
6ee50fd6d579ce19a7d49d07fa5f910b3316ab37ebb692571601c74d75493620
groestlcoin-2.16.0-win32.msi
f717a1bd8d6d1c4220c79f17b92eb9f2c7a292a6d0801fa83b58d8e3dc7e8c93
groestlcoin-2.16.0-x86_64-w64-mingw32.zip
327aaee189255f2722736a426732a0f38fef90bae6495f42fd148138523c586c
groestlcoin-2.16.0-i686-w64-mingw32.zip
4107659e268f1e4143bd7c8d7f7ffe1653fea95eca66de4259175585652306cd
groestlcoin-2.16.0-x86_64-apple-darwin11.tar.gz
5ff6e5a509e0c69f4a832bd3c40a1a93f80a68bc5f55a0b5d517716fb123164e

Source code:
https://github.com/Groestlcoin/groestlcoin
Build instructions for Linux can be found here: https://github.com/Groestlcoin/groestlcoin/blob/master/doc/build-unix.md
Build instructions for OSX can be found here: https://github.com/Groestlcoin/groestlcoin/blob/master/doc/build-osx.md
Build instructions for Windows can be found here: https://github.com/Groestlcoin/groestlcoin/blob/master/doc/build-windows.md

Hey Guys there is a news after 4 days. So, can it rise?

Heck, webbski. Sorry for the slow reply. (BCT has had a glitch, and I lost my old account. Sigh.)

I trade every day on Coinexchange, but I haven't had to put coin on in a while. Will check this out for us.

Hey Guys,any news on when deposits are possible on CoinExchange ?

https://komodoplatform.atlassian.net/wiki/spaces/KPSD/pages/311230483/How+to+Buy+on+HyperDEX


https://www.reddit.com/r/groestlcoin/comments/8oem7r/barterdex_becomes_hyperdex/

Nah, these are ATG: ass-to-grass(root) squats 

I can think of one disadvantage: "AssRoot"  

Thank you for sharing!

More places to get Groestlcoin - Godex.io has listed GRS for fast and secure exchanges
https://twitter.com/GroestlcoinTeam/status/1002505924995637248

Groestlcoin (GRS) is now listed on GODEX Exchange

https://twitter.com/GroestlcoinTeam/status/1002505924995637248

Congratulation !

Wish you very happy trading !

I think  you are richest man oon this planet...

Hello Groestlcoin believers,

Our aim is to add value to the whole crypto community by giving the best user experience to analyse cryptocurrencies.

It would be really great help from your side if you can spend 60 seconds of your time and give us your valuable feedback on our two recent updates 1) Snapshot and 2) Colourful
interface of Groestlcoin at: https://cointopper.com/coin/groestlcoin

Constructive criticisms are always welcome at CoinTopper.  Thank you!!