Dear Groestlers, it goes without saying that 2020 has been a difficult time for millions of people worldwide. The groestlcoin team would like to take this opportunity to wish everyone our best to everyone coping with the direct and indirect effects of COVID-19. Let it bring out the best in us all and show that collectively, we can conquer anything. The centralised banks and our national governments are facing unprecedented times with interest rates worldwide dropping to record lows in places. Rest assured that this can only strengthen the fundamentals of all decentralised cryptocurrencies and the vision that was seeded with Satoshi's Bitcoin whitepaper over 10 years ago. Despite everything that has been thrown at us this year, the show must go on and the team will still progress and advance to continue the momentum that we have developed over the past 6 years. In addition to this, we'd like to remind you all that this is Groestlcoin's 6th Birthday release! In terms of price there have been some crazy highs and lows over the years (with highs of around $2.60 and lows of $0.000077!), but in terms of value– Groestlcoin just keeps getting more valuable! In these uncertain times, one thing remains clear – Groestlcoin will keep going and keep innovating regardless. On with what has been worked on and completed over the past few months.
UPDATED - Groestlcoin Core 2.18.2
This is a major release of Groestlcoin Core with many protocol level improvements and code optimizations, featuring the technical equivalent of Bitcoin v0.18.2 but with Groestlcoin-specific patches. On a general level, most of what is new is a new 'Groestlcoin-wallet' tool which is now distributed alongside Groestlcoin Core's other executables. NOTE: The 'Account' API has been removed from this version which was typically used in some tip bots. Please ensure you check the release notes from 2.17.2 for details on replacing this functionality.
Builds are now done through Gitian
Calls to getblocktemplate will fail if the segwit rule is not specified. Calling getblocktemplate without segwit specified is almost certainly a misconfiguration since doing so results in lower rewards for the miner. Failed calls will produce an error message describing how to enable the segwit rule.
A warning is printed if an unrecognized section name is used in the configuration file. Recognized sections are [test], [main], and [regtest].
Four new options are available for configuring the maximum number of messages that ZMQ will queue in memory (the "high water mark") before dropping additional messages. The default value is 1,000, the same as was used for previous releases.
The rpcallowip option can no longer be used to automatically listen on all network interfaces. Instead, the rpcbind parameter must be used to specify the IP addresses to listen on. Listening for RPC commands over a public network connection is insecure and should be disabled, so a warning is now printed if a user selects such a configuration. If you need to expose RPC in order to use a tool like Docker, ensure you only bind RPC to your localhost, e.g. docker run [...] -p 127.0.0.1:1441:1441 (this is an extra :1441 over the normal Docker port specification).
The rpcpassword option now causes a startup error if the password set in the configuration file contains a hash character (#), as it's ambiguous whether the hash character is meant for the password or as a comment.
The whitelistforcerelay option is used to relay transactions from whitelisted peers even when not accepted to the mempool. This option now defaults to being off, so that changes in policy and disconnect/ban behavior will not cause a node that is whitelisting another to be dropped by peers.
A new short about the JSON-RPC interface describes cases where the results of anRPC might contain inconsistencies between data sourced from differentsubsystems, such as wallet state and mempool state.
A new document introduces Groestlcoin Core's BIP174 interface, which is used to allow multiple programs to collaboratively work to create, sign, and broadcast new transactions. This is useful for offline (cold storage) wallets, multisig wallets, coinjoin implementations, and many other cases where two or more programs need to interact to generate a complete transaction.
The output script descriptor (https://github.com/groestlcoin/groestlcoin/blob/mastedoc/descriptors.md) documentation has been updated with information about new features in this still-developing language for describing the output scripts that a wallet or other program wants to receive notifications for, such as which addresses it wants to know received payments. The language is currently used in multiple new and updated RPCs described in these release notes and is expected to be adapted to other RPCs and to the underlying wallet structure.
A new --disable-bip70 option may be passed to ./configure to prevent Groestlcoin-Qt from being built with support for the BIP70 payment protocol or from linking libssl. As the payment protocol has exposed Groestlcoin Core to libssl vulnerabilities in the past, builders who don't need BIP70 support are encouraged to use this option to reduce their exposure to future vulnerabilities.
The minimum required version of Qt (when building the GUI) has been increased from 5.2 to 5.5.1 (the depends system provides 5.9.7)
getnodeaddresses returns peer addresses known to this node. It may be used to find nodes to connect to without using a DNS seeder.
listwalletdir returns a list of wallets in the wallet directory (either the default wallet directory or the directory configured bythe -walletdir parameter).
getrpcinfo returns runtime details of the RPC server. Currently, it returns an array of the currently active commands and how long they've been running.
deriveaddresses returns one or more addresses corresponding to an output descriptor.
getdescriptorinfo accepts a descriptor and returns information aboutit, including its computed checksum.
joinpsbts merges multiple distinct PSBTs into a single PSBT. The multiple PSBTs must have different inputs. The resulting PSBT will contain every input and output from all the PSBTs. Any signatures provided in any of the PSBTs will be dropped.
analyzepsbt examines a PSBT and provides information about what the PSBT contains and the next steps that need to be taken in order to complete the transaction. For each input of a PSBT, analyze psbt provides information about what information is missing for that input, including whether a UTXO needs to be provided, what pubkeys still need to be provided, which scripts need to be provided, and what signatures are still needed. Every input will also list which role is needed to complete that input, and analyzepsbt will also list the next role in general needed to complete the PSBT. analyzepsbt will also provide the estimated fee rate and estimated virtual size of the completed transaction if it has enough information to do so.
utxoupdatepsbt searches the set of Unspent Transaction Outputs (UTXOs) to find the outputs being spent by the partial transaction. PSBTs need to have the UTXOs being spent to be provided because the signing algorithm requires information from the UTXO being spent. For segwit inputs, only the UTXO itself is necessary. For non-segwit outputs, the entire previous transaction is needed so that signers can be sure that they are signing the correct thing. Unfortunately, because the UTXO set only contains UTXOs and not full transactions, utxoupdatepsbt will only add the UTXO for segwit inputs.
getpeerinfo now returns an additional minfeefilter field set to the peer's BIP133 fee filter. You can use this to detect that you have peers that are willing to accept transactions below the default minimum relay fee.
The mempool RPCs, such as getrawmempool with verbose=true, now return an additional "bip125-replaceable" value indicating whether thetransaction (or its unconfirmed ancestors) opts-in to asking nodes and miners to replace it with a higher-feerate transaction spending any of the same inputs.
settxfee previously silently ignored attempts to set the fee below the allowed minimums. It now prints a warning. The special value of"0" may still be used to request the minimum value.
getaddressinfo now provides an ischange field indicating whether the wallet used the address in a change output.
importmulti has been updated to support P2WSH, P2WPKH, P2SH-P2WPKH, and P2SH-P2WSH. Requests for P2WSH and P2SH-P2WSH accept an additional witnessscript parameter.
importmulti now returns an additional warnings field for each request with an array of strings explaining when fields are being ignored or are inconsistent, if there are any.
getaddressinfo now returns an additional solvable Boolean field when Groestlcoin Core knows enough about the address's scriptPubKey, optional redeemScript, and optional witnessScript for the wallet to be able to generate an unsigned input spending funds sent to that address.
The getaddressinfo, listunspent, and scantxoutset RPCs now return an additional desc field that contains an output descriptor containing all key paths and signing information for the address (except for the private key). The desc field is only returned for getaddressinfo and listunspent when the address is solvable.
importprivkey will preserve previously-set labels for addresses or public keys corresponding to the private key being imported. For example, if you imported a watch-only address with the label "coldwallet" in earlier releases of Groestlcoin Core, subsequently importing the private key would default to resetting the address's label to the default empty-string label (""). In this release, the previous label of "cold wallet" will be retained. If you optionally specify any label besides the default when calling importprivkey, the new label will be applied to the address.
getmininginfo now omits currentblockweight and currentblocktx when a block was never assembled via RPC on this node.
The getrawtransaction RPC & REST endpoints no longer check the unspent UTXO set for a transaction. The remaining behaviors are as follows:
If a blockhash is provided, check the corresponding block.
If no blockhash is provided, check the mempool.
If no blockhash is provided but txindex is enabled, also check txindex.
unloadwallet is now synchronous, meaning it will not return until the wallet is fully unloaded.
importmulti now supports importing of addresses from descriptors. A desc parameter can be provided instead of the "scriptPubKey" in are quest, as well as an optional range for ranged descriptors to specify the start and end of the range to import. Descriptors with key origin information imported through importmulti will have their key origin information stored in the wallet for use with creating PSBTs.
listunspent has been modified so that it also returns witnessScript, the witness script in the case of a P2WSH orP2SH-P2WSH output.
createwallet now has an optional blank argument that can be used to create a blank wallet. Blank wallets do not have any keys or HDseed. They cannot be opened in software older than 2.18.2. Once a blank wallet has a HD seed set (by using sethdseed) or private keys, scripts, addresses, and other watch only things have been imported, the wallet is no longer blank and can be opened in 2.17.2. Encrypting a blank wallet will also set a HD seed for it.
signrawtransaction is removed after being deprecated and hidden behind a special configuration option in version 2.17.2.
The 'account' API is removed after being deprecated in v2.17.2 The 'label' API was introduced in v2.17.2 as a replacement for accounts. See the release notes from v2.17.2 for a full description of the changes from the 'account' API to the 'label' API.
addwitnessaddress is removed after being deprecated in version 2.16.0.
generate is deprecated and will be fully removed in a subsequent major version. This RPC is only used for testing, but its implementation reached across multiple subsystems (wallet and mining), so it is being deprecated to simplify the wallet-node interface. Projects that are using generate for testing purposes should transition to using the generatetoaddress RPC, which does not require or use the wallet component. Calling generatetoaddress with an address returned by the getnewaddress RPC gives the same functionality as the old generate RPC. To continue using generate in this version, restart groestlcoind with the -deprecatedrpc=generate configuration option.
Be reminded that parts of the validateaddress command have been deprecated and moved to getaddressinfo. The following deprecated fields have moved to getaddressinfo: ismine, iswatchonly,script, hex, pubkeys, sigsrequired, pubkey, embedded,iscompressed, label, timestamp, hdkeypath, hdmasterkeyid.
The addresses field has been removed from the validateaddressand getaddressinfo RPC methods. This field was confusing since it referred to public keys using their P2PKH address. Clients should use the embedded.address field for P2SH or P2WSH wrapped addresses, and pubkeys for inspecting multisig participants.
A new /rest/blockhashbyheight/ endpoint is added for fetching the hash of the block in the current best blockchain based on its height (how many blocks it is after the Genesis Block).
A new Window menu is added alongside the existing File, Settings, and Help menus. Several items from the other menus that opened new windows have been moved to this new Window menu.
In the Send tab, the checkbox for "pay only the required fee" has been removed. Instead, the user can simply decrease the value in the Custom Fee rate field all the way down to the node's configured minimumrelay fee.
In the Overview tab, the watch-only balance will be the only balance shown if the wallet was created using the createwallet RPC and thedisable_private_keys parameter was set to true.
The launch-on-startup option is no longer available on macOS if compiled with macosx min version greater than 10.11 (useCXXFLAGS="-mmacosx-version-min=10.11" CFLAGS="-mmacosx-version-min=10.11" for setting the deployment sdkversion)
A new groestlcoin-wallet tool is now distributed alongside Groestlcoin Core's other executables. Without needing to use any RPCs, this tool can currently create a new wallet file or display some basic information about an existing wallet, such as whether the wallet is encrypted, whether it uses an HD seed, how many transactions it contains, and how many address book entries it has.
Since version 2.16.0, Groestlcoin Core's built-in wallet has defaulted to generating P2SH-wrapped segwit addresses when users want to receive payments. These addresses are backwards compatible with all widely used software. Starting with Groestlcoin Core 2.20.1 (expected about a year after 2.18.2), Groestlcoin Core will default to native segwitaddresses (bech32) that provide additional fee savings and other benefits. Currently, many wallets and services already support sending to bech32 addresses, and if the Groestlcoin Core project sees enough additional adoption, it will instead default to bech32 receiving addresses in Groestlcoin Core 2.19.1. P2SH-wrapped segwit addresses will continue to be provided if the user requests them in the GUI or by RPC, and anyone who doesn't want the update will be able to configure their default address type. (Similarly, pioneering users who want to change their default now may set the addresstype=bech32 configuration option in any Groestlcoin Core release from 2.16.0 up.)
BIP 61 reject messages are now deprecated. Reject messages have no use case on the P2P network and are only logged for debugging by most network nodes. Furthermore, they increase bandwidth and can be harmful for privacy and security. It has been possible to disable BIP 61 messages since v2.17.2 with the -enablebip61=0 option. BIP 61 messages will be disabled by default in a future version, before being removed entirely.
The submitblock RPC previously returned the reason a rejected block was invalid the first time it processed that block but returned a generic "duplicate" rejection message on subsequent occasions it processed the same block. It now always returns the fundamental reason for rejecting an invalid block and only returns "duplicate" for valid blocks it has already accepted.
A new submitheader RPC allows submitting block headers independently from their block. This is likely only useful for testing.
The signrawtransactionwithkey and signrawtransactionwithwallet RPCs have been modified so that they also optionally accept a witnessScript, the witness script in the case of a P2WSH orP2SH-P2WSH output. This is compatible with the change to listunspent.
For the walletprocesspsbt and walletcreatefundedpsbt RPCs, if thebip32derivs parameter is set to true but the key metadata for a public key has not been updated yet, then that key will have a derivation path as if it were just an independent key (i.e. no derivation path and its master fingerprint is itself).
The -usehd configuration option was removed in version 2.16.0 From that version onwards, all new wallets created are hierarchical deterministic wallets. This release makes specifying -usehd an invalid configuration option.
This release allows peers that your node automatically disconnected for misbehaviour (e.g. sending invalid data) to reconnect to your node if you have unused incoming connection slots. If your slots fill up, a misbehaving node will be disconnected to make room for nodes without a history of problems (unless the misbehaving node helps your node in some other way, such as by connecting to a part of the Internet from which you don't have many other peers). Previously, Groestlcoin Core banned the IP addresses of misbehaving peers for a period (default of 1 day); this was easily circumvented by attackers with multiple IP addresses. If you manually ban a peer, such as by using the setban RPC, all connections from that peer will still be rejected.
The key metadata will need to be upgraded the first time that the HDseed is available. For unencrypted wallets this will occur on wallet loading. For encrypted wallets this will occur the first time the wallet is unlocked.
Newly encrypted wallets will no longer require restarting the software. Instead such wallets will be completely unloaded and reloaded to achieve the same effect.
A sub-project of Bitcoin Core now provides Hardware Wallet Interaction (HWI) scripts that allow command-line users to use several popular hardware key management devices with Groestlcoin Core. See their project page for details.
This release changes the Random Number Generator (RNG) used from OpenSSL to Groestlcoin Core's own implementation, although entropy gathered by Groestlcoin Core is fed out to OpenSSL and then read back in when the program needs strong randomness. This moves Groestlcoin Core a little closer to no longer needing to depend on OpenSSL, a dependency that has caused security issues in the past. The new implementation gathers entropy from multiple sources, including from hardware supporting the rdseed CPU instruction.
On macOS, Groestlcoin Core now opts out of application CPU throttling ("app nap") during initial blockchain download, when catching up from over 100 blocks behind the current chain tip, or when reindexing chain data. This helps prevent these operations from taking an excessively long time because the operating system is attempting to conserve power.
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. 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 http://groestlcoin.org/forum/index.php?topic=441.0
ALL NEW - Groestlcoin Moonshine iOS/Android Wallet
Built with React Native, Moonshine utilizes Electrum-GRS's JSON-RPC methods to interact with the Groestlcoin network. GRS Moonshine's intended use is as a hot wallet. Meaning, your keys are only as safe as the device you install this wallet on. As with any hot wallet, please ensure that you keep only a small, responsible amount of Groestlcoin on it at any given time.
Groestlcoin Mainnet & Testnet supported
Multiple wallet support
Electrum - Support for both random and custom peers
Biometric + Pin authentication
Custom fee selection
Import mnemonic phrases via manual entry or scanning
BIP39 Passphrase functionality
Support for Segwit-compatible & legacy addresses in settings
Support individual private key sweeping
UTXO blacklisting - Accessible via the Transaction Detail view, this allows users to blacklist any utxo that they do not wish to include in their list of available utxo's when sending transactions. Blacklisting a utxo excludes its amount from the wallet's total balance.
Ability to Sign & Verify Messages
Support BitID for password-free authentication
Coin Control - This can be accessed from the Send Transaction view and basically allows users to select from a list of available UTXO's to include in their transaction.
HODL GRS connects directly to the Groestlcoin network using SPV mode and doesn't rely on servers that can be hacked or disabled. HODL GRS utilizes AES hardware encryption, app sandboxing, and the latest security features to protect users from malware, browser security holes, and even physical theft. Private keys are stored only in the secure enclave of the user's phone, inaccessible to anyone other than the user. Simplicity and ease-of-use is the core design principle of HODL GRS. A simple recovery phrase (which we call a Backup Recovery Key) is all that is needed to restore the user's wallet if they ever lose or replace their device. HODL GRS is deterministic, which means the user's balance and transaction history can be recovered just from the backup recovery key.
Simplified payment verification for fast mobile performance
Groestlcoin Seed Savior is a tool for recovering BIP39 seed phrases. This tool is meant to help users with recovering a slightly incorrect Groestlcoin mnemonic phrase (AKA backup or seed). You can enter an existing BIP39 mnemonic and get derived addresses in various formats. To find out if one of the suggested addresses is the right one, you can click on the suggested address to check the address' transaction history on a block explorer.
If a word is wrong, the tool will try to suggest the closest option.
If a word is missing or unknown, please type "?" instead and the tool will find all relevant options.
NOTE: NVidia GPU or any CPU only. AMD graphics cards will not work with this address generator. VanitySearch is a command-line Segwit-capable vanity Groestlcoin address generator. Add unique flair when you tell people to send Groestlcoin. Alternatively, VanitySearch can be used to generate random addresses offline. If you're tired of the random, cryptic addresses generated by regular groestlcoin clients, then VanitySearch is the right choice for you to create a more personalized address. VanitySearch is a groestlcoin address prefix finder. If you want to generate safe private keys, use the -s option to enter your passphrase which will be used for generating a base key as for BIP38 standard (VanitySearch.exe -s "My PassPhrase" FXPref). You can also use VanitySearch.exe -ps "My PassPhrase" which will add a crypto secure seed to your passphrase. VanitySearch may not compute a good grid size for your GPU, so try different values using -g option in order to get the best performances. If you want to use GPUs and CPUs together, you may have best performances by keeping one CPU core for handling GPU(s)/CPU exchanges (use -t option to set the number of CPU threads).
Fixed size arithmetic
Fast Modular Inversion (Delayed Right Shift 62 bits)
SecpK1 Fast modular multiplication (2 steps folding 512bits to 256bits using 64 bits digits)
Use some properties of elliptic curve to generate more keys
SSE Secure Hash Algorithm SHA256 and RIPEMD160 (CPU)
Groestlcoin EasyVanity 2020 is a windows app built from the ground-up and makes it easier than ever before to create your very own bespoke bech32 address(es) when whilst not connected to the internet. If you're tired of the random, cryptic bech32 addresses generated by regular Groestlcoin clients, then Groestlcoin EasyVanity2020 is the right choice for you to create a more personalised bech32 address. This 2020 version uses the new VanitySearch to generate not only legacy addresses (F prefix) but also Bech32 addresses (grs1 prefix).
Ability to continue finding keys after first one is found
Includes warning on start-up if connected to the internet
Ability to output keys to a text file (And shows button to open that directory)
Show and hide the private key with a simple toggle switch
Show full output of commands
Ability to choose between Processor (CPU) and Graphics Card (GPU) ( NVidia ONLY! )
Features both a Light and Dark Material Design-Style Themes
Free software - MIT. Anyone can audit the code.
Written in C# - The code is short, and easy to review.
Groestlcoin WPF is an alternative full node client with optional lightweight 'thin-client' mode based on WPF. Windows Presentation Foundation (WPF) is one of Microsoft's latest approaches to a GUI framework, used with the .NET framework. Its main advantages over the original Groestlcoin client include support for exporting blockchain.dat and including a lite wallet mode. This wallet was previously deprecated but has been brought back to life with modern standards.
Works via TOR or SOCKS5 proxy
Can use bootstrap.dat format as blockchain database
Import/Export blockchain to/from bootstrap.dat
Import wallet.dat from Groestlcoin-qt wallet
Export wallet to wallet.dat
Use both groestlcoin-wpf and groestlcoin-qt with the same addresses in parallel. When you send money from one program, the transaction will automatically be visible on the other wallet.
Rescan blockchain with a simple mouse click
Works as a full node and listens to port 1331 (listening port can be changed)
Fast Block verifying, parallel processing on multi-core CPUs
Mine Groestlcoins with your CPU by a simple mouse click
All private keys are kept encrypted on your local machine (or on a USB stick)
Lite - Has a lightweight "thin client" mode which does not require a new user to download the entire Groestlcoin chain and store it
Free and decentralised - Open Source under GNU license
Fixed Import/Export to wallet.dat
Rescan wallet option
Change wallet password option
Address type and Change type options through *.conf file
Import from bootstrap.dat - It is a flat, binary file containing Groestlcoin blockchain data, from the genesis block through a recent height. All versions automatically validate and import the file "grs.bootstrap.dat" in the GRS directory. Grs.bootstrap.dat is compatible with Qt wallet. GroestlCoin-Qt can load from it.
In Full mode file %APPDATA%\Groestlcoin-WPF\GRS\GRS.bootstrap.dat is full blockchain in standard bootstrap.dat format and can be used with other clients.
Groestlcoin Electrum Personal Server aims to make using Electrum Groestlcoin wallet more secure and more private. It makes it easy to connect your Electrum-GRS wallet to your own full node. It is an implementation of the Electrum-grs server protocol which fulfils the specific need of using the Electrum-grs wallet backed by a full node, but without the heavyweight server backend, for a single user. It allows the user to benefit from all Groestlcoin Core's resource-saving features like pruning, blocks only and disabled txindex. All Electrum-GRS's feature-richness like hardware wallet integration, multi-signature wallets, offline signing, seed recovery phrases, coin control and so on can still be used, but connected only to the user's own full node. Full node wallets are important in Groestlcoin because they are a big part of what makes the system be trust-less. No longer do people have to trust a financial institution like a bank or PayPal, they can run software on their own computers. If Groestlcoin is digital gold, then a full node wallet is your own personal goldsmith who checks for you that received payments are genuine. Full node wallets are also important for privacy. Using Electrum-GRS under default configuration requires it to send (hashes of) all your Groestlcoin addresses to some server. That server can then easily spy on your transactions. Full node wallets like Groestlcoin Electrum Personal Server would download the entire blockchain and scan it for the user's own addresses, and therefore don't reveal to anyone else which Groestlcoin addresses they are interested in. Groestlcoin Electrum Personal Server can also broadcast transactions through Tor which improves privacy by resisting traffic analysis for broadcasted transactions which can link the IP address of the user to the transaction. If enabled this would happen transparently whenever the user simply clicks "Send" on a transaction in Electrum-grs wallet. Note: Currently Groestlcoin Electrum Personal Server can only accept one connection at a time.
Use your own node
Uses less CPU and RAM than ElectrumX
Used intermittently rather than needing to be always-on
Doesn't require an index of every Groestlcoin address ever used like on ElectrumX
UPDATED – Android Wallet 7.38.1 - Main Net + Test Net
The app allows you to send and receive Groestlcoin on your device using QR codes and URI links. When using this app, please back up your wallet and email them to yourself! This will save your wallet in a password protected file. Then your coins can be retrieved even if you lose your phone.
Add confidence messages, helping users to understand the confidence state of their payments.
Handle edge case when restoring via an external app.
Count devices with a memory class of 128 MB as low ram.
Introduce dark mode on Android 10 devices.
Reduce memory usage of PIN-protected wallets.
Tapping on the app's version will reveal a checksum of the APK that was installed.
Fix issue with confirmation of transactions that empty your wallet.
Groestlcoin Sentinel is a great solution for anyone who wants the convenience and utility of a hot wallet for receiving payments directly into their cold storage (or hardware wallets). Sentinel accepts XPUB's, YPUB'S, ZPUB's and individual Groestlcoin address. Once added you will be able to view balances, view transactions, and (in the case of XPUB's, YPUB's and ZPUB's) deterministically generate addresses for that wallet. Groestlcoin Sentinel is a fork of Groestlcoin Samourai Wallet with all spending and transaction building code removed.
UPDATE: VTC mining on Easymine back to normal, payouts have resumed. Zero fees for the rest of the month. Here's a more detailed response to https://old.reddit.com/vertcoin/comments/96z77t/psa_easy_mine_problem/ - bear with me and put on your nerd hat for a few mins. The stratum server for all EasyMine pools is node-merged-pool - a merge mining fork of node-stratum-pool. See my repo here @ https://github.com/nzsquirrell/node-merged-pool This is what miners connect to for work and to submit valid shares on the search for blocks. The information that is exchanged in hex digits, and the data coming back from the miner includes the time, the job, ExtraNonce2 and nonce (see https://en.bitcoin.it/wiki/Stratum_mining_protocol#mining.submit). All of these fields are used to notify the server of valid work exceeding a specific difficulty. Hex digits are not case-sensitive. So 'FF00AA11' is the same as 'ff00aa11'. Both equate to decimal 4278233617. So for the purposes of construction a block header, it doesn't matter if the hex digits are uppercase, lowercase, or a mixture of both - it all works out the same, and produces the same hash. Hold this thought. The stratum server knows what shares each miner has submitted, it keeps a track of all of the data in an array. It checks every time that work is submitted that the same work hasn't been submitted before whilst searching for the next block. If it was submitted, then the new submission is rejected as duplicate work. Now, where this has all gone wrong is that the way the data is stored in this array was a string containing the four fields mentioned above. Strings are case-sensitive and when making comparisons 'FF00AA11' != 'ff00aa11', as well as 'ff00aA11' and 'ff00AA11' and so on.... This allowed our attacker to submit the same work many many times, altering only the case of the hex digits (he was doing it to the nonce, but the other fields are also susceptible to the attack), so the logic to check for duplicate work wasn't firing, the shares were valid (as they produced a valid hash above difficulty), and our attacker was faking most of his hash-rate. A lot. A shit-ton of it. I have fixed this in my fork of node-stratum-pool - the fix is very easy, we just make all the characters lower case before testing for duplicate shares. See https://github.com/nzsquirrell/node-merged-pool/commit/9d068535d042516835f565a859852c7cf715da98 for my fix. My big concern is that the other forks I've seen for node-stratum-pool are susceptible to the attack, and quite possibly other pool software is toopossibly even p2pool? I've not looked. If someone can check and let me know and I'll update this. p2pool has been confirmed as resilient to this type of attack. So, Who-The-F&*k did this. This is what I have so far: He's used the following VTC and NIX addresses:
I've seen connections coming in from the following IP addresses:
He is still attacking EasyMine, but it's not having any effect now. Actually the server keeps banning him now as it's detecting that he's submitting too many invalid shares. Take that. The path forward I have a big mess to clean up, he's made off with about 652 VTC and about 3576 NIX, essentially stolen from you miners. I will see what I can do to recover some of this (not all of it has been paid to him yet), but there is going to be a substantial shortfall. Mr Attacker, feel free to PM me and we can arrange a settlement :) Payouts on both the VTC & NIX pools are suspended until i can clean this up, I hope this won't take more than a couple of days. Thanks.
In a few days segwit is activating so every mining pool needs to upgrade. This also applies to P2Pool. With P2Pool though being a decentralized mining protocol this is more complex than simply updating your mining software as P2Pool forms its own blockchain, the "sharechain", which is used to track payouts to miners. Any change to how P2Pool works which affects the validity of each share, as is the case with any upgrade to the chain being mined i.e. Bitcoin, requires coordination from the majority of P2Pool miners. Last year I posted a pull request to the main P2Pool repository with a patch to enable segwit compatibility. After testing on my part the patch was included in the Vertcoin P2Pool and has been working with great success making P2Pool among the largest Vertcoin pools. In fact after P2Pool's rise in popularity a second P2Pool network was introduced for smaller miners. Meanwhile big block populist Jonathan Toomim (jtoomim) has made a P2Pool fork and increased the share size limit from 50 kB per 30 seconds to 1 MB. While an increase was reasonable and in fact I included one in the segwit patch (to 100 kB) before him the excessive increase on jtoomim's fork is compatible with the BU vision campaigned by him and contradicts the decentralized nature of P2Pool. Now jtoomim has merged my segwit patch and made it a requirement [edit: albeit it can be manually overriden] to use btc1 (segwit2x) misleading users that his fork is a segwit upgrade.
I've got 15 minutes spare at lunch, so this is going to be very quick and quite rough: PoW change: We're intending to stick with Scrypt mining through to the 600k block at least, because we want miners to have confidence in investing in hardware. No plans past then, but it's more negotiable at least. Really not moving to X11; it's eleven random algorithms glued together, 5 of them with ASIC implementations already, and all 11 have FPGA implementations, it would be a highly costly move that is likely to give us much worse problems than those we face now, when X11 ASICs hit. Merged mining: There was an informal community poll, it went poorly. Needs p2pool as a pre-requisite, or all that happens is we add in functionality no-one actually uses. It's been pointed out that p2pool only really makes sense for significant miners (low powered miners are unlikely to get payouts), but for those who can use p2pool, please consider doing so. PoS: Still under consideration long term, but we'd much rather see the price stabilise high enough that we can sustain PoW, than incur the risk of moving. Also security concerns stemming from PoS meaning that coins have to be kept in hot wallets (as opposed to in paper wallets or similar. I'd hope it's clear why we have security concerns in light of issues such as DogeVault (no, I haven't heard anything more in weeks either). PoSV/PoT: Keeping an eye on them Generally, the developers are focusing on integrating Bitcoin client improvements, and we're now taking a clear lead on this compared to other altcoins. You can see this clearly reflected in the source code metrics on Coin Gecko, where did I mention we're the 2nd highest coin. Reference client 1.7.2 is progressing nicely and will be another non-required update. We have a number of developers working actively on the code, and an in-depth cross-checking process to ensure the results are of the high quality and stability you would expect from software dealing with $31mil of digital assets. We're working on making a rock solid platform for a currency, not a get rich quick scheme, and I hope you can appreciate this takes time. Also Twitch is coming.
[Serious, long] My thoughts on what next for Dogecoin
There’s been a lot of discussion in recent days about the decreasing price of Dogecoin, as well as the risk of a 51% attack from Wafflepool or similar. I wanted to do a wrap-up of the discussions happening amongst the developers of the last few weeks, partly to illustrate that we are looking at options, but mostly to talk about what is happening. Please note that this is all rapidly changing. Dogecoin is actually moving at breakneck speed for a project of its size, especially as we still have a relatively limited core team. This is part of why we don’t write posts very often, as they become out of date so quickly as new arguments and facts are presented. Lets talk about 51% attacks first. The theory is that if anyone has over 51% of the total hashing power of the network, they can form a blockchain of their own which is considered “more valid” than the blockchain most users are on. This is because cryptocurrency blockchains are secured through proof of work, and therefore more work on a chain makes it, in essence, more valid. This risks an attacker spending coins on one chain, then releasing their own private, longer, blockchain. That latter blockchain replaces the original blockchain, and the coins they spent on the original blockchain are effectively returned to them as if the transactions never happened. It’s important to understand this because I hear suggestions that Wafflepool shouldn’t accept over 51% of the network hashrate, and unfortunately all this would do is hide the risk. Having one pool own over 51% of the network hashrate is not a problem if it’s actually being used to mine, but instead if it’s used to create a personal blockchain. The other issue raised is one of price; we’ve been steadily dropping since around early February. The core of my answers here is that you need to consider demand vs supply. What happened back in February was that we saw a surge in demand beyond sustainable levels, likely in a form of tulip mania. As supply continued (mining), and demand dropped-off, our price has dropped. This has been worsened by a succession of bad news affecting Bitcoin (MtGox and other exchanges struggling, uncertainty of China and Russia, etc.), which both directly brings down our price, as well as undermining confidence in the entire cryptocurrency ecosystem. It has been suggested (and I can believe this, but have not done my own analysis) that as multipools continue to dominate Dogecoin mining, and they tend to sell coins directly, that they are further reducing the price. Specifically, given that while there is demand for further coins from miners, as they have already expended resources on mining hardware they cannot then purchase the cheap coins the mining pools are producing. Lastly, there’s the question of ASICs; these are specialised mining devices which are significantly faster than CPU/GPU mining hardware, and typically cheaper to run due to reduced power and space requirements. Their introduction into mining at the moment leaves vastly disproportionate mining power in the hands of a few (there’s one individual with a hashrate of around 20GH/s, for example), and in time is likely to make mining on commodity hardware infeasible. We’ve had a lot of suggestions for what to do; change proof of work algorithm, add multiple proof of work algorithms, move to proof of stake, merge-mine with Litecoin, have DigiShield merge-mine with us. We’ve considered everything, and then some; I’m not sure how much discussion has happened in total, but I’ve spent over a dozen hours looking at these issues on IRC. In virtually all cases, the majority of people with the skills to implement these changes have rejected them as too high risk and/or having other significant drawbacks. In summary:
Changing proof of work introduces a number of risks; potential for a bug in the change to cause serious consequences (see recent the issue withCleanWaterCoin for examples),that we don’t manage to get a majority updated before fork and end up effectively 51% attacking our own blockchain (not to mention that at least one exchange frequently misses these updates and causes problems as a result), that the algorithm itself has problems (see the long term issues of multipools managing to exploit “random” block rewards), or we simply lose users/merchants who are fed up constantly updating software.
As a less technical concern; personally I’m uncomfortable knowingly make changes which intentionally introduce unneeded inefficiencies, which mean consumption of vastly more resources (electricity, and by proxy fossil/nuclear fuels). I imagine I’ll be swamped by shibes running geothermal mining facilities at the end of this post…
Changing to proof of stake (and this is particularly relevant in context of my previous comment) is interesting, however right now I don’t feel I personally know enough to make a judgement on how to make the jump safely and efficiently. Statistician/economist shibes, I’d love to hear more from you.
While I don’t like the idea of changing proof of work, I’m also pragmatic about these things; I am trying to find time to read up on Myriadcoin‘s multiple-PoW support, and in particular considering whether it could be hooked into the code without necessarily enabling it right now, as a harness for potential future changes.
Merged mining with Litecoin (and thanks to Charlie Lee for the invitation, of course) would likely help us mitigate 51% attack risks, by merging our mining power together, however it would introduce what have so far been considered undue issues for our mining community. Specifically, merged mining would require significant changes to mining infrastructure, adopting either p2pool or a mining proxy. Many have raised concerns that LTC miners would simply dump DOGE; personally I believe we could have an LTC/DOGE swap doing in the p2pool layer to give each miner whichever coin they prefer, to mitigate this, so this is not a risk I consider a major issue. There are also concerns that we would always be the secondary coin to LTC; personally I’d have considered a pre-defined block at which we de-merge a requirement, but again this isn’t a route we’re taking, I am just going through the evaluation I have done for reference.
Having smaller coins merge with us is interesting, however given our size in proportion to those coins, and that they are likely to be reluctant to merge with us (as we are reluctant to merge with Litecoin), I’m not expecting to see much progress in this area. We have made the invitation to DigiByte however.
The best suggestion we have so far is to out-do the multipools directly, by working on open source multipool software which is more DOGE-friendly. As I understand it two key approaches are being considered for improving DOGE-friendliness; either by directly exchanging other coins to DOGE, or through improved trading algorithms which result in less sharp shocks to the price. For very large mining farms such as SFire’s, it’s hoped this will cause them to separate from the mining pools (which they pay fees to) and go solo. This reduces fees for the miner, as well as reducing the ability for DDoS attacks to be targeted at them, and for us it reduces risk of a 51% attack, improves confidence in the coin security, and enables us to better mitigate impact of people mining huge quantities to sell. Meanwhile, the main focus is on making Dogecoin (and cryptocurrencies in general) a viable way of moving value around. The 1.7 client (beta release is imminent, and in fact if you’re comfortable compiling it yourself, the code is available from https://github.com/dogecoin/dogecoin/tree/v1.7.0-Beta-1 ) is a major re-write of Dogecoin Core to base it on the Bitcoin Core 0.9 client (with Scrypt added in, of course). This gives us significant performance improvements, as well as a better underlying architecture. To repeat; this will not be a required update, although it will be strongly encouraged as it’s a huge leap forward technologically. One of the features which is currently not working in 1.7, but will be for release, is the Bitcoin payment protocol, which massively improves the payment request/receiving process for merchants. Fundamentally 1.7 is intended to prove we have the technical skills to maintain a stable, useful coin, and help drive/support adoption. Once 1.7 is done, my immediate priority is technical documentation; we have a security specialist currently working on a guide to cryptocurrency security (setup, risks, best practices, etc.), to help give merchants and exchanges an in-depth understanding of how to securely use cryptocurrency. I’ll be addressing the need for formal standards in Dogecoin, and preparing RFCs for the “dogecoin:” URI and relay network protocol for submission to the IETF (and IANA for the URI). Lastly; there was a post recently about the need for multi-signature addresses; I’d like to add my own “hell yes!” to that, although obviously I have to prioritise. If anyone else can look at these, that would be fantastic. For anyone wanting a more permanent link, there's a copy of this on my blog ( http://jrn.me.uk/wp/what-next-for-dogecoin-mid-april-2014/ ), however posting as full text here as probably easier for most people, and I'm not sure my server would survive a reddit hug! Edit: It's been pointed out that there's no verification of the problems with Blackcoin, and the source alleging problems has a serious credibility issue. Have removed the reference now.
Sorry everyone, this one’s going to be very serious again, and I'm going to start with administrivia. First of all, a few people have mistake me for lead developer recently; I'm not, I'm just the one that’s more vocal and therefore gets attention. langer_hans is lead developer, and has been working on the coin much longer than I have. Quick reminders of a couple of things; for new shibes getting started with the main client, you can download a blockchain bootstrap file which helps you get going faster. So Chain is hosting instructions, and copies of the bootstrap.dat are hosted by themselves and Moolah (see links on that page). We've also seen a few people asking about the 1.7 release; yes it’s out, no you don’t have to upgrade, but it does seem a lot faster to us, so we would encourage upgrading. Also there is a mailing list for announcements of upcoming client releases at https://lists.sourceforge.net/lists/listinfo/dogecoin-releases which I would recommend subscribing to. So, yesterday lleti asked about an idea to see if there was community support for it. A developer asking does not mean something is going to be done. Even if it was done, it does not mean you have to follow (I’ll talk about that in a moment). Feedback to date has been overwhelmingly negative, though, so consider the idea abandoned. A few people asked have why the idea was suggested; the intent would be to remove sharp shocks from the mining schedule, and spread it over a longer period of time in order to give adoption of Dogecoin a chance to catch up. One thing I'm not sure was clear was that there was consideration of changing block time to reduce the resulting inflation. As said, we’re not seeing community support for it. Talking of adoption; /dogecoin has just ticked over 87,000 subscribers. Some Dogecoin users don’t read the subreddit, some subreddit readers don’t use the coin, but lets use that as an estimate for user base. That’s huge for a coin that’s 6 months old, and tiny in terms of an Internet service. And it’s worth remembering Bitcoin is 5 years old, Litecoin 2 years. Peercoin, almost 2 years. That’s the coins we’re in the midst of right now. The developers are cautious of making big technical changes because we want to stabilise the coin so the more cautious companies can know the coin is rock solid, and encourage them to get involved. So, everyone’s been all about the price this week, and while I hate talking price with you guys, I need to as background on a lot of other stuff. So, the DOGE/BTC price is down, yes. DOGE/USD also a bit, but much less. DOGE/DOGE still solid, though. We’re Dogecoin, though, the price shouldn't matter… well, agreed, but it’s worrying people, and in particular there’s a lot of people worrying the price drops will lead to a 51% attack. So lets talk about 51% attacks, and lets also talk forks. A 51% attack is where someone gains control of over 50% of the hashrate of the network, and maliciously uses that hashrate to make their own private blockchain which grows faster than the default blockchain. The malicious part is really important here; it’s an attack, not something that happens accidentally. In doing this, they can spend money on the current blockchain, then release their private blockchain. The network sees the longer blockchain and moves to it as part of the fork handling code (note the fork, it’s important). This effectively reverses the spending of Dogecoin that they’ve done. Note that this is only really an attack on exchanges, as the attacker has to get their Dogecoin into another form (i.e. Bitcoin) before the transaction reverses, or the whole thing has no effect. So far, no exchange has communicated any serious concern about a 51% attack on Dogecoin to myself, and I am unaware of them having done so to any other developer. The concern over price is raised because as Dogecoin rewards per block diminish over time (which they continue to do for the next 6 months or so), the payments to miners become less valuable (in USD/BTC terms) unless the price goes up. Many of our miners are here to support the coin (with thanks to /DogecoinDefenseForce), but some are just here for the money, and people worry that losing them will make it easy to 51% attack the coin. So how does one a get enough mining power to 51% attack a coin? I mean, our hashrate is in the 40-50GH/s range, how do you get 51% of that (or more, if it’s a group not currently mining us)? Well, a hacked mining pool is the main scenario that worries people; it’s considered unlikely any mining pool would decide to attack their own funding source (and the big pools are making big money through entirely legal means). When Bitcoin had the same problem back in January, there was a major push to adopt what is called p2pool, which is a distributed alternative to conventional mining pools. There’s been a few issues with p2pool and Dogecoin which is part of why it’s not more widely used, but I’d really like to see more people looking at it, and talk to the developers about what (if anything) it needs for wider adoption. Ideally I’d like to get all new miners picking up p2pool, so if anyone wants to help with tutorials that would be awesome. A number of other ideas (apart from p2pool adoption) have been proposed; change proof of work, change to proof of stake now, change to proof of stake later, merged mining, multi-protocol mining… all of these have something in common, they require that we fork the coin. Now, a deliberate planned and controlled fork is quite different to a 51% attack fork, but that does not mean that it’s risk free. One scenario would be a disagreement with the developers over path the coin is taking (as we’re seeing with the tapering suggestion), and the community not updating, leaving the developers on their own very small fork. Other scenarios could include significant numbers of exchanges stuck on the wrong “prong” of the fork for an extended period of time. We've had at least one exchange get “stuck” for days or weeks on every fork so far, causing significant confusion and distress to those trying to send coins to or receive coins from the exchange. Same for merchants, who might report not receiving coins if they or the sender are on different forks. Although unlikely, it’s also possible that the fork would introduce a serious bug. There are a number of coins which have been PoW at launch and intended to move to PoS shortly afterwards, and failed to actually switch. Certainly any such change is not without its risks. Lastly, on a personal note, I'm going to be focusing primarily on co-ordination and communication from here on in, rather than working on the code base directly. I’d like to give a shout-out to our many other developers, there are far too many people now involved to name them all, but langer_hans as lead developer, leofidus-ger, patricklodder have all worked extensively on the 1.7 client. Go give them a hug! If any of the community want to get involved with development, please do swing by #dogecoin-dev on IRC Freenode and we can help get you started.
The Hardfork that Bitcoin REALLY Needs! (Not blocksize related)
We’re all witnessing an extreme amount of new hashing power increasing the difficulty to heights never seen before. This might seem like a good thing, more hashing power securing the Bitcoin network… But wait, have a look at the hashrate distribution: https://www.blocktrail.com/BTC/pools There are a total of 5 GIANT pools controlling ~82% of the TOTAL hashrate and increasing. I miss the times when people were running ASICs of their own and mining was truly decentralized. Right now, there is an unintentional incentive for miners to centralize. This has to change if Bitcoin is to become the solid foundation securing not only transactions on its own blockchain, but every layer that’s going to be relying on Bitcoin in the future (merged-mined sidechains, DNS-records, smart contracts and paymentchannels etc). The proposal to eliminate the unintentional incentive to centralize mining is to integrate a P2Pool fashioned mining protocol that would distribute the block reward to both big and small miners giving each their fair share. This solution would benefit EVERYONE in the Bitcoin community EXCEPT for the 5 biggest mining pools as they would have to share some of their reward with smaller miners. This has been thought of as a major roadblock to integrating this change because the biggest miners won’t mine on the new version because it’s giving them less reward. This topic has been suggested before but it never gained any traction due to the issue raised above. But in fact this is not really an issue. Imagine if the update was rolled with the consensus of the entire community except for the few biggest miners refusing to adopt it and still stubbornly mining on the old version. Their so beloved block reward would be worthless and they’d be forced to update. This is exactly the same reason why miners don’t create more than 25 new bitcoins per block even if they wanted to do so. Because they know that the rest of the Bitcoin community would consider their blocks worthless, that’s why they obey the rules of consensus. tl;dr
There is an unintentional incentive for centralized mining.
Fix it by hardforking a P2Pool fashioned mining protocol.
This would benefit the entire Bitcoin community except for the few biggest mining pools.
If the few biggest mining pools refuse to upgrade, their reward would be useless anyway.
Anyone who has an old dusty ASIC lying around, plug it in and mine away because it will be profitable again!
Abstract Merged mining refers to the concept of mining more than one cryptocurrency without necessitating additional proof-of-work effort. Merged mining was introduced in 2011 as a boostrapping mechanism for new cryptocurrencies and countermeasures against the fragmentation of mining power across competing systems. Although merged mining has already been adopted by a number of cryptocurrencies, to this date little is known about the effects and implications. In this thesis, we shed light on this topic area by performing a comprehensive analysis of merged mining in practice. As part of this analysis, we present a block attribution scheme for mining pools to assist in the evaluation of mining centralization. Our findings disclose that mining pools in merge-mined cryptocurrencies have operated at the edge of, and even beyond, the security guarantees offered by the underlying Nakamoto consensus for extended periods. We discuss the implications and security considerations for these cryptocurrencies and the mining ecosystem as a whole, and link our findings to the intended effects of merged mining. Bibliography  Coinmarketcap. http://coinmarketcap.com/. Accessed 2017-09-28.  P2pool. http://p2pool.org/. Accessed: 2017-05-10.  M. Ali, J. Nelson, R. Shea, and M. J. Freedman. Blockstack: Design and implementation of a global naming system with blockchains. http://www.the-blockchain.com/docs/BlockstackDesignandImplementationofaGlobalNamingSystem.pdf, 2016. Accessed: 2016-03-29.  G. Andersen. Comment in "faster blocks vs bigger blocks". https://bitcointalk.org/index.php?topic=673415.msg7658481#msg7658481, 2014. Accessed: 2017-05-10.  G. Andersen. [bitcoin-dev] weak block thoughts... https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Septembe011157.html, 2015. Accessed: 2017-05-10.  L. Anderson, R. Holz, A. Ponomarev, P. Rimba, and I. Weber. New kids on the block: an analysis of modern blockchains. http://arxiv.org/pdf/1606.06530.pdf, 2016. Accessed: 2016-07-04.  E. Androulaki, S. Capkun, and G. O. Karame. Two bitcoins at the price of one? double-spending attacks on fast payments in bitcoin. In CCS, 2012.  A. Back, M. Corallo, L. Dashjr, M. Friedenbach, G. Maxwell, A. Miller, A. Poelstra, J. Timón, and P. Wuille. Enabling blockchain innovations with pegged sidechains. http://newspaper23.com/ripped/2014/11/http-_____-___-_www___-blockstream___-com__-_sidechains.pdf, 2014. Accessed: 2017-09-28.  A. Back et al. Hashcash - a denial of service counter-measure. http://www.hashcash.org/papers/hashcash.pdf, 2002. Accessed: 2017-09-28.  S. Barber, X. Boyen, E. Shi, and E. Uzun. Bitter to better - how to make bitcoin a better currency. In Financial cryptography and data security, pages 399–414. Springer, 2012.  J. Becker, D. Breuker, T. Heide, J. Holler, H. P. Rauer, and R. Böhme. Can we afford integrity by proof-of-work? scenarios inspired by the bitcoin currency. In WEIS. Springer, 2012.  I. Bentov, R. Pass, and E. Shi. Snow white: Provably secure proofs of stake. https://eprint.iacr.org/2016/919.pdf, 2016. Accessed: 2017-09-28.  Bitcoin Community. Bitcoin developer guide- transaction data. https://bitcoin.org/en/developer-guide#term-merkle-tree. Accessed: 2017-06-05.  Bitcoin Community. Bitcoin protocol documentation - merkle trees. https://en.bitcoin.it/wiki/Protocol_documentation#Merkle_Trees. Accessed: 2017-06-05.  Bitcoin community. Bitcoin protocol rules. https://en.bitcoin.it/wiki/Protocol_rules. Accessed: 2017-08-22.  V. Buterin. Chain interoperability. Technical report, Tech. rep. 1. R3CEV, 2016.  W. Dai. bmoney. http://www.weidai.com/bmoney.txt, 1998. Accessed: 2017-09-28.  C. Decker and R. Wattenhofer. Information propagation in the bitcoin network. In Peer-to-Peer Computing (P2P), 2013 IEEE Thirteenth International Conference on, pages 1–10. IEEE, 2013.  C. Decker and R. Wattenhofer. Bitcoin transaction malleability and mtgox. In Computer Security-ESORICS 2014, pages 313–326. Springer, 2014.  Dogecoin community. Dogecoin reference implementation. https://github.com/dogecoin/  A. Gervais, G. Karame, S. Capkun, and V. Capkun. Is bitcoin a decentralized currency? volume 12, pages 54–60, 2014.  A. Gervais, G. O. Karame, K. Wüst, V. Glykantzis, H. Ritzdorf, and S. Capkun. On the security and performance of proof of work blockchains. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pages 3–16. ACM, 2016.  I. Giechaskiel, C. Cremers, and K. B. Rasmussen. On bitcoin security in the presence of broken cryptographic primitives. In European Symposium on Research in Computer Security (ESORICS), September 2016.  J. Göbel, H. P. Keeler, A. E. Krzesinski, and P. G. Taylor. Bitcoin blockchain dynamics: The selfish-mine strategy in the presence of propagation delay. Performance Evaluation, 104:23–41, 2016.  E. Heilman, A. Kendler, A. Zohar, and S. Goldberg. Eclipse attacks on bitcoin’s peer-to-peer network. In 24th USENIX Security Symposium (USENIX Security 15), pages 129–144, 2015.  Huntercoin developers. Huntercoin reference implementation. https://github.com/chronokings/huntercoin. Accessed: 2017-06-05.  B. Jakobsson and A. Juels. Proofs of work and bread pudding protocols, Apr. 8 2008. US Patent 7,356,696; Accessed: 2017-06-05.  M. Jakobsson and A. Juels. Proofs of work and bread pudding protocols. In Secure Information Networks, pages 258–272. Springer, 1999.  A. Judmayer, N. Stifter, K. Krombholz, and E. Weippl. Blocks and chains: Introduction to bitcoin, cryptocurrencies, and their consensus mechanisms. Synthesis Lectures on Information Security, Privacy, & Trust, 9(1):1–123, 2017.  A. Juels and J. G. Brainard. Client puzzles: A cryptographic countermeasure against connection depletion attacks. In NDSS, volume 99, pages 151–165, 1999.  A. Juels and B. S. Kaliski Jr. Pors: Proofs of retrievability for large files. In Proceedings of the 14th ACM conference on Computer and communications security, pages 584–597. Acm, 2007.  H. Kalodner, M. Carlsten, P. Ellenbogen, J. Bonneau, and A. Narayanan. An empirical study of namecoin and lessons for decentralized namespace design. In WEIS, 2015.  G. O. Karame, E. Androulaki, and S. Capkun. Double-spending fast payments in bitcoin. In Proceedings of the 2012 ACM conference on Computer and communications security, pages 906–917. ACM, 2012.  G. O. Karame, E. Androulaki, M. Roeschlin, A. Gervais, and S. Čapkun. Misbehavior in bitcoin: A study of double-spending and accountability. volume 18, page 2. ACM, 2015.  A. Kiayias, A. Russell, B. David, and R. Oliynykov. Ouroboros: A provably secure proof-of-stake blockchain protocol. In Annual International Cryptology Conference, pages 357–388. Springer, 2017.  S. King. Primecoin: Cryptocurrency with prime number proof-of-work. July 7th, 2013.  T. Kluyver, B. Ragan-Kelley, F. Pérez, B. E. Granger, M. Bussonnier, J. Frederic, K. Kelley, J. B. Hamrick, J. Grout, S. Corlay, et al. Jupyter notebooks-a publishing format for reproducible computational workflows. In ELPUB, pages 87–90, 2016.  Lerner, Sergio D. Rootstock plattform. http://www.the-blockchain.com/docs/Rootstock-WhitePaper-Overview.pdf. Accessed: 2017-06-05.  Y. Lewenberg, Y. Bachrach, Y. Sompolinsky, A. Zohar, and J. S. Rosenschein. Bitcoin mining pools: A cooperative game theoretic analysis. In Proceedings of the 2015 International Conference on Autonomous Agents and Multiagent Systems, pages 919–927. International Foundation for Autonomous Agents and Multiagent Systems, 2015.  Litecoin community. Litecoin reference implementation. https://github.com/litecoin-project/litecoin. Accessed: 2017-09-28.  I. Maven. Apache maven project, 2011.  G. Maxwell. Comment in "[bitcoin-dev] weak block thoughts...". https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Septembe011198.html, 2016. Accessed: 2017-05-10.  S. Meiklejohn, M. Pomarole, G. Jordan, K. Levchenko, D. McCoy, G. M. Voelker, and S. Savage. A fistful of bitcoins: characterizing payments among men with no names. In Proceedings of the 2013 conference on Internet measurement conference, pages 127–140. ACM, 2013.  S. Micali. Algorand: The efficient and democratic ledger. http://arxiv.org/abs/1607.01341, 2016. Accessed: 2017-02-09.  A. Miller, A. Juels, E. Shi, B. Parno, and J. Katz. Permacoin: Repurposing bitcoin work for data preservation. In Security and Privacy (SP), 2014 IEEE Symposium on, pages 475–490. IEEE, 2014.  A. Miller, A. Kosba, J. Katz, and E. Shi. Nonoutsourceable scratch-off puzzles to discourage bitcoin mining coalitions. In Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, pages 680–691. ACM, 2015.  B. Momjian. PostgreSQL: introduction and concepts, volume 192. Addison-Wesley New York, 2001.  Myriad core developers. Myriadcoin reference implementation. https://github.com/myriadcoin/myriadcoin. Accessed: 2017-06-05.  S. Nakamoto. Bitcoin: A peer-to-peer electronic cash system. https://bitcoin.org/bitcoin.pdf, Dec 2008. Accessed: 2017-09-28.  S. Nakamoto. Merged mining specification. https://en.bitcoin.it/wiki/Merged_mining_specification, Apr 2011. Accessed: 2017-09-28.  Namecoin Community. Merged mining. https://github.com/namecoin/wiki/blob/masteMerged-Mining.mediawiki#Goal_of_this_namecoin_change. Accessed: 2017-08-20.  Namecoin community. Namecoin reference implementation. https://github.com/namecoin/namecoin. Accessed: 2017-09-28.  A. Narayanan, J. Bonneau, E. Felten, A. Miller, and S. Goldfeder. Bitcoin and Cryptocurrency Technologies: A Comprehensive Introduction. Princeton University Press, 2016.  K. Nayak, S. Kumar, A. Miller, and E. Shi. Stubborn mining: Generalizing selfish mining and combining with an eclipse attack. In 1st IEEE European Symposium on Security and Privacy, 2016. IEEE, 2016.  K. J. O’Dwyer and D. Malone. Bitcoin mining and its energy footprint. 2014.  R. Pass, L. Seeman, and A. Shelat. Analysis of the blockchain protocol in asynchronous networks. In Annual International Conference on the Theory and Applications of Cryptographic Techniques, pages 643–673. Springer, 2017.  D. Pointcheval and J. Stern. Security arguments for digital signatures and blind signatures. Journal of cryptology, 13(3):361–396, 2000.  Pseudonymous("TierNolan"). Decoupling transactions and pow. https://bitcointalk.org/index.php?topic=179598.0, 2013. Accessed: 2017-05-10.  P. R. Rizun. Subchains: A technique to scale bitcoin and improve the user experience. Ledger, 1:38–52, 2016.  K. Rosenbaum. Weak blocks - the good and the bad. http://popeller.io/index.php/2016/01/19/weak-blocks-the-good-and-the-bad/, 2016. Accessed: 2017-05-10.  K. Rosenbaum and R. Russell. Iblt and weak block propagation performance. Scaling Bitcoin Hong Kong (6 December 2015), 2015.  M. Rosenfeld. Analysis of bitcoin pooled mining reward systems. arXiv preprint arXiv:1112.4980, 2011.  M. Rosenfeld. Analysis of hashrate-based double spending. http://arxiv.org/abs/1402.2009, 2014. Accessed: 2016-03-09.  R. Russel. Weak block simulator for bitcoin. https://github.com/rustyrussell/weak-blocks, 2014. Accessed: 2017-05-10.  A. Sapirshtein, Y. Sompolinsky, and A. Zohar. Optimal selfish mining strategies in bitcoin. In International Conference on Financial Cryptography and Data Security, pages 515–532. Springer, 2016.  Sathoshi Nakamoto. Comment in "bitdns and generalizing bitcoin" bitcointalk thread. https://bitcointalk.org/index.php?topic=1790.msg28696#msg28696. Accessed: 2017-06-05.  O. Schrijvers, J. Bonneau, D. Boneh, and T. Roughgarden. Incentive compatibility of bitcoin mining pool reward functions. In FC ’16: Proceedings of the the 20th International Conference on Financial Cryptography, February 2016.  B. Sengupta, S. Bag, S. Ruj, and K. Sakurai. Retricoin: Bitcoin based on compact proofs of retrievability. In Proceedings of the 17th International Conference on Distributed Computing and Networking, page 14. ACM, 2016.  N. Szabo. Bit gold. http://unenumerated.blogspot.co.at/2005/12/bit-gold.html, 2005. Accessed: 2017-09-28.  M. B. Taylor. Bitcoin and the age of bespoke silicon. In Proceedings of the 2013 International Conference on Compilers, Architectures and Synthesis for Embedded Systems, page 16. IEEE Press, 2013.  Unitus developers. Unitus reference implementation. https://github.com/unitusdev/unitus. Accessed: 2017-08-22.  M. Vukolić. The quest for scalable blockchain fabric: Proof-of-work vs. bft replication. In International Workshop on Open Problems in Network Security, pages 112–125. Springer, 2015.  P. Webb, D. Syer, J. Long, S. Nicoll, R. Winch, A. Wilkinson, M. Overdijk, C. Dupuis, and S. Deleuze. Spring boot reference guide. Technical report, 2013-2016.  A. Zamyatin. Name-squatting in namecoin. (unpublished BSc thesis, Vienna University of Technology), 2015.
Abstract The term near or weak blocks describes Bitcoin blocks whose PoW does not meet the required target difficulty to be considered valid under the regular consensus rules of the protocol. Near blocks are generally associated with protocol improvement proposals striving towards shorter transaction confirmation times. Existing proposals assume miners will act rationally based solely on intrinsic incentives arising from the adoption of these changes, such as earlier detection of blockchain forks. In this paper we present Flux, a protocol extension for proof-of-work blockchains that leverages on near blocks, a new block reward distribution mechanism, and an improved branch selection policy to incentivize honest participation of miners. Our protocol reduces mining variance, improves the responsiveness of the underlying blockchain in terms of transaction processing, and can be deployed without conflicting modifications to the underlying base protocol as a velvet fork. We perform an initial analysis of selfish mining which suggests Flux not only provides security guarantees similar to pure Nakamoto consensus, but potentially renders selfish mining strategies less profitable. References  Bitcoin Cash. https://www.bitcoincash.org/. Accessed: 2017-01-24.  P2pool. http://p2pool.org/. Accessed: 2017-05-10.  G. Andersen. Comment in ”faster blocks vs bigger blocks”. https://bitcointalk.org/index.php?topic=673415.msg7658481#msg7658481, 2014. Accessed: 2017-05-10.  G. Andersen. [bitcoin-dev] weak block thoughts... https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Septembe011157.html, 2015. Accessed: 2017-05-10.  E. Androulaki, S. Capkun, and G. O. Karame. Two bitcoins at the price of one? double-spending attacks on fast payments in bitcoin. In CCS, 2012.  J. Becker, D. Breuker, T. Heide, J. Holler, H. P. Rauer, and R. Bohme. ¨ Can we afford integrity by proof-of-work? scenarios inspired by the bitcoin currency. In WEIS. Springer, 2012.  I. Bentov, R. Pass, and E. Shi. Snow white: Provably secure proofs of stake. https://eprint.iacr.org/2016/919.pdf, 2016. Accessed: 2016-11-08.  Bitcoin community. OP RETURN. https://en.bitcoin.it/wiki/OP\RETURN. Accessed: 2017-05-10.  Bitcoin Wiki. Merged mining specification. [https://en.bitcoin.it/wiki/Merged\](https://en.bitcoin.it/wiki/Merged)) mining\ specification. Accessed: 2017-05-10.  Blockchain.info. Hashrate Distribution in Bitcoin. https://blockchain.info/de/pools. Accessed: 2017-05-10.  Blockchain.info. Unconfirmed bitcoin transactions. https://blockchain.info/unconfirmed-transactions. Accessed: 2017-05-10.  J. Bonneau, A. Miller, J. Clark, A. Narayanan, J. A. Kroll, and E. W. Felten. Sok: Research perspectives and challenges for bitcoin and cryptocurrencies. In IEEE Symposium on Security and Privacy, 2015.  V. Buterin. Ethereum: A next-generation smart contract and decentralized application platform. https://github.com/ethereum/wiki/wiki/White-Paper, 2014. Accessed: 2016-08-22.  C. Decker and R. Wattenhofer. Information propagation in the bitcoin network. In Peer-to-Peer Computing (P2P), 2013 IEEE Thirteenth International Conference on, pages 1–10. IEEE, 2013.  J. R. Douceur. The sybil attack. In International Workshop on Peer-toPeer Systems, pages 251–260. Springer, 2002.  I. Eyal, A. E. Gencer, E. G. Sirer, and R. Renesse. Bitcoin-ng: A scalable blockchain protocol. In 13th USENIX Security Symposium on Networked Systems Design and Implementation (NSDI’16). USENIX Association, Mar 2016.  I. Eyal and E. G. Sirer. Majority is not enough: Bitcoin mining is vulnerable. In Financial Cryptography and Data Security, pages 436–454. Springer, 2014.  J. Garay, A. Kiayias, and N. Leonardos. The bitcoin backbone protocol: Analysis and applications. In Advances in Cryptology-EUROCRYPT 2015, pages 281–310. Springer, 2015.  A. E. Gencer, S. Basu, I. Eyal, R. Renesse, and E. G. Sirer. Decentralization in bitcoin and ethereum networks. In Proceedings of the 22nd International Conference on Financial Cryptography and Data Security (FC). Springer, 2018.  A. Gervais, G. Karame, S. Capkun, and V. Capkun. Is bitcoin a decentralized currency? volume 12, pages 54–60, 2014.  A. Gervais, G. O. Karame, K. Wust, V. Glykantzis, H. Ritzdorf, ¨ and S. Capkun. On the security and performance of proof of work blockchains. https://eprint.iacr.org/2016/555.pdf, 2016. Accessed: 2016-08-10.  M. Jakobsson and A. Juels. Proofs of work and bread pudding protocols. In Secure Information Networks, pages 258–272. Springer, 1999.  A. Judmayer, A. Zamyatin, N. Stifter, A. G. Voyiatzis, and E. Weippl. Merged mining: Curse or cure? In CBT’17: Proceedings of the International Workshop on Cryptocurrencies and Blockchain Technology, Sep 2017.  G. O. Karame, E. Androulaki, M. Roeschlin, A. Gervais, and S. Capkun. ˇ Misbehavior in bitcoin: A study of double-spending and accountability. volume 18, page 2. ACM, 2015.  A. Kiayias, A. Miller, and D. Zindros. Non-interactive proofs of proof-of-work. Cryptology ePrint Archive, Report 2017/963, 2017. Accessed:2017-10-03.  A. Kiayias, A. Russell, B. David, and R. Oliynykov. Ouroboros: A provably secure proof-of-stake blockchain protocol. In Annual International Cryptology Conference, pages 357–388. Springer, 2017.  Y. Lewenberg, Y. Sompolinsky, and A. Zohar. Inclusive block chain protocols. In Financial Cryptography and Data Security, pages 528–547. Springer, 2015.  Litecoin community. Litecoin reference implementation. https://github.com/litecoin-project/litecoin. Accessed: 2018-05-03.  G. Maxwell. Comment in ”[bitcoin-dev] weak block thoughts...”. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Septembe011198.html, 2016. Accessed: 2017-05-10.  S. Micali. Algorand: The efficient and democratic ledger. http://arxiv.org/abs/1607.01341, 2016. Accessed: 2017-02-09.  S. Nakamoto. Bitcoin: A peer-to-peer electronic cash system. https://bitcoin.org/bitcoin.pdf, Dec 2008. Accessed: 2015-07-01.  Namecoin community. Namecoin reference implementation. https://github.com/namecoin/namecoin. Accessed: 2017-05-10.  Narayanan, Arvind and Bonneau, Joseph and Felten, Edward and Miller, Andrew and Goldfeder, Steven. Bitcoin and cryptocurrency technologies. https://d28rh4a8wq0iu5.cloudfront.net/bitcointech/readings/princeton bitcoin book.pdf?a=1, 2016. Accessed: 2016-03-29.  K. Nayak, S. Kumar, A. Miller, and E. Shi. Stubborn mining: Generalizing selfish mining and combining with an eclipse attack. In 1st IEEE European Symposium on Security and Privacy, 2016. IEEE, 2016.  K. J. O’Dwyer and D. Malone. Bitcoin mining and its energy footprint. 2014.  R. Pass and E. Shi. Fruitchains: A fair blockchain. http://eprint.iacr.org/2016/916.pdf, 2016. Accessed: 2016-11-08.  C. Perez-Sol ´ a, S. Delgado-Segura, G. Navarro-Arribas, and J. Herrera- ` Joancomart´ı. Double-spending prevention for bitcoin zero-confirmation transactions. http://eprint.iacr.org/2017/394, 2017. Accessed: 2017-06-  Pseudonymous(”TierNolan”). Decoupling transactions and pow. https://bitcointalk.org/index.php?topic=179598.0, 2013. Accessed: 2017-05-10.  P. R. Rizun. Subchains: A technique to scale bitcoin and improve the user experience. Ledger, 1:38–52, 2016.  K. Rosenbaum. Weak blocks - the good and the bad. http://popeller.io/ index.php/2016/01/19/weak-blocks-the-good-and-the-bad/, 2016. Accessed: 2017-05-10.  K. Rosenbaum and R. Russell. Iblt and weak block propagation performance. Scaling Bitcoin Hong Kong (6 December 2015), 2015.  M. Rosenfeld. Analysis of hashrate-based double spending. http://arxiv.org/abs/1402.2009, 2014. Accessed: 2016-03-09.  R. Russel. Weak block simulator for bitcoin. https://github.com/rustyrussell/weak-blocks, 2014. Accessed: 2017-05-10.  A. Sapirshtein, Y. Sompolinsky, and A. Zohar. Optimal selfish mining strategies in bitcoin. http://arxiv.org/pdf/1507.06183.pdf, 2015. Accessed: 2016-08-22.  E. B. Sasson, A. Chiesa, C. Garman, M. Green, I. Miers, E. Tromer, and M. Virza. Zerocash: Decentralized anonymous payments from bitcoin. In Security and Privacy (SP), 2014 IEEE Symposium on, pages 459–474. IEEE, 2014.  Satoshi Nakamoto. Comment in ”bitdns and generalizing bitcoin” bitcointalk thread. https://bitcointalk.org/index.php?topic=1790.msg28696#msg28696. Accessed: 2017-06-05.  Y. Sompolinsky, Y. Lewenberg, and A. Zohar. Spectre: A fast and scalable cryptocurrency protocol. Cryptology ePrint Archive, Report 2016/1159, 2016. Accessed: 2017-02-20.  Y. Sompolinsky and A. Zohar. Secure high-rate transaction processing in bitcoin. In Financial Cryptography and Data Security, pages 507–527. Springer, 2015.  Suhas Daftuar. Bitcoin merge commit: ”mining: Select transactions using feerate-with-ancestors”. https://github.com/bitcoin/bitcoin/pull/7600. Accessed: 2017-05-10.  M. B. Taylor. Bitcoin and the age of bespoke silicon. In Proceedings of the 2013 International Conference on Compilers, Architectures and Synthesis for Embedded Systems, page 16. IEEE Press, 2013.  F. Tschorsch and B. Scheuermann. Bitcoin and beyond: A technical survey on decentralized digital currencies. In IEEE Communications Surveys Tutorials, volume PP, pages 1–1, 2016.  P. J. Van Laarhoven and E. H. Aarts. Simulated annealing. In Simulated annealing: Theory and applications, pages 7–15. Springer, 1987.  A. Zamyatin, N. Stifter, A. Judmayer, P. Schindler, E. Weippl, and W. J. Knottebelt. (Short Paper) A Wild Velvet Fork Appears! Inclusive Blockchain Protocol Changes in Practice. In 5th Workshop on Bitcoin and Blockchain Research, Financial Cryptography and Data Security 18 (FC). Springer, 2018.  F. Zhang, I. Eyal, R. Escriva, A. Juels, and R. Renesse. Rem: Resourceefficient mining for blockchains. http://eprint.iacr.org/2017/179, 2017. Accessed: 2017-03-24.
Vertcoin's Recent Decisions. The damage hasn't been done yet, please join me in stopping the madness!
Foreword Alright, I’ve been sitting on the sidelines about most of the dealings with Vertcoin because I felt like a lot of the sensible voices were loud enough on their own. Many people have stepped up to the plate and developed amazing products that benefit Vertcoin at no addition expense to the original development team. I’ve seen and helped test/brainstorm some incredible projects. Vert.geek.nz was a great example: a project that promoted p2pool mining while still allowing miners to reap the benefit of merged mining. Before nzsquirrell brought us this product we were all forced to either solo mine or to switch to a mining pool that support merged coins (namely SimpleVert at the time). V2p was another amazing product. There's the One Click Miner that's being developed right now... There are a lot more, but my point is that people were able to see a need for a new service, and build that service without any voting or public funding or whatever. And they did an amazing job because they thought things through. With input from multiple sources, and a slow, steady brainstorming session, they were able to develop something that really couldn’t have been made better. Democracy in Action Alternatively, Vertcoin itself is being left to an absolutely ridiculous voting process right now that WILL destroy the coin, and here’s why: The democratic process doesn’t work. If you build a system by which the majority can make these kinds of decisions, you create an environment based purely on mob mentality. If I can convince a large enough group of people that a certain idea is better than another, I win. This is extremely bad if you’re trying to gather interest from investors as well because it creates too much variance in coin value and feature sets (the idea of changing the also they would probably like, since that’s something Vertcoin has been about since the beginning, changing the inner workings of the coin simply to combat a single “problem” is VERY BAD if you want to attract investors because they see these moves as signs of weakness). Development Now, I’ll come back to the VertVote process later, because I think the most important thing to talk about right now is the decision-making process on the part of our developers. The VTC dev team has done numerous things that don’t make sense to a number of users lately, and they need to be addressed. First, the website update. We’ve beat this horse to a pulp, and I understand that, but I think people still need to keep this in mind. When the new site was released, there wasn’t any input from the community. There wasn’t any play-testing or public brainstorming done to help promote discussion that might have found issues with this site. For example, the “Mining” page still doesn’t have a single mining pool listed, which leaves a user to go out and find a solid pool on their own. This isn’t easy, especially for someone who doesn’t even know how cryptocurrencies work (the primary audience for a site like this should be users with no crypto experience). The same goes for the “Details” page. There’s plenty of technical information, but that doesn’t mean anything to a regular person. They don’t know what an algorithm is, or what block times/rewards are… It even mentioned merged-mining, without any information on what that is. It’s just confusing for a newbie. Management Second, and similarly, the marketing fund got thrown into a pit of uselessness. Vertcoin.org was advertised to miners on a site where people go to see the profitability and mining calculations for a number of coins. Let’s just say that the ad actually catches a miners eye and they click on it. It would lead them to a site that has no information on which mining pools they can/should connect to, aside from p2pool. So the most common frequenter of that site can’t access the most important information he would want from the Vertcoin website. I want to know how that seemed like a good idea. Alternatively, a group of dedicated Vertans (including one miner that has somewhere in the ballpark of 40 rigs, so he’s pretty damn dedicated), built an entire site from scratch that addressed a number of things for regular folks who we should be attracting to Vertcoin, and presented it to the community and the development team. I realize that there’s a sort of pride in work mentality that might have made the devs prefer their own site, but in this case the new presentation was, in my opinion, better. Furthermore, the devs could have taken this new site and moved it over straight away with almost no other changes, besides a couple small fixes and integration to include mobile browsers. Instead, all they got was a 'thanks for the suggestions, I’ll use some of your stuff if it seems fitting’. If you want to check out the alternative site that a few dedicated Vertans built, check it out here. VertVote Now, I promised to come back to VertVote. VertVote says on their front page: "You may vote once on any active poll. Make your voice heard Vertan!”, yet there’s literally nothing stopping a member from voting multiple times. So now we’re making decisions about the life of the coin based on how many possible mis-informed people vote for something, with the honest folks losing out more than anyone else (since the honest ones are the ones less likely to cheat)… Probably the most important factor for VertVote would be the fact that it's in the hands of such a knee-jerk crew right now. I didn't even realize that the vote for block maturation was actually a decision-making vote. I assumed it was simply a poll that the dev team wanted to conduct to get a gauge of how strongly the miners feel on the subject. Instead, they took one of the most poorly worded/conducted votes and turned it into the final decision on the continuation of the coin. That was the wrong decision. Not only that, but it appears that the dev team has decided to interpret the voting results however they see fit, without letting anyone know the conditions of the vote in advance. The example of this being that fact that they completely disregarded the winning vote and instead gave the vote to the second-highest result. To me, this would be like throwing the clear presidential winner out because he only had 49% of the vote (so 51% didn’t want him) and instead picking the candidate who had 30% of the vote simply because he was among the majority… It makes no sense, and if you were going to start a vote with such a senseless base to it, you should have stated as much and given voters more time to decide before they cast their vote(s). As for the VertVote manipulation, for those who don’t believe me. It’s incredibly easy, and ridiculous. To test things out, I used 100 VTC, spread it out across 10 VTC addresses and cast a vote from each. Nothing in the site, not even a browser cookie, stopped me from casting multiple votes. But then I thought a bit more. Why limit myself by how much VTC I have? All I need is 10 VTC in an address at the moment I cast my vote. So really, I just need 10 VTC plus [number of votes I want to cast] times [transaction fee to send 10 VTC]. I could just keep creating wallets, sending the 10 VTC to the new wallet, and vote again… On the other hand, one of the measures to fight against this behavior is a block on IP addresses submitting multiple votes. This doesn't seem all that logical, considering multiple people could reside at one location / share an internet connection and not be able to voice their opinion as well as a single person / internet user. Economically, These are Bad Decisions As for the block subsidy change proposal: This is getting out of hand. Cryptocurrencies’ values need to stay in line with regular products and fiat currency. A very successful cryptocurrency should have about a 1:1 ratio with things normal people are used to. What this means is that we want Vertcoin to settle in value somewhere between $0.50 and $3 each, so that normal people can easily convert the value and go from there. Artificially halting/slowing the production of Vertcoin may result in a slight pump in value, but ultimately it will detract investors because it causes more variance (who knows what the devs/community will want to do next) and it makes Vertcoin less easy to calculate compared to what they’re used to (i.e. the dollar, euro, etc). Think of it, literally, as a coin. If Vertcoin were an actual coin and each coin were worth over $100, people won’t exactly want to carry it around. For this reason, Bitcoin community members have been discussing creating a denomination of sorts, so they could refer to smaller increments of BTC as something like bits and have each bit worth $0.10-1.00. Your proposal would do the exact opposite and make Vertcoin even more difficult for the layman to comprehend. Minor side-point One last thing, and this is mostly unrelated (I noticed it during my experimentation): Vertcoin-Qt has an option to view a transaction on VertExplorer, even though VertExplorer isn’t even around anymore. Alternatively, there’s explorer.vertcoin.org, which works fine. Can the devs please change the wallet so that it can reference transactions without having to copy, browse to explorer.vertcoin.org and then paste/search for that transaction? For Those Who Think We Need VertVote: I ask you this, what did you come here for? Did you like Vertcoin, or did you like the idea of a coin that could be constantly changed on the whim of a couple hundred votes? We all bought into Vertcoin because we liked what it stood for (ASIC-resistance), and the economics of it were sound. Even now, the economics of it are only frowned upon because we see so many PoS coins taking over the market. Nobody's out there suggesting we switch to a PoS model, even though PoS is patently anti-ASIC, ASIC-proof for that matter. The whole point of cryptocurrencies is that they are void of any centralized control. If we leave this coin up to the decisions of those who hold it, we're still centralizing the currency's control to those people in particular. Instead, we should be basing the currency on a constitutional model (by that I mean that there should be absolutes that won't be changed, such as the block reward schedule, total VTC supply, time to block solve, etc). The technical details should only change out of absolute necessity to maintain the requirements laid out in the coin's "constitution". In this case, changing the algorithm makes sense, because it maintains the constitutional requirement of being ASIC-resistant. Changing the block reward is just an idea that people like because they see it as a way to increase the value and ROI of their current holdings, without regard to the fact that it'll scare off practically any conscious investor.
If I were to write vertcoin.org.....[LONG POST WARNING!]
I want to preface this post by saying that I have great respect for a432511, and the amount he's achieved since joining the dev team is remarkable. However, since I first looked at the revamped vertcoin.org this morning, I've had an uneasy feeling all day that it hasn't moved us far enough in the right direction. I'm not a visual person, so I'm not really referring to the aesthetic design of the site here (I think the general consensus is that this has been improved). I'm more concerned about the content (or lack of). It's not his fault, because, unless I missed it, we never really had a community discussion about what content would be good to have on the site. I think one of our weaknesses as a community is that we tend to focus on the mechanics of the coin (often from the perspective of miners), perhaps at the expense of considering the image we portray to the outside world? Sooner or later, if we're to succeed in the goal of mass adoption, this has to change. I think if we honestly and objectively try to look at our website through the eyes of someone who's never come across Vertcoin before - or even maybe only just heard about Bitcoin - the site doesn't deliver the key information it needs to with clarity and simplicity. So I thought I'd have a go at writing an outline for the sub-pages and content I'd like to see on the site. The sub-pages I would have are: Features Buy/Trade VTC (I wouldn't write "VTC" on the navigation bar, I'd use the "v" logo) Store VTC Use VTC Mine VTC FAQs Team Blog A rough outline of page content would be as follows: Features: I think I recall seeing a good short video explanation of Vertcoin on the old website? I would have this and the new video explaining SX side by side on this page, together with the "Features" content that's currently on the home page (though some of that content could do with a bit of fleshing out - for example "support" should maybe include a link to this sub-reddit, or wherever else we're offering support?) Some of the current "details" page could also live here, though I'd drop the merged-mining info and save it for the mining page. Buy/Trade VTC: This sub-page would replace the current "invest" sub-page. I would give up front prominence to all fiat>vtc exchange services such as Bittylicious, Vault of Satoshi and Prelude. Why? Because anyone looking at crypto for the very first time is going to want to take the most straightforward route possible. I know there are verification headaches with fiat>crypto exchanges, but I don't think that's a good enough reason to send people via BTC by default. Perhaps we could incorporate a dropdown for country of residence so that visitors can see at a glance which exchanges are available in their country? If their country is not served by a fiat exchange, only then should we send them down the route of buying BTC by whatever means available. Store VTC: One of the biggest pitfalls for anyone getting started in crypto is learning the basics of safely storing them. So this page would need to be educational, and include warnings about things like leaving coins on exchanges and not encrypting and backing up your wallet. This page is where the wallet downloads belong. Details on cold storage and trustworthy paper wallet creators would be good to include here. Use VTC: This page would be all about how awesomely versatile VTC is as a spendable currency. I can't stress enough that we need to really start selling the utility of our coin better. A link to a "Merchant Monday" reddit post does not cut the mustard! I'd start with the most universal means of spending VTC anywhere via services like The Crypto Depot. The next most versatile means of spending it would be VertVerser. Then finally I'd have a regularly updated copy of the Merchant Monday list (though as this grows we'd have to give some consideration to presenting this in the form of a directory). Mine VTC: This is where we make a big deal of the fact that we intend to keep our coin mineable with consumer grade hardware. As and when it's available, the one click miner download would be prominent on this page. We give p2pool the prominence it deserves too, perhaps with a statement that we're proud to have the highest p2pool participation of any coin? I don't think p2pool prominence should be at the expense of total exclusion of traditional pools though. I suggest we emphasise the importance of spreading the hashrate, list available pools in order of size (largest always at the bottom), and say that we'll exclude a pool from the list if they're over a certain percentage of network hashrate. FAQs: I hope this page is fairly self explanatory, but I think an FAQ page would be a nice resource to include for newbies. Team: Not too much to be said that hasn't already been said about this elsewhere. Blog: Vital that this gets updated regularly, even if they're just one-liners. The twitter feed may also belong on this page? (not sure it looks great on the home page right now). I hope this post is received in the positive way that it's intended. I'm just very keen for us all to get maximum bang for our buck from the forthcoming marketing campaign. If the marketing campaign is primarily focussed on driving traffic to vertcoin.org, then it's vital that we work hard to make it the very best it can be.
I believe in Quark due to the increased security and fast transaction times but the worry I always have with the coin is the dropping hashrate caused by the low block reward combined with zero transaction fees. See http://bitinfocharts.com/comparison/hashrate-qrk.html which shows a steady decrease now most of the mining is over. There is an interesting post on the bitcoin subreddit http://redd.it/22aw8c showing the dangers for altcoins with low hashrates. I'm not sure how quark would be safe from these attacks if it rose in price and popularity again to make these attacks financially worthwhile. I know we now have mining in the wallet but even maxing out an ivy bridge I7 for a few days I couldn't get any. Maybe if the client automatically connected to the nearest p2pool it would produce a few coins a day but would this get a big enough hashrate to protect the coin? The only solutions I can think of would need a hard fork, either an increase in the block reward or turning into a hybrid POS/POW coin. Ideally both to provide the max benefit with minimum forks. Most people would class 2% inflation as low in the fiat world so there is plenty of scope to increase it in Quark. Especially if we're aiming for a fast secure means of paying for stuff rather than a long term savings coin. I'm guessing that merged mining wouldn't be an option due to the difficulty of finding suitable coins to merge mine with that are big enough to make a difference. I'm hoping the devs are looking into these dangers as on the internet there will be a few people with the computing power to trash alt-coins if they can make money out of it and they won't care about the work that's gone into the coin. Sorry if this post comes across as negative but as I'm in the IT security business I'm the sort of person who looks into the worst case scenarios, how likely they are and how to avoid them.
Is vertco.in's addition of merged mining with Monoacle going to affect how many Vertcoin are mined?
I want to be clear, that I have tried to understand this whole monoacle merged mining concept, but I do not. However, I have zero interest in the coin or whatever merged mining is. Vertcoin is what I want. To that end, I have been mining it on Vertco.in. Today I saw the announcement that they are going to merge mine with monoacle. I don't want Monoacle coins, I really want nothing at all to do with them. Do I have to take them if I continue to mine with Vertco.in or should I take my 3-4 MH/s somewhere else? My concern is that by spending MH/s mining a coin I do not want I will short myself of the coin that I want. Please ELI5 that I either do or do not have something to be concerned about. I appreciate any time you devote to this response!
Dear Bushido Please allow me to introduce myself. My (not real) name is depboy. You may have seen me around this subreddit. I first came across Bitcoin about three years ago. At first I only took a passing interest and only really got involved with making my first purchases in 2013. Like many others I was inspired by blockchain technology and the concept of a financial system based on distributed consensus. I guess it appealed to the anarchist libertarian in me. As I immersed myself in the world of crypto, it became apparent to me that, beautiful as blockchain technology is, it’s not immune to the subversive forces of centralization. Naturally, I began looking for alternative cryptocurrencies that built upon the Bitcoin model, but had greater potential for remaining decentralized in the long term. In March 2014 I discovered Vertcoin. The 6+ months that I’ve been an active member of this community have been quite a ride! In the early days I got stuck in enthusiastically as a miner. I had my 12 gpus mining away on my own private p2pool node. Following the launch of Monocle, I branched out into making my node public and joining in with Vertgeek to help support merged mining and p2pool participation. I was hooked. That all feels like a long time ago now. In the time I’ve been involved here, I’ve seen so much change, and I have to be honest and say that much of it has not been positive. The only thing that’s remained unnervingly constant is the total number of subscribers on this sub which has flat-lined at ~5K. Anyway, I’m determined not to dwell on past negativity, but instead look ahead to the future. That must necessarily be based on an honest assessment of where this coin stands presently. For better or worse, Vertcoin has nailed its colours to the mast and differentiated itself as the only truly ASIC resistant crypto. Implicit in this statement is a pledge to fork this coin onto another algo as and when the need arises due to ASIC development. We’ve reached the point in time when this pledge is about to be tested for the first time, with ASIC manufacturers making bold claims about scrypt-n capabilities. There’s also circumstantial evidence of ASIC testing in the form of miners with very large hashrates appearing sporadically on some pools. There are only two possible outcomes where ASICs are concerned: either they come to dominate the Vertcoin network forever more, or they don’t. Some people seem to think that Vertcoin could be forked to move away from ASICs after the fact. This overlooks the non-trivial issue of successful forks requiring network consensus. In a network of pools and miners dominated by ASICs, that would be analogous to turkeys voting for Christmas. Put simply, if we pass a certain point in terms of ASIC mining, the ASIC resistant claim will be forever lost. The need for mining consensus is critical here. We can fool ourselves all we like that developers hold the key to the future of this coin. The true power lies with the miners, or more specifically the larger mining pools. Out of adversity springs the greatest opportunity? It’s seems likely to me that if Vertcoin succeeded in forking away from ASICs in time, and did it in a convincing manner that instilled confidence in a decentralized future, Vertcoin could flourish. Truly passionate about decentralization? We don’t know each other personally, but I’m going to go out on a limb here and assume some common ground. Because I find it hard to believe that someone who took the time to launch something like Vertcoin would not have an awareness of, and passion for, true decentralization. All alt currencies begin life as the brainchild of their developer(s). It’s not unreasonable to assume that during the early stages a coin is dependent on its developer(s), in much the same way that children depend on their parents. However, for a decentralized currency to achieve long term viability, there must come a time in the life of every coin when the developer(s) take a back seat and the training wheels are removed. Whether by accident or design, Vertcoin has travelled some way down this road already. It seems clear that in terms of the dev team you are pretty much the last man standing. Unfortunately for Vertcoin, being beholden to a one man dev team runs contrary to the decentralized ethos. “If you love it, set it free” I understand that you’ve had recent obstacles in your life that must take precedence over Vertcoin. You are not a paid employee and nobody has the right to expect you to dedicate your time to Vertcoin. But this coin is now in a perilous position where ASICs are apparently knocking on the door, and we’re down to one semi active lead dev. Don’t get me wrong, I appreciate the time and effort it took on your part to appear at Hashers United, but publicly implying that you head up a team of active developers is disingenuous, and I fear it does this coin no favours. So I have the following suggestions for you as steps you could take to turn adversity into opportunity, in order for this coin to flourish:
Publically declare that Vertcoin no longer has a formal dev team. This could include a statement to say that you no longer consider yourself to be the lead dev, and that henceforth, to be consistent with Vertcoin’s decentralized nature, development will be “ad hoc” in nature. This might sound very counter-intuitive, but please consider the possibility of stealing a march on the competition by “walking the walk” in terms of true, meaningful decentralization. It’s all about turning a negative into a positive.
Acknowledge that the true power over the destiny of any coin lies not with developers, but with miners. This very much relates to number 1, because where ASICs are concerned, no dev team can ever hope to offer indefinite resistance. We are all mortal.
Give as honest and accurate assessment as you can of the threat of ASICs, and how imminent that threat is to the Vertcoin network.
Provide a realistic and conservative estimate of when you expect to be able to roll out Lyra2.
If you cannot be confident that the answer to 4, is earlier than the answer to 3, then it’s imperative that you issue an open invite to anyone who’s technically capable of producing a fork to an ASIC resistant algo, even if that ASIC resistance is only temporary. Possibly even forking to a higher N-factor? In fact, I recall Boris the Spider making frequent references to “tricks up sleeves” when it came to swerving ASICs, so maybe you could even pull those out of the hat? Really, all options should be open to exploration if the alternative is a one way ticket to ASIC-induced oblivion. We can surely assume that any sensibly proposed fork would achieve consensus while our mining pools are still dominated by gpus? The window to act may be shorter than we think here, given the advanced notice required for a hard fork.
At first glance some of what I’m proposing here may sound drastic, or even abhorrent. But before you dismiss it out of hand, please remember that none of the above need necessarily change your practical day-to-day involvement with Vertcoin. Aside from the obvious priority of ASIC avoidance, these suggestions are primarily designed to rebrand the development of Vertcoin to be in line with our decentralized aspirations. Peace and love depboy
Proposition: Vertcoin Foundation / Association / Governance Team
What I am about to propose here is likely to come across to some as controversial, to others as revolutionary, however I believe this is the best way forward to protect and further enhance what we have already – a community of good people around a technically superior currency. First – something about me, as a declaration of my interests. I was a relative late comer to crypto, getting my first rig up and running a couple of days before Christmas 2013. I was mining LTC and seeing about a 300% return on my electricity costs – fantastic I thought. Then as we all know things started to slide, and before I knew it I was mining at a loss – until I found Vertcoin. My first mined VTC hit my wallet on 29th March, and I've been hooked ever since with both the prospects of the currency and the community surrounding it. Since then I have been involved in setting up vert.geek.nz – which in the golden days of p2pool merged mining was seeing about 85 MH/s from 80+ miners spread around the globe. Those days however are over, I have even taken the step of shutting my own rig down given the massive loss I would be making. I still sit on a modest sum of VTC, hoping that one day it returns to a position of breaking even – not that I intend to dump it on an exchange – which will go some way to satisfy myself that I did indeed make the right decision to back Vertcoin. That all aside, this is the situation I see Vertcoin facing right now. Pros
Technically one of the best coins out there
Talented developers who are keen to do the right thing
A good selection of mining pools
Good presence on exchanges
Obviously the low price
Few places to actually spend Vertcoin
No killer reasons for non-miners to purchase or hold the currency
A development ‘team’, most members of which appear to be absent, who are trying to do too much
That last point – the development ‘team’ - let me expand on this. The vertcoin.org website lists 10 members of the team. Now we all know that a432511 has been working hard and is ever present here. Bushido - vertcoin – makes appearances here from time to time and was significantly involved with the recent SX releases for MON and VTC. However it has been a while since we have heard of or seen any of the other members – I'm not saying they are not active – I am however concerned that a432511 appears to be doing everything lately. Not only is he working on projects like Vertlet, VertVersa, and SharkBite, but he is also acting website developer / maintainer, running all of the PR / marketing work to promote Vertcoin, and acting as the conduit for communication between the community and the development team. Oh, and I believe he still manages to hold down a day job, sleep, eat and do those other things we as humans must do every day. I also see a lot of work going on here by members of the community producing graphics / ads / videos / etc all towards improving our coin. This is all happening, but there doesn't seem to be much, if any, organisation or management of all of these efforts. We have great talent and abilities here in this community – if only we could get it all working together then we might start to see our situation improve. So, to start to address these concerns, I would like to propose the following. I believe we should build a governance / management team that can better organise and facilitate the resources that we have available. This team should be representative of the community – so it should contain members of the development team, pool operators, miners, merchants and possibly others I have omitted. The team should have, at least, the following roles / tasks / goals assigned to it:
Promote Vertcoin as a currency to prospective merchants and purchasers
Drive all PR and marketing campaigns
Maintain and develop the Vertcoin website and other web properties
Be the communication channel between the community and the developers
Work with the developers to define and publish a development roadmap
I believe the development team should be doing just that - development = ensuring this coin maintains it's technical excellence along with making it easier for merchants to sell products and services using Vertcoin. All of the PR and Marketing tasks should be handled by those who have skills and experience in PR and Marketing. Bitcoin have something in place similar to this – see https://bitcoinfoundation.org – they have realised the benefit of having a team whose role it is to promote and enhance the foundations already in place. I believe that for us to see success with our coin – Vertcoin – we too need to come together and work as a unified team. This will need buy-in from both the community and the development team so that it stands a chance to get going and make a positive difference. Let’s start this discussion, let’s try to make a difference and see if we can ensure the security and future of this great community. Please feel free to let me know what you think of this approach, either publicly or privately.
Myriadcoin Bounties List - Donate, Claim, and Suggest!
These are the latest bounties available to the Myriadcoin community. I wanted to showcase them here so I can stick them at the top of this subreddit for a while. The real bounty page is here: http://birdonwheels5.no-ip.org/myriad-bounty/index.php Please donate to ones that interest you. Feel free to claim any of them here (you'll need to provide progress updates to me). Also, this is the place where you can suggest new bounties! Cheers everyone!
Title:Algorithm Monitoring Dashboard
Description: Algorithm Monitoring Dashboard that datamines all current algorithms used by coins but not used by Myriad
Title:Publish a positive Myriadcoin Article on Coindesk
Description: See title. Please include in the article all the good juicy stuff. Topic - Myriadcoin and all the good stuff, 5 algos, really built for commerce/currency due to short block times (average 30secs, wide distribution and large amount of coins in circulation, accepted by major exchanges and some of the payment processors such as Coinpayment), one of the MOST FAIREST in coin distribution as able to mine with ASIC's, GPU's, CPU's, all with equal chance/amount and no instamine but very long block halvings; very very, VERY active development as evidenced by the github (updated to latest bitcoin core .0.9.2.1, not even #2 litecoin is updated to that level) and also as shown by myriadcoinplatform.org projects. Hmmm, I'm sure I missed some other stuff
Description: Modify birdonwheels5's P2Pools to support the following: Ability to query the database for a user's payout address so users can connect with their username. All shares that are found for master and merged coins must be inserted into a MySQL database (SQL command MUST be configurable). Ideally we'd want usernames stored in the sharechain or something like that so people can mine with usernames on all nodes Does "usernames stored in the sharechain" sound familiar? Perhaps you could complete the "DNS Sidechain" bounty, and have a huge head-start on this one.
Description: Create a sidechain that acts as a public directory. This public directory will link a chosen Myriadcoin address to a specific username of the user's choosing. Users must be able to perform this linking via a webpage or the wallet. Both are preferred. An example would look something like: MSJ8nCKxxWicU8DMyqusdFF8v5L6DDvcrx to birdonwheels5. I would now be able to send Myriadcoins directly to birdonwheels5 with the syntax: [email protected] Linking a Myriad address to an email account would NOT work, because the addresses are stored directly on the blockchain, meaning anyone would be able to view your email address. This could potentially lead to spammers datamining the blockchain, and emailing en mass to all the addresses on the sidechain.
Description: Create a multi-algo coin like Myriadcoin except enable auxPoW on at least 2 of the algorithms. You may want to utilize the multi-vPoW concept (myriadplatform.org/multi-vpow/) to retain value of your coin!
Description: I'm looking for someone to turn my SHA256D pool into a multicultural pool! (still not allowed to pee in the water!!). So what i'm saying, i want merged mining enabled! There is currently 125K available for the one who creates this for us. Need anything? Questions? contact me (meziti) on IRC.As a bonus: If this bounty is completed before 14th september I add 50K Before 30th September I add 25K
Description: The goal of this bounty is to incentivize the recruitment of new vendors. Each claim on the bounty will pay 50% of raised funds. Until the first vendor claims this, half of the current amount shown to the right of this description will be paid out.
Bitcoin Stack Exchange is a question and answer site for Bitcoin crypto-currency enthusiasts. It only takes a minute to sign up. Sign up to join this community . Anybody can ask a question Anybody can answer The best answers are voted up and rise to the top Bitcoin . Home ; Questions ; Tags ; Users ; Jobs; Unanswered ; p2pool merged mining. Ask Question Asked 6 years, 3 months ago. Active 4 ... F2Pool is a geographically distributed mining pool, helping miners all over the globe secure Bitcoin and 40+ Proof–of–Work networks since 2013. Merged mining only affect mining of the coin. It does not affect the amount of coins produced, the block times, the block rewards, the price of the coin, the usage of the coin, the community, or the development of the coin. Only miners would have to care about merged mining. Regular users would not need to know or care that their dogecoins were produced at the same time as litecoins. NOTE: This standard is used by Namecoin, but new merged mining data should likely propose a new BIP to supercede it with something based on p2pool's merged mining. The Bitcoin.com mining pool has the lowest share reject rate (0.15%) we've ever seen. Other pools have over 0.30% rejected shares. Furthermore, the Bitcoin.com pool has a super responsive and reliable support team.
In diesem Tutorial geht es um den speziellen P2P-Pool. Früherer Zugang zu Tutorials, Abstimmungen, Live-Events und Downloads https://www.patreon.... How to connect to p2pool for Quark mining. - sorry for crappy audio - Chamath Palihapitiya Live: Bitcoin Halving, BTC Updates, Price and Mining Chamath US Live 57,685 watching Live now DIY Bitcoin Mining: Hardware (part1) - Duration: 7:45. How to setup p2pool jtoomim 1mb_segwit LTC node. p2pool install written by Jtoomim https://forum.bitcoin.com/pools/p2pool-decentralized-dos-resistant-trustle... Gource visualization of p2pool (https://github.com/p2pool/p2pool). Peer-to-peer Bitcoin mining pool