GetBlock | Blockchain Nodes Provider | Get access for most

Configuring bitcoin full node for faster RPC calls

I have been working with a bitcoin full node and attempting to parse the blockchain data, whilst storing it in an external database.
The script I am using iterates through each block using getblock[hash;2] which populates multiple tables. However in order to get the current blocks input values we have to perform an expensive getRawTransaction each previous txid.
We have singled this out as the bottleneck in the code for most time taken, rendering the script very slow. We have also tried using RPC batching but this also takes considerable amount of time, potentially more with a memory overhead.
I am wondering if there is a best configuration of the daemon to improve RPC call speed? i.e. using rpcthread/queue, increasing dbcache etc.
Another option would be to implement blocks only mode, by reducing the bandwidth could this improve RPC commands?
Bitcoin Core Daemon version v0.16.0.0-g4b4d7eb255
Server Details OS-Ubuntu 16.04 32 GB ram
submitted by dandan4561 to Bitcoin [link] [comments]

BlockParser - A way to get the balance of all bitcoin addresses

For same time, I was searching for a way to get the balance of all bitcoin addresses in order to do statistical analysis of the wealthy distribution. If finally found a way to do it without using an external API such as This method will allow you to create a list of all bitcoin addresses ordered by balance, excluding empty ones. This does not work properly for addresses involved in multisignature transactions.
Step 1 – Parse all blocks using this small program
#!/usbin/perl # File: # Author: Saulo Fonseca # Licence: GNU GPLv3 use warnings; use strict; use JSON; # Get argument as block number my $blockNumber = $ARGV[0] + 0; # Convert to int # Get all transactions my $blockHash = `bitcoin-cli getblockhash $blockNumber`; chomp($blockHash); my $out = `bitcoin-cli getblock $blockHash`; my $json = decode_json($out); if (defined $json->{'tx'}) { my $txs = $json->{'tx'}; foreach my $txHash (@$txs) { $out = `bitcoin-cli getrawtransaction $txHash 1`; $json = decode_json($out); if (defined $json->{'vin'}) { # Get all input transactions my $vins = $json->{'vin'}; foreach my $vin (@$vins) { if (defined $vin->{'txid'}) { my $tx = $vin->{'txid'}; my $index = $vin->{'vout'}; printf("%s\t%d\tdel\n",$tx,$index); } } } if (defined $json->{'vout'}) { # Get all output addresses my $vouts = $json->{'vout'}; foreach my $vout (@$vouts) { if (defined $vout->{'scriptPubKey'}->{'addresses'}) { my $keys = $vout->{'scriptPubKey'}->{'addresses'}; my $value = $vout->{'value'}; my $index = $vout->{'n'}; foreach my $key (@$keys) { printf("%s\t%d\t%s\t%.8f\n",$txHash,$index,$key,$value); } } } } } } 
This program will get the height of the block as an argument and return a tab separated output with the following columns:
Here is an example of the output for the block 100000 (with cropped TXIDs in order to fit the reddit width):
8c14f0...d06d87 0 1HWqMzw1jfpXb3xyuUZ4uWXY4tqL2cW47J 50.00000000 87a157...382e03 0 del fff252...9702c4 0 1JqDybm2nWTENrHvMyafbSXXtTk5Uv5QAn 5.56000000 fff252...9702c4 1 1EYTGtG4LnFfiMvjJdsU7GMGCQvsRSjYhx 44.44000000 cf4e29...bf3ec3 1 del 6359f0...236ec4 0 1H8ANdafjpqYntniT3Ddxh4xPBMCSz33pj 0.01000000 6359f0...236ec4 1 1Am9UTGfdnxabvcywYG2hvzr6qK8T3oUZT 2.99000000 f4515f...72600b 0 del e9a668...b80c1d 0 16FuTPaeRSPVxxCnwQmdyx2PQWxX6HWzhQ 0.01000000 
You should process all blocks using this program and send the output to a text file. The command in bash that does it is:
seq -w 1 555000 | while read i; do (./ $i >> blocks.txt); done 
This will take a while depending on the performance of your system. However, it must be done only one time.
Step 2 – Export the list of all spent transactions
Use the following command to export all spent transactions on all processed blocks on step 1:
grep -h del blocks.txt | cut -f1,2 > spent.txt 
The lower cap letter L in “del” will not match any entry on a hex string nor on an address, as it is not allowed in base58.
Step 3 – Get the list of all UTXO
By removing all spent transactions, you have the list of all UTXO (unspent transactions output). Do it by running:
grep -v -f spent.txt blocks.txt > utxo.txt 
Step 4 – List all addresses balances
Using the UTXO list, you can get the balances of all addresses by running:
cat utxo.txt | cut -f3,4 | awk '{ seen[$1] += $2 } END { for (i in seen) printf "%.8f\t%s\n", seen[i], i }' | sort -n -r > anyBTC.txt 
You can import this last file on your favorite analysis program in order to have a better idea how the distribution of bitcoins over the addresses is.
PS: After the arrival of new blocks by the network, you only need to process the step 1 for the new blocks and repeat all the other steps in order to have an updated version of the files.
submitted by sauloqf to Bitcoin [link] [comments]

PIVX Core Wallet 3.0.5 final release (November 13th, 2017) - Mandatory Upgrade

Github release link
Forum Post

Important Notes

Upgrade instructions

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](
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
  1. stop your wallet and/or daemon
  2. locate the folder with the blockchain folders (usually ~/.pivx/)
  3. do a complete(!) backup of this folder in case something goes wrong
  4. completely remove the folders "blocks", "chainstate", "sporks" and "zerocoin"
  5. download one of the snapshot-files (preferably the newest one) above into this folder
  6. unpack the snapshot file: 'unzip '
  7. the folders deleted above are now replaced by the ones from the snapshot
  8. 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
spork show 
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 . This can be done from the debug menu or with pivx-cli by saying
addnode add 

Notable Changes

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.

Multisig GUI

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.



  • 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.
submitted by turtleflax to pivx [link] [comments]

Bitcoin ABC 0.18.8 released!

Bitcoin ABC version 0.18.8 is now available from:
This release includes the following features and fixes: - dumpwallet now includes hex-encoded scripts from the wallet in the dumpfile - importwallet now imports these scripts, but corresponding addresses may not be added correctly or a manual rescan may be required to find relevant· transactions - getblock 2 (verbosity = 2) now returns hex values in transaction JSON blobs - Remove miner policy estimator in favor of minimum fees, also remove fee_estimates.dat. Old copies will be left in place. - The log timestamp format is now ISO 8601 (e.g. "2019-01-28T15:41:17Z") - Behavior change: in case of multiple values for an argument, the following rules apply: - From the command line, the last value takes precedence - From the config file, the first value takes precedence - From the config file, if an argument is negated it takes precedent over all the previous occurences of this argument (e.g. "foo=2 \n nofoo=1" will set foo=0) - The configuration files now support assigning options to a specific network. To do so, sections or prefix can be used: main.uacomment=bch-mainnet test.uacomment=bch-testnet regtest.uacomment=bch-regtest [main] mempoolsize=300 [test] mempoolsize=200 [regtest] mempoolsize=50 The addnode=, connect=, port=, bind=, rpcport=, rpcbind= and wallet= options will only apply to mainnet when specified in the configuration file, unless a network is specified.
submitted by jasonbcox to BitcoinABC [link] [comments]

Help understanding raw transactions

I'm struggling a bit with understanding raw transactions. I understand from the Bitcoin wiki that the input(s) reference previous transactions as the source of funds. Then the outputs is how the source of funds is paid out. Typically if there are two outputs, it is because the entire input transaction must be spent and so one output is the payment and the second output is the remainder being paid back to self.
This all makes sense until I went to look at a ReddCoin transaction. I used getblockcount then getblockhash, then getblock to retrieve the latest confirmed block. Then looked at one of the transactions with getrawtransaction then decoderawtransaction.
Here is the transaction I looked at: ece8f2411a3c0193ee59b4e22ee6cab4e0f15e480e61bfad018fc0c4f76758b4
There is one input and two outputs. Both outputs are equal value and paid to the same wallet. The input transaction is a similar transaction where two outputs both paid to the same wallet but the value is double. The input of that transaction is the same again but with the value doubled.
I can't understand what the point of this transaction would be. Someone with a balance of x is sending a two payments to self of x/2. Then when that transaction is confirmed, each output is then used to make two more payments to self of x/2/2 and so on.
Can someone explain this to me? Is this related to staking?
submitted by CaptainCryptogram to reddCoin [link] [comments]

[Informational] [CC0] Plug In To The Bitcoin Network

Bitcoin Peer to Peer Network Protocol

The Bitcoin network is designed to operate in a peer to peer configuration, in a reflection of the overall decentralized design of the system. The network goal is to sync the Blockchain, the transaction record and payment settlement system through which Bitcoins are minted and exchanged with Bitcoin users. A high level view of the network is that of a wide array of individual peers, each helping to broadcast updated Blockchain information across the entire group.
The broadcast sync of the Blockchain and the network setup and operational action are accomplished through a narrow network protocol, consisting of a small set of messages. Most messages are designed with pushing data in mind, to continue to propagate waves of updated Blockchain and peer data to local peers and across the greater network.


All Bitcoin network communication occurs using TCP, the standard Internet protocol for reliable networking. Bitcoin has supported the IPv6 standard since September of 2012, and can be used over a user selected port, with the default being 8333.
When a Bitcoin node is instantiated for the first time, it needs to find a way to connect to the greater network. At the start of the project, new nodes would automatically connect to a hard-coded IRC server, with IRC channels being used to publish and discover IP addresses of network nodes. This bootstrapping process was created in 2011, complementing the IRC system it would ultimately wholly replace. In this system hard-coded DNS address based seeds are resolved to the IP addresses of seed nodes to direct a new node onto the network. Since 2012 Bitcoin Core developers Luke-Jr and Pieter Wuille have operated seed nodes, along with various others over the years.
When connecting to a node IP, a Bitcoin node will send its version as the initial message, in a handshaking process where information about its makeup including its current clock value is published to the remote node. The specific messages used are version, which sends the node information, and verack, which acknowledges the receipt of the version information. This handshake helps a node define a normalized network clock value: time calculations a node makes are based not off of its own clock, but rather the median time from all successfully connected peers.
After the initial bootstrapped connection onto the network, previously connected-to peers as well as relayed known local active peer information is cached. Nodes are designed to recall other nodes in an archival list. This list of node IPs is cached in order to bypass the node seed stage on subsequent starts. On each network join, a node will consult its cache of nodes, semi-randomly selecting nodes to attempt to connect to, with a prioritization of most recently active.


Once nodes have successfully joined the network, they are then faced with their primary task of syncing the Blockchain. The workhorse message that helps a node accomplish this task is the inventory or more precisely inv message, which a node uses to push listings of blocks and transactions to connected peers. Inventory messages are simply concise high level identification information, they do not carry any information beyond a listing of blocks and transactions. These messages are published constantly, as novel blocks and transactions are validated and then pushed to other peers to relay the new information.
Specific inventory messages may be requested directly from a connected peer using the getblocks message that queries about a specific set of blocks. This message is used to sync nodes that are out of date, such as nodes that are new to the network and must sync the entire blockchain through a long series of getblocks requests.
When an inventory message is received, listed inventory of blocks and transactions may be requested through the getdata request. This is generally performed when a node receives an inventory message containing novel block or transaction information. In response to the getdata response the node returns with a block or tx message, sending blocks and transactions respectively.

Syncing to Light Clients

Full nodes may also service the syncing needs of light clients, which some call SPV clients after a general proposal made by Satoshi in the original Bitcoin whitepaper. These clients avoid validating the blockchain to provide a more practical user experience at the cost of incurring counter-party risk of an abusive miner or set of miners.
Filter message features so that full node could service requests for light clients were added through BIP 37. Light clients uses the getheaders message to request that full nodes return Blockchain headers information which are sent using the headers message. The chain of Blockchain headers are used to piece together the chain with the greatest proof of work. This is used to verify transactions as being on the longest chain of blocks, with the important caveat that it may be an invalid chain.
Light clients also use bloom messages to request transactions that they care about, they do not ask directly for transactions in an effort to add some slight privacy to the client's financial status, however these efforts have only a small impact and are not comprehensive.

Peer Announcements

In addition to syncing the Blockchain, the Bitcoin network syncs information about the IP addresses that comprise the network, to provide for sustainable connectivity. Nodes publish to other nodes the set of active peers they know about using the addr message, which can contain a list of up to a thousand known active nodes. Nodes can also ask other nodes for an addr message using a getaddr message. Every twenty four hours every node will broadcast a heartbeat addr message, which is passed along to two connected nodes.
General network connectivity may also be tested by a node using the ping message, which does nothing other than attempt a connection to verify connectivity.

Obsolete Messages

In the original Bitcoin protocol, support was present for an IP based sending system. The concept allowed connecting to a node directly to make a transaction. To accomplish that task nodes used messages that were later deprecated and removed. IP based sending was eliminated very early on due to security, privacy, and practicality issues.
Although the Bitcoin network was designed as a group of headless automatons, early in its life various critical defects were found that required aggressive central action to remedy. As a practical solution to facilitate the rapid deployment of requisite fixes, Satoshi Nakamoto devised an alerting system for sending version update messages across the node network.
This system used a protocol message called alert to directly broadcast a signed message from Satoshi, to be shown to users to inform them of critical information. To avoid a singular dependency Satoshi shared the signing key with others, which over time became an unnecessary risk to the network. In April of 2016 the release of Bitcoin Core version 0.12.1 eliminated the alert system.
submitted by pb1x to writingforbitcoin [link] [comments]

Facilitating Discussion of 0.9.0 FINAL of Bitcoin Core (aka Bitcoin QT)

To facilitate a detailed discussion of some of the finer points of this update, I added numbering to each bullet in release notes, and also posted it to RapGenius, where people can annotate it if they'd like.
I'm not a programmer, but I'm curious to hear what programmers and other people smarter than me have to say about all the new changes.
EDIT1 : Doh! Reddit detroyed all the formatting and now i'm on baby duty so can't fix it. EDIT 2: Nap time! Just fixed the formatting :)
---- 0.9.0 RELEASE NOTES ----
Part 1. RPC:
1.1 - New notion of 'conflicted' transactions, reported as confirmations: -1
1.2 - 'listreceivedbyaddress' now provides tx ids
1.3 - Add raw transaction hex to 'gettransaction' output
1.4 - Updated help and tests for 'getreceivedby(account|address)'
1.5 - In 'getblock', accept 2nd 'verbose' parameter, similar to getrawtransaction, but defaulting to 1 for backward compatibility
1.6 - Add 'verifychain', to verify chain database at runtime
1.7 - Add 'dumpwallet' and 'importwallet' RPCs
1.8 - 'keypoolrefill' gains optional size parameter
1.9 - Add 'getbestblockhash', to return tip of best chain
1.10 - Add 'chainwork' (the total work done by all blocks since the genesis block) to 'getblock' output
1.11 - Make RPC password resistant to timing attacks
1.12 - Clarify help messages and add examples
1.13 - Add 'getrawchangeaddress' call for raw transaction change destinations
1.14 - Reject insanely high fees by default in 'sendrawtransaction'
1.15 - Add RPC call 'decodescript' to decode a hex-encoded transaction script
1.16 - Make 'validateaddress' provide redeemScript
1.17 - Add 'getnetworkhashps' to get the calculated network hashrate
1.18 - New RPC 'ping' command to request ping, new 'pingtime' and 'pingwait' fields in 'getpeerinfo' output
1.19 - Adding new 'addrlocal' field to 'getpeerinfo' output
1.20 - Add verbose boolean to 'getrawmempool'
1.21 - Add rpc command 'getunconfirmedbalance' to obtain total unconfirmed balance
1.22 - Explicitly ensure that wallet is unlocked in importprivkey
1.23 - Add check for valid keys in importprivkey
Part 2. Command-line options:
2.1 - New option: -nospendzeroconfchange to never spend unconfirmed change outputs
2.2 - New option: -zapwallettxes to rebuild the wallet's transaction information
2.3 - Rename option '-tor' to '-onion' to better reflect what it does
2.4 - Add '-disablewallet' mode to let bitcoind run entirely without wallet (when built with wallet)
2.5 - Update default '-rpcsslciphers' to include TLSv1.2
2.6 - make '-logtimestamps' default on and rework help-message
2.7 - RPC client option: '-rpcwait', to wait for server start
2.8 - Remove '-logtodebugger'
2.9 - Allow -noserver with bitcoind
Part 3. Block-chain handling and storage:
3.1 - Update leveldb to 1.15
3.2 - Check for correct genesis (prevent cases where a datadir from the wrong network is accidentally loaded)
3.3 - Allow txindex to be removed and add a reindex dialog
3.4 - Log aborted block database rebuilds
3.5 - Store orphan blocks in serialized form, to save memory
3.6 - Limit the number of orphan blocks in memory to 750
3.7 - Fix non-standard disconnected transactions causing mempool orphans
3.8 - Add a new checkpoint at block 279,000
Part 4. Wallet:
4.1 - Bug fixes and new regression tests to correctly compute the balance of wallets containing double-spent (or mutated) transactions
4.2 - Store key creation time. Calculate whole-wallet birthday
4.3 - Optimize rescan to skip blocks prior to birthday
4.4 - Let user select wallet file with -wallet=foo.dat
4.5 - Consider generated coins mature at 101 instead of 120 blocks
4.6 - Improve wallet load time
4.7 - Don't count txins for priority to encourage sweeping
4.8 - Don't create empty transactions when reading a corrupted wallet
4.9 - Fix rescan to start from beginning after importprivkey
4.10 - Only create signatures with low S values
Part 5. Mining:
5.1 - Increase default -blockmaxsize/prioritysize to 750K/50K
5.2 - 'getblocktemplate' does not require a key to create a block template
5.3 - Mining code fee policy now matches relay fee policy
Part 6. Protocol and network:
6.1 - Drop the fee required to relay a transaction to 0.01mBTC per kilobyte
6.2 - Send tx relay flag with version
6.3 - New 'reject' P2P message (BIP 0061, see for draft)
6.4 - Dump addresses every 15 minutes instead of 10 seconds
6.5 - Relay OP_RETURN data TxOut as standard transaction type
6.6 - Remove CENT-output free transaction rule when relaying
6.7 - Lower maximum size for free transaction creation
6.8 - Send multiple inv messages if mempool.size > MAX_INV_SZ
6.10 - Do not treat fFromMe transaction differently when broadcasting
6.11 - Process received messages one at a time without sleeping between messages
6.12 - Improve logging of failed connections
6.13 - Bump protocol version to 70002
6.14 - Add some additional logging to give extra network insight
6.15 - Added new DNS seed from
Part 7. Validation:
7.1 - Log reason for non-standard transaction rejection
7.2 - Prune provably-unspendable outputs, and adapt consistency check for it
7.3 - Detect any sufficiently long fork and add a warning
7.4 - Call the -alertnotify script when we see a long or invalid fork
7.5 - Fix multi-block reorg transaction resurrection
7.6 - Reject non-canonically-encoded serialization sizes
7.7 - Reject dust amounts during validation
7.8 - Accept nLockTime transactions that finalize in the next block
Part 8. Build system:
8.1 - Switch to autotools-based build system
8.2 - Build without wallet by passing --disable-wallet to configure, this removes the BerkeleyDB dependency
8.3 - Upgrade gitian dependencies (libpng, libz, libupnpc, boost, openssl) to more recent versions
8.4 - Windows 64-bit build support
8.5 - Solaris compatibility fixes
8.6 - Check integrity of gitian input source tarballs
8.7 - Enable full GCC Stack-smashing protection for all OSes
Part 9. GUI:
9.1 - Switch to Qt 5.2.0 for Windows build
9.2 - Add payment request (BIP 0070) support
9.3 - Improve options dialog
9.4 - Show transaction fee in new send confirmation dialog
9.5 - Add total balance in overview page
9.6 - Allow user to choose data directory on first start, when data directory ismissing, or when the -choosedatadir option is passed
9.7 - Save and restore window positions
9.8 - Add vout index to transaction id in transactions details dialog
9.9 - Add network traffic graph in debug window
9.10 - Add open URI dialog
9.11 - Add Coin Control Features
9.12 - Improve receive coins workflow: make the 'Receive' tab into a form to request payments, and move historical address list functionality to File menu
9.13 - Rebrand to Bitcoin Core
9.14 - Move initialization/shutdown to a thread. This prevents "Not responding" messages during startup. Also show a window during shutdown
9.15 - Don't regenerate autostart link on every client startup
9.16 - Show and store message of normal bitcoin:URI
9.17 - Fix richtext detection hang issue on very old Qt versions
9.18 - OS X: Make use of the 10.8+ user notification center to display Growl-like notifications
9.19 - OS X: Added NSHighResolutionCapable flag to Info.plist for better font rendering on Retina displays
9.20 - OS X: Fix bitcoin-qt startup crash when clicking dock icon
9.21 - Linux: Fix Gnome bitcoin: URI handler
Part 10. Miscellaneous:
10.1 - Add Linux script (contrib/qos/ to limit outgoing bandwidth
10.2 - Add '-regtest' mode, similar to testnet but private with instant block generation with 'setgenerate' RPC
10.3 - Add '' script to contrib, for creating bootstrap.dat
10.4 - Add separate bitcoin-cli client
submitted by WhiteyFisk to Bitcoin [link] [comments]

Bitcoin-QT 0.9 disponível para download

The Core Developers of Bitcoin released the 0.9.0 FINAL of Bitcoin Core (aka Bitcoin QT).
This is a Final Version, but its the same as 0.9.0rc3
Bitcoin Core version 0.9.0 is now available from:
This is a release candidate for a new major version. A major version brings both new features and bug fixes.
Please report bugs using the issue tracker at github:

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), uninstall all earlier versions of Bitcoin, then run the installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux).
If you are upgrading from version 0.7.2 or earlier, the first time you run 0.9.0 your blockchain files will be re-indexed, which will take anywhere from 30 minutes to several hours, depending on the speed of your machine.
On Windows, do not forget to uninstall all earlier versions of the Bitcoin client first, especially if you are switching to the 64-bit version.

Windows 64-bit installer

New in 0.9.0 is the Windows 64-bit version of the client. There have been frequent reports of users running out of virtual memory on 32-bit systems during the initial sync. Because of this it is recommended to install the 64-bit version if your system supports it.
NOTE: Release candidate 2 Windows binaries are not code-signed; use PGP and the SHA256SUMS.asc file to make sure your binaries are correct. In the final 0.9.0 release, Windows setup.exe binaries will be code-signed.

OSX 10.5 / 32-bit no longer supported

0.9.0 drops support for older Macs. The minimum requirements are now: * A 64-bit-capable CPU (see; * Mac OS 10.6 or later (see

Downgrading warnings

The 'chainstate' for this release is not always compatible with previous releases, so if you run 0.9 and then decide to switch back to a 0.8.x release you might get a blockchain validation error when starting the old release (due to 'pruned outputs' being omitted from the index of unspent transaction outputs).
Running the old release with the -reindex option will rebuild the chainstate data structures and correct the problem.
Also, the first time you run a 0.8.x release on a 0.9 wallet it will rescan the blockchain for missing spent coins, which will take a long time (tens of minutes on a typical machine).

Rebranding to Bitcoin Core

To reduce confusion between Bitcoin-the-network and Bitcoin-the-software we have renamed the reference client to Bitcoin Core.

Autotools build system

For 0.9.0 we switched to an autotools-based build system instead of individual (q)makefiles.
Using the standard "./; ./configure; make" to build Bitcoin-Qt and bitcoind makes it easier for experienced open source developers to contribute to the project.
Be sure to check doc/build-*.md for your platform before building from source.


Another change in the 0.9 release is moving away from the bitcoind executable functioning both as a server and as a RPC client. The RPC client functionality ("tell the running bitcoin daemon to do THIS") was split into a separate executable, 'bitcoin-cli'. The RPC client code will eventually be removed from bitcoind, but will be kept for backwards compatibility for a release or two.

walletpassphrase RPC

The behavior of the walletpassphrase RPC when the wallet is already unlocked has changed between 0.8 and 0.9.
The 0.8 behavior of walletpassphrase is to fail when the wallet is already unlocked:
> walletpassphrase 1000 walletunlocktime = now + 1000 > walletpassphrase 10 Error: Wallet is already unlocked (old unlock time stays) 
The new behavior of walletpassphrase is to set a new unlock time overriding the old one:
> walletpassphrase 1000 walletunlocktime = now + 1000 > walletpassphrase 10 walletunlocktime = now + 10 (overriding the old unlock time) 

Transaction malleability-related fixes

This release contains a few fixes for transaction ID (TXID) malleability issues:

Transaction Fees

This release drops the default fee required to relay transactions across the network and for miners to consider the transaction in their blocks to 0.01mBTC per kilobyte.
Note that getting a transaction relayed across the network does NOT guarantee that the transaction will be accepted by a miner; by default, miners fill their blocks with 50 kilobytes of high-priority transactions, and then with 700 kilobytes of the highest-fee-per-kilobyte transactions.
The minimum relay/mining fee-per-kilobyte may be changed with the minrelaytxfee option. Note that previous releases incorrectly used the mintxfee setting to determine which low-priority transactions should be considered for inclusion in blocks.
The wallet code still uses a default fee for low-priority transactions of 0.1mBTC per kilobyte. During periods of heavy transaction volume, even this fee may not be enough to get transactions confirmed quickly; the mintxfee option may be used to override the default.

0.9.0 Release notes

Command-line options:
Block-chain handling and storage:
Protocol and network:
Build system:
submitted by allex2501 to BrasilBitcoin [link] [comments]

Get Relevant Address/Amount from Coinbase Block

Just wondering if there is a better way to get my relevant addresses and amounts from a USDe block.
I just want to get the address from a (type: Generate) transaction.
Here is what I have so far (python):
d = usded block = d.getblock(blockhash) for tx in block['tx']: try: gettx = d.gettransaction(tx) except Exception, e: gettx = None if gettx: txid = tx summery = [] raw_tx = d.decoderawtransaction(d.getrawtransaction(txid)) has_val = False for vout in raw_tx['vout']: if vout['scriptPubKey']['type'] == 'pubkey' or vout['scriptPubKey']['type'] == 'pubkeyhash': val = d.validateaddress(vout['scriptPubKey']['addresses'][0]) if 'ismine' in val: if val['ismine'] == True: summery.append({'address': vout['scriptPubKey']['addresses'][0], 'amount': vout['value']}) print summery 
The latest DOGE and Bitcoin daemon APIs just give me the address with gettransaction but not the USDed..
submitted by ShadowState to USDe [link] [comments]

BITCOIN PRICE PLUMMETS IN MINUTES!  WHAT IS NEXT FOR BTC? My take on Micro Bitcoin Value TIP260: BITCOIN MATH & VALUE – W/ PLAN B How High Can Litecoin Price Go Due To Block Reward Halving? Bitcoin Halving 2020: Explanation & Price Prediction - YouTube

getblock¶. getblock "blockhash" (verbosity). If verbosity is 0, returns a string that is serialized, hex-encoded data for block ‘hash’. If verbosity is 1, returns an Object with information about block ‘hash’. BlockCard account holders can now seamlessly purchase Bitcoin (BTC) utilizing their Bank Accounts — no hassles, quick and easy! Unlike other platforms that make you wait days or weeks for access to your Bitcoin, BlockCard offers near instant settlement of Bitcoin purchases to your self-custodial wallet. Not only is this match-two mobile game fun to play, you will get rewarded with Bling Points that can be exchanged for Bitcoin. The amount you receive will be very small, but the more you play, the more you will earn! FEATURES: - Earn 1000 Bling Points to cash out to Bitcoin! - Cash out every 7 days! - Win or lose, always earn Bling Points! GetBlock is a blockchain nodes provider. Сonnect to Bitcoin, Ethereum, Monero, Litecoin and other nodes with JSON RPC API. All nodes have an open API and available for connection. Get a free API key right now! getblocktemplate¶. getblocktemplate "template_request". If the request parameters include a ‘mode’ key, that is used to explicitly select between the default ‘template’ request or a ‘proposal’.

[index] [11704] [634] [7168] [4207] [6705] [4152] [23068] [33973] [2468] [21484]


$10,000 Bitcoin By Halving, IF Key Resistance Breaks! HUGE ETHEREUM NEWS Will Rocket Price! - Duration: 14:43. The Crypto Lark 28,810 views What it really takes to mine a Bitcoin in 10 Minutes. Firstly I'll show you a special free method to mine Bitcoin and send funds directly to your wallet in 1... Highlights from The Value of Bitcoin Conference on June 3rd, 2019. After more than 10 years, Bitcoin is still around and the signals that indicate Bitcoin is here to stay are only getting stronger. Free Bitcoin Mining with Bitcoin Values 1BTC Per Week Speed (TH/s) - Duration: 3:02. How To Make Money Online For Free 3,395 views bitcoin is finally breakout from the long lasting down trend channel. Could this be a new begging in bitcoins price? I will address this question in this vid...