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.
arriving at consensus AND distributing coins via burning Bitcoin instead of electricity/equipment to create permissionless, unfakeable, green, and trust minimized basis over every aspect of sidechain control.
creating Bitcoin peg from altcoin chain to mainchain (the hard direction) by allocating small percentage of Bitcoin intended for burning to reimbursing withdrawals, effectively making it a childchain/sidechain (no oracles or federated multisigs)
This is not an altcoin thread. I'm not making anything. The design discussed options for existing altcoins and new ways to built on top of Bitcoin inheriting some of its security guarantees. 2 parts: First, the design allows any altcoins to switch to securing themselves via Bitcoin instead of their own PoW or PoS with significant benefits to both altcoins and Bitcoin (and environment lol). Second, I explain how to create Bitcoin-pegged assets to turn altcoins into a Bitcoin sidechain equivalent. Let me know if this is of interest or if it exists, feel free to use or do anything with this, hopefully I can help.
how to create continuous sunk costs, permissionless entry, high cost of attacks?
how to do it without needing to build up a new source of hardware capital or energy costs?
how to peg another chain's token value w/o incentivized collusion risk of federation or oracles?
how to make sidechain use fully optional for all Bitcoin parties?
how to allow programmable Bitcoins w/ unlimited permissionless expressiveness w/o forcing mainchain into additional risks?
Solution to first few points:
Continuous Proof of Bitcoin Burn (CPoBB) to distribute supply control and sidechain consensus control to independent parties
Distributes an altcoin for permissionless access and sidechain-only sybil protection.
In case of sidechain block-producer censorship, Bitcoin's independent data availability makes sidechain nodes trivially aware
PoW altcoin switching to CPoBB would trade:
cost of capital and energy -> cost of burnt bitcoin
finality of their PoW -> finality of Bitcoin's PoW
impact on environment -> 0 impact on environment
unforgeable costliness of work -> unforgeable costliness of burn
contract logic can include conditions dependent on real Bitcoins as it's Bitcoin-aware
PoS altcoin switching to CPoBB would trade:
permissioned by coin holders entry -> permissionless entry by anyone with access to Bitcoin
no incentive to give up control or sell coins -> incentive to sell coins to cover the cost of burnt bitcoin
incentivized guaranteed centralization of control over time by staking -> PoW guarantees with same 0 environmental impact
nothing at stake -> recovering sunk costs at stake
contract logic can include conditions dependent on real Bitcoins as it's Bitcoin-aware
We already have a permissionless, compact, public, high-cost-backed finality base layer to build on top - Bitcoin! It will handle sorting, data availability, finality, and has something of value to use instead of capital or energy that's outside the sidechain - the Bitcoin coins. The sunk costs of PoW can be simulated by burning Bitcoin, similar to concept known as Proof of Burn where Bitcoin are sent to unspendable address. Unlike ICO's, no contributors can take out the Bitcoins and get rewards for free. Unlike PoS, entry into supply lies outside the alt-chain and thus doesn't depend on permission of alt-chain stake-coin holders. It's hard to find a more bandwidth or state size protective blockchain to use other than Bitcoin as well so altcoins can be Bitcoin-aware at little marginal difficulty - 10 years of history fully validates in under a day.
What are typical issues with Proof of Burn?
limited burn time window prevents permissionless entry in the future. how many years did it take for most heavily mined projects to become known and well reviewed? many. thus entry into control of supply that's vital to control of chain cannot be dependent on the earliest stage of the project. (counterparty)
"land grabs" - by having limited supply without continuous emission or inflation we encourage holding vs spending.
These issues can be fixed by having Proof of Burn be permanently accessible and continuous: Continuous Proof of Bitcoin Burn CPoBB
This should be required for any design for it to stay permissionless. Optional is constant fixed emission rate for altcoins not trying to be money if goal is to maximize accessibility. Since it's not depending on brand new PoW for security, they don't have to depend on massive early rewards giving disproportionate fraction of supply at earliest stage either. If 10 coins are created every block, after n blocks, at rate of 10 coins per block, % emission per block is = (100/n)%, an always decreasing number. Sidechain coin doesn't need to be scarce money, and could maximize distribution of control by encouraging further distribution. If no burners exist in a block, altcoin block reward is simply added to next block reward making emission predictable. Sidechain block content should be committed in burn transaction via a root of the merkle tree of its transactions. Sidechain state will depend on Bitcoin for finality and block time between commitment broadcasts. However, the throughput can be of any size per block, unlimited number of such sidechains can exist with their own rules and validation costs are handled only by nodes that choose to be aware of a specific sidechain by running its consensus compatible software. Important design decision is how can protocol determine the "true" side-block and how to distribute incentives. Simplest solution is to always :
Agree on the valid sidechain block matching the merkle root commitment for the largest amount of Bitcoin burnt, earliest inclusion in the bitcoin block as the tie breaker
Distribute block reward during the next side-block proportional to current amounts burnt
Bitcoin fee market serves as deterrent for spam submissions of blocks to validate
sidechain block reward is set always at 10 altcoins per block Bitcoin block contains the following content embedded and part of its transactions: tx11: burns 0.01 BTC & OP_RETURN tx56: burns 0.05 BTC & OP_RETURN ... <...root of valid sidechain block version 1> ... tx78: burns 1 BTC & OP_RETURN ... <...root of valid sidechain block version 2> ... tx124: burns 0.2 BTC & OP_RETURN ... <...root of INVALID sidechain block version 3> ...
Validity is deterministic by rules in client side node software (e.g. signature validation) so all nodes can independently see version 3 is invalid and thus burner of tx124 gets no reward allocated. The largest valid burn is from tx78 so version 2 is used for the blockchain in sidechain. The total valid burn is 1.06 BTC, so 10 altcoins to be distributed in the next block are 0.094, 0.472, 9.434 to owners of first 3 transactions, respectively. Censorship attack would require continuous costs in Bitcoin on the attacker and can be waited out. Censorship would also be limited to on-sidechain specific transactions as emission distribution to others CPoB contributors wouldn't be affected as blocks without matching coin distributions on sidechain wouldn't be valid. Additionally, sidechains can allow a limited number of sidechain transactions to happen via embedding transaction data inside Bitcoin transactions (e.g. OP_RETURN) as a way to use Bitcoin for data availability layer in case sidechain transactions are being censored on their network. Since all sidechain nodes are Bitcoin aware, it would be trivial to include. Sidechain blocks cannot be reverted without reverting Bitcoin blocks or hard forking the protocol used to derive sidechain state. If protocol is forked, the value of sidechain coins on each fork of sidechain state becomes important but Proof of Burn natively guarantees trust minimized and permissionless distribution of the coins, something inferior methods like obscure early distributions, trusted pre-mines, and trusted ICO's cannot do. More bitcoins being burnt is parallel to more hash rate entering PoW, with each miner or burner getting smaller amount of altcoins on average making it unprofitable to burn or mine and forcing some to exit. At equilibrium costs of equipment and electricity approaches value gained from selling coins just as at equilibrium costs of burnt coins approaches value of altcoins rewarded. In both cases it incentivizes further distribution to markets to cover the costs making burners and miners dependent on users via markets. In both cases it's also possible to mine without permission and mine at a loss temporarily to gain some altcoins without permission if you want to. Altcoins benefit by inheriting many of bitcoin security guarantees, bitcoin parties have to do nothing if they don't want to, but will see their coins grow more scarce through burning. The contributions to the fee market will contribute to higher Bitcoin miner rewards even after block reward is gone.
What is the ideal goal of the sidechains? Ideally to have a token that has the bi-directionally pegged value to Bitcoin and tradeable ~1:1 for Bitcoin that gives Bitcoin users an option of a different rule set without compromising the base chain nor forcing base chain participants to do anything different. Issues with value pegs:
federation based pegs allow collusion to steal bitcoins stored in multi-party controlled accounts
even if multisig participants are switched or weighted in some trust minimized manner, there's always incentive to collude and steal more
smart contract pegs (plasma, rollups) on base chain would require bitcoin nodes and miners to validate sidechain transactions and has to provide block content for availability (e.g. call data in rollups), making them not optional.
bitcoin nodes shouldn't be sidechain aware so impossible to peg the value
Let's get rid of the idea of needing Bitcoin collateral to back pegged coins 1:1 as that's never secure, independent, or scalable at same security level. As drive-chain design suggested the peg doesn't have to be fast, can take months, just needs to exist so other methods can be used to speed it up like atomic swaps by volunteers taking on the risk for a fee. In continuous proof of burn we have another source of Bitcoins, the burnt Bitcoins. Sidechain protocols can require some minor percentage (e.g. 20%) of burner tx value coins via another output to go to reimburse those withdrawing side-Bitcoins to Bitcoin chain until they are filled. If withdrawal queue is empty that % is burnt instead. Selection of who receives reimbursement is deterministic per burner. Percentage must be kept small as it's assumed it's possible to get up to that much discount on altcoin emissions. Let's use a really simple example case where each burner pays 20% of burner tx amount to cover withdrawal in exact order requested with no attempts at other matching, capped at half amount requested per payout. Example:
withdrawal queue: request1: 0.2 sBTC request2: 1.0 sBTC request3: 0.5 sBTC same block burners: tx burns 0.8 BTC, 0.1 BTC is sent to request1, 0.1 BTC is sent to request2 tx burns 0.4 BTC, 0.1 BTC is sent to request1 tx burns 0.08 BTC, 0.02 BTC is sent to request 1 tx burns 1.2 BTC, 0.1 BTC is sent to request1, 0.2 BTC is sent to request2 withdrawal queue: request1: filled with 0.32 BTC instead of 0.2 sBTC, removed from queue request2: partially-filled with 0.3 BTC out of 1.0 sBTC, 0.7 BTC remaining for next queue request3: still 0.5 sBTC
Withdrawal requests can either take long time to get to filled due to cap per burn or get overfilled as seen in "request1" example, hard to predict. Overfilling is not a big deal since we're not dealing with a finite source. The risk a user that chooses to use the sidechain pegged coin takes on is based on the rate at which they can expect to get paid based on value of altcoin emission that generally matches Bitcoin burn rate. If sidechain loses interest and nobody is burning enough bitcoin, the funds might be lost so the scale of risk has to be measured. If Bitcoins burnt per day is 0.5 BTC total and you hope to deposit or withdraw 5000 BTC, it might take a long time or never happen to withdraw it. But for amounts comparable or under 0.5 BTC/day average burnt with 5 side-BTC on sidechain outstanding total the risks are more reasonable. Deposits onto the sidechain are far easier - by burning Bitcoin in a separate known unspendable deposit address for that sidechain and sidechain protocol issuing matching amount of side-Bitcoin. Withdrawn bitcoins are treated as burnt bitcoins for sake of dividing block rewards as long as they followed the deterministic rules for their burn to count as valid and percentage used for withdrawals is kept small to avoid approaching free altcoin emissions by paying for your own withdrawals and ensuring significant unforgeable losses. Ideally more matching is used so large withdrawals don't completely block everyone else and small withdrawals don't completely block large withdrawals. Better methods should deterministically randomize assigned withdrawals via previous Bitcoin block hash, prioritized by request time (earliest arrivals should get paid earlier), and amount of peg outstanding vs burn amount (smaller burns should prioritize smaller outstanding balances). Fee market on bitcoin discourages doing withdrawals of too small amounts and encourages batching by burners. The second method is less reliable but already known that uses over-collateralized loans that create a oracle-pegged token that can be pegged to the bitcoin value. It was already used by its inventors in 2014 on bitshares (e.g. bitCNY, bitUSD, bitBTC) and similarly by MakerDAO in 2018. The upside is a trust minimized distribution of CPoB coins can be used to distribute trust over selection of price feed oracles far better than pre-mined single trusted party based distributions used in MakerDAO (100% pre-mined) and to a bit lesser degree on bitshares (~50% mined, ~50% premined before dpos). The downside is 2 fold: first the supply of BTC pegged coin would depend on people opening an equivalent of a leveraged long position on the altcoin/BTC pair, which is hard to convince people to do as seen by very poor liquidity of bitBTC in the past. Second downside is oracles can still collude to mess with price feeds, and while their influence might be limited via capped price changes per unit time and might compromise their continuous revenue stream from fees, the leverage benefits might outweight the losses. The use of continous proof of burn to peg withdrawals is superior method as it is simply a minor byproduct of "mining" for altcoins and doesn't depend on traders positions. At the moment I'm not aware of any market-pegged coins on trust minimized platforms or implemented in trust minimized way (e.g. premined mkr on premined eth = 2 sets of trusted third parties each of which with full control over the design). _______________________________________
Brief issues with current altchains options:
PoW: New PoW altcoins suffer high risk of attacks. Additional PoW chains require high energy and capital costs to create permissionless entry and trust minimized miners that are forever dependent on markets to hold them accountable. Using same algorithm or equipment as another chain or merge-mining puts you at a disadvantage by allowing some miners to attack and still cover sunk costs on another chain. Using a different algorithm/equipment requires building up the value of sunk costs to protect against attacks with significant energy and capital costs. Drive-chains also require miners to allow it by having to be sidechain aware and thus incur additional costs on them and validating nodes if the sidechain rewards are of value and importance.
PoS: PoS is permissioned (requires permission from internal party to use network or contribute to consensus on permitted scale), allows perpetual control without accountability to others, and incentivizes centralization of control over time. Without continuous source of sunk costs there's no reason to give up control. By having consensus entirely dependent on internal state network, unlike PoW but like private databases, cannot guarantee independent permissionless entry and thus cannot claim trust minimization. Has no built in distribution methods so depends on safe start (snapshot of trust minimized distributions or PoW period) followed by losing that on switch to PoS or starting off dependent on a single trusted party such as case in all significant pre-mines and ICO's.
Proof of Capacity: PoC is just shifting costs further to capital over PoW to achieve same guarantees.
PoW/PoS: Still require additional PoW chain creation. Strong dependence on PoS can render PoW irrelevant and thus inherit the worst properties of both protocols.
Tokens inherit all trust dependencies of parent blockchain and thus depend on the above.
Embedded consensus (counterparty, veriblock?, omni): Lacks mechanism for distribution, requires all tx data to be inside scarce Bitcoin block space so high cost to users instead of compensated miners. If you want to build a very expressive scripting language, might very hard & expensive to fit into Bitcoin tx vs CPoBB external content of unlimited size in a committed hash. Same as CPoBB is Bitcoin-aware so can respond to Bitcoin being sent but without source of Bitcoins like burning no way to do any trust minimized Bitcoin-pegs it can control fully.
Few extra notes from my talks with people:
fees must be high to be included in next block (and helps pay and bribe bitcoin miners), RBF use is encouraged to cancel late transactions
what if not enough burners, just passive nodes? you can burn smallest amount of bitcoin yourself when you have a transaction you want to go through
using commit hashes on bitcoin to lock altcoin state isn't new (e.g. kmd) but usually those rely on some federation or permissioned proof of stake mechanism with no real costs. this is combination of both.
this is not exactly like counterparty's embedded consensus as block data and transactions are outside Bitcoin, but consensus is derived with help of embedded on Bitcoin data.
deterministic randomness (e.g. via that block's hash) could be used to assign winning sidechain block weighted by amount burned to allow occasional blocks formed by others curbing success rate of censorship by highest burner
wants to transition away from using proof of burn via tunable proofs and native proof of work (whitepaper)
a dominant premine (trust maximized) relative to emission that defeats the purpose of distributing control over incentives (figure 3 in tokenpaper suggests premine still ~30%-70% by year 2050)
variable emission rate "adaptive mint and burn" makes supply unpredictable (and possibly gameable)
additional rewards that aren't trust minimized like "app mining" and "user incentives" possibly gameable with premine
election of a leader includes their own PoW to be elected even at start (5% cap), why lol?
blockstack also suggested use of randomness that depends on that block so Bitcoin miners that already spent energy mining that block can't just re-do it to get picked at no cost
if can burn bitcoins directly via op_return tx would help to use 1 less output and be provably prunable for utxo set (not sure if that's relayed as standard)
Main questions to you:
why not? (other than blocktime)
can this be done without an altcoin? (Not sure and don't think so w/o compromising unforgeable costliness and thus trust minimization. At least it's not using an altcoin that's clearly centralized.)
how to make it less detectable by Bitcoin miners? ( BMM could use some techniques described here: https://twitter.com/SomsenRuben/status/1210040270328254464 ) ( Perhaps since sidechain nodes receive proposed blocks independently and can figure out their hash, the commit message ( sidechain id + block commit + miner address) can be hashed one more time before its placed on Bitcoin, making miners unaware until after Bitcoin block is found that this is that sidechain's burn. Sidechain block producers would have to delay sidechain block propagation until after Bitcoin block is propagated, 10 minutes blocktime helps here. Hiding the fact that Bitcoin is burnt until after the fact is another possibly important matter. )
Should reward be split between all valid blocks or just winner gets all? (Blockstacks approach does not reward blocks marked by different from leader chaintip. That seems dangerous since sidechain tx sorting would be difficult to match and could take significant time to be compensated for perfectly valid work and coins burned. It doesn't seem as necessary in burning since we're not expending costs based on only one previous block version, the costs are independent of block assembly. Tradeoff is between making it easier for independent "mining" of sidechain and making it easier to validate for full nodes on sidechain)
Hello, I’ve been trying to decide on a FPGA development board, and have only been able to find posts and Reddit threads from 4-5 years ago. So I wanted to start a new thread and ask about the best “mid-range” FGPA development board in 2018. (Price range $100-$300.) I started with this Quora answer about FPGA boards, from 2013. The Altera DE1 sounded good. Then I looked through the Terasic DE boards. Then I found this Reddit thread from 2014, asking about the DE1-SoC vs the Cyclone V GX Starter Kit: https://www.reddit.com/FPGA/comments/1xsk6w/cyclone_v_gx_starter_kit_vs_de1soc_board/ (I was also leaning towards the DE1-SoC.) Anyway, I thought I better ask here, because there are probably some new things to be aware of in 2018. I’m completely new to FPGAs and VHDL, but I have experience with electronics/microcontrollers/programming. My goal is to start with some basic soft-core processors. I want to get some C / Rust programs compiling and running on my own CPU designs. I also want to play around with different instruction sets, and maybe start experimenting with asynchronous circuits (e.g. clock-less CPUs) Also I don’t know if this is possible, but I’d like to experiment with ternary computing, or work with analog signals instead of purely digital logic. EDIT: I just realized that you would call those FPAAs, i.e. “analog” instead of “gate”. Would be cool if there was a dev board that also had an FPAA, but no problem if not. EDIT 2: I also realized why "analog signals on an FPGA" doesn't make any sense, because of how LUTs work. They emulate boolean logic with a lookup table, and the table can only store 0s and 1s. So there's no way to emulate a transistor in an intermediate state. I'll just have play around with some transistors on a breadboard. UPDATE: I've put together a table with some of the best options:
A very simple FPGA development board that plugs into a Raspberry Pi, so you have a "backup" hard-core CPU that can control networking, etc. Supports a huge range of pmod accessories. You can write a program/circuit so that the Raspberry Pi CPU and the FPGA work together, similar to a SoC. Proprietary bitstream is fully reverse engineered and supported by Project IceStorm, and there is an open-source toolchain that can compile your hardware design to bitstream. Has everything you need to start experimenting with FPGAs.
Xilinx Zynq 7-Series SoC - ARM Cortex-A9 processor, and Artix-7 FPGA. 125 IO pins. 1GB DDR2 RAM. Texas Instruments WiLink 8 wireless module for 802.11n Wi-Fi and Bluetooth 4.1. No LEDs or buttons, but easy to wire up your own on a breadboard. If you want to use a baseboard, you'll need a snickerdoodle black ($195) with the pins in the "down" orientation. (E.g. The "breakyBreaky breakout board" ($49) or piSmasher SBC ($195)). The snickerdoodle one only comes with pins in the "up" orientation and doesn't support any baseboards. But you can still plug the jumpers into the pins and wire up things on a breadboard.
Has one of the latest Xilinx SoCs. 2 GB (512M x32) LPDDR4 Memory. Wi-Fi / Bluetooth. Mini DisplayPort. 1x USB 3.0 type Micro-B, 2x USB 3.0 Type A. Audio I/O. Four user-controllable LEDs. No buttons and limited LEDs, but easy to wire up your own on a breadboard
Xilinx Zynq 7000 SoC (ARM Cortex-A9, 7-series FPGA.) 1 GB DDR3 RAM. A few switches, push buttons, and LEDs. USB and Ethernet. Audio in/out ports. HDMI source + sink with CEC. 8 Total Processor I/O, 40 Total FPGA I/O. Also a faster version for $299 (Zybo Z7-20).
Same as DE10-Standard, but not as many peripherals, buttons, LEDs, etc.
icoBoard ($100). (Buy it here.) The icoBoard plugs into a Raspberry Pi, so it's similar to having a SoC. The iCE40-HX8K chip comes with 7,680 LUTs (logic elements.) This means that after you learn the basics and create some simple circuits, you'll also have enough logic elements to run the VexRiscv soft-core CPU (the lightweight Murax SoC.) The icoBoard also supports a huge range of pluggable pmod accessories:
numato Mimas A7 ($149). An excellent development board with a Xilinx Artix 7 FPGA, so you can play with a bigger / faster FPGA and run a full RISC-V soft-core with all the options enabled, and a much higher clock speed. (The iCE40 FPGAs are a bit slow and small.)
I ordered a iCE40-HX8K Breakout Board to try out the IceStorm open source tooling. (I would have ordered an icoBoard if I had found it earlier.) I also bought a numato Mimas A7 so that I could experiment with the Artix 7 FPGA and Xilinx software (Vivado Design Suite.)
What can I do with an FPGA? / How many LUTs do I need?
VexRiscv is "A FPGA friendly 32 bit RISC-V CPU implementation." This is a RISC-V implementation written in SpinalHDL. VexRiscv has a lot of plugin and configuration options. The Murax SoC is a very light SoC that can run on an iCE40-HX8k (but probably not the 1k FPGA that only has 1,280 LUTs). The Briey SoC only runs on Xilinx or Altera FPGAs.
Ritocoin - a 100% community driven project based on Ravencoin
tl:dr: Ritocoin is a code fork of the Ravencoin codebase and continues to track future Ravencoin developments. The project was launched to provide a more community-oriented blockchain with the same functionality as Ravencoin, without a corporate overseer, and with a more flexible model for community participation and development. It’s intention is to be a hacker’s playground for innovative ideas. Specifications Proof-of-Work Algorithm: X21S Block Time: 60 seconds POW Block Reward: Smooth curve down Community fund: 1% first year Difficulty Retargeting: DGW-180 Maximum Supply: 6 months: 993,521,892 RITO 1 year: 1,227,448,858 RITO 5 years: 1,762,210,058 RITO 10 years: 1,820,404,381 RITO 50 years: 2,030,907,256 RITO 100 years: 2,293,707,246 RITO Infinite: 10 RITO per block in perpetuity Pre-mine: None Masternodes: Researching for use case Asset layer: Was enabled at height 50,000 Links Website /ritocoin Explorer Github Whitepaper twitter [ANN] X21S This hashing algorithm was created specifically for Ritocoin, and was designed to resist FPGAs, ASICs, and NiceHash. It is X16S (16 algorithms shuffled and hashed),, followed by 5 additional hashing algorithms: haval256, tiger, lyra2, gost512, and sha256. The inclusion of lyra2 brings numerous advantages, making parallelization of the algorithm practically impossible, with each step relying on the previous step having already been computed. It is a “friendly” algorithm that makes GPUs produce much less heat and uses less electricity during mining. Take your time to learn more about us in the below story of Ritocoin... The spirit of Bitcoin continues to inspire, empower and enable people around the globe. Ten years later, just as it seemed Bitcoin was being defined by commercial agents and regulated governance, that same free and independent spirit imbued the Ravencoin community. In ten short months, however, 30% of the Ravencoin project’s net hash comes from NiceHash and the looming impact of the imminent FPGA mining cards and X16R bitstreams certainly promises to shake up the dream of this GPU miner’s darling. Ravencoin’s fair launch genuinely inspired our developers and supporters. We admire the way Ravencoin came out swinging — fighting for fairness, an honest distribution of coins and a place where GPU miners could thrive. The asset layer attracted many more miners and investors to the pools. Many Ritocoin enthusiasts came from the Ravencoin community, and continue their association with that project. The whole crypto ecosystem should appreciate the work begun by Ravencoin. Obviously they continue to inspire and motivate us to this day. It’s the reason we took action. We decided to start our own project which focuses upon at least two pillars of decentralized networks in the crypto space: community governance and a fair distribution of coins. It is a core belief throughout Ritocoin that in order to successfully develop and maintain this hacker’s playground — a place where a broad range of ideas could be tried and allowed to flourish — these two ideals must be allowed to drive and guide our community. This deep focus on community choices creates a project flexible enough to support most ideas, and agile enough to define new frontiers. A mining network’s distributed ledger is defined by its technology. Like many in the broader crypto-mining community, we value the GPU for its accessibility. These processors are available for purchase all around the world without any legal restrictions. GPUs are vastly more accessible for hobbyists and miners to acquire. They can be shipped nearly anywhere around the globe, a nice benefit to the popular secondary market which has sprung up much to the chagrin of PC gamers. More constraints exist for the ASIC and FPGA miner. Laws in some parts of the world restrict people from using or buying ASIC and FPGA mining hardware. This alone is directly in confrontation with Ritocoin’s core values of decentralized stewardship and sovereignty. The GPU, in essence, is like your voice. Anyone with the means of acquiring one GPU should be able to have their voice heard. ASIC and FPGA mining devalues the GPU miner’s voice and silos that coin’s network away from the small scale and personal mining operator. A truly community driven project means each stakeholder, regardless of size of contribution to the network’s net hash, has an opportunity to build, vote and direct. If you are already familiar with our website, discord or whitepaper, you are probably aware that masternodes had been proposed as a feature of the network from the beginning. This opened the door to ongoing discussions in the Ritocoin community regarding ● A masternode’s true purpose ● What benefit they provide to the project ● How the benefit is realized ● The collateral This discussion, governed entirely by stakeholders across the extended network yielded a defining moment for our vision of flexibility. We have not yet found the potential utility of masternodes, however, the conversation has not reached an extent to where we could abandon the idea. To quote one of our developers during this discussion on our Discord:
“Just want to give a reminder here that even though masternodes are on the roadmap, it is not set in stone. This coin belongs to the community and we will do what we as a community want to do. If we conclude that we want to take this coin a different direction than masternodes, then that is what we’ll do.” --traysi
We are all volunteers at Ritocoin. Our moderators and community leaders try to give immediate support to all users that require it. Contact us in Discord or Telegram, not only for support, but, proposing new ideas, revising old ones and just so you can find a place to get together and find people to hang out with. You are well within your rights to enjoy yourself at any given moment, and, should you feel so inclined to begin working with the team, we just so happen to be looking for ambitious individuals that see themselves as being part of a greater vision, are inspired by change, and inspired to be the change they want to see making things better in this world. Join us in a space where your ideas to build something great can become a reality. We are eager to know what you think is best for the future of Rito. What steps would you take to become more resilient, stronger, fair and decentralized? Because at the end of the day, like it or not, love it or leave it.. this is your coin, too. You can become a significant part of this project. We will help you further develop the role you wish to fill in the cryptocurrency space — influencer, developer, analyst, you name it. This is not a just-for-developer’s playground. We want the enthusiasts. We want the perplexed and the rabbit-hole divers. This is the coin for everyone who is trying to find their place on the path that Satoshi began unfolding in 2008 after the collapse of the housing market rippled out into the subsequent crash of global markets. That’s why we have Bitcoin, remember? Be your own bank. This is why Satoshi and Bitcoin.org kept their software open source. It’s up to us to keep the torch ablaze. Community funds For the first year, about 1% of mined coins are set aside into a developers fund that is used to provide bounties to the community developers who make substantial development contributions to the Ritocoin ecosystem. We have already paid out numerous bounties for important work that has already benefits Ritocoin in substantial ways. We also have another donation-driven community fund that has recently been put together for the purposes of doing fun contests and things like that. Cooperation and collaborations We have discovered a number of fatal flaws in the original Ravencoin codebase and worked with the Ravencoin developers to get those fixed in both Ritocoin and Ravencoin. This work has benefitted Ravencoin in numerous ways and we look forward to a long time of collaboration and cooperation between us and them. Many members of the Safecoin team are also in our discord group, and have collaborated with us in shaping the future decisions of Ritocoin. We have several thousand members in our group and they represent all walks of cryptocurrency life. We invite all coin developers, miners and enthusiasts to join our discord and be a part of this coin that truly belongs entirely to the community. Block reward A couple weeks ago we met for a scheduled meeting in our discord group and had a lengthy conversation about the block reward. Our block reward started at 5,000 RITO per block (every 60 seconds) just like Ravencoin. This extremely high number of coins coupled with the high profitability of mining led to unforeseen consequences with pools auto-exchanging the coin into bitcoin. This dumping by non-community miners had a very negative impact on the community sentiment and morale, as we watched the exchange price plunge. We looked at other coins and realized that this fate has befell many other coins with high block rewards. Following much discussion, we decided to change the reward structure. Starting around March 19th the block rewards will start to slowly go down in a curve until it reaches 1,000. Then the reduction will be even more slowed down with block rewards exponentially dropping at periodic intervals. We have posted charts on our website that shows what the long-term effects of our reward reducing algorithms will be. As a miner, the next 2 months will be a great time to mine and hold, while the block reward is still fairly high. We encourage all miners and cryptocurrency enthusiasts to take advantage of the current favourable block reward and build a nice holding for yourself. Then join the community and be a part of the fun we’re having with this project. This post was prepared by a collaboration of multiple Ritocoin members and was posted to reddit by the core developer Trevali, who posts to reddit under the ritocoin username and will be very happy to answer any questions anybody may have about our project. Traysi (well known in the Ravencoin community) is also an active Ritocoin developer and may come to this thread if needed. We welcome any questions from any of you regarding our project!
Developer Update - New BiblePay Miner (Stratum Compatible) In Progress
" So if you are all wondering what the devs are working on -- I'm working on a new BiblePay miner. Just to explain the situation a little more, a year ago when people asked me about possibly separating the miner program from the core wallet, I didnt really like the idea because I felt we would be on track for continually modifying the mining algo to be impossible to run outside the core. However, I feel that our POBH algorithm has matured to the point where its no longer changing - so as to reduce the risk of someone trying to port it to GPU or ASIC, I feel this is a good time for us to make the move - to make a standalone miner - and give any new devs out there the chance to enhance POBH. This will also allow us to add stratum support and standardize our pool to be p2p/stratum compatible. The bbp-miner.exe must be outside of the wallet primarily to fulfill the stratum protocol request (as putting stratum inside the core wallet violates the code of conduct for exchanges). So, I decided to go ahead and start creating a bbp-miner.exe, and at the very least we will test its performance with solo mining. Then if it offers an edge over the core wallet, we will then look into making our pool(s) stratum compatible and standardizing the miner to be a code-branch, the pool to be a branch of p2pool, etc, to be compatible with the bitcoin and dash specs in the latest evo code base (for future maintenance). This part is also important so that we can attract more blockchain devs to the project and to allow us to clean up legacy code and be more fast/lean. So far, I have ported the KJV bible into bbp-miner.exe, a cross-platform C program, using the AES256, base64, SHA256, X11, MD5 and our getblocktemplate rules. The miner will work on all platforms, of course. I'll let you all know as soon as a I have a working solo miner, so we can test it. If its performance is worthy, then we will move on to making the pool compatible with dash and bitcoin, etc (with p2pool) and stratum. " - Rob, Founder and Lead Developer Reference: https://bitcointalk.org/index.php?topic=2388064.msg52681896#msg52681896
It is simple, provable engineering fact that storing data in transaction outputs makes block validation, double-spend checks and other critical consensus operations more expensive. More RAM is used on average. In general, it burdens the entire network. UTXO is our most critical resource currently.
Further, you cannot handwave away the problem that, if transactions is infinitesimally cheap, people will abuse the system by sending non-currency data messages. Lots of them. Gigabytes worth, as other alt-chain field experience has proven. To the point that bitcoin-the-currency transactions are impacted. "I want a system that can process infinite amounts of traffic" is in the land of unicorns. The accusation of dev laziness is particularly rich, given that SatoshiDICE abused the blockchain in this way, by sending informational messages (IM "You lost a bet") via the blockchain. If you want an infinite amount of transactions per 10 minutes, you have just reinvented the Internet... over the blockchain. Poorly.
one cannot ignore a key attribute conferring by a limit like the 1MB limit: it encourages engineering efficiencies to be sought. Programmers have an incentive to actively seek ways to reduce the number of transactions, or reduce transaction size, when faced with a limited resource. Some business models simply don't care about that part of the equation. It's not a conspiracy by Gavin and the Bitcoin Foundation funders, it is simply one facet of some bitcoin businesses. They make money with increased transaction volume. That's fine, but a key economic counter-point is that these businesses are not bearing the costs of the mining/blockchain impact of a million-TX-per-day policy.
It's open source. Fork away. Though the consequence is that you remain at a higher, hardcoded fee level, and people will still dump megabytes worth of non-currency data into the blockchain (wikileaks cables etc.).
There have been chains of hashes and chains of digital signatures before. What makes bitcoin different is that it is timestamping these digital messages, and protecting those timestamps against being reversed. The currency aspect of bitcoin is simply a layer on top of the distributed timestamping service
Satoshi also intended the subsidy-free, fee-only future to support bitcoin. He did not describe fancy assurance contracts and infinite block sizes; he cleared indicated that fees would be driven in part by competition for space in the next block.
Any miner that increases MAX_BLOCK_SIZE beyond 1MB will self-select themselves away from the network, because all other validating nodes would ignore that change. Just like if a miner decides to issue themselves 100 BTC per block. All other validating nodes consider that invalid data, and do not relay or process it further.
If the users are not voting (validating), then it is trivial for miners to rewrite the rules. If the users are fully validating, then a miner decision to have each block produce 50 BTC again would be instantly rejected.
In an unfunded open source project, arguing all day about the lack of full-engineering-team rigor is entirely wasted energy. Blame the dev team if that is your favorite target, that will not magically create extra time in the day or extra manpower to accomplish these extra tasks being demanded by non-contributors. The time spent whining about what an unfunded effort fails to do could be better spent, say, creating a test network of full nodes running all known bitcoind versions, 0.3 through present. And test, test, test changes through that.
A hard fork is a significant event that knocks legitimate users off the network, makes coins unspendable, or potentially makes the same coins spendable in two different locations, depending on whether or not you're talking to an updated node. It is, to pick a dramatic term, an Extinction Level Event. If done poorly, a hard fork could make it impossible for reasonable merchants to trust the bitcoins they receive, the very foundation of their economic value. Furthermore, a hard fork is akin to a Constitutional Convention: a hard fork implies the ability to rewrite the ground rules of bitcoin, be it block size, 21M limit, SHA256 hash, or other hard-baked behavior. Thus, there is always the risk of unpredictable miners, users and devs changing more than just the block size precisely because it makes the most engineering sense to change other hard-to-change features at the time of hard-fork. It is a nuclear option with widespread economic consequences for all bitcoin users.
Being the person who actually posted a faux-patch increasing the block size limit, it is important to understand why I disagree with that now... it was erroneously assuming that the block size was the whole-picture, and not a simple, lower layer solution in a bigger picture. The block size is an intentionally limited economic resource, just like the 21,000,000-bitcoin limit.
Boy that's a shortsighted analysis. Bitcoin will grow layers above the base layer -- the blockchain -- that will enable instant transactions, microtransactions, and other scalable issues. Do not think that the blockchain is the only way to transfer bitcoins. Larger aggregators will easily compensate for current maximum block size in a scalable manner. All nation-state/fiat currencies are multi-layer. Too many people look at what bitcoin does now, and assume that those are the only currency services that will ever exist.
Transactions will not always be free. Any time there are a lot of transactions being sent, free transactions get the lowest priority and might have to wait to make it into a block. If blocks are often full, you will need to pay a transaction fee to get priority.
It is not as good when obviously-still-learning people are billing their project as the "future of bitcoin" and misleading people into thinking they are a bitcoin expert, and are misleading people into thinking they are producing high quality, proven code (and potentially taking thousands of dollars for it). Those who are not coders lack the skills to judge this sort of thing, and only have hype from this thread to go on.
Miners only select (or ignore) transactions provided to them. The bitcoin client you run chooses what transactions and blocks to validate and relay. Miners cannot change the rules without bitcoin user agreement.
I think users with older clients, holders of older bitcoins quite appreciate the struggle to maintain backwards compat. Nobody wants to wake up in the morning, to discover that their money is unspendable outside of a required upgrade.
My brief observation of most common Consensus Algorithms
I have studied most common consensus algorithms. Here is the summary, maybe for someone it will be helpful. My goal is to describe every specific consensus briefly so everyone can easily understand it. *Please let me know if I have wrote something wrong, or maybe you are aware of interesting algorithm, I have missed. [Proof of Work] - very short, cuz it's well-known.  Bitcoin - to generate a new block miner must generate hash of the new block header that is in line with given requirements. Others: Ethereum, Litecoin etc. [Hybrid of PoW and PoS]  Decred - hybrid of “proof of work” and “proof of stake”. Blocks are created about every 5 minutes. Nodes in the network looking for a solution with a known difficulty to create a block (PoW). Once the solution is found it is broadcast to the network. The network then verifies the solution. Stakeholders who have locked some DCR in return for a ticket* now have the chance to vote on the block (PoS). 5 tickets are chosen pseudo-randomly from the ticket pool and if at least 3 of 5 vote ‘yes’ the block is permanently added to the blockchain. Both miners and voters are compensated with DCR : PoS - 30% and PoW - 60% of about 30 new Decred issued with a block. * 1 ticket = ability to cast 1 vote. Stakeholders must wait an average of 28 days (8,192 blocks) to vote their tickets. [Proof of Stake]  Nxt - The more tokens are held by account, the greater chance that account will earn the right to generate a block. The total reward received as a result of block generation is the sum of the transaction fees located within the block. Three values are key to determining which account is eligible to generate a block, which account earns the right to generate a block, and which block is taken to be the authoritative one in times of conflict: base target value, target value and cumulative difficulty. Each block on the chain has a generation signature parameter. To participate in the block's forging process, an active account digitally signs the generation signature of the previous block with its own public key. This creates a 64-byte signature, which is then hashed using SHA256. The first 8 bytes of the resulting hash are converted to a number, referred to as the account hit. The hit is compared to the current target value(active balance). If the computed hit is lower than the target, then the next block can be generated.  Peercoin (chain-based proof of stake) - coin age parameter. Hybrid PoW and PoS algorithm. The longer your Peercoins have been stationary in your account (to a maximum of 90 days), the more power (coin age) they have to mint a block. The act of minting a block requires the consumption of coin age value, and the network determines consensus by selecting the chain with the largest total consumed coin age. Reward - minting + 1% yearly.  Reddcoin (Proof of stake Velocity) - quite similar to Peercoin, difference: not linear coin-aging function (new coins gain weight quickly, and old coins gain weight increasingly slowly) to encourage Nodes Activity. Node with most coin age weight have a bigger chance to create block. To create block Node should calculate right hash. Block reward - interest on the weighted age of coins/ 5% annual interest in PoSV phase.  Ethereum (Casper) - uses modified BFT consensus. Blocks will be created using PoW. In the Casper Phase 1 implementation for Ethereum, the “proposal mechanism" is the existing proof of work chain, modified to have a greatly reduced block reward. Blocks will be validated by set of Validators. Block is finalised when 2/3 of validators voted for it (not the number of validators is counted, but their deposit size). Block creator rewarded with Block Reward + Transaction FEES.  Lisk (Delegated Proof-of-stake) - Lisk stakeholders vote with vote transaction (the weight of the vote depends on the amount of Lisk the stakeholder possess) and choose 101 Delegates, who create all blocks in the blockchain. One delegate creates 1 block within 1 round (1 round contains 101 blocks) -> At the beginning of each round, each delegate is assigned a slot indicating their position in the block generation process -> Delegate includes up to 25 transactions into the block, signs it and broadcasts it to the network -> As >51% of available peers agreed that this block is acceptable to be created (Broadhash consensus), a new block is added to the blockchain. *Any account may become a delegate, but only accounts with the required stake (no info how much) are allowed to generate blocks. Block reward - minted Lisks and transaction fees (fees for all 101 blocks are collected firstly and then are divided between delegates). Blocks appears every 10 sec.  Cardano (Ouroboros Proof of Stake) - Blocks(slots) are created by Slot Leaders. Slot Leaders for N Epoch are chosen during n-1 Epoch. Slot Leaders are elected from the group of ADA stakeholders who have enough stake. Election process consist of 3 phases: Commitment phase: each elector generates a random value (secret), signs it and commit as message to network (other electors) saved in to block. -> Reveal phase: Each elector sends special value to open a commitment, all this values (opening) are put into the block. -> Recovery phase: each elector verifies that commitments and openings match and extracts the secrets and forms a SEED (randomly generated bytes string based on secrets). All electors get the same SEED. -> Follow the Satoshi algorithm : Elector who have coin which corresponded to SEED become a SLOT LEADER and get a right to create a block. Slot Leader is rewarded with minted ADA and transactions Fee.  Tezos (Proof Of Stake) - generic and self-amending crypto-ledger. At the beginning of each cycle (2048 blocks), a random seed is derived from numbers that block miners chose and committed to in the penultimate cycle, and revealed in the last. -> Using this random seed, a follow the coin strategy (similar to Follow The Satoshi) is used to allocate mining rights and signing rights to stakeholders for the next cycle*. -> Blocks are mined by a random stakeholder (the miner) and includes multiple signatures of the previous block provided by random stakeholders (the signers). Mining and signing both offer a small reward but also require making a one cycle safety deposit to be forfeited in the event of a double mining or double signing. * the more coins (rolls) you have - the more your chance to be a minesigner.  Tendermint (Byzantine Fault Tolerance) - A proposal is signed and published by the designated proposer at each round. The proposer is chosen by a deterministic and non-choking round robin selection algorithm that selects proposers in proportion to their voting power. The proposer create the block, that should be validated by >2/3 of Validators, as follow: Propose -> Prevote -> Precommit -> Commit. Proposer rewarded with Transaction FEES.  Tron (Byzantine Fault Tolerance) - This blockhain is still on development stage. Consensus algorithm = PoS + BFT (similar to Tendermint): PoS algorithm chooses a node as Proposer, this node has the power to generate a block. -> Proposer broadcasts a block that it want to release. -> Block enters the Prevote stage. It takes >2/3 of nodes' confirmations to enter the next stage. -> As the block is prevoted, it enters Precommit stage and needs >2/3 of node's confirmation to go further. -> As >2/3 of nodes have precommited the block it's commited to the blockchain with height +1. New blocks appears every 15 sec.  NEO (Delegated Byzantine Fault Tolerance) - Consensus nodes* are elected by NEO holders -> The Speaker is identified (based on algorithm) -> He broadcasts proposal to create block -> Each Delegate (other consensus nodes) validates proposal -> Each Delegate sends response to other Delegates -> Delegate reaches consensus after receiving 2/3 positive responses -> Each Delegate signs the block and publishes it-> Each Delegate receives a full block. Block reward 6 GAS distributed proportionally in accordance with the NEO holding ratio among NEO holders. Speaker rewarded with transaction fees (mostly 0). * Stake 1000 GAS to nominate yourself for Bookkeeping(Consensus Node)  EOS (Delegated Proof of Stake) - those who hold tokens on a blockchain adopting the EOS.IO software may select* block producers through a continuous approval voting system and anyone may choose to participate in block production and will be given an opportunity to produce blocks proportional to the total votes they have received relative to all other producers. At the start of each round 21 unique block producers are chosen. The top 20 by total approval are automatically chosen every round and the last producer is chosen proportional to their number of votes relative to other producers. Block should be confirmed by 2/3 or more of elected Block producers. Block Producer rewarded with Block rewards. *the more EOS tokens a stakeholder owns, the greater their voting power [The XRP Ledger Consensus Process]  Ripple - Each node receives transaction from external applications -> Each Node forms public list of all valid (not included into last ledger (=block)) transactions aka (Candidate Set) -> Nodes merge its candidate set with UNLs(Unique Node List) candidate sets and vote on the veracity of all transactions (1st round of consensus) -> all transactions that received at least 50% votes are passed on the next round (many rounds may take place) -> final round of consensus requires that min 80% of Nodes UNL agreeing on transactions. It means that at least 80% of Validating nodes should have same Candidate SET of transactions -> after that each Validating node computes a new ledger (=block) with all transactions (with 80% UNL agreement) and calculate ledger hash, signs and broadcasts -> All Validating nodes compare their ledgers hash -> Nodes of the network recognize a ledger instance as validated when a 80% of the peers have signed and broadcast the same validation hash. -> Process repeats. Ledger creation process lasts 5 sec(?). Each transaction includes transaction fee (min 0,00001 XRP) which is destroyed. No block rewards. [The Stellar consensus protocol]  Stellar (Federated Byzantine Agreement) - quit similar to Ripple. Key difference - quorum slice. [Proof of Burn]  Slimcoin - to get the right to write blocks Node should “burn” amount of coins. The more coins Node “burns” more chances it has to create blocks (for long period) -> Nodes address gets a score called Effective Burnt Coins that determines chance to find blocks. Block creator rewarded with block rewards. [Proof of Importance]  NEM - Only accounts that have min 10k vested coins are eligible to harvest (create a block). Accounts with higher importance scores have higher probabilities of harvesting a block. The higher amount of vested coins, the higher the account’s Importance score. And the higher amount of transactions that satisfy following conditions: - transactions sum min 1k coins, - transactions made within last 30 days, - recipient have 10k vested coins too, - the higher account’s Important score. Harvester is rewarded with fees for the transactions in the block. A new block is created approx. every 65 sec. [Proof of Devotion]  Nebulas (Proof of Devotion + BFT) - quite similar to POI, the PoD selects the accounts with high influence. All accounts are ranked according to their liquidity and propagation (Nebulas Rank) -> Top-ranked accounts are selected -> Chosen accounts pay deposit and are qualified as the blocks Validators* -> Algorithm pseudo-randomly chooses block Proposer -> After a new block is proposed, Validators Set (each Validator is charged a deposit) participate in a round of BFT-Style voting to verify block (1. Prepare stage -> 2. Commit Stage. Validators should have > 2/3 of total deposits to validate Block) -> Block is added. Block rewards : each Validator rewarded with 1 NAS. *Validators Set is dynamic, changes in Set may occur after Epoch change. [IOTA Algorithm]  IOTA - uses DAG (Directed Acyclic Graph) instead of blockchain (TANGLE equal to Ledger). Graph consist of transactions (not blocks). To issue a new transaction Node must approve 2 random other Transactions (not confirmed). Each transaction should be validate n(?) times. By validating PAST(2) transactions whole Network achieves Consensus. in Order to issue transaction Node: 1. Sign transaction with private key 2. choose two other Transactions to validate based on MCMC(Markov chain Monte Carlo) algorithm, check if 2 transactions are valid (node will never approve conflicting transactions) 3. make some PoW(similar to HashCash). -> New Transaction broadcasted to Network. Node don’t receive reward or fee. [PBFT + PoW]  Yobicash - uses PBFT and also PoW. Nodes reach consensus on transactions by querying other nodes. A node asks its peers about the state of a transaction: if it is known or not, and if it is a doublespending transaction or not. As follow : Node receives new transaction -> Checks if valid -> queries all known nodes for missing transactions (check if already in DAG ) -> queries 2/3 nodes for doublepsending and possibility -> if everything is ok add to DAG. Reward - nodes receive transaction fees + minting coins. [Proof of Space/Proof of Capacity]  Filecoin (Power Fault Tolerance) - the probability that the network elects a miner(Leader) to create a new block (it is referred to as the voting power of the miner) is proportional to storage currently in use in relation to the rest of the network. Each node has Power - storage in use verified with Proof of Spacetime by nodes. Leaders extend the chain by creating a block and propagating it to the network. There can be an empty block (when no leader). A block is committed if the majority of the participants add their weight on the chain where the block belongs to, by extending the chain or by signing blocks. Block creator rewarded with Block reward + transaction fees. [Proof of Elapsed Time]  Hyperledger Sawtooth - Goal - to solve BFT Validating Nodes limitation. Works only with intel’s SGX. PoET uses a random leader election model or a lottery based election model based on SGX, where the protocol randomly selects the next leader to finalize the block. Every validator requests a wait time from an enclave (a trusted function). -> The validator with the shortest wait time for a particular transaction block is elected the leader. -> The BlockPublisher is responsible for creating candidate blocks to extend the current chain. He takes direction from the consensus algorithm for when to create a block and when to publish a block. He creates, Finalizes, Signs Block and broadcast it -> Block Validators check block -> Block is created on top of blockchain. [Other]  Byteball (Delegated Byzantine Fault Tolerance) - only verified nodes are allowed to be Validation nodes (list of requirements https://github.com/byteball/byteball-witness). Users choose in transaction set of 12 Validating nodes. Validating nodes(Witnesses) receive transaction fees.  Nano - uses DAG, PoW (HashCash). Nano uses a block-lattice structure. Each account has its own blockchain (account-chain) equivalent to the account’s transaction/balance history. To add transaction user should make some HashCash PoW -> When user creates transaction Send Block appears on his blockchain and Receive block appears on Recipients blockchain. -> Peers in View receive Block -> Peers verify block (Double spending and check if already in the ledger) -> Peers achieve consensus and add block. In case of Fork (when 2 or more signed blocks reference the same previous block): Nano network resolves forks via a balance-weighted voting system where representative nodes vote for the block they observe, as >50% of weighted votes received, consensus achieved and block is retained in the Node’s ledger (block that lose the vote is discarded).  Holochain - uses distributed hash table (DHT). Instead of trying to manage global consensus for every change to a huge blockchain ledger, every participant has their own signed hash chain. In case of multi-party transaction, it is signed to each party's chain. Each party signs the exact same transaction with links to each of their previous chain entries. After data is signed to local chains, it is shared to a DHT where every neighbor node validate it. Any consensus algorithms can be built on top of Holochain.  Komodo ('Delegated' Delayed Proof of Work (dPoW)) - end-to-end blockchain solutions. DPoW consensus mechanism does not recognize The Longest Chain Rule to resolve a conflict in the network, instead the dPoW looks to backups it inserted previously into the chosen PoW blockchain. The process of inserting backups of Komodo transactions into a secure PoW is “notarization.” Notarisation is performed by the elected Notary nodes. Roughly every ten minutes, the Notary nodes perform a special block hash mined on the Komodo blockchain and take note of the overall Komodo blockchain “height”. The notary nodes process this specifc block so that their signatures are cryptographically included within the content of the notarized data. There are sixty-four “Notary nodes” elected by a stake-weighted vote, where ownership of KMD represents stake in the election. They are a special type of blockchain miner, having certain features in their underlying code that enable them to maintain an effective and cost-efcient blockchain and they periodically receives the privilege to mine a block on “easy difculty.” post with references you can find here: https://bitcointalk.org/index.php?topic=2936428.msg30170673#msg30170673
Bitmain is regarded as one of the most influential companies in the ASIC mining industry. It is estimated that they have manufactured approximately 53% of all mining equipment.Without including their mining profits, that’s around $140 million dollars in sales. These figures are staggering, but Bitmain’s monopoly of the Bitcoin ASIC market may come to an end, following the release of PowerAsic’s asicpower AP9-SHA256.
About the asicpower AP9-SHA256
Designed with brand new technology and boasting 94 TH/s per miner, the AP(-SHA256 is the most powerful and efficient Bitcoin miner to date.PowerAsic claims they spent $12 million dollars on research, development, and prototypes.PowerAsic also noted that their miners take advantage of ASICBOOST, an exploit of Bitcoin’s algorithm which improves mining efficiency by 20%.An unusual approach separate Powerasic’s miner to the other manufactures is the implementation of copper heat-sink claimed to have a superior thermal conductivity 69% better than aluminium. Don’t take their words for it but confirm the facts are correct on widely well known and published science documents as this one.The first batch of miners were announced and made available for order in August of 2019, with start scheduled for shipment in September, 2019. Powerasic claims that the machines are around 40 percent more productive than the most proficient ASIC on the market, Bitmain’s Antminer S17.According to PowerAsic, they started a mining project with the aim to bring much needed competition to the market…We want to ‘make SHA256 great again.Sitting at the hefty price of $2,795.00, the powerasic AP9-SHA256 is far from affordable for the average person. Fortunately, due to the newly born rivalry between Bitmain and Powerasic, the price will probably lower with time and competition.The power supply for this unit is included and integrated in the top-box also including the controler card as a one unit. You will also get standard power cable, network cable, manual and software in the packet. In comparison to the price of the Antminer S17 , the Powerasic AP9-Sha256 is a better value.
The integrated PSU 3300W has a inputVoltage 220V 50Hz 30A. There are 2 fan 40mm., 1 fan 60mm to keep it cool and the power cable 3 legs following CEE 7 standard.Professional mining hardware runs optimally at 220-240V, hence why mining farms step down their own electricity supply to 220-240V. Note that 220V current is only found outside of the US – American outlets are 110V by default. Unless you want to hire an electrician, this could cause some people trouble adapt to the eficient and recomended 220V power needed, still 110V will get the job done, but they are not ideal for optimum mining performance.
Thanks to the powerasic AP9-HA256’s new 7nm generation of ASIC chips, the AP9-SHA256 has become the most electrically-efficient miner on the market.Consuming merely 30.J/TB, or 2860W from the wall, the 16T is 30% more electrically-efficient than the Antminer S17.
Powerasic ’s new ASIC technology is impressive. When compared to its closest competitor, the Antminer S17, the powerasic AP9-HA256 is the clear winner. It hashes at 94 TH/s, as opposed to the S17’s 56 TH/s. Moreover, the the AP9-HA256 consumes 30J/GH, whereas the S17 consumes 39-45J/TB.The difference in power consumption is miniscule, but when it comes to large-scale mining, the the AP9-HA256’s edge will drastically increase the profitability of a mining operation. This ASIC is profitable not only for mining on a large scale, but for the individual miner as well.Take a look at the projected mining profitability of a single miner:Note that is appears profitable even with high electricity costs ($0.1 per KW/h). With $0.05 / KW/h it’s even more profitable:📷Each powerasic AP9-HA256 will generate about $6,009 per year (calculated with 1 BTC=$10,141.5). Mining profitability may vary. You can usethis free profitability calculator to determine your projected earnings.
Is powerasic AP9-HA256 a Scam?
There is been a lot of talk on Twitter that powerasic AP9-HA256 is a scam. It appears it is not, as many users are already claiming to have received their miners.Slush, the creator ot Slush Mining Pool and the TREZOR hardware wallet, claims on Twitter that he has seen units and knows people who have had their miners delivered:
Verdict: Is The Antminer S17 Outdated?
When the first batch of Bitmain’s Antminer S17 ASICs reached the eager hands of miners, they were all the rage. The S17 was renowned as the most efficient ASIC miner on the market. Many used the S17 as the industry’s golden standard.Up until the launch of the powerasic AP9-HA256, it was the golden standard.But, now?Things have changed.Not only is the powerasic AP9-HA256 more powerful than its predecessor from Bitmain, but also more efficient, and therefore, more profitable.Ever since the announcement of the new ASIC, there was widespread speculation of its legitimacy – and rightly so.The Bitcoin community has been plagued with small, phony companies manipulating images of preexisting antminers as a ploy to hype up their fake products. Nevertheless, powerasic AP9-HA256 is taking things seriously, and their first batch of miners have lived up to expectations.The fact of the matter is, Bitmain’s most powerful and efficient antminer has been dethroned by the new reigning king of ASICs: The powerasic AP9-HA256.
Bitmain has dominated the ASIC market since its inception in 2013.There are a few other companies producing ASICs. However, before the creation of PowerAsics AP9-SHA256., Bitmain was the only company with a proven track record that sold efficient miners directly to the public.Powerasic AP9-HA256 has the potential to bring Bitmain’s monopoly to an end. Powerasic AP9-HA256 has a bright future ahead of them. Now that Bitmain has noteworthy competition, it will be interesting to see how it affects the market. The powerasic AP9-HA256 is the best option (for now) for anyone getting started with mining. Powerasic’s innovation should force other ASIC producers to innovate and force other companies to release new miners with better efficiency. So whether you’re buying a miner now or soon, you’re likely to benefit from the development of this new miner. For more, Visit Us: https://asicpower.net/product.php
tl;dr: GHash.IO shows that the economic incentives behind Bitcoin are probably very flawed, it might take a disaster to get the consensus to fix it, and if that happens I want to make sure I can pay my rent and buy food while we're fixing it. I made a promise to myself a while back that I'd sell 50% of my bitcoins if a pool hit 50%, and it's happened. I've known for awhile now that the incentives Bitcoin is based on are flawed for many reasons and seeing a 50% pool even with only a few of those reasons mattering is worrying to say the least. Where do we go from here? We need to do three things: 1) Eliminate pools. 2) Provide a way for miners to solo-mine with low varience and frequent mining payouts even with only small amounts of hashing power. 3) Get rid of ASICs. Unfortunately #3 is probably impossible - there is no known way to make a PoW algorithm where an ASIC implementation isn't significantly less expensive on a marginal cost basis than an implementation on commodity hardware. Every way people have tried has the perverse effect of increasing the cost to make the first ASIC, which just further centralizes mining. Absent new ideas - ideas that will be from hardware engineers, not programmers - SHA256² is probably the best of many bad choices. (and no, PoS still stands for something other than 'stake') We are however lucky that we have physics and (maybe) international relations on our side. It will always be cheaper to run a small amount of hashing power than a large amount, at least for some value of 'small' and 'large'. It's the cube-square law, as applied to heat dissipation: a small amount of mining equipment has a much larger surface area compared to a large amount, and requires much less effort per unit hashing power to keep cool. Additionally finding profitable things to do with small amounts of waste heat is easy and distributed all over the planet - heating houses, water tanks, greenhouses, etc. As for international relations, restricting access to chip fabrication facilities is a very touchy subject due to how it can make or break economies, and especially militaries. (but that's a hopeful view) Solving problem #1 and getting rid of pools is probably possible - Andrew Miller came up with the idea of a non-outsourceable puzzle. While tricky to implement, the basic idea is simple: make it possible for whomever finds the block to steal the reward, even after the fact, in a way that doesn't make it possible to prove any specific miner did it. Adding this protection to Bitcoin requires a hard-fork as described, though perhaps there's a similar idea that can be done as a soft-fork. Block withholding attacks - where miners simply don't submit valid solutions - could also achieve the same goal, although in a far uglier way. Solving problem #2 and letting miners achieve low varience even with a small amount of hashing power is also possible - p2pool does it already, and tree chains would do it as a side effect. However p2pool is itself just another type of pool, so if non-outsourceable puzzles are implemented they'll need to be compatible. p2pool in its current form is also less then ideal - it does need a lot of bandwidth, and if you have lower latency than average you have a significant unfair advantage. But these are problems that (probably) can be fixed before adding it to the protocol. (this can be done in a soft-fork) Do I still think Bitcoin will succeed in the long run? Yes, but I'm a lot less sure of it than I used to be. I'm also very skeptical that any of the above will be implemented without a clear failure of the system happening first - there's just too many people, miners, developers, merchants, etc. whose heads are in the sand, or even for that matter, actively making the problem worse. If that failure happens it's quite likely that the Bitcoin price will drop to essentially nothing - not a good way to start a few months of work fixing the problem when my expenses are denominated in Canadian dollars. I hope I'm on the wrong side of history here, but I'm a cautious guy and selling a significant chunk of bitcoins is just playing it safe; I'm not rich. BTW If you owe me fiat and normally pay me via Bitcoin, for the next 2.5 weeks you can pay me based on the price I sold at, $650 CAD.
[ANN] Askcoin is a cryptocurrency for real-time Q&A, Mainnet is launched now !!!
Askcoin is a cryptocurrency for real-time Q&A. It was born to achieve freedom of speech and question-and-answer worldwide. It's decentralized and ASIC-resistant, this is achieved by a new POW consensus algorithm. As we all know, bitcoin is mined by calculating sha256, so whoever calculates sha256 fast will be able to produce new blocks before anyone else, this is exactly what ASIC mining machines on the market are good at. In order to weaken the advantages of ASIC mining machine, the mining algorithm of askcoin uses sha256 combined with memory loading to resist ASIC machine. In askcoin, the speed of mining depends mainly on the speed of memory load, not the speed of sha256 calculation. Now, Askcoin's Mainnet is launched, it is different from any question-and-answer project in the past, because it is a completely decentralized project, which is reflected in the following aspects:
Anyone can run askcoin's full node freely
Anyone can freely choose whether to mine on the Full node or not.
Anyone can run their own block explorer freely.
Anyone can connect askcoin's block explorer to the full node they are running
Anyone can connect askcoin's mobile app to the full node they are running
Unlike Bitcoin, askcoin uses an account model, so before using askcoin, you have to register an account in the block chain. In askcoin, there are five types of transactions: Register an account Transfer Ask a question (or topic) Reply to a question Reward a reply In order to prevent DDoS attacks, 2 ASK fees will be deducted from the initiator of each transaction. But if you are registering an account, who will pay for it? That's what your referrer should do. In askcoin, if you want to register an account, you need to enter your username, avatar, and the string signed by your referrer. When the full node receives your registration request, it will deduct 2 ASK from your referrer's account. Of the 2 ASK fees paid for each transaction you initiate since then, 1 ASK will be paid to the miner's account that put the transaction in the block, and another 1 ASK will be paid to your referrer's account. The total supply of askcoin is 1000 billion, of which 500 billion is produced by miners through mining, and another 500 billion is temporarily retained by the founder team for promotion, popularization, attracting users, stabilizing the market and so on. When the project develops to a stable state, we are willing to donate most of our ASK coins and transfer them to the system reserve account to supplement the supply of mining (the proportion of donations will reach or exceed 80%). That is to say, the vast majority of ASK comes from mining. SPECIFICATION: Total supply: 1000 billion (considering the long-term support of small reward amount, so a single ASK price must be low enough) Block time: 20 sec Block reward: 5000 ASK Algorithm: SHA256-AR (asic-resistant) RELATED LINKS: Full node binary: https://github.com/lichuan/askcoin/releases Full node (source code): https://github.com/lichuan/askcoin (The source code of askcoin's Fullnode will be open after it has passed its infancy in order to protect its originality) Full node (doc): https://github.com/lichuan/askcoin#askcoin Telegram group: https://t.me/askcoin Telegram channel: https://t.me/askcoin_channel Bitcointalk: https://bitcointalk.org/index.php?topic=5104959 Reddit: https://www.reddit.com/askcoin My twitter: https://twitter.com/lichuan_001 Miner (doc): https://github.com/lichuan/askcoin#miner 3rd exchange api (doc): https://github.com/lichuan/askcoin#exchange-api Website: http://www.askcoin.me Block explorer: http://explorer.askcoin.me Block explorer (source code): https://github.com/lichuan/askcoin-explorer Whitepaper (English): http://www.askcoin.me/whitepaper_en.pdf Whitepaper (Chinese): http://www.askcoin.me/whitepaper_cn.pdf Mobile app (source code) https://github.com/lichuan/askcoin-client Mobile app (android apk): https://github.com/lichuan/askcoin-client/releases For the reasons stated above, when you first register, you need someone to generate a signature string for your registration. You can post a reply here, leave the user name you want to register, or tell me through telegram that I can help you generate this signature string. The person who replies here can get 1000 ASK coins for free. Once you register successfully, you can also help others to generate the registration signature string by using the corresponding function button in the mobile app, and you will automatically become their referrer. To make it easier for new users to register, we have released a web tool to generate signature strings for users to register. You can access its source code through github: https://github.com/lichuan/askcoin-gen-reg-sign If you are a new user and need to register, you can generate the signature string for registration through the following address: http://generate.askcoin.me If you want to register through mobile app, you can copy the signature string generated by the above tool to the corresponding input box in the registration UI of mobile app for subsequent registration process. If you want to register by running the full-node command, you need to modify the config.json file first, and make sure that your node has established a communication connection with other nodes, and then wait for your node to synchronize with other peer nodes before proceeding with the registration process, and then synchronize your system time with global UTC time (using crontab and ntpdate command).
PSA: Users, (solo)miners, exchanges/merchants, and pool operators must be on v0.10.1 in advance of the hardfork otherwise you will get forked/booted off the network. Miners, please contact your pool operator to ask them if they have upgraded | Monero v0.10.1 released - mandatory upgrade!
Approximately the 9th of January there will be a hardfork on the Monero network. Most pools have upgraded or are in the process of upgrading, but some have not upgraded yet. If they don't upgrade before the hardfork they will get forked/booted off the network. As a result you will miss out on revenue if you are mining on these pools. Thus, if you are mining on one of the pools that hasn't upgraded yet or hasn't scheduled an upgrade, please contact your pool owner as soon as possible and urge them to upgrade. Alternatively, you can switch to a pool that is on the right version.
To all pool operators: If you haven't already, you will need to update the node-cryptonote-util software in order for your pool to cross the january fork. I think many of the pool ops have done so already, but for those who are not in #monero-pools, you will need this patch: https://paste.fedoraproject.org/506116/17116821/ This applies to zone117x's version of the pool. There is a version of this ported to clintar's fork, which is here: https://github.com/M5M400/node-cryptonote-util/commit/37f50f9b535f0258c3a1c6f7247a891b4c211ff3. If you're not running this when the fork happens, you will be forked off. For pool miners, you may want to check with your pool op that they're running the patch a few days before the fork, and switch to a known good pool otherwise. Please prefer smaller pools when doing so.
Also bear in mind that running v0.10.1 or the GUI beta is mandatory. Any other versions will get booted off the network. Thus, miners, please email your pools and ask them if they are running v0.10.1 and have applied aforementioned patch.
General hardfork information
The upcoming fork will enable Ring Confidential Transactions. This will significantly enhance Monero's privacy. Note that they will not be enforced yet. That is, this hardfork will enable them, whereas the hardfork of September 2017 will enforce them. If you want to read more about Ring Confidential Transactions, see: https://lab.getmonero.org/pubs/MRL-0005.pdf https://monero.stackexchange.com/questions/tagged/ringct Due to variance the hard fork will likely be on the 9th or 10th of January. A specific block height was determined for the hardfork, not a specific date. The specific blockheight for the hardfork can be found here. That is:
// version 4 starts from block 1220516
As an user you need to run either v0.10.1 or the Monero Core GUI Beta 1.
Monero v0.10.1 - Wolfram Warptangent - release
First and foremost, please upgrade to this version. A blockchain resync is not needed. Only this version will work after the fork of January 5. Note that this fork will enable Ring CT transactions, but will not enforce them yet.
This is a necessary point release of Monero v0.10 "Wolfram Warptangent", and is highly recommended as it includes consensus-changing fixes to the RingCT implementation and various other bug fixes. Some highlights of this release are:
major changes to support the GUI
adds full support for "fluffy blocks", a propagation improvement similar to Compact Blocks in Bitcoin Core
adds in a dynamic fee system
expansion of the data stored in the wallet cache, including the GUI address book
switch to Borromean signatures in RingCT
add Monero payment URI support to the wallet library
complete overhaul of the threading system
optimise the wallet blockchain refresh mechanism
created a contributing guide
switched to a dynamic dust threshold system
added a command to compute the total coinbase
major RingCT performance improvements
killed off the old fast_exit mechanism, which caused more issues than anything else
improved and fixed the cold wallet transaction signing mechanism
Simply create a new directory with the 0.10.1 binaries and copy your wallet files over to there. Make sure to backup your wallet files properly. If you need any help, feel free to PM me or respond in this thread. Note that your wallet contains three files, namely wallet.keys (this is the most important file, since it contains your keys), wallet (this is the wallet cache, which contains your transaction history and private tx keys), and wallet.address (which is just your public address). In addition, if you incur a bug whilst upgrading, you can always restore your wallet with the mnemonic seed as follows: For Mac and Linux: ./monero-wallet-cli --restore-deterministic-wallet On Windows make sure to launch it from the command line. Go to the folder monero-cli-wallet is located and make sure your cursor isn't located on any of the files. Subsequently do SHIFT + right click and it will give you an option to "Open command window here". Lastly, type the following command: monero-wallet-cli.exe --restore-deterministic-wallet If you want to restore from the private keys instead of the mnemonic seed, replace --restore-deterministic-wallet with --generate-from-keys
Contributors for this Release
This release was the direct result of 29 people who worked, largely unpaid and altruistically, to put out 481 commits containing 10 517 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:
J Ryan Littlefield
You can find the release (and binaries) of the first beta here.
My brief observation of most common Consensus Algorithms
I have studied most common consensus algorithms. Here is the summary, maybe for someone it will be helpful. My goal is to describe every specific consensus briefly so everyone can easily understand it. *Please let me know if I have wrote something wrong, or maybe you are aware of interesting algorithm, I have missed. Proof of Work - very short, cuz it's well-known. Bitcoin - to generate a new block miner must generate hash of the new block header that is in line with given requirements. Others: Ethereum, Litecoin etc. Proof of Stake Nxt- The more tokens are held by account, the greater chance that account will earn the right to generate a block. The total reward received as a result of block generation is the sum of the transaction fees located within the block. Three values are key to determining which account is eligible to generate a block, which account earns the right to generate a block, and which block is taken to be the authoritative one in times of conflict: base target value, target value and cumulative difficulty. Each block on the chain has a generation signature parameter. To participate in the block's forging process, an active account digitally signs the generation signature of the previous block with its own public key. This creates a 64-byte signature, which is then hashed using SHA256. The first 8 bytes of the resulting hash are converted to a number, referred to as the account hit. The hit is compared to the current target value(active balance). If the computed hit is lower than the target, then the next block can be generated. Peercoin (chain-based proof of stake) - coin age parameter. Hybrid PoW and PoS algorithm. The longer your Peercoins have been stationary in your account (to a maximum of 90 days), the more power (coin age) they have to mint a block. The act of minting a block requires the consumption of coin age value, and the network determines consensus by selecting the chain with the largest total consumed coin age. Reward - minting + 1% yearly. Reddcoin (Proof of stake Velocity) - quite similar to Peercoin, difference: not linear coin-aging function (new coins gain weight quickly, and old coins gain weight increasingly slowly) to encourage Nodes Activity. Node with most coin age weight have a bigger chance to create block. To create block Node should calculate right hash. Block reward - interest on the weighted age of coins/ 5% annual interest in PoSV phase. Ethereum (Casper) - uses modified BFT consensus. Blocks will be created using PoW. In the Casper Phase 1 implementation for Ethereum, the “proposal mechanism" is the existing proof of work chain, modified to have a greatly reduced block reward. Blocks will be validated by set of Validators. Block is finalised when 2/3 of validators voted for it (not the number of validators is counted, but their deposit size). Block creator rewarded with Block Reward + Transaction FEES. Lisk (Delegated Proof-of-stake) - Lisk stakeholders vote with vote transaction (the weight of the vote depends on the amount of Lisk the stakeholder possess) and choose 101 Delegates, who create all blocks in the blockchain. One delegate creates 1 block within 1 round (1 round contains 101 blocks) -> At the beginning of each round, each delegate is assigned a slot indicating their position in the block generation process -> Delegate includes up to 25 transactions into the block, signs it and broadcasts it to the network -> As >51% of available peers agreed that this block is acceptable to be created (Broadhash consensus), a new block is added to the blockchain. *Any account may become a delegate, but only accounts with the required stake (no info how much) are allowed to generate blocks. Block reward - minted Lisks and transaction fees (fees for all 101 blocks are collected firstly and then are divided between delegates). Blocks appears every 10 sec. Cardano (Ouroboros Proof of Stake) - Blocks(slots) are created by Slot Leaders. Slot Leaders for N Epoch are chosen during n-1 Epoch. Slot Leaders are elected from the group of ADA stakeholders who have enough stake. Election process consist of 3 phases: Commitment phase: each elector generates a random value (secret), signs it and commit as message to network (other electors) saved in to block. -> Reveal phase: Each elector sends special value to open a commitment, all this values (opening) are put into the block. -> Recovery phase: each elector verifies that commitments and openings match and extracts the secrets and forms a SEED (randomly generated bytes string based on secrets). All electors get the same SEED. -> Follow the Satoshi algorithm : Elector who have coin which corresponded to SEED become a SLOT LEADER and get a right to create a block. Slot Leader is rewarded with minted ADA and transactions Fee. Tendermint (Byzantine Fault Tolerance) - A proposal is signed and published by the designated proposer at each round. The proposer is chosen by a deterministic and non-choking round robin selection algorithm that selects proposers in proportion to their voting power. The proposer create the block, that should be validated by >2/3 of Validators, as follow: Propose -> Prevote -> Precommit -> Commit. Proposer rewarded with Transaction FEES. Tron (Byzantine Fault Tolerance) - This blockhain is still on development stage. Consensus algorithm = PoS + BFT (similar to Tendermint): PoS algorithm chooses a node as Proposer, this node has the power to generate a block. -> Proposer broadcasts a block that it want to release. -> Block enters the Prevote stage. It takes >2/3 of nodes' confirmations to enter the next stage. -> As the block is prevoted, it enters Precommit stage and needs >2/3 of node's confirmation to go further. -> As >2/3 of nodes have precommited the block it's commited to the blockchain with height +1. New blocks appears every 15 sec. NEO (Delegated Byzantine Fault Tolerance) - Consensus nodes* are elected by NEO holders -> The Speaker is identified (based on algorithm) -> He broadcasts proposal to create block -> Each Delegate (other consensus nodes) validates proposal -> Each Delegate sends response to other Delegates -> Delegate reaches consensus after receiving 2/3 positive responses -> Each Delegate signs the block and publishes it-> Each Delegate receives a full block. Block reward 6 GAS distributed proportionally in accordance with the NEO holding ratio among NEO holders. Speaker rewarded with transaction fees (mostly 0). * Stake 1000 GAS to nominate yourself for Bookkeeping(Consensus Node) EOS (Delegated Proof of Stake) - those who hold tokens on a blockchain adopting the EOS.IO software may select* block producers through a continuous approval voting system and anyone may choose to participate in block production and will be given an opportunity to produce blocks proportional to the total votes they have received relative to all other producers. At the start of each round 21 unique block producers are chosen. The top 20 by total approval are automatically chosen every round and the last producer is chosen proportional to their number of votes relative to other producers. Block should be confirmed by 2/3 or more of elected Block producers. Block Producer rewarded with Block rewards. *the more EOS tokens a stakeholder owns, the greater their voting power The XRP Ledger Consensus Process Ripple - Each node receives transaction from external applications -> Each Node forms public list of all valid (not included into last ledger (=block)) transactions aka (Candidate Set) -> Nodes merge its candidate set with UNLs(Unique Node List) candidate sets and vote on the veracity of all transactions (1st round of consensus) -> all transactions that received at least 50% votes are passed on the next round (many rounds may take place) -> final round of consensus requires that min 80% of Nodes UNL agreeing on transactions. It means that at least 80% of Validating nodes should have same Candidate SET of transactions -> after that each Validating node computes a new ledger (=block) with all transactions (with 80% UNL agreement) and calculate ledger hash, signs and broadcasts -> All Validating nodes compare their ledgers hash -> Nodes of the network recognize a ledger instance as validated when a 80% of the peers have signed and broadcast the same validation hash. -> Process repeats. Ledger creation process lasts 5 sec(?). Each transaction includes transaction fee (min 0,00001 XRP) which is destroyed. No block rewards. The Stellar consensus protocol Stellar (Federated Byzantine Agreement) - quit similar to Ripple. Key difference - quorum slice. Proof of Burn Slimcoin - to get the right to write blocks Node should “burn” amount of coins. The more coins Node “burns” more chances it has to create blocks (for long period) -> Nodes address gets a score called Effective Burnt Coins that determines chance to find blocks. Block creator rewarded with block rewards. Proof of Importance NEM - Only accounts that have min 10k vested coins are eligible to harvest (create a block). Accounts with higher importance scores have higher probabilities of harvesting a block. The higher amount of vested coins, the higher the account’s Importance score. And the higher amount of transactions that satisfy following conditions: - transactions sum min 1k coins, - transactions made within last 30 days, - recipient have 10k vested coins too, - the higher account’s Important score. Harvester is rewarded with fees for the transactions in the block. A new block is created approx. every 65 sec. IOTA Algorithm IOTA - uses DAG (Directed Acyclic Graph) instead of blockchain (TANGLE equal to Ledger). Graph consist of transactions (not blocks). To issue a new transaction Node must approve 2 random other Transactions (not confirmed). Each transaction should be validate n(?) times. By validating PAST(2) transactions whole Network achieves Consensus. in Order to issue transaction Node: 1. Sign transaction with private key 2. choose two other Transactions to validate based on MCMC(Markov chain Monte Carlo) algorithm, check if 2 transactions are valid (node will never approve conflicting transactions) 3. make some PoW(similar to HashCash). -> New Transaction broadcasted to Network. Node don’t receive reward or fee. Proof of Space/Proof of Capacity Filecoin (Power Fault Tolerance) - the probability that the network elects a miner(Leader) to create a new block (it is referred to as the voting power of the miner) is proportional to storage currently in use in relation to the rest of the network. Each node has Power - storage in use verified with Proof of Spacetime by nodes. Leaders extend the chain by creating a block and propagating it to the network. There can be an empty block (when no leader). A block is committed if the majority of the participants add their weight on the chain where the block belongs to, by extending the chain or by signing blocks. Block creator rewarded with Block reward + transaction fees. Proof of Elapsed Time Hyperledger Sawtooth - Goal - to solve BFT Validating Nodes limitation. Works only with intel’s SGX. PoET uses a random leader election model or a lottery based election model based on SGX, where the protocol randomly selects the next leader to finalize the block. Every validator requests a wait time from an enclave (a trusted function). -> The validator with the shortest wait time for a particular transaction block is elected the leader. -> The BlockPublisher is responsible for creating candidate blocks to extend the current chain. He takes direction from the consensus algorithm for when to create a block and when to publish a block. He creates, Finalizes, Signs Block and broadcast it -> Block Validators check block -> Block is created on top of blockchain. post with references you can find here: https://bitcointalk.org/index.php?topic=2936428.msg30170673#msg30170673
This is a Bitcoin (BTC) SHA256 SOLO Mining pool. No registration required. Instant Payout immediately when block found. Bitcoin Cash mining calculator for SHA-256: Price 219.51$, 383.6057G difficulty, 2.3933 EH/s network hashrate, 6.2500 BCH block reward. Bitcoin Cash mining pools list and list of best mining software. BitcoinV mining calculator for SHA-256: Price 0.00778529$, 45.2298M difficulty, 343.701 TH/s network hashrate, 50.00 BTCV block reward. BitcoinV mining pools list and list of best mining software. List of top SHA256 coins by Market Capitalization. About. Coinlore provides original cryptocurrency/coin prices calculated by own algorithm, and other metrics such as markets, volumes, historical prices, charts, coin market caps, blockchain info, API, widgets and more. Antminer S19 Pro 110Th/s. Antminer S19 Pro 110Th/s is an SHA-256 algorithm mining equipment sold by minerzilla.com. It is able to mine Bitcoin (BTC) with a maximum hashrate of 110Th/s for a power consumption of 3250W.
Are USB Bitcoin Miners Profitable RIGHT NOW In 2020? - YouTube
Instruction book: https://images-na.ssl-images-amazon.com/images/I/81lOfu4a6VL.pdf Driver usb: https://zadig.akeo.ie/ Forum Gekko Newpac: https://bitcointalk... Top List old 80-90% Bitcoin SHA256 ASIC Btc BCH Miner Ebit E9i 13.5T With PSU Low price than Antminer S9 S9j T9+ S11 Z9 z11 M3 12t 11.5T Price: $188 Discount... New video every Tuesday! Today we are taking a look at the Gekkoscience NewPac USB miner. We'll check all the hardware you need for setting it up, discuss so... This is an experiment of EPIC proportions creating the worlds tiniest and cutest miner. 3D Printer - MakerBot Replicator - https://amzn.to/2Nu0xr7 Printer Fi... Are USB Bitcoin Miners profitable right now? This video will show you all of the facts you need to know about usb bitcoin miners and how much money they actu...