A new major Groestlcoin Core version 2.13.3 is now available for download bringing both new features and bug fixes, so it is recommended to upgrade to it if you are running a full Groestlcoin node or a local Groestlcoin Core wallet.
v2.13.3 is now the official release version of Groestlcoin Core. On top of the new features and performance improvements, this update contains very important security fixes. It is recommended to upgrade to this version as soon as possible.
Pool operators, P2Pool and solo miners especially because by default, Groestlcoin Core automatically set and unsets version bits as required.
The deployment sets the block version number to 0x20000023 between midnight 21th Jan 2017 and midnight 21th June 2017 to signal readiness for deployment. The version number consists of 0x20000000 to indicate version bits together with setting bit 0, bit 1 and bit 5 to indicate support for this combined deployment, shown as "csv", "segwit" and "bip65" in the "getblockchaininfo" RPC call. Please note it will keep generating blocks with version 0x20000023 until "csv", "segwit" and "bip65" are activated at which point is will automatically unset bit 0, bit 1 and bit 5.
All pools, services, exchanges are already upgraded.
We would like to thank everybody for a smooth and fast upgrade (in no particular order):
Suprnova
Dwarfpool
Zpool
Miningpoolhub
Coinmine.pl
Chainz
Bchain
Cryptoguru
Fogify
Bittrex
Cryptopia
What's new in version v2.13.3?
This is a major release of Groestlcoin Core with many protocol level improvements and code optimizations, featuring the technical equivalent of Bitcoin v0.13.3 but with Groestlcoin specific patches. On a general level, most of what is new is the ability to roll out several soft forks at once, the greatly anticipated segregated witness (segwit) innovation, csv and BIP65.
Changelog:
• Qt dependency changed. Version upgraded to 5.7.1
• BerkeleyDB dependency changed. Version for Windows and MAC upgraded to 5.3.28 (9 September 2013).
• Blockversion bumped to 0x20000000 to get ready for BIP9 deployment.
• Alert keys removed.
• Extra DNS seed added.
• Hardcoded main seeds added.
• Hardcoded test seeds added.
• Installer comes now with Groestlcoin logo and uninstaller.
• New transaction cost mechanism.
• Chinese, Bulgarian, Russian, Ukrainian, Japanese and Arabic translation for Groestlcoin added.
• All possible languages updated.
• BIP9 - This BIP allows multiple soft fork changes to be deployed in parallel.
• BIP65 - This BIP allows a transaction output to be made unspendable until some point in the future.
• BIP68 - This BIP allows relative locktime enforcement through sequence numbers.
• BIP112 - This BIP is a proposal to redefine the semantics used in determining a time-locked transaction's eligibility for inclusion in a block. The median of the last 11 blocks is used instead of the block's timestamp, ensuring that it increases monotonically with each block.
• BIP113 - This BIP describes a new opcode (CHECKSEQUENCEVERIFY) for the groestlcoin scripting system that in combination with BIP68 allows execution pathways of a script to be restricted based on the age of the output being spent.
• BIP130 - This BIP adds a new message, "sendheaders", which indicates that a node prefers to receive new block announcements via a "headers" message rather than an "inv".
• BIP133 - This BIP adds a new message “feefilter”, which serves to instruct peers not to send “inv”s to the node for transactions with fees below the specified fee rate.
• BIP141 - This BIP defines a new structure called a “witness” that is committed to blocks separated from the transaction merkle tree.
• BIP143 - This BIP contains the logic for signature verification for version 0 witness program.
• BIP144 - This BIP contains the logic for new messages and serialization formats for propagation of transactions and blocks committing to segregated witness structures.
• BIP147 - This BIP contains changes to the transaction validity rules to fix a malleability vector.
• BIP152 - This BIP add compact block relay to reduce the bandwidth required to propagate new blocks.
• Segregated witness soft fork. To allow for greater transaction output and mitigation of transaction malleability.
• Hierarchical Deterministic Key Generation. Groestlcoin Core will support hierarchical deterministic wallets, as described in BIP32, also known as HD wallets.
• Signature validation using libsecp256k1. ECDSA signatures inside Groestlcoin transactions now use validation using libsecp256k1 instead of OpenSSL.
• Wallet: Pruning. To reduce block size storage.
• Memory pool limiting. Better mempool filtering of transactions.
• Automatically use Tor hidden services. Inbuilt Tor control socket API support if Tor is running and also stream isolation for Tor communication.
• Option to reduce upload traffic. It is now possible to reduce the total upload traffic via the '-maxuploadtarget' parameter.
• Notifications through ZMQ. Groestlcoind can now (optionally) asynchronously notify clients through a ZMQ-based PUB socket of the arrival of new transactions and blocks.
• NODE_BLOOM service bit. Support for the NODE_BLOOM service bit, as described in BIP 111, has been added to the P2P protocol code.
• Removal of internal miner. As CPU mining in the wallet has been useless for a long time, the internal miner has been removed in this release, and replaced with a simpler implementation for the test framework.
• Opt-in Replace-by-fee transactions. It is now possible to replace transactions in the transaction memory pool of Groestlcoin Core 2.13.3 nodes.
• RPC: SSL support dropped. SSL support for RPC, previously enabled by the option rpcssl has been dropped from both the client and the server. This was done for removing the dependency on OpenSSL for the daemon completely.
• Fix buffer overflow in bundled upnp. Bundled miniupnpc was updated to 1.9.20151008. This fixes a buffer overflow in the XML parser during initial network discovery.
• Test for LowS signatures before relaying. Make the node require the canonical 'low-s' encoding for ECDSA signatures when relaying or mining. This removes a nuisance malleability vector. Consensus behavior is unchanged.
• Windows bug fix for corrupted UTXO database on unclean shutdowns. This release no longer relies on memory-mapped files for the UTXO database, which significantly reduced the frequency of unclean shutdowns leading to required reindexes.
• RPC: Random-cookie RPC authentication. When no -rpcpassword is specified, the daemon now uses a special 'cookie' file for authentication. This file is generated with random content when the daemon starts, and deleted when it exits. Its contents are used as authentication token.
• Relay: Any sequence of pushdatas in OP_RETURN outputs now allowed. Previously OP_RETURN outputs with a payload were only relayed and mined if they had a single pushdata. This restriction has been lifted to allow any combination of data pushes and numeric constant opcodes (OP_1 to OP_16) after the OP_RETURN. The limit on OP_RETURN output size is now applied to the entire serialized scriptPubKey, 83 bytes by default. (the previous 80 byte default plus three bytes overhead).
• Relay: New and only new blocks relayed when pruning. When running in pruned mode, the client will now relay new blocks. When responding to the getblocks message, only hashes of blocks that are on disk and are likely to remain there for some reasonable time window (1 hour) will be returned (previously all relevant hashes were returned).
• Relay and Mining: Priority transactions. In Groestlcoin Core 2.13.3, when mempool limit has been reached a higher minimum relay fee takes effect to limit memory usage. Transactions which do not meet this higher effective minimum relay fee will not be relayed or mined even if they rank highly according to the priority heuristic.
• Wallet: Transaction fees. Various improvements have been made to how the wallet calculates transaction fees.
• Wallet: Negative confirmations and conflict detection. The wallet will now report a negative number for confirmations that indicates how deep in the block chain the conflict is found.
• Wallet: Merkle branches removed. Previously, every wallet transaction stored a Merkle branch to prove its presence in blocks. This wasn't being used for more than an expensive sanity check. Since 2.13.3, these are no longer stored. When loading a 2.13.2 wallet into an older version, it will automatically rescan to avoid failed checks.
• Option parsing behavior. Command line options are now parsed strictly in the order in which they are specified.
• RPC: Low-level API changes. Monetary amounts can be provided as strings. This means that for example the argument to sendtoaddress can be "0.0001" instead of 0.0001. This can be an advantage if a JSON library insists on using a lossy floating point type for numbers, which would be dangerous for monetary amounts.
• Database cache memory increased. The default was changed to 300 MiB in this release.
• Groestlcoin-cli: arguments privacy. The RPC command line client gained a new argument: "-stdin" to read extra arguments from standard input, one per line until EOF/Ctrl-D.
• Mining transaction selection ("Child Pays For Parent"). The mining transaction selection algorithm has been replaced with an algorithm that selects transactions based on their feerate inclusive of unconfirmed ancestor transactions.
• Reindexing changes. In earlier versions, reindexing did validation while reading through the block files on disk. These two have now been split up, so that all blocks are known before validation starts. This was necessary to make certain optimizations that are available during normal synchronizations also available during reindexing.
• New bytespersigop implementation.
• Change to wallet handling of mempool rejection.
• Low-level P2P changes. The optional new p2p message "feefilter" is implemented and the protocol version is bumped to 70015.
• Low-level RPC changes. Removed RPC commands: setgenerate, getgenerate. New RPC commands: generatetoaddress, importprunedfunds, removeprunedfunds, signmessagewithprivkey, getmempoolancestors, getmempooldescendants, getmempoolentry, createwitnessaddress, addwitnessaddress.
• Mining Code Changes. The mining code in 2.13.3 has been optimized to be significantly faster and use less memory. As part of these changes, consensus critical calculations are cached on a transaction's acceptance into the mempool and the mining code now relies on the consistency of the mempool to assemble blocks. However all blocks are still tested for validity after assembly.
• Other P2P Changes. The list of banned peers is now stored on disk rather than in memory. Restarting groestlcoind will no longer clear out the list of banned peers; instead a new RPC call (clearbanned) can be used to manually clear the list. The new setban RPC call can also be used to manually ban or unban a peer.
CSV, Segregated Witness and BIP65 Upgrade Information
The csv, segwit and BIP65 soft fork is fully backwards compatible with all Groestlcoin wallets, so you will continue to be able to safely send and receive groestlcoins whether or not csv, segwit and BIP65 is activated.
CSV, Segwit and BIP65 timeline:
• Signal: Miners will be able to signal that they are willing and able to enforce csv, segwit and BIP65 starting at the beginning of the first 2016 block retarget period on or after 21 January 2017 (UTC). In short signalling will start on block 1435392.
• Lock-in: Once 95% of blocks in a 2016 block long period have signaled that their miners are ready to enforce csv, segwit and BIP65 then csv, segwit and BIP65 will lock-in – meaning that unless the blockchain is rolled back at that point, csv, segwit and BIP65 will become active. In short Lock-in will be on block 1437408.
• Activate: After another 2016 block period, csv, segwit and BIP65 will activate, allowing miners to produce blocks containing csv, segwit and BIP65 transactions on Groestlcoin’s mainnet. In short Activate will be on block 1439424. When segwit is activated, transaction-producing software will be able to separate (segregate) transaction signatures (witnesses) from the part of the data in a transaction that is covered by the txid.Segwit benefits
1. Elimination of unwanted transaction malleability
Segregating the witness allows both existing and upgraded software to calculate the transaction identifier (txid) of transactions without referencing the witness, which can sometimes be changed by third-parties (such as miners) or by co-signers in a multisig spend. This solves all known cases of unwanted transaction malleability, which is a problem that makes programming Groestlcoin wallet software more difficult and which seriously complicates the design of smart contracts for Groestlcoin.
2. Capacity increase
Segwit transactions contain new fields that are not part of the data currently used to calculate the size of a block, which allows a block containing segwit transactions to hold more data than allowed by the current maximum block size. Estimates based on the transactions currently found in blocks indicate that if all wallets switch to using segwit, the network will be able to support about 70% more transactions. The network will also be able to support more of the advanced-style payments (such as multisig) than it can support now because of the different weighting given to different parts of a transaction after segwit activates (see the following section for details).
3. Weighting data based on how it affects node performance
Some parts of each Groestlcoin block need to be stored by nodes in order to validate future blocks; other parts of a block can be immediately forgotten (pruned) or used only for helping other nodes sync their copy of the block chain. One large part of the immediately prunable data are transaction signatures (witnesses), and segwit makes it possible to give a different "weight" to segregated witnesses to correspond with the lower demands they place on node resources. Specifically, each byte of a segregated witness is given a weight of 1, each other byte in a block is given a weight of 4, and the maximum allowed weight of a block is 4 million. Weighting the data this way better aligns the most profitable strategy for creating blocks with the long-term costs of block validation.
4. Signature covers value
A simple improvement in the way signatures are generated in segwit simplifies the design of secure signature generators (such as hardware wallets), reduces the amount of data the signature generator needs to download, and allows the signature generator to operate more quickly. This is made possible by having the generator sign the amount of bitcoins they think they are spending, and by having full nodes refuse to accept those signatures unless the amount of groestlcoins being spent is exactly the same as was signed. For non-segwit transactions, wallets instead had to download the complete previous transactions being spent for every payment they made, which could be a slow operation on hardware wallets and in other situations where bandwidth or computation speed was constrained.
5. Linear scaling of sighash operations
In 2015 a block in Bitcoin was produced that required about 25 seconds to validate on modern hardware because of the way transaction signature hashes are performed. Other similar blocks, or blocks that could take even longer to validate, can still be produced today. The problem that caused this can't be fixed in a soft fork without unwanted side-effects, but transactions that opt-in to using segwit will now use a different signature method that doesn't suffer from this problem and doesn't have any unwanted side-effects.
6. Increased security for multisig
Groestlcoin addresses (both P2PKH addresses that start with a 'F' and P2SH addresses that start with a '3') use a hash function known as RIPEMD-160. For P2PKH addresses, this provides about 160 bits of security---which is beyond what cryptographers believe can be broken today. But because P2SH is more flexible, only about 80 bits of security is provided per address. Although 80 bits is very strong security, it is within the realm of possibility that it can be broken by a powerful adversary. Segwit allows advanced transactions to use the Groestl hash function instead, which provides about 128 bits of security (that is 281 trillion times as much security as 80 bits and is equivalent to the maximum bits of security believed to be provided by Groestlcoin's choice of parameters for its Elliptic Curve Digital Security Algorithm [ECDSA].)
7. More efficient almost-full-node security
Satoshi Nakamoto's original Bitcoin paper describes a method for allowing newly-started full nodes to skip downloading and validating some data from historic blocks that are protected by large amounts of proof of work. Unfortunately, Nakamoto's method can't guarantee that a newly-started node using this method will produce an accurate copy of Groestlcoin's current ledger (called the UTXO set), making the node vulnerable to falling out of consensus with other nodes. Although the problems with Nakamoto's method can't be fixed in a soft fork, Segwit accomplishes something similar to his original proposal: it makes it possible for a node to optionally skip downloading some blockchain data (specifically, the segregated witnesses) while still ensuring that the node can build an accurate copy of the UTXO set for the block chain with the most proof of work. Segwit enables this capability at the consensus layer, but note that Groestlcoin Core does not provide an option to use this capability as of this 2.13.3 release.
8. Script versioning
Segwit makes it easy for future soft forks to allow Groestlcoin users to individually opt-in to almost any change in the Groestlcoin Script language when those users receive new transactions. Features currently being researched by Bitcoin Core contributors that may use this capability include support for Schnorr signatures, which can improve the privacy and efficiency of multisig transactions (or transactions with multiple inputs), and Merklized Abstract Syntax Trees (MAST), which can improve the privacy and efficiency of scripts with two or more conditions. Other Bitcoin community members are studying several other improvements that can be made using script versioning.
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 view your transaction on a third party blockexplorer (restart the client after entering the url of the blockexplorer) ?
4. Can you use the wallet with TOR?
5. Are you able to backup your wallet (wallet.dat) file?
6. Are you able to encrypt your wallet (wallet.dat) file?
7. Are you able to use watch-only function?
8. How long does it take to fully synchronize?
9. Are you able to sign/verify messages?
10. Are you able to see you send/receive addresses?
11. 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/issuesImportant:
• 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 network there is the possibility that we missed something. ALWAYS BACKUP YOUR GROESTLCOIN WALLET BEFORE UPGRADING.How to Upgrade?
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.
Mac: 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.0Linux users:
http://groestlcoin.org/forum/index.php?topic=97.0Download the Windows Wallet (64 bit) here:
https://github.com/Groestlcoin/groestlcoin/releases/download/v2.13.3/groestlcoin_x64.msiDownload the Windows Wallet (32 bit) here:
https://github.com/Groestlcoin/groestlcoin/releases/download/v2.13.3/groestlcoin_x86.msiDownload the MAC Wallet here:
https://github.com/Groestlcoin/groestlcoin/releases/download/v2.13.3/Groestlcoin-Qt.dmgSource code:
https://github.com/Groestlcoin/groestlcoinBuild instructions for Linux can be found here:
https://github.com/Groestlcoin/groestlcoin/blob/master/doc/build-unix.mdBuild instructions for OSX can be found here:
https://github.com/Groestlcoin/groestlcoin/blob/master/doc/build-osx.mdBuild instructions for Windows can be found here:
https://github.com/Groestlcoin/groestlcoin/blob/master/doc/build-windows.md
