Bitcoin Forum

Bitcoin Core version 0.11.0 is now available from:

https://bitcoin.org/bin/bitcoin-core-0.11.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

---

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).
Downgrade warning

Because release 0.10.0 and later makes use of headers-first synchronization and parallel block download (see further), the block files and databases are not backwards-compatible with pre-0.10 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. There are no known problems when downgrading from 0.11.x to 0.10.x.

---

Important information

Transaction flooding

At the time of this release, the P2P network is being flooded with low-fee transactions. This causes a ballooning of the mempool size.

If this growth of the mempool causes problematic memory use on your node, it is possible to change a few configuration options to work around this. The growth of the mempool can be monitored with the RPC command getmempoolinfo.

One is to increase the minimum transaction relay fee minrelaytxfee, which defaults to 0.00001. This will cause transactions with fewer BTC/kB fee to be rejected, and thus fewer transactions entering the mempool.

The other is to restrict the relaying of free transactions with limitfreerelay. This option sets the number of kB/minute at which free transactions (with enough priority) will be accepted. It defaults to 15. Reducing this number reduces the speed at which the mempool can grow due to free transactions.

For example, add the following to bitcoin.conf:

minrelaytxfee=0.00005
limitfreerelay=5

More robust solutions are being worked on for a follow-up release.

---

Notable changes

Block file pruning

This release supports running a fully validating node without maintaining a copy of the raw block and undo data on disk. To recap, there are four types of data related to the blockchain in the bitcoin system: the raw blocks as received over the network (blk???.dat), the undo data (rev???.dat), the block index and the UTXO set (both LevelDB databases). The databases are built from the raw data.

Block pruning allows Bitcoin Core to delete the raw block and undo data once it's been validated and used to build the databases. At that point, the raw data is used only to relay blocks to other nodes, to handle reorganizations, to look up old transactions (if -txindex is enabled or via the RPC/REST interfaces), or for rescanning the wallet. The block index continues to hold the metadata about all blocks in the blockchain.

The user specifies how much space to allot for block & undo files. The minimum allowed is 550MB. Note that this is in addition to whatever is required for the block index and UTXO databases. The minimum was chosen so that Bitcoin Core will be able to maintain at least 288 blocks on disk (two days worth of blocks at 10 minutes per block). In rare instances it is possible that the amount of space used will exceed the pruning target in order to keep the required last 288 blocks on disk.

Block pruning works during initial sync in the same way as during steady state, by deleting block files "as you go" whenever disk space is allocated. Thus, if the user specifies 550MB, once that level is reached the program will begin deleting the oldest block and undo files, while continuing to download the blockchain.

For now, block pruning disables block relay. In the future, nodes with block pruning will at a minimum relay "new" blocks, meaning blocks that extend their active chain.

Block pruning is currently incompatible with running a wallet due to the fact that block data is used for rescanning the wallet and importing keys or addresses (which require a rescan.) However, running the wallet with block pruning will be supported in the near future, subject to those limitations.

Block pruning is also incompatible with -txindex and will automatically disable it.

Once you have pruned blocks, going back to unpruned state requires re-downloading the entire blockchain. To do this, re-start the node with -reindex. Note also that any problem that would cause a user to reindex (e.g., disk corruption) will cause a pruned node to redownload the entire blockchain. Finally, note that when a pruned node reindexes, it will delete any blk???.dat and rev???.dat files in the data directory prior to restarting the download.

To enable block pruning on the command line:

    -prune=N: where N is the number of MB to allot for raw block & undo data.

Modified RPC calls:

    getblockchaininfo now includes whether we are in pruned mode or not.
    getblock will check if the block's data has been pruned and if so, return an error.
    getrawtransaction will no longer be able to locate a transaction that has a UTXO but where its block file has been pruned.

Pruning is disabled by default.

Big endian support

Experimental support for big-endian CPU architectures was added in this release. All little-endian specific code was replaced with endian-neutral constructs. This has been tested on at least MIPS and PPC hosts. The build system will automatically detect the endianness of the target.

Memory usage optimization

There have been many changes in this release to reduce the default memory usage of a node, among which:

    Accurate UTXO cache size accounting (#6102); this makes the option -dbcache precise where this grossly underestimated memory usage before
    Reduce size of per-peer data structure (#6064 and others); this increases the number of connections that can be supported with the same amount of memory
    Reduce the number of threads (#5964, #5679); lowers the amount of (esp. virtual) memory needed

Fee estimation changes

This release improves the algorithm used for fee estimation. Previously, -1 was returned when there was insufficient data to give an estimate. Now, -1 will also be returned when there is no fee or priority high enough for the desired confirmation target. In those cases, it can help to ask for an estimate for a higher target number of blocks. It is not uncommon for there to be no fee or priority high enough to be reliably (85%) included in the next block and for this reason, the default for -txconfirmtarget=n has changed from 1 to 2.

Privacy: Disable wallet transaction broadcast

This release adds an option -walletbroadcast=0 to prevent automatic transaction broadcast and rebroadcast (#5951). This option allows separating transaction submission from the node functionality.

Making use of this, third-party scripts can be written to take care of transaction (re)broadcast:

    Send the transaction as normal, either through RPC or the GUI
    Retrieve the transaction data through RPC using gettransaction (NOT getrawtransaction). The hex field of the result will contain the raw hexadecimal representation of the transaction
    The transaction can then be broadcasted through arbitrary mechanisms supported by the script

One such application is selective Tor usage, where the node runs on the normal internet but transactions are broadcasted over Tor.

For an example script see bitcoin-submittx.

Privacy: Stream isolation for Tor

This release adds functionality to create a new circuit for every peer connection, when the software is used with Tor. The new option, -proxyrandomize, is on by default.

When enabled, every outgoing connection will (potentially) go through a different exit node. That significantly reduces the chance to get unlucky and pick a single exit node that is either malicious, or widely banned from the P2P network. This improves connection reliability as well as privacy, especially for the initial connections.

Important note: If a non-Tor SOCKS5 proxy is configured that supports authentication, but doesn't require it, this change may cause that proxy to reject connections. A user and password is sent where they weren't before. This setup is exceedingly rare, but in this case -proxyrandomize=0 can be passed to disable the behavior.

---

0.11.0 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 REST

    #5461 5f7279a signrawtransaction: validate private key
    #5444 103f66b Add /rest/headers//.
    #4964 95ecc0a Add scriptPubKey field to validateaddress RPC call
    #5476 c986972 Add time offset into getpeerinfo output
    #5540 84eba47 Add unconfirmed and immature balances to getwalletinfo
    #5599 40e96a3 Get rid of the internal miner's hashmeter
    #5711 87ecfb0 Push down RPC locks
    #5754 1c4e3f9 fix getblocktemplate lock issue
    #5756 5d901d8 Fix getblocktemplate_proposals test by mining one block
    #5548 d48ce48 Add /rest/chaininfos
    #5992 4c4f1b4 Push down RPC reqWallet flag
    #6036 585b5db Show zero value txouts in listunspent
    #5199 6364408 Add RPC call gettxoutproof to generate and verify merkle blocks
    #5418 16341cc Report missing inputs in sendrawtransaction
    #5937 40f5e8d show script verification errors in signrawtransaction result
    #5420 1fd2d39 getutxos REST command (based on Bip64)
    #6193 42746b0 [REST] remove json input for getutxos, limit to query max. 15 outpoints
    #6226 5901596 json: fail read_string if string contains trailing garbage

Configuration and command-line options

    #5636 a353ad4 Add option -allowselfsignedrootcertificate to allow self signed root certs (for testing payment requests)
    #5900 3e8a1f2 Add a consistency check -checkblockindex for the block chain data structures
    #5951 7efc9cf Make it possible to disable wallet transaction broadcast (using -walletbroadcast=0)
    #5911 b6ea3bc privacy: Stream isolation for Tor (on by default, use -proxyrandomize=0 to disable)
    #5863 c271304 Add autoprune functionality (-prune=<size>)
    #6153 0bcf04f Parameter interaction: disable upnp if -proxy set
    #6274 4d9c7fe Add option -alerts to opt out of alert system

Block and transaction handling

    #5367 dcc1304 Do all block index writes in a batch
    #5253 203632d Check against MANDATORY flags prior to accepting to mempool
    #5459 4406c3e Reject headers that build on an invalid parent
    #5481 055f3ae Apply AreSane() checks to the fees from the network
    #5580 40d65eb Preemptively catch a few potential bugs
    #5349 f55c5e9 Implement test for merkle tree malleability in CPartialMerkleTree
    #5564 a89b837 clarify obscure uses of EvalScript()
    #5521 8e4578a Reject non-final txs even in testnet/regtest
    #5707 6af674e Change hardcoded character constants to descriptive named constants for db keys
    #5286 fcf646c Change the default maximum OP_RETURN size to 80 bytes
    #5710 175d86e Add more information to errors in ReadBlockFromDisk
    #5948 b36f1ce Use GetAncestor to compute new target
    #5959 a0bfc69 Add additional block index consistency checks
    #6058 7e0e7f8 autoprune minor post-merge improvements
    #5159 2cc1372 New fee estimation code
    #6102 6fb90d8 Implement accurate UTXO cache size accounting
    #6129 2a82298 Bug fix for clearing fCheckForPruning
    #5947 e9af4e6 Alert if it is very likely we are getting a bad chain
    #6203 c00ae64 Remove P2SH coinbase flag, no longer interesting
    #5985 37b4e42 Fix removing of orphan transactions
    #6221 6cb70ca Prune: Support noncontiguous block files
    #6256 fce474c Use best header chain timestamps to detect partitioning
    #6233 a587606 Advance pindexLastCommonBlock for blocks in chainActive

P2P protocol and network code

    #5507 844ace9 Prevent DOS attacks on in-flight data structures
    #5770 32a8b6a Sanitize command strings before logging them
    #5859 dd4ffce Add correct bool combiner for net signals
    #5876 8e4fd0c Add a NODE_GETUTXO service bit and document NODE_NETWORK
    #6028 b9311fb Move nLastTry from CAddress to CAddrInfo
    #5662 5048465 Change download logic to allow calling getdata on inbound peers
    #5971 18d2832 replace absolute sleep with conditional wait
    #5918 7bf5d5e Use equivalent PoW for non-main-chain requests
    #6059 f026ab6 chainparams: use SeedSpec6's rather than CAddress's for fixed seeds
    #6080 31c0bf1 Add jonasschnellis dns seeder
    #5976 9f7809f Reduce download timeouts as blocks arrive
    #6172 b4bbad1 Ignore getheaders requests when not synced
    #5875 304892f Be stricter in processing unrequested blocks
    #6333 41bbc85 Hardcoded seeds update June 2015

Validation

    #5143 48e1765 Implement BIP62 rule 6
    #5713 41e6e4c Implement BIP66

Build system

    #5501 c76c9d2 Add mips, mipsel and aarch64 to depends platforms
    #5334 cf87536 libbitcoinconsensus: Add pkg-config support
    #5514 ed11d53 Fix 'make distcheck'
    #5505 a99ef7d Build winshutdownmonitor.cpp on Windows only
    #5582 e8a6639 Osx toolchain update
    #5684 ab64022 osx: bump build sdk to 10.9
    #5695 23ef5b7 depends: latest config.guess and config.sub
    #5509 31dedb4 Fixes when compiling in c++11 mode
    #5819 f8e68f7 release: use static libstdc++ and disable reduced exports by default
    #5510 7c3fbc3 Big endian support
    #5149 c7abfa5 Add script to verify all merge commits are signed
    #6082 7abbb7e qt: disable qt tests when one of the checks for the gui fails
    #6244 0401aa2 configure: Detect (and reject) LibreSSL
    #6269 95aca44 gitian: Use the new bitcoin-detached-sigs git repo for OSX signatures
    #6285 ef1d506 Fix scheduler build with some boost versions.
    #6280 25c2216 depends: fix Boost 1.55 build on GCC 5
    #6303 b711599 gitian: add a gitian-win-signer descriptor
    #6246 8ea6d37 Fix build on FreeBSD
    #6282 daf956b fix crash on shutdown when e.g. changing -txindex and abort action
    #6354 bdf0d94 Gitian windows signing normalization

Wallet

    #2340 811c71d Discourage fee sniping with nLockTime
    #5485 d01bcc4 Enforce minRelayTxFee on wallet created tx and add a maxtxfee option
    #5508 9a5cabf Add RandAddSeedPerfmon to MakeNewKey
    #4805 8204e19 Do not flush the wallet in AddToWalletIfInvolvingMe(..)
    #5319 93b7544 Clean up wallet encryption code
    #5831 df5c246 Subtract fee from amount
    #6076 6c97fd1 wallet: fix boost::get usage with boost 1.58
    #5511 23c998d Sort pending wallet transactions before reaccepting
    #6126 26e08a1 Change default nTxConfirmTarget to 2
    #6183 75a4d51 Fix off-by-one error w/ nLockTime in the wallet
    #6276 c9fd907 Fix getbalance * 0

GUI

    #5219 f3af0c8 New icons
    #5228 bb3c75b HiDPI (retina) support for splash screen
    #5258 73cbf0a The RPC Console should be a QWidget to make window more independent
    #5488 851dfc7 Light blue icon color for regtest
    #5547 a39aa74 New icon for the debug window
    #5493 e515309 Adopt style colour for button icons
    #5557 70477a0 On close of splashscreen interrupt verifyDB
    #5559 83be8fd Make the command-line-args dialog better
    #5144 c5380a9 Elaborate on signverify message dialog warning
    #5489 d1aa3c6 Optimize PNG files
    #5649 e0cd2f5 Use text-color icons for system tray Send/Receive menu entries
    #5651 848f55d Coin Control: Use U+2248 "ALMOST EQUAL TO" rather than a simple tilde
    #5626 ab0d798 Fix icon sizes and column width
    #5683 c7b22aa add new osx dmg background picture
    #5620 7823598 Payment request expiration bug fix
    #5729 9c4a5a5 Allow unit changes for read-only BitcoinAmountField
    #5753 0f44672 Add bitcoin logo to about screen
    #5629 a956586 Prevent amount overflow problem with payment requests
    #5830 215475a Don't save geometry for options and about/help window
    #5793 d26f0b2 Honor current network when creating autostart link
    #5847 f238add Startup script for centos, with documentation
    #5915 5bd3a92 Fix a static qt5 crash when using certain versions of libxcb
    #5898 bb56781 Fix rpc console font size to flexible metrics
    #5467 bc8535b Payment request / server work - part 2
    #6161 180c164 Remove movable option for toolbar
    #6160 0d862c2 Overviewpage: make sure warning icons gets colored

Tests

    #5453 2f2d337 Add ability to run single test manually to RPC tests
    #5421 886eb57 Test unexecuted OP_CODESEPARATOR
    #5530 565b300 Additional rpc tests
    #5611 37b185c Fix spurious windows test failures after 012598880c
    #5613 2eda47b Fix smartfees test for change to relay policy
    #5612 e3f5727 Fix zapwallettxes test
    #5642 30a5b5f Prepare paymentservertests for new unit tests
    #5784 e3a3cd7 Fix usage of NegateSignatureS in script_tests
    #5813 ee9f2bf Add unit tests for next difficulty calculations
    #5855 d7989c0 Travis: run unit tests in different orders
    #5852 cdae53e Reinitialize state in between individual unit tests.
    #5883 164d7b6 tests: add a BasicTestingSetup and apply to all tests
    #5940 446bb70 Regression test for ResendWalletTransactions
    #6052 cf7adad fix and enable bip32 unit test
    #6039 734f80a tests: Error when setgenerate is used on regtest
    #6074 948beaf Correct the PUSHDATA4 minimal encoding test in script_invalid.json
    #6032 e08886d Stop nodes after RPC tests, even with --nocleanup
    #6075 df1609f Add additional script edge condition tests
    #5981 da38dc6 Python P2P testing
    #5958 9ef00c3 Add multisig rpc tests
    #6112 fec5c0e Add more script edge condition tests

Miscellaneous

    #5457, #5506, #5952, #6047 Update libsecp256k1
    #5437 84857e8 Add missing CAutoFile::IsNull() check in main
    #5490 ec20fd7 Replace uint256/uint160 with opaque blobs where possible
    #5654, #5764 Adding jonasschnelli's GPG key
    #5477 5f04d1d OS X 10.10: LSSharedFileListItemResolve() is deprecated
    #5679 beff11a Get rid of DetectShutdownThread
    #5787 9bd8c9b Add fanquake PGP key
    #5366 47a79bb No longer check osx compatibility in RenameThread
    #5689 07f4386 openssl: abstract out OPENSSL_cleanse
    #5708 8b298ca Add list of implemented BIPs
    #5809 46bfbe7 Add bitcoin-cli man page
    #5839 86eb461 keys: remove libsecp256k1 verification until it's actually supported
    #5749 d734d87 Help messages correctly formatted (79 chars)
    #5884 7077fe6 BUGFIX: Stack around the variable 'rv' was corrupted
    #5849 41259ca contrib/init/bitcoind.openrc: Compatibility with previous OpenRC init script variables
    #5950 41113e3 Fix locale fallback and guard tests against invalid locale settings
    #5965 7c6bfb1 Add git-subtree-check.sh script
    #6033 1623f6e FreeBSD, OpenBSD thread renaming
    #6064 b46e7c2 Several changes to mruset
    #6104 3e2559c Show an init message while activating best chain
    #6125 351f73e Clean up parsing of bool command line args
    #5964 b4c219b Lightweight task scheduler
    #6116 30dc3c1 [OSX] rename Bitcoin-Qt.app to Bitcoin-Core.app
    #6168 b3024f0 contrib/linearize: Support linearization of testnet blocks
    #6098 7708fcd Update Windows resource files (and add one for bitcoin-tx)
    #6159 e1412d3 Catch errors on datadir lock and pidfile delete
    #6186 182686c Fix two problems in CSubnet parsing
    #6174 df992b9 doc: add translation strings policy
    #6210 dfdb6dd build: disable optional use of gmp in internal secp256k1 build
    #6264 94cd705 Remove translation for -help-debug options
    #6286 3902c15 Remove berkeley-db4 workaround in MacOSX build docs
    #6319 3f8fcc9 doc: update mailing list address

---

Credits

Thanks to everyone who directly contributed to this release:

    21E14
    Adam Weiss
    Alex Morcos
    ayeowch
    azeteki
    Ben Holden-Crowther
    bikinibabe
    BitcoinPRReadingGroup
    Blake Jakopovic
    BtcDrak
    charlescharles
    Chris Arnesen
    Ciemon
    CohibAA
    Corinne Dashjr
    Cory Fields
    Cozz Lovan
    Daira Hopwood
    Daniel Kraft
    Dave Collins
    David A. Harding
    dexX7
    Earlz
    Eric Lombrozo
    Eric R. Schulz
    Everett Forth
    Flavien Charlon
    fsb4000
    Gavin Andresen
    Gregory Maxwell
    Heath
    Ivan Pustogarov
    Jacob Welsh
    Jameson Lopp
    Jason Lewicki
    Jeff Garzik
    Jonas Schnelli
    Jonathan Brown
    Jorge Timón
    joshr
    jtimon
    Julian Yap
    Luca Venturini
    Luke Dashjr
    Manuel Araoz
    MarcoFalke
    Matt Bogosian
    Matt Corallo
    Micha
    Michael Ford
    Mike Hearn
    mrbandrews
    Nicolas Benoit
    paveljanik
    Pavel Janík
    Pavel Vasin
    Peter Todd
    Philip Kaufmann
    Pieter Wuille
    pstratem
    randy-waterhouse
    rion
    Rob Van Mieghem
    Ross Nicoll
    Ruben de Vries
    sandakersmann
    Shaul Kfir
    Shawn Wilkinson
    sinetek
    Suhas Daftuar
    svost
    Thomas Zander
    Tom Harding
    UdjinM6
    Vitalii Demianets
    Wladimir J. van der Laan

And all those who contributed additional code review and/or security research:

    Sergio Demian Lerner

As well as everyone that helped translating on Transifex.

---

this was originally posted  (https://bitcointalk.org/index.php?topic=1119609.msg11861059)by SteamGamesBTC.com (https://bitcointalk.org/index.php?action=profile;u=62795). However, I didn't feel safe stickying his topic because it would be editable by him. (Sorry for not trusting you :()

Continuing from the other thread :)


I have read the changelog on bitcoin.org before seeing this thread.

This release supports a fully validating node. But not a node that currently relays transactions. That was the objective of my post.

If it does not relay blocks, why would it be essential for a currently running node to upgrade and prune the blockchain data? They would stop relaying blocks...

Please correct me if I'm wrong :)

Why so ?

Agreed. But the number of full copies of the blockchain could still increase, eg. two partial nodes that store 80% of the blockchain provide more copies than one full node with 100%.

I upgraded from 10 and it went smoothly to 11 very quick , good work guys!!!

You can't relay blocks yet, although that will be fixed at a later date according to some information that I've found. However, you also mentioned that one wouldn't be able to run a wallet.
This is a common misconception, and you would know if you followed the GitHub page closely. This is clearly shown here (https://github.com/bitcoin/bitcoin/pull/6057).

There is also information related to relaying:
You're right. Let's see how the situation unfolds.

@grue
It's OK grue, thanks for mention me up! :-)

I have tested the RC2-RC3 ... very good product.  8)
i have already tested the pruning mode, good feature ... but for helping the network, it must be an other feature than that (pruning is a little "dumb" to delete the first block, i see more a randomly deleting to not have the same result on all member that they use it.).

All right, thanks for the clarification, I thought something was escaping me, apparently not :)

Yes, I do not follow the GitHub page, but I follow release changelogs and this one states the following


I find it odd if it is a misconception, changelogs are probably prepared and proofread many times, by many people... If it is in fact a misconception it will probably be corrected soon, I think.


Yes, that's also on the changelog, unfortunately, as it says, it's not for this version...

Any help with the following error I get on Debian 6 LTS when trying to build would be appreciated:

I just synced my 0.10.2 and now i see that 0.11.0 is not backwards compatible.. so I need to download the whole damn thing again?
I see that pruning doesnt work when "running a wallet", not sure what that means, but it sounds like it would be useless to anyone using core as its wallet.

Do i need to delete the whole blockchain, or can I just install 0.11 on top and it will download the whole blockchain on top?

No. You only need to download again if you go back to an older version.


For now, yes.


Just close 0.10.2, wait till it shuts down, install 0.11, open, enjoy a fully synced wallet.

If I understand correctly pruning does not fully work yet?

Thanks for the update

Smooth process. Just upgraded my full node with the minrelaytxfee and limitfreerelay settings. Thanks team !!

it seems very limited, you can't have an amount when doing it and you need to redo the synching if you want to return to your previos status

not something i would be excited about, in the future they said it will be fully supported

should set limitfreerelay to 0, lol

I upgraded to Bitcoin Core 0.11 on Ubuntu MATE 14.04, but quickly went back to 0.10.2.
New version of bitcoin-qt looks odd - small fonts, ugly icons. Is this something with new version of QT used?
Also, program icon is not displayed in notification area when I closed the window. Had to end bitcoin-qt with system monitor.

The sentence

"Block pruning is currently incompatible with running a wallet"

should be exposed in the changelog.

The sticky at the top of the forum do not mention 0.11 as a "safe" client - I guess it should be amended ASAP?

definetly.

it will be less problematic if the user will be alerted in the beginning of the pruning process, though.

Thanks team!  Really, really looking forward to the coming update that will enable the wallet functionality.  In the meantime, I am going to install QT back on my MacBook air for the first time in 9 months, as soon as I get back to a fast connection.

Could we say that 0.11 is not affected by the fork problem, as stated by the sticky at the top of this forum?


Also, could we use 0.11 as a wallet, if we do not enable pruning (which if i understood correctly is not enabled by default)?

Confirmation from the devs is always nice, but in this case I think it's pretty safe to assume if you don't enable pruning, you're running the same good old full node you've always been running, with wallet and all.

I agree, the new look is horribly ugly, it's all black and white the the icons for incoming/outgoing tx are terrible.

Give me back my colorized lock, connectivity monitor, and check mark!

the new client is unfunctional as a wallet ??
WTF #

if i wanted a node i could set one up but most people want the wallet first and foremost  i would imagine

they need to get on this ASAP

if i upgrade what happens to my old wallet + addresses + priv keys + btc balance ??

Nothing, you run as usual.

If you upgrade and set pruning up, then the wallet functionality is disabled. You don't lose any funds, the privkeys are still stored in the wallet.dat file, it's just that Bitcoin Core would ignore it.

I'm very pleased to see some fledgling support for big-endian architecture. This is great news!

So if the wallet is disabled in pruning mode, what purpose if any is pruning good for? Seeing you cant send /receive btc running it that way?

Icon

If you're currently running a full node: none.

If not, you already have some other wallet, so this doesn't affect you. Pruning allows you to set up a node without the need to dedicate 50 Gb of storage to it.

I get way, way more random crashes/errors in v0.11.0 than I ever did with 0.10.2.  Some times the programs shuts down with no error or notice, thankfully bitnodes emails me when the node goes down so I can restart it, but it sure is frustrating having the thing crash for no apparent reason.

Thank you very much for the "block file pruning" mode! The barrier to run a full node for the support of the Bitcoin network now should be much lower.

The v0.11.0 bitcoin-qt binary for 64bit Linux is 30.2 MB.
Bitcoin Core version v0.10.2 (64-bit) bitcoin-qt binary for Linux is only 13.3 MB.

Why is there such a huge file size difference?

Thanks for the heads up. I recently upgraded my Bitcoin Core from version 0.9.x to 0.10.2 (mainly due to recent small blockchain split) and I thought that new version look less intuitive than old.
And now I see that developer continue to bring changes which will make Bitcoin core the ugliest bitcoin wallet on Earth. I will rather wait for version 0.12.0 and then update my client.

I will not upgrade until someone explains the file size difference. Did the developer leave debug symbols in or what? This is just fishy.

Does prunning only help with hard disk space usage?
Are there any more benefits?

That's the only real benefit. It was introduced mainly because people started complaining that the blockchain is becoming too big.
However, it currently has some limitations so you should read the changelog before deciding.

I second this.

Probably better off asking on github or the Development section on here.

will this fix the spammy transactions we've been having in the network?

I want a shell script which check whether bitcoind is running or not and to relaunch it. Is there a way to do this? I have a home 24/7 node and sometimes it crash( power off etc) and i like to relaunch it.

its possible you can set a bash script to run every time when pc is booting up and start the bitcoind also you can set a cronjob to check e.g every hour if bitcoind run if run ok if not run start it check the example below

if ps ax | grep -v grep | grep bitcoind > /dev/null

then
exit #bitcoind already running

else
#start the bitcoind
/home/username/pathtobitcoind/bitcoind
fi

thx i have done it with this bash script

#!/bin/bash

tested the RC2-RC3 ... a good product  ;)

Mine is fucked, it keeps crashing with a reindex the block chain error

I'm going to have to delete the lot and start again from scratch

Is there something currently wrong with the new bitcoin 0.11.0 x64 windows wallet??

why do you see something wrong ??

Not indexing the last 40 hours of the blockchain

Error crashing not finding the blckchain

i have try to add to start bitcoind in every boot in crontab -e with this adds

@reboot bitcoind -daemon

or

@reboot /usr/bin/bitcoind -daemon

both of them are not working and in every reboot i have to start manual bitcoind
Any idea how can i auto the bitcoind start in every bott or reboot?

Should probably hit up bitcoin-dev, but:

Somebody on reddit mentioned (https://www.reddit.com/r/Bitcoin/comments/3efzuz/satoshi0110_now_running_on_the_majority_of/cton9tz) that 0.11.0 requires OS X 10.7 or above.  The last release notes bullet item about dropping support for an OS X version was back in 0.9.0 mentioning that support was dropped for anything below OS X 10.6.

---

Speaking of release notes, the github repo does not have release notes for 0.11.0; https://github.com/bitcoin/bitcoin/tree/master/doc/release-notes

well, only if they are good. I see lots of "it sucks" "have to reindex, re download"  etc on this version.

I dont really feel like doing things that suck.

as my current version 0.10.2 works I havent updated yet.

I'm using Linux Mint 17.2 64-Bit
When using the official 0.11.0 binaries the file size is 30.2 MB (Double the size than earlier versions)
It's using QT-5 when past versions where using QT-4.

First picture is the official client running on my system and the second picture is a build I compiled myself configured to run QT-4.

Official build: https://i.imgur.com/IKKtpmr.png
My build: https://i.imgur.com/RCYG8mq.png

Is this caused by my system missing required dependencies to run QT-5 or bugs in the official build?

Probably because everyone else does not post that they have no problems. Those that I see that constantly have to reindex seem to have hardware problems or otherwise issues with their OS. You can hardly blame QT for that. I run 0.11. without issues.

true that. I usually figure most problems are malware, outdated drivers, special config myself

but my version works well and a scratch blockchain would take a couple weeks with my crappy internet in thr sticks.. no cable or DSL

the risks outweigh the benefits in this case for me. what I have works so Ill pass.

if only we can fix this flooding of transactions with upgrades would be really great

The flooding of dust has not affected any of my transactions as of yet   I don't think it's as big a panic issue as some people think....

In a sense its fixed. For you running bitcoin core there are two problems from the spam.

#1 most common is that you will have to pay a higher fee and its complicated to know how high a good fee is. Bitcoin core is the only client I know that has a feature for this for a while. Some other clients new implement similar features so it will be common soon(ish). If the spam pays 20k satoshi per kb bitcoin core will adjust your fee accordingly. The send tab also allows you to set this either to fast (and pay a high fee) or to "normal" and pay a lower fee.

#2 less common is that your client runs out of resources as it is no longer able to handle the high amount of transactions. With 0.11. you can now decide how high a fee should be for your client to recognize the transaction as valid. You also can directly influence how many (in size) free transaction your node will relay.

#3 a somewhat often complaint I see is that one runs out of disk space and my server is currently shut down because its indeed full. 0.11. also offers a solution for this with pruning I just did not find the time to fix the issue yet.

I've been having problems with v0.10.2 , it was taking forever to actually open the wallet & sometimes if I hadn't synced for a few days it'd get stuck on a certain 'hours to go' & literally not move. The wallet wouldn't even close sometimes.

I've just upgraded to v0.11.0 & it's absolutely fine, quicker & worked 1st time. Marvellous.

any major improvement over the transaction spamming so far ?

So your local drive is only 60GB? Just asking, not judging.


There is a middle ground between the extremes of storing a complete copy of the blockchain and trusting a 3rd party. Slim or light clients like multibit (HD) or electrum (2) do not require you to download the entire blockchain, but still run on your local machine without you needing to trust someone offering a wallet service.


Mining with a computer is dead, if you dont have specialized hardware dont even bother.


What is good for me might not be what is good for you. Thats why there are different solutions, not everyone needs bitcoin core, but the network certainly needs to run full nodes. Without full nodes some client can not gather the data, without full nodes miners cant mine and without full nodes your transactions cant get relayed to miners to get a confirmation. The purpose of depending on a local wallet is that you do not need to trust someone else with your money. You only have to depend on yourself and your security practices. This is certainly not for everyone, but with bitcoin its possibility.

Can we have someone who can audit?

Do you mean code audit ? If yes, the code is open in the Github and anyone can do it for themselve. If you want someone else to do it for you, then you need to tell how much you are willing to pay for that.

Kudos to developers and bitcoin community for getting this out . Thumbs up for pruning feature

- Cheers

Kind of glad that I just started and I already get the upgrade/update to my wallet.  Though that did take a while to sync up upon launching.

bitcoin wallet is popular wallet all over the world.
i can purchase any thing from onlline market using  bitcoin  wallet really it asewom. we will tell my all friends to suggest u should use bit coin wallet for onnline purchase u do not to need  dc or cc or any type of cards.

I upgraded my node a while ago and just wanted to thank the devs for all of their hard work! :)

So far I have had to rebuild the blockchain twice since "updating" to 0.11.0.  Both times I received a "cannot read database" error, and upon restart I was prompted to re-syn the chain.  Dunno if this is a hardware error on my side or not, but I did not have these issues on the 0.10.x releases.

Edit - Now core won't even startup after this last db error.  It gets to activating best chain then crashes with no error... I really want to run a full node, but it's becoming too much of a hassle.

I completely uninstalled 0.11.0 and reinstalled it on a different partition.  Currently re-downloading the blockchain... again... hopefully the new location will clear up these errors.

i downloaded that bitcoin core after installation my computer always say low hard drive space.. i think it download all blockchain blocks... do you have a portable bitcoin core?please in form me

What's a portable Bitcoin core?

https://electrum.org

Portable means ----} able to be easily carried or moved, especially because of being a lighter and smaller version than usual. light version of bitcoin core that no need to download all blocks from server....

No, there is only one version of core and it requires you to download the entire blockchain.

You want an SPV wallet: https://www.google.com/search?q=spv+wallet

It's more of an amateur. I propose to Vote :)

I'm completely lost  ???

What the heck does it mean to upgrade?

Are you talking about that wallet you download on your computer and it takes hours to synchronize with the network?
Is that the thing you're talking about upgrading?

I'm confused... I haven't messed with offline wallet for years.
I use like Coinbase and Blockchain as a wallet.......
So how the heck do you upgrade?

Can anyone break this down in laymans terms?

Have you read the thread or at least the title? :-\

It means to upgrade Bitcoin Core <0.11 to Bitcoin Core 0.11.


They are many wallets and Bitcoin Core is one of them. Bitcoin Core takes a few hours to a few days to synchronize completely and SPV wallets syncs faster but it still takes a few hours and you won't get some features you get in Bitcoin Core.


They are online wallets. I recommend you to use Coinbase multisig wallet instead of their default wallet and I highly recommend to stay away from Blockchain.info wallet because of their buggy codes and lack of good development.


If you want to use a local wallet(aka offline wallet), download one and send Bitcoins from your online wallet(here, Coinbase or Blockchain.info online wallet) to local wallet you have installed.


Okay?

Cool thanks. Excuse my paranoia. Bitcoin XT and Bear market gots me on edge lately.

And finally finished re-syncing.  I have cable internet and it took 4 days to acquire the blockchain again.  I thought it was supposed to be much faster after 0.10.x...  ???

updated to 0.11.0 x64
Thanks!

I cant do it - please help me
Bitcoin 0.7.2 BETA is what I am using now
How do I update
any links
Please help

Well, you could try reading the first post of this thread, for starters...

my new version of bitcoin is not showing and also the slow down speed and network error r there !!

I can't upgrade it so plzz help me !!!

What is your exact problem? I can't understand from your above post. Please post in Technical Support^[1] to get help.

[1] https://bitcointalk.org/index.php?board=4.0

I've had two blue screen of death crashes since I finished the reinstall.  Can't say it's related, but it sure is a coincidence.

Hey Guyz >:(

Just downloaded latest version, you have a  key logger and a add user Infection. Your distributing Viruses.
Just letting you know, would like to check out your software
MikeC.

CompTIA Linux
LPIC   
Oracle Linux OCA   
Oracle Linux OCP   
RHCA   
RHCE   123   
RHCSA   
SUSE CLA
SUSE CLE   
SUSE CLP   
LFCS   
LFCE
MCSE, CCIE
WTF

Hello, I'm new to the Darknet and bitcoin world and I'm looking for information on bitcoin wallets. I need to find one that is trustworthy while also being secure and untraceable. If someone could refer a good service it would be much appreciated.

Is there a blockchain that can be downloaded without waiting weeks for Bitcoin Core to download it all?
And is there a security problem if does not wait for it and puts someone else's blockchain into it?

Thanks

No.  And it doesn't take weeks, it takes a couple days.

There is only 1 (bitcoin) blockchain, that's kinda the whole point.

How much did you pay for your account?

Maybe you have a better Internet connection. I don't.

I was only asking since you can do that with some altcoins: I was just curious.

Thanks anyway.

Hello thank you for your information, but I can't upgrade the new version bitcoin.
Anyone can help me pelase?

OH Wow! much faster to sync on my computer than before nice work devs :)

For me it's the same speed as it was before. ;D

Well, i'll try this release. Hope it's good!

Thanks for the update.

thanks informasi  :D

Hopefully its gonna work for me. Sorry for disturbing.. Im brand new here.  8)

hello,

sorry, i'm new in using bitcoins.

i went to coinBase, transfered some €uros, got bitcoin.
next i loaded down the
Bitcoin Core Version v0.11.0 (64-Bit) windows wallet.

i could'nt find somewere informations how to use
(...in german, my english is'nt so fine)

end of song:
i createt a new "get money number" in the wallet,
gave it to coinbase and sendet the btc to  my btc core wallet.

now the wallet shows me that it has to work a line of numbers witch is stored for 2 years and some weeks first before beeing aktuell...

i think this will need a few days!!
is there a way to speed it up that the btc can reach my wallet??or what else can i do?

it would be great if someone would help a newby!

thx
kind regards

miko

Bitcoin core needs to store the whole blockchain on your hard disk. Downloading (and verifying) that amount of data takes quite some time, that's right.

Currently there's no easy way around this with bitcoin core, other wallets such as Electrum don't store the full blockchain but rely on external services for blockchain access. This is much faster for initial setup, but at the moment, this is not an option for you because you already sent funds from coinBase to an address within your bitcoin core wallet. So you'll definitely want to keep that running until you have full control over your funds.
It might be possible to export the private key for the address to which you sent your coinBase funds, and import this into another wallet which you can use sooner, but I don'd really have experience in this, so I won't advise you to do this. If you find someone who can explain this process and lead you through it, that might be an option, though.

Onkel Paul

Danke für deine Ausführungen Onkel Paul!

Wenn ich es richtig verstanden habe brauche (muß) ich nur abzuwarten bis die Kette durch ist dann kommt auch das Geld.
Ist das lange warten nur einmalig oder muss ich bei jeder Transaktion die ganze Kette abwarten?

Miko

Du musst jedes mal synchronisieren. Das kann am Anfang ein paar Tage dauern, aber danach muss nur noch synchronisiert werden was Du "verpasst" hast während bitcoin core geschlossen war. Wenn Du also jeden Tag einmal synchronisieren lässt ist das relativ übersichtlich und sollte nicht länger als 15 minuten dauern. Wie lange genau hängt von der Festplatte der CPU und deiner Internetverbindung ab.

Für alles weitere auf Deutsch, bitte hier -> https://bitcointalk.org/index.php?board=16.0 im deutschen Bereich posten.

---

English translation:

The sync has to be done every time, but only the first sync tages up to a gew days. Every further sync only has to catch up to the latest blocks which is significantly faster. If you sync once a day it should not take longer than ~15 minutes, depending on disk, CPU and internet connection.

Vielen Dank

This is kinda handy thank you for the update and sharing this.

So while I was re-syncing the blockchain over the weekend (every time my computer loses power my local copy of the blockchain becomes corrupt, kind of annoying) and I noticed that my USB miners, specifically my U3, freak out while core is syncing.  The U3 is a crazy machine to begin with, but I was really surprised to see it basically be unable to hash while the sync was taking place.  It would have HW errors more than 20%, hash rate would gradually fall and fall and fall if I left it running, so I killed it until the sync was done and now it's back to running, well I hesitate to say good, but it's running as good as a U3 is expected to.

So any reason why the windows 64 bit version is now eating up over 2 gb of system ram while running..?

All my other QT clients ltc/huc only use ~ 400 mb of ram while running 

Icon

Vulnerability in UPnP library used by Bitcoin Core.An exploitable buffer overflow vulnerability exists in the XML parser functionality of the MiniUPnP library. A specially crafted XML response can lead to a buffer overflow on the stack resulting in remote code execution. An attacker can set up a server on the local network to trigger this vulnerability. ???

It is not a big deal. You can't just easily access someones local network. Just upgrade to 0.11.1 and ignore it. Besides a quick workaround was posted as soon as that was discovered.

Upgrade to 0.11.1 and this is no concern.

Or you can uncheck the upnp box in the config settings and the vulnerability is negated.

What versions does this affect?

all, but 0.11.1 and 0.10.3

 :)

Close this thread and sticky this : https://bitcointalk.org/index.php?topic=1209137.0

 :)

Thanks, I will update all my nodes.