Before staking or otherwise unlocking, you must make sure you're on the right chain and your spork 16 value is 1510179528 (should now be 1609459199 so it is enabled). Instructions for these steps are below
Zerocoin mints and spends are still disabled for now Zerocoin is now active
You should still have enablezeromint=0 in your configuration file until further notice
If you added addnode, banscore, or bantime entries to your config during the test build, you no longer need those but as noted below if you are having trouble syncing you may benefit from the addnode lines
1- Download the appropriate release for your platform from the Github release link. For command line installs/updates this link may help. 2- Start up your client and see if you are on the wrong chain by using this link (Am I forked?) or manually comparing your latest block hash against the [block explorer](www.presstab.pw/phpexplorePIVX/index.php#) 3- If you are on the correct chain, let it fully sync (or as far as it will go) and then repeat step 2. If you are still on the right chain move on to step 4. If you're on the wrong chain, download the chainstate from this link (mirror) and follow the instructions to install it. Do NOT delete wallet.dat or your backups folder. Once this is done, restart your client and let it finish syncing
stop your wallet and/or daemon
locate the folder with the blockchain folders (usually ~/.pivx/)
do a complete(!) backup of this folder in case something goes wrong
completely remove the folders "blocks", "chainstate", "sporks" and "zerocoin"
download one of the snapshot-files (preferably the newest one) above into this folder
unpack the snapshot file: 'unzip '
the folders deleted above are now replaced by the ones from the snapshot
restart your wallet and/or daemon
4- On this step you should be fully synced and on the right chain. Using the debug screen or pivx-cli, use the command
to output your spork status. Have a look at spork 16 and make sure the value is 1510179528 (now 1609459199). If it is, go ahead and start staking. If you are having trouble getting the correct value for spork 16, try adding nodes to your pivx.conf file that are protocol 70912. A list of 70912 nodes can be found at http://www.presstab.pw/phpexplorePIVX/nodes.php . This can be done from the debug menu or with pivx-cli by saying
addnode 184.108.40.206 add
libzerocoin Exploit Fix
zPIV relies on a 3rd party library called libzerocoin. All currencies that utilize the zerocoin protocol use libzerocoin, and many of those currencies have been exposed to an exploit which allowed for the creation of multiple zero-knowledge spending proofs for one single zerocoin mint. The PIVX developers were able properly identify the exploit, track down any fraudulent spending proofs, link the fraudulent spending proofs with their one valid proof that they were mutated from, and remove any mints from the accumulators that were derived from the invalid spends.
zPIV Maintenance Mode Spork
Handling the above noted libzerocoin exploit required the PIVX team to immediately release a patched wallet to as many users as possible which rejected bad spends and also disabled all zPIV transactions in general. The process of releasing a patched wallet in such a small time frame is frustrating and difficult for all members of the PIVX team and especially users of PIVX. The PIVX developers have added a new spork which allows for zPIV transacting to be turned on/off without having to release a patched wallet. This will allow much smoother operation if any problems occur in the future, and should also allow exchanges and 3rd party services to continue to operate even if zPIV is in maintenance mode.
Accumulator Code Refactor
The zPIV accumulator code has undergone a major refactor. Accumulators are one of the most essential components of the zerocoin protocol, and also one of the most computationally expensive parts of the protocol. This refactoring speeds up syncing and spending of zPIV by over 5x. The new code also allows for spending of zPIV with only 2 required mints occurring on the network after your mint has been added, whereas before 3 were required. This refactor allows for lighter resource load and a smoother user experience.
Money Supply Indexing
The exploit in libzerocoin threw off some of the wallet's internal money supply calculations for both the zPIV supply and the PIV supply. User's wallet's will automatically recalculate the supply on block 908001. User's also have the ability to recalculate supply using the startup flag reindexmoneysupply.
More Extensive Tracking of zPIV Supply Through RPC
More information has been added to the getinfo and getblock RPC calls, which now display the total zPIV supply as well as the balance for each zPIV accumulator.
Provides functionality which is currently only available through raw transactions. Multisignature addresses require signatures from multiple parties before coins belonging to the address are spent. Accessed through the File dropdown menu.
As well as everyone that helped translating on Transifex.
Will I lose piv or zpiv?
No. Backup your wallet.dat again for good measure and never delete a wallet.dat file.
My wallet is stuck on block ?
Check if you're forked (Am I forked?) and then check if you're really on v3.0.5. If you're on the right version and chain, just hang tight and your wallet will find a good node to sync with eventually. Contact support if it's more than a few hours and the problem persists
My zPIV balance is incorrect
Contact support in discord or via the Support Portal. Please note that during the upgrade period and zerocoin maintenance mode there may be delays.
Non-propagating dust transaction creation by pools needs to stop!
This is an issue that has led to unnecessary clogging of the network for a long time, yet it seems to be one that has been overlooked for some time. For those who don't know: BLOCK REWARD = 12.5BTC + (SUM OF ALL TRANSACTION FEES MINED ON THAT BLOCK) Most of the largest pools keep the transaction fee part of the block reward for themselves (i.e. they do not pay that out to miners.) Here's what I'm talking about: This is done by pools that do not pay out transaction fees to miners (Antpool is by far the worst offender.) The practice is only profitable to pools which retain the transaction fee part of the block reward for themselves. The pool constantly creates a large number of minable but non-propagating transactions by creating transactions which violate the network "dust" rule. This rule prevents payments of less than 0.00001BTC from being broadcast throughout the network. As a result the transaction gets "stuck" in the pool's node and as such can only be mined by them. They will attach a large fee to the transaction, which in turn lowers the priority of transactions with lower fees attached. This ensures that only transactions with the highest fees are included in the block they mine- leaving the transactions with lower fees attached unconfirmed, driving up the necessary transaction fee, wasting mining power mining transactions that server no other purpose other than to drive up transaction fees and allowing the pool to, in essence, refuse to mine transactions with a fee below a certain amount attached. Since the pool will mine it's own transactions, they can create a virtually unlimited number of these transactions, with many unconfirmed descendants, to serve their purpose depending on the state of the mempool, and since they do not pay out transaction fees to the miners, they will get back all the transaction fees they used to attach to these transactions. Algorithms determine how much of the block-space to "waste" in order to maximize the profit- since the mempool can be analyzed at any time, it can be determined exactly how many transactions to create and what fee to attach in order to mine the transactions with the highest fee attached and drive up the necessary fee to have a transaction confirmed along with the "smart-fee," while ensuring low fee transactions are mined by the pools that do not practice this strategy. The strategy pays highest when the mempool is above 1MB (the size of a block) or has quickly filled. It also is most profitable when the fee distribution and queue-time in the mempool is highly divided/distributed- this strategy can prevent lower-fee transactions that have been waiting a long time to confirm from replacing new transactions that have a high fee attached on a block. In Summary:
Pool creates many "dust" transactions and attaches a high fee to each.
Dust transactions (transactions below 0.00001BTC) do not broadcast, so the pool is guaranteed to mine its own transactions and re-collect the high fees they attached to the transaction.
Pool now only mines outside transactions with the highest fees (per kB) attached, leaving the low-fee transactions to be mined by pools which do not practice this while simultaneously driving up the fee necessary to have a transaction confirmed.
Example: https://www.blockchain.com/en/btc/tx/c57ea54104bbf160bac88b65b2edf465c5f8ac9253c42e391100fc31b028d645 If you click on the address, you can see this exact transaction is repeated exactly every hour (which sends a fixed amount back to itself and an address that cannot be decoded, due to the nature of the transaction, being sent 0BTC- which is what makes this a dust transaction.) If you go back to the block this transaction was originally confirmed (mined) on (by Antpool) you will see tons of similar transactions. In fact, Antpool has hundreds, if not thousands, of addresses used solely for this purpose. The practice is much more calculated and complex (in actual practice) than I summarized above. Eventually (or sometimes even on the same block) the divided outputs created by each transaction you see on that account would/will be concatenated into a single output over an additional series of combining, non-broadcasting, "dust" transactions. Can it technically be considered a fair practice? While their are plenty of valid reasons to create non-propagating transactions, such as to concatenate inputs left with dust amounts of bitcoin after valid transactions, without risking loosing the entire amount due to the minimum transaction fee being larger than the total amount, creating transactions like this with no other purpose than to increase a pools own profits is hard to argue as being a honorable one. Furthermore, since this practice is overall detrimental to the network (filling blocks with loads of unnecessary transactions, slowing confirmation times and artificially manipulating the necessary transaction fees) and in addition penalizes pools which pay the transaction fee part of the block reward to miners (since the practice cannot be performed by such pools, as it would cost the pool far too much,) as well as the fact that THE MINERS- THE ONES ACTUALLY CONTRIBUTING THE MINING POWER ARE NOT BENEFITING, I think it is safe to say that this practice is a deplorable one. Yes, one could argue that this is a loophole and exploiting it is going to be a natural occurrence, but I believe that since it encourages pools not to pay the transaction fee part of the block reward to miners, it is a practice that should not continue. What to do about it? There are a few options: You can try if you run a full-node, but...: I for instance run a full node on a high bandwidth, fixed IP and allow incoming connections. I allow more connections in the command line options and maintain a few hundred connections at once. I noticed a few pools started automatically connecting to my node (I had to do some nmap scanning and some other testing to confirm they were indeed pool nodes, and who they belonged to, but was able to determine that- my first clue was multiple connections from bitcoinj nodes in the same subnet.) I was also able to find the addresses of other pool nodes and manually add them with the `addnode' command. So, with multiple pools connected (or the ability to connect to multiple pools upon restart,) I tweaked my node to allow for the broadcast of both zero-fee and dust transactions. My thinking was that I could serve as an unknowing "bridge" between pools- broadcasting one pools "dust" transactions to another, thereby removing the pool's ability to ensure that the transaction was not mined by another pool and making the practice unprofitable. BUT... While this sounds good in theory, in practice it doesn't work for a few reasons. First of all, the pool nodes would not connect to me once I started broadcasting dust transactions. Second, I noticed my overall connection count way down, leading me to believe that broadcasting dust transactions was causing me to be labeled as a misbehaving node and finally, while this could work for some less advanced pools, Antpool, at least, designs its dust transactions in such a way that they violate more than just the "dust" rule- further tweaking would be required and this would need to be an action taken by a majority of nodes to work. The only other option, I suppose, would be to appeal to the bitcoin dev team. Perhaps they could implement a way to prevent this practice, although I do not likely see it happening. The "dust" rule is in place to prevent clogging of the network with tiny transactions- to prevent anyone wishing to back-up the network from being able to do so without spending a large sum of money. The dust rule and the minimum transaction fee go hand in hand to prevent such occurrence- so anyone wishing to do harm to the network would soon find themselves spending very large amounts of BTC in an attempt to back it up- pools which retain the transaction fee however are not bound by these limitations. The only real option to fight this, as a miner, is to mine on a pool that pays the transaction fee part of the block reward to the miners- you'll make more anyway, even if the overall fee may be slightly higher. An example of one of these pools is KANO, there are many others. I would just avoid antpool in general- but that's just me. tl;dr Pools which retain the transaction fee part of the block reward use a loophole is a network rule that allows them to only mine high fee transactions, which in turn hurts pools that pay the transaction fee part of the block reward to miners, clogs up the network- slowing confirmation times, and drives up transaction fees.
Hello folks and welcome to another Developer Update from the Gridcoin team. I'd like to remind everyone that these posts will be created every two weeks unless a wallet update is pending that week.
These last two weeks, developers have been preparing for an upcoming leisure update and finalizing fixes currently in staging branch. Testnet has been busy as well testing various new features and verifying fixes. Some of the pull requests these last two weeks have included:
#1054 by @thecharlatan cleans up the voting code and removes a call to RPC from within the GUI wallet that has gone unnoticed for a long time.
#1060 by @tomasbrod is the start of implementing superblock contract forwarding to non-Windows nodes. This is intended as a temporary way to allow non-Windows wallets to help stake superblocks while the current NN is being rewritten to C++. To summarize how this works: when Windows nodes have agreed upon a consensus neural hash, Linux nodes will be able to request the packed superblock contract data associated with the current quorum hash (best hash) and try to stake a superblock just like the Windows nodes. In this implementation the Windows nodes are still doing most of the work gathering the NN data and forming consensus, but the Linux nodes are able to assist in the actual staking of the superblock itself once consensus is reached. This should reduce superblock delays once implemented.
#1056 by @ifoggz fixes the issue #1035 first reported about a month ago related to the output of beaconreport cutting off the first character of each CPID in the list.
#1057 by @tomasbrod adds feedback to the addnode command in debug letting the user know whether they successfully connected to the peer or if the connection failed for some reason. This addresses issue #867 and is a nice quality of life improvement.
#1059 by @ifoggz addresses an issue initially brought to us by the Flyp.me exchange. The relevant issue is #1055. To summarize, the output of the listtransactions RPC command was inconsistent with what was expected from other Bitcoin-like wallets and this PR changes the output to make the call more in line with what exchanges expect to see.
In addition to the PRs listed above, @ifoggz has been working with the testing team to improve performance and better handle errors in the current Windows neural network implementation. So far these tests have been positive and show greatly improved consensus among neural nodes. In particular an issue was found when the downloaded gz files from project sites were incorrectly formatted. In the past, the NN would simply accept the bad data and try to use it for calculations resulting in wildly inaccurate magnitudes and hashes. The new improved NN code will recognize badly formatted project data files and prevent their bad data from being included in NN calculations. The new NN code will also try to redownload the excluded bad data on the next sync. I would like to thank personthingman2 for all his help assisting in this testing.
I would like to add a quick update on testnet. I gave a "Introduction to Testnet" talk on the last Fireside podcast. Thanks to @jringo for having me and I look forward to hearing the edited audio once it is finalized. The goal of this talk was to educate people about testnet and bring new testers on board.
Thanks for reading this edition of the Developer Update. Expect to see another update two weeks from today (5/7), barring a wallet update around that time. If you have any comments or questions for the Gridcoin development team feel free to ask in the comments below. If I am not able to answer your question directly, I can certainly forward it to someone who can! Thanks everyone!
Proof of Nodework (PoNW) - a method to trustlessly reward nodes for storing and verifying the blockchain | John Hardy | Feb 07 2017
John Hardy on Feb 07 2017: Proof of Nodework (PoNW) is a way to reward individual nodes for keeping a full copy of and verifying the blockchain. Hopefully they also do useful ‘traditional’ node activities too like relay transactions and blocks, but there isn’t really any way I can think of to trustlessly verify this also. PoNW would require a new separate area of block space, a nodeblock, purely concerned with administering the system. A nodeblock is committed to a block as with SegWit. A recent history of nodeblocks needs to be stored by nodes, however the data eventually becomes obsolete and so does not need to be retained forever. In order to prevent Sybil, a node must register an Bitcoin address by submitting an addNode transaction - along with a security deposit to prevent cheating. This transaction will be stored in the nodeblock. Once a node can see that its addNode transaction has been added it can begin the PoNW process. The node’s registered address will be hashed with the block header of the block it wants to work on. This will determine exactly where within the blockchain to begin the PoNW. The PoNW method could be as simple as creating a Merkle tree from the randomly generated point on the blockchain, though a method that is CPU/Memory heavy and less likely to be replaced by dedicated hardware like ASICs would be better. This process could not begin until the most recent block has been fully verified, and while being carried out should still enable normal relay activities to proceed as normal, since it shouldn’t tie up network at all. The data processed should also be mixed with data from the latest block so that it cannot be computed in advance. A node can do as much PoNW for a block as it likes. Once finished it will then create a nodeWorkComplete transaction for that block with its final proof value, add how much ‘work’ it did - and create a couple of assertions about what it processed (such as there were x number of pieces of data matching a particular value during calculating). These assertions can be accurate or inaccurate. The system will run in epochs. During each epoch of say 2016 blocks, there will be an extended window for PoNW transactions to be added to nodeblocks to limit minor censorship. The random hash generated from a node’s address and blockhash will also be used to determine nodeWorkComplete transactions from a previous block that the node must also verify, and correctly calculate whether the assertions it made were true or false. The average PoNW that a node performed in its previous x nodeblocks will be used to determine the target PoNW for the node to verify - and this will randomly be a large number of smaller PoNW transactions, or a smaller number of large PoNW. This process will be deterministic based on that block and address hash. All the data will be put together in a transaction and then signed by the node addresses private key. If a nodeWorkComplete transaction contains any incorrect information in an attempt to cheat the validation process a challenge transaction can be created. This begins a refereeing process where other nodes check the challenge and vote whether it is to be upheld or not. The losing node is punished by losing their accrued PoNW for that epoch and a percentage of their security deposit. Nodes will also be punished if they broadcast more than one signed transaction per block. In order to prevent nodes from having multiple keys registered - which would enable them choose to perform PoNW on a subset of the data that they hold - the share of reward that the node gets will be multiplied based on the number of blocks within an epoch that the node performs PoNW on. The share of reward is limited based on how much security deposit has been staked. The higher the PoNW the higher the deposit needed in order to claim their full allocation of any reward. At the end of an epoch, with a wait period for any delayed or censored transactions or challenges to be included and settled up, the process of calculating the reward each node is due can begin. This will then be then paid in a regular block, and means for all the data involved in PoNW, the only permanent mark it makes on the main blockchain is for a transaction that pays all addresses their share of the reward at the end of epoch. Any miner who creates a block without correctly calculating and paying the due reward will have mined an invalid block and be orphaned. The question of where and how much the reward comes from is a different one. It could come from the existing miner reward, or a special new tx donation fee for nodes. If there was some way for users to ‘donate’ to the reward pool for nodes this would increase the incentive for additional nodes to participate on the network in the event of centralisation. This is a relatively effective way to create a reward for all nodes participating on a network. I’d be keen to field any questions or critiques. Thanks, John Hardy john at seebitcoin.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170207/ff6c8c31/attachment-0001.html original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013551.html
Bitcoin Core 0.14.1 released | Wladimir J. van der Laan | Apr 22 2017
Wladimir J. van der Laan on Apr 22 2017: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Bitcoin Core version 0.14.1 is now available from: https://bitcoin.org/bin/bitcoin-core-0.14.1/ Or, by torrent: magnet:?xt=urn:btih:0482be8fc8e1c0b02162871e3591efc3d1d34585&dn;=bitcoin-core-0.14.1&tr;=udp%3A%2F%2Fpublic.popcorn-tracker.org%3A6969%2Fannounce&tr;=http%3A%2F%2Fatrack.pow7.com%2Fannounce&tr;=http%3A%2F%2Fbt.henbt.com%3A2710%2Fannounce&tr;=http%3A%2F%2Fmgtracker.org%3A6969%2Fannounce&tr;=http%3A%2F%2Fopen.touki.ru%2Fannounce.php&tr;=http%3A%2F%2Fp4p.arenabg.ch%3A1337%2Fannounce&tr;=http%3A%2F%2Fpow7.com%3A80%2Fannounce&tr;=http%3A%2F%2Ftracker.dutchtracking.nl%3A80%2Fannounce This is a new minor version release, including various bugfixes and performance improvements, as well as updated translations. Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issues To receive security and update notifications, please subscribe to: https://bitcoincore.org/en/list/announcements/join/ Compatibility Bitcoin Core is extensively tested on multiple operating systems using the Linux kernel, macOS 10.8+, and Windows Vista and later. Microsoft ended support for Windows XP on April 8th, 2014, No attempt is made to prevent installing or running the software on Windows XP, you can still do so at your own risk but be aware that there are known instabilities and issues. Please do not report issues about Windows XP to the issue tracker. Bitcoin Core should also work on most other Unix-like systems but is not frequently tested on them. Notable changes RPC changes
The first positional argument of createrawtransaction was renamed from
transactions to inputs.
The argument of disconnectnode was renamed from node to address.
These interface changes break compatibility with 0.14.0, when the named arguments functionality, introduced in 0.14.0, is used. Client software using these calls with named arguments needs to be updated. Mining In previous versions, getblocktemplate required segwit support from downstream clients/miners once the feature activated on the network. In this version, it now supports non-segwit clients even after activation, by removing all segwit transactions from the returned block template. This allows non-segwit miners to continue functioning correctly even after segwit has activated. Due to the limitations in previous versions, getblocktemplate also recommended non-segwit clients to not signal for the segwit version-bit. Since this is no longer an issue, getblocktemplate now always recommends signalling segwit for all miners. This is safe because ability to enforce the rule is the only required criteria for safe activation, not actually producing segwit-enabled blocks. UTXO memory accounting Memory usage for the UTXO cache is being calculated more accurately, so that the configured limit (-dbcache) will be respected when memory usage peaks during cache flushes. The memory accounting in prior releases is estimated to only account for half the actual peak utilization. The default -dbcache has also been changed in this release to 450MiB. Users who currently set -dbcache to a high value (e.g. to keep the UTXO more fully cached in memory) should consider increasing this setting in order to achieve the same cache performance as prior releases. Users on low-memory systems (such as systems with 1GB or less) should consider specifying a lower value for this parameter. Additional information relating to running on low-memory systems can be found here: reducing-bitcoind-memory-usage.md. 0.14.1 Change log Detailed release notes follow. This overview includes changes that affect behavior, not code moves, refactors and string updates. For convenience in locating the code changes and accompanying discussion, both the pull request and git merge commit are mentioned.
RPC and other APIs
#10084 142fbb2 Rename first named arg of createrawtransaction (MarcoFalke)
#10139 f15268d Remove auth cookie on shutdown (practicalswift)
#10146 2fea10a Better error handling for submitblock (rawodb, gmaxwell)
Bitcoin Core 0.10.0 released | Wladimir | Feb 16 2015
Wladimir on Feb 16 2015: Bitcoin Core version 0.10.0 is now available from: https://bitcoin.org/bin/0.10.0/ This is a new major version release, bringing both new features and bug fixes. Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issues The whole distribution is also available as torrent: https://bitcoin.org/bin/0.10.0/bitcoin-0.10.0.torrent magnet:?xt=urn:btih:170c61fe09dafecfbb97cb4dccd32173383f4e68&dn;=0.10.0&tr;=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr;=udp%3A%2F%2Fopen.demonii.com%3A1337&ws;=https%3A%2F%2Fbitcoin.org%2Fbin%2F Upgrading and downgrading How to Upgrade 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 (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux). Downgrading warning Because release 0.10.0 makes use of headers-first synchronization and parallel block download (see further), the block files and databases are not backwards-compatible with older versions of Bitcoin Core or other software:
Blocks will be stored on disk out of order (in the order they are
received, really), which makes it incompatible with some tools or other programs. Reindexing using earlier versions will also not work anymore as a result of this.
The block index database will now hold headers for which no block is
stored on disk, which earlier versions won't support. If you want to be able to downgrade smoothly, make a backup of your entire data directory. Without this your node will need start syncing (or importing from bootstrap.dat) anew afterwards. It is possible that the data from a completely synchronised 0.10 node may be usable in older versions as-is, but this is not supported and may break as soon as the older version attempts to reindex. This does not affect wallet forward or backward compatibility. Notable changes Faster synchronization Bitcoin Core now uses 'headers-first synchronization'. This means that we first ask peers for block headers (a total of 27 megabytes, as of December 2014) and validate those. In a second stage, when the headers have been discovered, we download the blocks. However, as we already know about the whole chain in advance, the blocks can be downloaded in parallel from all available peers. In practice, this means a much faster and more robust synchronization. On recent hardware with a decent network link, it can be as little as 3 hours for an initial full synchronization. You may notice a slower progress in the very first few minutes, when headers are still being fetched and verified, but it should gain speed afterwards. A few RPCs were added/updated as a result of this:
getblockchaininfo now returns the number of validated headers in addition to
the number of validated blocks.
getpeerinfo lists both the number of blocks and headers we know we have in
common with each peer. While synchronizing, the heights of the blocks that we have requested from peers (but haven't received yet) are also listed as 'inflight'.
A new RPC getchaintips lists all known branches of the block chain,
including those we only have headers for. Transaction fee changes This release automatically estimates how high a transaction fee (or how high a priority) transactions require to be confirmed quickly. The default settings will create transactions that confirm quickly; see the new 'txconfirmtarget' setting to control the tradeoff between fees and confirmation times. Fees are added by default unless the 'sendfreetransactions' setting is enabled. Prior releases used hard-coded fees (and priorities), and would sometimes create transactions that took a very long time to confirm. Statistics used to estimate fees and priorities are saved in the data directory in the fee_estimates.dat file just before program shutdown, and are read in at startup. New command line options for transaction fee changes:
-txconfirmtarget=n : create transactions that have enough fees (or priority)
so they are likely to begin confirmation within n blocks (default: 1). This setting is over-ridden by the -paytxfee option.
-sendfreetransactions : Send transactions as zero-fee transactions if possible
(default: 0) New RPC commands for fee estimation:
estimatefee nblocks : Returns approximate fee-per-1,000-bytes needed for
a transaction to begin confirmation within nblocks. Returns -1 if not enough transactions have been observed to compute a good estimate.
estimatepriority nblocks : Returns approximate priority needed for
a zero-fee transaction to begin confirmation within nblocks. Returns -1 if not enough free transactions have been observed to compute a good estimate. RPC access control changes Subnet matching for the purpose of access control is now done by matching the binary network address, instead of with string wildcard matching. For the user this means that -rpcallowip takes a subnet specification, which can be
a single IP address (e.g. 220.127.116.11 or fe80::0012:3456:789a:bcde)
a network/CIDR (e.g. 18.104.22.168/24 or fe80::0000/64)
a network/netmask (e.g. 22.214.171.124/255.255.255.0 or fe80::0012:3456:789a:bcde/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff)
An arbitrary number of -rpcallow arguments can be given. An incoming connection will be accepted if its origin address matches one of them. For example: | 0.9.x and before | 0.10.x | |--------------------------------------------|---------------------------------------| | -rpcallowip=192.168.1.1 | -rpcallowip=192.168.1.1 (unchanged) | | -rpcallowip=192.168.1.* | -rpcallowip=192.168.1.0/24 | | -rpcallowip=192.168.* | -rpcallowip=192.168.0.0/16 | | -rpcallowip=* (dangerous!) | -rpcallowip=::/0 (still dangerous!) | Using wildcards will result in the rule being rejected with the following error in debug.log:
Error: Invalid -rpcallowip subnet specification: *. Valid are a single IP (e.g. 126.96.36.199), a network/netmask (e.g. 188.8.131.52/255.255.255.0) or a network/CIDR (e.g. 184.108.40.206/24).
REST interface A new HTTP API is exposed when running with the -rest flag, which allows unauthenticated access to public node data. It is served on the same port as RPC, but does not need a password, and uses plain HTTP instead of JSON-RPC. Assuming a local RPC server running on port 8332, it is possible to request:
In every case, EXT can be bin (for raw binary data), hex (for hex-encoded binary) or json. For more details, see the doc/REST-interface.md document in the repository. RPC Server "Warm-Up" Mode The RPC server is started earlier now, before most of the expensive intialisations like loading the block index. It is available now almost immediately after starting the process. However, until all initialisations are done, it always returns an immediate error with code -28 to all calls. This new behaviour can be useful for clients to know that a server is already started and will be available soon (for instance, so that they do not have to start it themselves). Improved signing security For 0.10 the security of signing against unusual attacks has been improved by making the signatures constant time and deterministic. This change is a result of switching signing to use libsecp256k1 instead of OpenSSL. Libsecp256k1 is a cryptographic library optimized for the curve Bitcoin uses which was created by Bitcoin Core developer Pieter Wuille. There exist attacks against most ECC implementations where an attacker on shared virtual machine hardware could extract a private key if they could cause a target to sign using the same key hundreds of times. While using shared hosts and reusing keys are inadvisable for other reasons, it's a better practice to avoid the exposure. OpenSSL has code in their source repository for derandomization and reduction in timing leaks that we've eagerly wanted to use for a long time, but this functionality has still not made its way into a released version of OpenSSL. Libsecp256k1 achieves significantly stronger protection: As far as we're aware this is the only deployed implementation of constant time signing for the curve Bitcoin uses and we have reason to believe that libsecp256k1 is better tested and more thoroughly reviewed than the implementation in OpenSSL.  https://eprint.iacr.org/2014/161.pdf Watch-only wallet support The wallet can now track transactions to and from wallets for which you know all addresses (or scripts), even without the private keys. This can be used to track payments without needing the private keys online on a possibly vulnerable system. In addition, it can help for (manual) construction of multisig transactions where you are only one of the signers. One new RPC, importaddress, is added which functions similarly to importprivkey, but instead takes an address or script (in hexadecimal) as argument. After using it, outputs credited to this address or script are considered to be received, and transactions consuming these outputs will be considered to be sent. The following RPCs have optional support for watch-only: getbalance, listreceivedbyaddress, listreceivedbyaccount, listtransactions, listaccounts, listsinceblock, gettransaction. See the RPC documentation for those methods for more information. Compared to using getrawtransaction, this mechanism does not require -txindex, scales better, integrates better with the wallet, and is compatible with future block chain pruning functionality. It does mean that all relevant addresses need to added to the wallet before the payment, though. Consensus library Starting from 0.10.0, the Bitcoin Core distribution includes a consensus library. The purpose of this library is to make the verification functionality that is critical to Bitcoin's consensus available to other applications, e.g. to language bindings such as [python-bitcoinlib](https://pypi.python.org/pypi/python-bitcoinlib) or alternative node implementations. This library is called libbitcoinconsensus.so (or, .dll for Windows). Its interface is defined in the C header [bitcoinconsensus.h](https://github.com/bitcoin/bitcoin/blob/0.10/src/script/bitcoinconsensus.h). In its initial version the API includes two functions:
bitcoinconsensus_verify_script verifies a script. It returns whether the indicated input of the provided serialized transaction
correctly spends the passed scriptPubKey under additional constraints indicated by flags
bitcoinconsensus_version returns the API version, currently at an experimental 0
The functionality is planned to be extended to e.g. UTXO management in upcoming releases, but the interface for existing methods should remain stable. Standard script rules relaxed for P2SH addresses The IsStandard() rules have been almost completely removed for P2SH redemption scripts, allowing applications to make use of any valid script type, such as "n-of-m OR y", hash-locked oracle addresses, etc. While the Bitcoin protocol has always supported these types of script, actually using them on mainnet has been previously inconvenient as standard Bitcoin Core nodes wouldn't relay them to miners, nor would most miners include them in blocks they mined. bitcoin-tx It has been observed that many of the RPC functions offered by bitcoind are "pure functions", and operate independently of the bitcoind wallet. This included many of the RPC "raw transaction" API functions, such as createrawtransaction. bitcoin-tx is a newly introduced command line utility designed to enable easy manipulation of bitcoin transactions. A summary of its operation may be obtained via "bitcoin-tx --help" Transactions may be created or signed in a manner similar to the RPC raw tx API. Transactions may be updated, deleting inputs or outputs, or appending new inputs and outputs. Custom scripts may be easily composed using a simple text notation, borrowed from the bitcoin test suite. This tool may be used for experimenting with new transaction types, signing multi-party transactions, and many other uses. Long term, the goal is to deprecate and remove "pure function" RPC API calls, as those do not require a server round-trip to execute. Other utilities "bitcoin-key" and "bitcoin-script" have been proposed, making key and script operations easily accessible via command line. Mining and relay policy enhancements Bitcoin Core's block templates are now for version 3 blocks only, and any mining software relying on its getblocktemplate must be updated in parallel to use libblkmaker either version 0.4.2 or any version from 0.5.1 onward. If you are solo mining, this will affect you the moment you upgrade Bitcoin Core, which must be done prior to BIP66 achieving its 951/1001 status. If you are mining with the stratum mining protocol: this does not affect you. If you are mining with the getblocktemplate protocol to a pool: this will affect you at the pool operator's discretion, which must be no later than BIP66 achieving its 951/1001 status. The prioritisetransaction RPC method has been added to enable miners to manipulate the priority of transactions on an individual basis. Bitcoin Core now supports BIP 22 long polling, so mining software can be notified immediately of new templates rather than having to poll periodically. Support for BIP 23 block proposals is now available in Bitcoin Core's getblocktemplate method. This enables miners to check the basic validity of their next block before expending work on it, reducing risks of accidental hardforks or mining invalid blocks. Two new options to control mining policy:
-datacarrier=0/1 : Relay and mine "data carrier" (OP_RETURN) transactions
if this is 1.
-datacarriersize=n : Maximum size, in bytes, we consider acceptable for
"data carrier" outputs. The relay policy has changed to more properly implement the desired behavior of not relaying free (or very low fee) transactions unless they have a priority above the AllowFreeThreshold(), in which case they are relayed subject to the rate limiter. BIP 66: strict DER encoding for signatures Bitcoin Core 0.10 implements BIP 66, which introduces block version 3, and a new consensus rule, which prohibits non-DER signatures. Such transactions have been non-standard since Bitcoin v0.8.0 (released in February 2013), but were technically still permitted inside blocks. This change breaks the dependency on OpenSSL's signature parsing, and is required if implementations would want to remove all of OpenSSL from the consensus code. The same miner-voting mechanism as in BIP 34 is used: when 751 out of a sequence of 1001 blocks have version number 3 or higher, the new consensus rule becomes active for those blocks. When 951 out of a sequence of 1001 blocks have version number 3 or higher, it becomes mandatory for all blocks. Backward compatibility with current mining software is NOT provided, thus miners should read the first paragraph of "Mining and relay policy enhancements" above. 0.10.0 Change log Detailed release notes follow. This overview includes changes that affect external behavior, not code moves, refactors or string updates. RPC:
f923c07 Support IPv6 lookup in bitcoin-cli even when IPv6 only bound on localhost
b641c9c Fix addnode "onetry": Connect with OpenNetworkConnection
Find out what your expected return is depending on your hash rate and electricity cost. Find out if it's profitable to mine Bitcoin, Ethereum, Litecoin, DASH or Monero. Do you think you've got what it takes to join the tough world of cryptocurrency mining? L.A.-based Bitcoin service provider OpenNode has released a new feature, Bitcoin Payouts, to pave the way for automated bitcoin payroll on the platforms. Bitcoin Diamond (BCD) Stats. Transactions count, value, Bitcoin Diamonds sent, difficulty, blocks count, network hashrate, market capitalization... Master Node Calculator . Sort By: Name: Nodes: Price $ Price BTC: Best BTC $ ROI Days: ROI Yearly: Coins for Node: Node Worth: Coins Daily: Daily Weekly: Monthly Yearly: Masternode Services: Absolute Coin (ABS) Block Explorer Mining Pools Lyra2v2: $ 0.0000 (No data at exchange) 9 282,20 (Register here) 0: 0,00 %: 2500 ABS: $ 0,00: 0: $ Bitcoin Interest ("BCI") is a competitive staking cryptocurrency focusing on three key areas Technology, Community, and Savings. Our blockchain has new integrated savings technology that allows our users to safely park their coins and earn interest payments without ever moving coins from their wallets. Simply register your Wallet Address and the amount of Bitcoin Interest coins it contains to
Complete instructions with node list!!!! Here is my Node List for EmberCoin: addnode=220.127.116.11:10024 addnode=18.104.22.168:3584 addnode=22.214.171.124:4... Our Masternode Rewards Calculator is here to help you get acquainted with Divi's five-tier system before our Mainnet launch in May: https: ... Bitcoin for Beginners 13,950 views. The main function of a Bitcoin calculator is to compute how much processing power it will take to generate Bitcoins with a given hardware setup. Because of the deterministic nature of all the ... addnode=126.96.36.199:7118 addnode=188.8.131.52:7118 addnode=184.108.40.206:7118 addnode=220.127.116.11:7118 addnode=18.104.22.168:7118 addnode=22.214.171.124... Attack hit chance and critical chance calculator Tales. Loading... Unsubscribe from Tales? Cancel Unsubscribe. ... Banking on Bitcoin YouTube Movies. 2017 · Documentary; 1:23:41. Dil Bechara ...