Groestlcoin 5th Anniversary Release Update
What a wild ride it has been, Groestlcoin is officially turning 5 years old today!
It has been a crazy year and we have overcome many obstacles along the way, yet here we are five years down and still going strong because Groestlcoin is here to stay!
Just being here after 5 years is a massively more major victory than many - probably most - will ever realise. Over the course of the past 5 years,Groestlcoin has had committed development, numerous updates and a very turbulent altcoin market. With an explosion of altcoins in 2017 - many of them wouldn't last more than a week or month - the altcoin market got very heated. But with the great development team and loyal community, we have stayed true to this day. Our sincerest thanks to all of you who have stood with us.
Groestlcoin has maintained its vision and goal clearly throughout, we feel that with every passing day the coin becomes a stronger contender in the cryptocurrency field. While others are forced to promise the moon and other aggressive over-promises - but under-deliver - we will promise nothing and over-deliver. When you expect nothing and get everything; that's destiny. What we can promise is this - Groestlcoin is here for the long-haul!
We are very excited about what the future holds and very committed to the long-term success of Groestlcoin. We are working on several exciting projects to push Groestlcoin forward in 2019. During 2019 you will see more end user tools increasing the ease of use as well to ensure we are present on all possible platforms.
- Now listed on over 50 cryptocurrency exchanges
- You can store your Groestlcoin on 10 different hardware wallets
- You can store your Groestlcoin on 13 Third-Party multi-currency wallets
- Store your Groestlcoin on 4 actively-developed mobile wallets
- Included in 2 Debit Card systems via Mastercard (PolisPay) and VISA (Equicex)
- Included in 7 Payment Processors for Merchants to accept GRS – Groestlcoin is now accepted in hundreds of stores worldwide, directly or indirectly.
- Over 230 Developed repositories on Github
- Over 107k subscribers on Reddit
- Over 3500 members on Telegram
- Over 2200 members on Discord
- Over 8000 followers on Facebook
- Over 38k followers on Twitter
Recap of the past 3 months:
- 24/12/2018 – Added to COINiD Hot & Cold Mobile Wallet.
- 26/12/2018 –Added to iVendPay Vending Machine Hardware.
- 27/12/2018 – Added to Paybyte Payment Processor.
- 09/01/2019 – Added to Coinomi Desktop Wallets for Windows, Linux and MacOS.
- 14/01/2019 – Added to ExRates cryptocurrency exchange.
- 15/01/2019 – Added to Cryptocrowns betting system.
- 17/01/2019 – Added to Binance Info’s transparency initiative.
- 28/01/2019 – Added to MyCryptoCheckout Payment Processor.
- 28/01/2019 – Added to SideShift AI Cryptocurrency Swap/Exchange Platform.
- 28/01/2019 – Added to ELLIPAL Hardware Wallet with Exchange System.
- 29/01/2019 – Added to CoinRoom cryptocurrency exchange.
- 30/01/2019 – Added a test-net faucet to claim test-net coins for new developers to test new platforms and systems.
- 31/01/2019 – Added to MAGNUM Cryptocurrency Web-Wallet.
- 01/02/2019 – Added to the test-net mining pool run by ocminer (SuprNova).
- 05/02/2019 – Added to Ledger Nano S and Nano Ledger Blue Hardware Wallets.
- 07/02/2019 – Added to Paytomat payment processor.
- 08/02/2019 – Testnet added to Ledger Nano S and Nano Ledger Blue wallets.
- 08/02/2019 – GRSPay includes support for Ledger devices. Receive and make payments with Ledger directly from GRSPay!
- 12/02/2019 – Testnet added to Trezor T hardware wallets.
- 25/02/2019 – Added to FLX Hardware Wallet including an intuitive mobile app
- 26/02/2019 – Added to top-10 exchange Bit-Z! – With a 50,000 GRS Giveaway Trading Competition!
- 27/02/2019 – Ability to buy Groestlcoin with your credit card on LiteBit.
- 27/02/2019 – Added USDT Trading Pair on CryptoBridge.
- 28/02/2019 – Added to Zelcore intuitive multi-asset mobile wallet, available on iOS, Android, Windows, Mac OS and Linux, with exchange functionality built-in from Changelly and CoinSwitch.
- 28/02/2019 – Won free listing on XBTS Decentralised Cryptocurrency Exchange.
- 02/03/2019 – Added to Changeangel crypto-to-crypto swap exchange service.
- 04/03/2019 – Added to OnePageX swap exchange service.
- 08/03/2019 – Formally listed on XBTS Decentralised Exchange
- 11/03/2019 – Added to PolisPay the first Mastercard debit card for Groestlcoin *Currently limited to Mexico
- 14/03/2019 –Launched on Bitfi Hardware Wallet – The official hardware wallet for Groestlcoin
- 18/03/2019 – Added to Equicex, the first VISA debit card for Groestlcoin, accepted anywhere that accepts VISA card payments. Also added to Equicex Swap Exchange and included in the Black Edition of the card – No ID or Utility Bills etc. required. 100% Anonymous.
- 19/03/2019 – Added to DigiFinex, with a 20,000 GRS Giveaway STILL LIVE
- 20/03/2019 – Added to changehero Cryptocurrency
What’s Released Today?
Groestlcoin Core 2.17.2
Groestlcoin Core version 2.17.2 is now available for download – Bringing both new features and of course bug fixes, so it is recommended to upgrade to it if you are running a full Groestlcoin node or a local Groestlcoin wallet. Most services have already pre-emptively upgraded to this version.
This is a major release of Groestlcoin Core with many protocol level improvements and code optimizations, featuring the technical equivalent to Bitcoin v0.17.2 but with Groestlcoin-specific patches. On a general level, most of what is new areBIP174 PSBT support. BIP 174 PSBT support is an interchange format for Groestlcoin transactions that are not fully signed yet, together with relevant metadata to help entities work towards signing it. It is intended to simplify workflows where multiple parties need to co-operate to produce a transaction. Examples include hardware wallets, multi-sig setups, and CoinJoin transactions.
- -includeconf=<file>can be used to include additional configuration files. Only works inside the groestlcoin.conf file, not inside included files or from the command-line. Multiple files may be included, and this can be disabled from the command-line via -noincludeconf. Not that multi-argument commands like:-includeconfwill override preceding -noincludeconfas conf will still include relative.conf.
- Block storage can be limited under Preferences, in the Main tab. Undoing this setting requires downloading the full blockchain again. This mode is incompatible with -txindexand -rescan.
- The -wallet=<path> option now accepts full paths instead of requiring wallets to be in the -walletdir
- If -wallet=<path> is specified with a path that does not exist, it will now create a wallet directory at the specified location (containing a wallet.dat data file, a db.log file, and database/log.x files) instead of just creating a data file at the path and storing log files in the parent directory. This should make backing up wallets more straightforward than before because the specified wallet path can just be directly archived without having to look in the parent directory for transaction log files. For backwards compatibility, wallet paths that are names of existing data files in the -walletdirdirectory will continue to be accepted and interpreted the same as before.
- Previously, wallets could only be loaded or created at startup, by specifying -wallet parameters on the command line or in the groestlcoin.conf file. It is now possible to load, create and unload wallets dynamically at runtime:
- Existing wallets can be loaded by calling the loadwallet The wallet can be specified as file/directory basename (which must be located in the -walletdir directory), or as an absolute path to a file/directory.
- New wallets can be created (and loaded) by calling the createwallet The provided name must not match a wallet file in the walletdir directory or the name of a wallet that is currently loaded.
- Loaded Wallets can be unloaded by calling the unloadwallet RPC command.
- This feature is currently only available through the RPC interface.
- When an address is paid multiple times, the coin from those separate payments can be spent separately. This hurts privacy due to linking otherwise separate addresses. A new -avoidpartialspends flag has been added (default to false). If enabled, the wallet will always spend existing UTXO to the same address together, even if it results in higher fees. If someone were to send coins to an address after it was used, those coins will still be included in future coin selections.
- It is now possible for a single configuration file to set different options for different networks. This is done by using sections or by prefixing the option with the network, such as uacomment=groestlcoin or [main] [Settings]. If not specified, they will only apply to the main net.
- A new label API has been introduced for the wallet. This is intended as a replacement for the deprecated account The account API can continue to be used in V2.17.2 by starting groestlcoind with -deprecatedrpc=accounts argument and will be fully removed in V2.18.1. The label RPC methods mirror the account functionality, with the following functional differences:
- Labels can be set on any address, not just receiving addresses. This functionality was previously only available through the GUI.
- Labels can be deleted by reassigning all addresses using the setlabel RPC method.
- There isn’t support for sending transactions from a label, or for determining which label a transaction was sent from
- Labels do not have a balance
- Here are the changes to all RPC methods, as follows:
|Deprecated Method||New Method||Notes|
|getaccount||getaddressinfo||Returns a JSON object with address information instead of just the name of the account as a string.|
|getaccountaddress||N/A||No replacement since labels does not have an associated receive address.|
|listaccounts||listlabels||Does not return a balance or accept minconf and watchonly arguments.|
|listreceivedbyaccount||Listreceivedbylabel||Both methods return new label fields, along with account fields for backward compatibility.|
Both methods now:
· Allow assigning labels to any address, instead of raising an error if the address is not a receiving address.
· Delete the previous label associated with an address when the final address using that label is reassigned to a different label. Instead of making an implicit getaccountaddress call to ensure the previous label still has a receiving address.
|addmultisigaddress||Renamed account parameter to label*|
|getnewaddress||Renamed account parameter to label*|
|listunspent||Returns new label fields*|
|sendmany||The account named parameter has been renamed to the dummy.If provided, the dummy parameter must be set to an empty string*.|
|listtransactions||Renamed account parameter to label*|
|getbalance||account, minconf and include_watchonly parameters are deprecated*|
*Still accepted or unchanged for backwards compatibility if running with -deprecatedrpc=accounts flag.
- BIP 174 PSBT is an interchange format for Groestlcoin transactions that are not fully signed yet, together with relevant metadata to help entities work towards signing it. It is intended to simplify workflows where multiple parties need to co-operate to produce a transaction. Examples include hardware wallets, multi-sig setups, and CoinJoin The construction to a fully signed transaction goes through the following steps:
- A Creator proposes a particular transaction to be created. He constructs a PSBT that contains certain inputs and outputs, but no additional metadata.
- For each input, an Updater adds information about the UTXOs being spent by the transaction to the PSBT.
- A potential other Updater adds information about the scripts and public keys involved in each of the inputs (and possibly outputs) of the PSBT.
- Signers inspect the transaction and its metadata to decide whether they agree with the transaction. They can use amount of information from the UTXOs to assess the values and fees involved. If they agree, they produce a partial signature for the inputs for which they have a relevant key(s) for.
- A Finalizer is run for each input to convert the partial signatures and possibly script information into a final scriptSig and/or scriptWitness.
- An Extractor produces a valid Groestlcoin transaction (in network format) from a PSBT for which all inputs are finalised.
Generally, each of the above (excluding Creator and Extractor) will simply add more and more data to a PSBT. In a naïve workflow, they all must operate sequentially, passing the PSBT from one to the next, until the Extractor can convert it to a real transaction. In order to permit parallel operation, Combiners can be employed which merge metadata from different PSBTs for the same unsigned transaction. The names above in bold are the names of the roles defined in BIP174. They’re useful in understanding the underlying steps, but in practice, software and hardware implementations will typically implement multiple roles simultaneously.
- converttopsbt (Creator) is a utility RPC that converts an unsigned raw transaction to PSBT format. It ignores existing signatures.
- createpsbt (Creator) is a utility RPC that takes a list of inputs and outputs and converts them to a PSBT with no additional information. It is equivalent to calling `createrawtransaction` followed by `converttopsbt`.
- walletcreatefundedpsbt (Creator, Updater) is a wallet RPC that creates a PSBT with the specified inputs and outputs, adds additional inputs and change to it to balance it out, and adds relevant metadata. For inputs that the wallet knows about (counting towards its normal or watch-only balance), UTXO information will be added. For outputs and inputs with UTXO information present, key and script information will be added which the wallet knows about. It is equivalent to running createrawtransaction, followed by fundrawtransaction, and converttopsbt.
- walletprocesspsbt (Updater, Signer, Finalizer) is a wallet RPC that takes as input a PSBT, adds UTXO, key, and script data to inputs and outputs that miss it, and optionally signs inputs. Where possible it also finalizes the partial signatures.
- finalizepsbt (Finalizer, Extractor) is a utility RPC that finalizes any partial signatures, and if all inputs are finalized, converts the result to a fully signed transaction which can be broadcast with sendrawtransaction.
- combinepsbt (Combiner) is a utility RPC that implements a Combiner. It can be used at any point in the workflow to merge information added to different versions of the same PSBT. It is useful to combine the output of multiple Updaters or Signers.
- decodepsbt is a diagnostic utility RPC which will show all information in a PSBT in human-readable form, as well as compute its eventual fee if known.
- Since Groestlcoin Core 2.13.3, creating new BIP 32 Hierarchical Deterministic wallets has been supported by Groestlcoin Core but old non-HD wallets could not be upgraded to HD. Now non-HD wallets can be upgraded to HD using the -upgradewallet command line option. This upgrade will result in all keys in the key pool being marked as used and a new key pool generated.
NOTE:A new backup must be made when this upgrade is performed.
Additionally, -upgradewallet can be used to upgraded from a non-split HD chain (all keys generated with m/0'/0'/i') to a split HD chain (receiving keys generated with `'m/0'/0'/i'` and change keys generated with m'/0'/1'/i'). When this upgrade occurs, all keys already in the key pool will remain in the key pool to be used until all keys from before the upgrade are exhausted. This is to avoid issues with backups and downgrades when some keys may come from the change key pool. Users can begin using the new split HD chain key pools by using the `newkeypool` RPC to mark all keys in the key pool as used and begin using a new key pool generated from the split HD chain.
- A new RPC, sethdseed, has been introduced which allows users to set a new HD seed or set their own HD seed. This allows for a new HD seed to be used. NOTE: A new backup must be made when a new HD seed is set.
- The new RPC scantxoutset can be used to scan the UTXO set for entries that match certain output descriptors. Refer to the [output descriptors reference documentation] (/doc/descriptors.md) for more details. This call is like listunspent but does not use a wallet, meaning that the wallet can be disabled at compile or run time. This call is experimental, as such, is subject to changes or removal in future releases.
- The createrawtransaction RPC will now accept an array or dictionary (kept for compatibility) for the `outputs` parameter. This means the order of transaction outputs can be specified by the client.
- The fundrawtransaction RPC will reject the previously deprecated reserveChangeKey
- sendmany now shuffles outputs to improve privacy, so any previously expected behaviour with regards to output order can no longer be relied upon.
- The new RPC testmempoolaccept can be used to test acceptance of a transaction to the mempool without adding it.
- JSON transaction decomposition now includes a ‘weight’ field which provides the transaction's exact weight. This is included in REST /rest/tx/ and /rest/block/ endpoints when in JSON This is also included in getblock (with verbosity=2), listsinceblock, listtransactions, and getrawtransaction RPC command.
- New fees field introduced in getrawmempool, getmempoolancestors, getmempooldescendants and getmempoolentry when verbosity is set to true with sub-fields ancestor, base, modified and descendant denominated in GRS. This new field deprecates previous fee fields, such as fee, modifiedfee, ancestorfee and descendantfee.
- The new RPC getzmqnotifications returns information about active ZMQ notifications.
- When groestlcoin is not started with any -wallet=<path> options, the name of the default wallet returned by getwalletinfo and listwallets RPCs is now the empty string "" instead of "wallet.dat". If Groestlcoin is started with any -wallet=<path> options, there is no change in behaviour, and the name of any wallet is just its <path>
- Passing an empty string ("") as the address_type parameter to getnewaddress, getrawchangeaddress, addmultisigaddress, fundrawtransaction RPCs is now invalid. Previously, this would fall back to using the default address type. It is still possible to pass null or leave the parameter unset to use the default address type.
- Bare multi-sig outputs to our keys are no longer automatically treated as incoming payments. As this feature was only available for multi-sig outputs for which you had all private keys in your wallet, there was generally no use for them compared to single-key schemes. Furthermore, no address format for such outputs is defined, and wallet software can't easily send to it. These outputs will no longer show up in listtransactions, listunspent, or contribute to your balance, unless they are explicitly watched (using importaddress or importmulti with hex script argument). signrawtransaction also still works for them.
- The getwalletinfo RPC method now returns an hdseedid value, which is always the same as the incorrectly-named hdmasterkeyid hdmasterkeyid will be removed in V2.18.1.
- The getaddressinfo RPC method now returns an hdseedid value, which is always the same as the incorrectly-named hdmasterkeyid hdmasterkeyid will be removed in V2.18.1.
- Parts of the validateaddress RPC method have been deprecated and moved to getaddressinfo. Clients must transition to using getaddressinfo to access this information before upgrading to v2.18.1. The following deprecated fields have moved to getaddressinfo and will only be shown with -deprecatedrpc=validateaddress: ismine, iswatchonly, script, hex, pubkeys, sigsrequired, pubkey, addresses, embedded, iscompressed, account, timestamp, hdkeypath, hdmasterkeyid.
- signrawtransaction is deprecated and will be fully removed in v2.18.1. To use signrawtransaction in v2.17.2, restart groestlcoind with -deprecatedrpc=signrawtransaction. Projects should transition to using signrawtransactionwithkey and signrawtransactionwithwallet before upgrading to v2.18.1.
- The inactivehdmaster property in the dumpwallet output has been corrected to inactivehdseed
- The log timestamp format is now ISO 8601 (e.g. "2018-02-28T12:34:56Z").
- When running groestlcoind with -debug but without -daemon, logging to stdout is now the default behaviour. Setting -printtoconsole=1 no longer implicitly disables logging to debug.log. Instead, logging to file can be explicitly disabled by setting -debuglogfile=0.
- The transaction index is now built separately from the main node procedure, meaning the -txindex flag can be toggled without a full re-index. If groestlcoind is run with -txindex on a node that is already partially or fully synced without one, the transaction index will be built in the background and become available once caught up. When switching from running -txindex to running without the flag, the transaction index database will not be deleted automatically, meaning it could be turned back on later without a full resync.
- The -blockmaxsize option for miners to limit their blocks' sizes was deprecated in V2.16.0 and has now been removed. Miners should use the -blockmaxweight option if they want to limit the weight of their blocks.
- Support for Python 2 has been discontinued for all test files and tools.
Download the Windows Installer (64 bit) here
Download the Windows Installer (32 bit) here
Download the Windows binaries (64 bit) here
Download the Windows binaries (32 bit) here
Download the OSX Installer here
Download the OSX binaries here
Download the Linux binaries (64 bit) here
Download the Linux binaries (32 bit) here
Download the ARM Linux binaries (64 bit) here
Download the ARM Linux binaries (32 bit) here
Build instructions for Linux can be found here
Build instructions for OSX can be found here
Build instructions for Windows can be found here
Electrum-GRS is Groestlcoins official “thin client” Groestlcoin wallet for Windows, MacOS and Linux. Its main advantages over Core include support for multi-signature wallets and not requiring downloading the blockchain before use. If you are an every-day user of Groestlcoin and simply want the convenience of a web wallet with the security of a real application, with multi-signature support, then Electrum-GRS is the right choice for you.
- Hardware Wallets:
- Archos Safe-T mini: Fix for signing issue
- KeepKey: Full Segwit Support
- Trezor: Refactoring and compat with python-trezor11
- Fix a regression during transaction signing that prompts the users too many times for confirmations.
- Fix Qt bug that made all hardware wallets unusable on Windows 8.1.
- The network layer has been rewritten using asyncio and aiorpcx. In addition to easier maintenance, this makes the client more robust against misbehaving servers.
- The blockchain headers and fork handling logic have been generalised. Clients by default will now follow the chain based on most work, not length.
- New wallet creation defaults to native Segwit (BECH32).
- RBF batching (opt-in): If the wallet has an unconfirmed RBF transaction, new payments will be added to that transaction, instead of creating new transactions.
- MacOS: Support QR code scanner in binaries.
- Performance should be better for larger wallets: QT Listing Rewritten: The History tab now uses QAbstractItemModel, the other tabs use QStandardItemModel.
- Prepend server transaction broadcast error messages with an explanatory message. Render error messages in plain text.
- Do not expose users to server error messages.
- Notify users of new releases. Release announcements must be signed, and they are verified by Electrum-GRS using a hardcoded Groestlcoin address.
- Display only QR code in QRCode window
- Randomise lock-time of transactions.
- AppImage: We now also distribute self-contained binaries for x86_64 Linux in the form of an AppImage. The Python interpreter, PyQt5, libsecp256k1, PyCryptodomex, zbar, hidapi/libusb (including hardware wallet libraries) are all bundled. Note that users of hardware wallets still need to set udev rules by themselves.
- Transactions now set nVersion to 2, to mimic Groestlcoin Core.
- Improve network timeouts.
- Fix bugs in wallet creation wizard that resulted in corrupted wallets being created in rare cases
- Fix compatibility with Qt 5.12.
- Fix groestlcoin URI handling when the app is already running.
- The minimum Python version increased to 3.6.
- Several other minor bugfixes and usability improvements.
Download Windows installer here
Download Windows standalone wallet here
Download Windows portable version here
Download the OSX wallet here
Download Linux installer here
GitHub Source server
Github Source server installer
Github Source client
Github Source Icons
Github Source locale
Electrum-GRS for Android is a lightweight wallet which mimics the Windows equivalent in forms of convenience and security, utilising the power of electrum servers to bring Groestlcoin securely to Android.
- As on Windows. The network layer has been re-written using asyncio and aiorpcx. Allowing for easier maintenance and greater security against misbehaving servers.
- New wallet creation defaults to Native Segwit (BECH32).
- RBF batching (opt-in): If the wallet has an unconfirmed RBF transaction, new payments will be added to that transaction, instead of creating new transactions.
- Randomise lock-time of transactions.
- Transactions now set nVersion to 2, to mimicGroestlcoin Core
- Android APK:
- Build using Google NDK instead of Crystax NDK
- Target API 28
- Do not use external storage (Previously for block headers)
- Minor GUI Improvements and fixes.
Groestlcoin Broadcast Tool
The all-new Groestlcoin Broadcast Tool gives you the ability to broadcast transactions quicker, to several services. By doing this, you will increase the chances of your transaction being included in blocks – leading to faster confirmation times.
- Broadcast raw signed transactions to Chainz.CryptoID Block Explorer.
- Broadcast raw signed transactions to Blockbook Block Explorer.
- Broadcast raw signed transactions to Groestlsight Block Explorer.
- Supports broadcasting of signed test-net raw transactions.
- Open Source under the MIT license.
You can download it using the links below.
Download the Windows Wallet (64 bit) here
Download the Windows Wallet (32 bit) here
Hint for Groestlcoin Puzzle!
Look at the image with 356EF and combine them to find the right sequence for unlocking the next stage of the puzzle.