Bitcoin Forum

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

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. `1.2.3.4` or `fe80::0012:3456:789a:bcde`)
- a network/CIDR (e.g. `1.2.3.0/24` or `fe80::0000/64`)
- a network/netmask (e.g. `1.2.3.4/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. 1.2.3.4), a network/netmask (e.g. 1.2.3.4/255.255.255.0) or a network/CIDR (e.g. 1.2.3.4/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:

- Blocks: http://localhost:8332/rest/block/*HASH*.*EXT*
- Blocks without transactions: http://localhost:8332/rest/block/notxdetails/*HASH*.*EXT*
- Transactions (requires `-txindex`): http://localhost:8332/rest/tx/*HASH*.*EXT*

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[1] 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.

[1] 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
- `171ca77` estimatefee / estimatepriority RPC methods
- `b750cf1` Remove cli functionality from bitcoind
- `f6984e8` Add "chain" to getmininginfo, improve help in getblockchaininfo
- `99ddc6c` Add nLocalServices info to RPC getinfo
- `cf0c47b` Remove getwork() RPC call
- `2a72d45` prioritisetransaction <txid> <priority delta> <priority tx fee>
- `e44fea5` Add an option `-datacarrier` to allow users to disable relaying/mining data carrier transactions
- `2ec5a3d` Prevent easy RPC memory exhaustion attack
- `d4640d7` Added argument to getbalance to include watchonly addresses and fixed errors in balance calculation
- `83f3543` Added argument to listaccounts to include watchonly addresses
- `952877e` Showing 'involvesWatchonly' property for transactions returned by 'listtransactions' and 'listsinceblock'. It is only appended when the transaction involves a watchonly address
- `d7d5d23` Added argument to listtransactions and listsinceblock to include watchonly addresses
- `f87ba3d` added includeWatchonly argument to 'gettransaction' because it affects balance calculation
- `0fa2f88` added includedWatchonly argument to listreceivedbyaddress/...account
- `6c37f7f` `getrawchangeaddress`: fail when keypool exhausted and wallet locked
- `ff6a7af` getblocktemplate: longpolling support
- `c4a321f` Add peerid to getpeerinfo to allow correlation with the logs
- `1b4568c` Add vout to ListTransactions output
- `b33bd7a` Implement "getchaintips" RPC command to monitor blockchain forks
- `733177e` Remove size limit in RPC client, keep it in server
- `6b5b7cb` Categorize rpc help overview
- `6f2c26a` Closely track mempool byte total. Add "getmempoolinfo" RPC
- `aa82795` Add detailed network info to getnetworkinfo RPC
- `01094bd` Don't reveal whether password is <20 or >20 characters in RPC
- `57153d4` rpc: Compute number of confirmations of a block from block height
- `ff36cbe` getnetworkinfo: export local node's client sub-version string
- `d14d7de` SanitizeString: allow '(' and ')'
- `31d6390` Fixed setaccount accepting foreign address
- `b5ec5fe` update getnetworkinfo help with subversion
- `ad6e601` RPC additions after headers-first
- `33dfbf5` rpc: Fix leveldb iterator leak, and flush before `gettxoutsetinfo`
- `2aa6329` Enable customising node policy for datacarrier data size with a -datacarriersize option
- `f877aaa` submitblock: Use a temporary CValidationState to determine accurately the outcome of ProcessBlock
- `e69a587` submitblock: Support for returning specific rejection reasons
- `af82884` Add "warmup mode" for RPC server
- `e2655e0` Add unauthenticated HTTP REST interface to public blockchain data
- `683dc40` Disable SSLv3 (in favor of TLS) for the RPC client and server
- `44b4c0d` signrawtransaction: validate private key
- `9765a50` Implement BIP 23 Block Proposal
- `f9de17e` Add warning comment to getinfo

Command-line options:

- `ee21912` Use netmasks instead of wildcards for IP address matching
- `deb3572` Add `-rpcbind` option to allow binding RPC port on a specific interface
- `96b733e` Add `-version` option to get just the version
- `1569353` Add `-stopafterblockimport` option
- `77cbd46` Let -zapwallettxes recover transaction meta data
- `1c750db` remove -tor compatibility code (only allow -onion)
- `4aaa017` rework help messages for fee-related options
- `4278b1d` Clarify error message when invalid -rpcallowip
- `6b407e4` -datadir is now allowed in config files
- `bdd5b58` Add option `-sysperms` to disable 077 umask (create new files with system default umask)
- `cbe39a3` Add "bitcoin-tx" command line utility and supporting modules
- `dbca89b` Trigger -alertnotify if network is upgrading without you
- `ad96e7c` Make -reindex cope with out-of-order blocks
- `16d5194` Skip reindexed blocks individually
- `ec01243` --tracerpc option for regression tests
- `f654f00` Change -genproclimit default to 1
- `3c77714` Make -proxy set all network types, avoiding a connect leak
- `57be955` Remove -printblock, -printblocktree, and -printblockindex
- `ad3d208` remove -maxorphanblocks config parameter since it is no longer functional

Block and transaction handling:

- `7a0e84d` ProcessGetData(): abort if a block file is missing from disk
- `8c93bf4` LoadBlockIndexDB(): Require block db reindex if any `blk*.dat` files are missing
- `77339e5` Get rid of the static chainMostWork (optimization)
- `4e0eed8` Allow ActivateBestChain to release its lock on cs_main
- `18e7216` Push cs_mains down in ProcessBlock
- `fa126ef` Avoid undefined behavior using CFlatData in CScript serialization
- `7f3b4e9` Relax IsStandard rules for pay-to-script-hash transactions
- `c9a0918` Add a skiplist to the CBlockIndex structure
- `bc42503` Use unordered_map for CCoinsViewCache with salted hash (optimization)
- `d4d3fbd` Do not flush the cache after every block outside of IBD (optimization)
- `ad08d0b` Bugfix: make CCoinsViewMemPool support pruned entries in underlying cache
- `5734d4d` Only remove actualy failed blocks from setBlockIndexValid
- `d70bc52` Rework block processing benchmark code
- `714a3e6` Only keep setBlockIndexValid entries that are possible improvements
- `ea100c7` Reduce maximum coinscache size during verification (reduce memory usage)
- `4fad8e6` Reject transactions with excessive numbers of sigops
- `b0875eb` Allow BatchWrite to destroy its input, reducing copying (optimization)
- `92bb6f2` Bypass reloading blocks from disk (optimization)
- `2e28031` Perform CVerifyDB on pcoinsdbview instead of pcoinsTip (reduce memory usage)
- `ab15b2e` Avoid copying undo data (optimization)
- `341735e` Headers-first synchronization
- `afc32c5` Fix rebuild-chainstate feature and improve its performance
- `e11b2ce` Fix large reorgs
- `ed6d1a2` Keep information about all block files in memory
- `a48f2d6` Abstract context-dependent block checking from acceptance
- `7e615f5` Fixed mempool sync after sending a transaction
- `51ce901` Improve chainstate/blockindex disk writing policy
- `a206950` Introduce separate flushing modes
- `9ec75c5` Add a locking mechanism to IsInitialBlockDownload to ensure it never goes from false to true
- `868d041` Remove coinbase-dependant transactions during reorg
- `723d12c` Remove txn which are invalidated by coinbase maturity during reorg
- `0cb8763` Check against MANDATORY flags prior to accepting to mempool
- `8446262` Reject headers that build on an invalid parent
- `008138c` Bugfix: only track UTXO modification after lookup

P2P protocol and network code:

- `f80cffa` Do not trigger a DoS ban if SCRIPT_VERIFY_NULLDUMMY fails
- `c30329a` Add testnet DNS seed of Alex Kotenko
- `45a4baf` Add testnet DNS seed of Andreas Schildbach
- `f1920e8` Ping automatically every 2 minutes (unconditionally)
- `806fd19` Allocate receive buffers in on the fly
- `6ecf3ed` Display unknown commands received
- `aa81564` Track peers' available blocks
- `caf6150` Use async name resolving to improve net thread responsiveness
- `9f4da19` Use pong receive time rather than processing time
- `0127a9b` remove SOCKS4 support from core and GUI, use SOCKS5
- `40f5cb8` Send rejects and apply DoS scoring for errors in direct block validation
- `dc942e6` Introduce whitelisted peers
- `c994d2e` prevent SOCKET leak in BindListenPort()
- `a60120e` Add built-in seeds for .onion
- `60dc8e4` Allow -onlynet=onion to be used
- `3a56de7` addrman: Do not propagate obviously poor addresses onto the network
- `6050ab6` netbase: Make SOCKS5 negotiation interruptible
- `604ee2a` Remove tx from AlreadyAskedFor list once we receive it, not when we process it
- `efad808` Avoid reject message feedback loops
- `71697f9` Separate protocol versioning from clientversion
- `20a5f61` Don't relay alerts to peers before version negotiation
- `b4ee0bd` Introduce preferred download peers
- `845c86d` Do not use third party services for IP detection
- `12a49ca` Limit the number of new addressses to accumulate
- `35e408f` Regard connection failures as attempt for addrman
- `a3a7317` Introduce 10 minute block download timeout
- `3022e7d` Require sufficent priority for relay of free transactions
- `58fda4d` Update seed IPs, based on bitcoin.sipa.be crawler data
- `18021d0` Remove bitnodes.io from dnsseeds.

Validation:

- `6fd7ef2` Also switch the (unused) verification code to low-s instead of even-s
- `584a358` Do merkle root and txid duplicates check simultaneously
- `217a5c9` When transaction outputs exceed inputs, show the offending amounts so as to aid debugging
- `f74fc9b` Print input index when signature validation fails, to aid debugging
- `6fd59ee` script.h: set_vch() should shift a >32 bit value
- `d752ba8` Add SCRIPT_VERIFY_SIGPUSHONLY (BIP62 rule 2) (test only)
- `698c6ab` Add SCRIPT_VERIFY_MINIMALDATA (BIP62 rules 3 and 4) (test only)
- `ab9edbd` script: create sane error return codes for script validation and remove logging
- `219a147` script: check ScriptError values in script tests
- `0391423` Discourage NOPs reserved for soft-fork upgrades
- `98b135f` Make STRICTENC invalid pubkeys fail the script rather than the opcode
- `307f7d4` Report script evaluation failures in log and reject messages
- `ace39db` consensus: guard against openssl's new strict DER checks
- `12b7c44` Improve robustness of DER recoding code
- `76ce5c8` fail immediately on an empty signature

Build system:

- `f25e3ad` Fix build in OS X 10.9
- `65e8ba4` build: Switch to non-recursive make
- `460b32d` build: fix broken boost chrono check on some platforms
- `9ce0774` build: Fix windows configure when using --with-qt-libdir
- `ea96475` build: Add mention of --disable-wallet to bdb48 error messages
- `1dec09b` depends: add shared dependency builder
- `c101c76` build: Add --with-utils (bitcoin-cli and bitcoin-tx, default=yes). Help string consistency tweaks. Target sanity check fix
- `e432a5f` build: add option for reducing exports (v2)
- `6134b43` Fixing condition 'sabotaging' MSVC build
- `af0bd5e` osx: fix signing to make Gatekeeper happy (again)
- `a7d1f03` build: fix dynamic boost check when --with-boost= is used
- `d5fd094` build: fix qt test build when libprotobuf is in a non-standard path
- `2cf5f16` Add libbitcoinconsensus library
- `914868a` build: add a deterministic dmg signer
- `2d375fe` depends: bump openssl to 1.0.1k
- `b7a4ecc` Build: Only check for boost when building code that requires it

Wallet:

- `b33d1f5` Use fee/priority estimates in wallet CreateTransaction
- `4b7b1bb` Sanity checks for estimates
- `c898846` Add support for watch-only addresses
- `d5087d1` Use script matching rather than destination matching for watch-only
- `d88af56` Fee fixes
- `a35b55b` Dont run full check every time we decrypt wallet
- `3a7c348` Fix make_change to not create half-satoshis
- `f606bb9` fix a possible memory leak in CWalletDB::Recover
- `870da77` fix possible memory leaks in CWallet::EncryptWallet
- `ccca27a` Watch-only fixes
- `9b1627d` [Wallet] Reduce minTxFee for transaction creation to 1000 satoshis
- `a53fd41` Deterministic signing
- `15ad0b5` Apply AreSane() checks to the fees from the network
- `11855c1` Enforce minRelayTxFee on wallet created tx and add a maxtxfee option

GUI:

- `c21c74b` osx: Fix missing dock menu with qt5
- `b90711c` Fix Transaction details shows wrong To:
- `516053c` Make links in 'About Bitcoin Core' clickable
- `bdc83e8` Ensure payment request network matches client network
- `65f78a1` Add GUI view of peer information
- `06a91d9` VerifyDB progress reporting
- `fe6bff2` Add BerkeleyDB version info to RPCConsole
- `b917555` PeerTableModel: Fix potential deadlock. #4296
- `dff0e3b` Improve rpc console history behavior
- `95a9383` Remove CENT-fee-rule from coin control completely
- `56b07d2` Allow setting listen via GUI
- `d95ba75` Log messages with type>QtDebugMsg as non-debug
- `8969828` New status bar Unit Display Control and related changes
- `674c070` seed OpenSSL PNRG with Windows event data
- `509f926` Payment request parsing on startup now only changes network if a valid network name is specified
- `acd432b` Prevent balloon-spam after rescan
- `7007402` Implement SI-style (thin space) thoudands separator
- `91cce17` Use fixed-point arithmetic in amount spinbox
- `bdba2dd` Remove an obscure option no-one cares about
- `bd0aa10` Replace the temporary file hack currently used to change Bitcoin-Qt's dock icon (OS X) with a buffer-based solution
- `94e1b9e` Re-work overviewpage UI
- `8bfdc9a` Better looking trayicon
- `b197bf3` disable tray interactions when client model set to 0
- `1c5f0af` Add column Watch-only to transactions list
- `21f139b` Fix tablet crash. closes #4854
- `e84843c` Broken addresses on command line no longer trigger testnet
- `a49f11d` Change splash screen to normal window
- `1f9be98` Disable App Nap on OSX 10.9+
- `27c3e91` Add proxy to options overridden if necessary
- `4bd1185` Allow "emergency" shutdown during startup
- `d52f072` Don't show wallet options in the preferences menu when running with -disablewallet
- `6093aa1` Qt: QProgressBar CPU-Issue workaround
- `0ed9675` [Wallet] Add global boolean whether to send free transactions (default=true)
- `ed3e5e4` [Wallet] Add global boolean whether to pay at least the custom fee (default=true)
- `e7876b2` [Wallet] Prevent user from paying a non-sense fee
- `c1c9d5b` Add Smartfee to GUI
- `e0a25c5` Make askpassphrase dialog behave more sanely
- `94b362d` On close of splashscreen interrupt verifyDB
- `b790d13` English translation update
- `8543b0d` Correct tooltip on address book page

Tests:

- `b41e594` Fix script test handling of empty scripts
- `d3a33fc` Test CHECKMULTISIG with m == 0 and n == 0
- `29c1749` Let tx (in)valid tests use any SCRIPT_VERIFY flag
- `6380180` Add rejection of non-null CHECKMULTISIG dummy values
- `21bf3d2` Add tests for BoostAsioToCNetAddr
- `b5ad5e7` Add Python test for -rpcbind and -rpcallowip
- `9ec0306` Add CODESEPARATOR/FindAndDelete() tests
- `75ebced` Added many rpc wallet tests
- `0193fb8` Allow multiple regression tests to run at once
- `92a6220` Hook up sanity checks
- `3820e01` Extend and move all crypto tests to crypto_tests.cpp
- `3f9a019` added list/get received by address/ account tests
- `a90689f` Remove timing-based signature cache unit test
- `236982c` Add skiplist unit tests
- `f4b00be` Add CChain::GetLocator() unit test
- `b45a6e8` Add test for getblocktemplate longpolling
- `cdf305e` Set -discover=0 in regtest framework
- `ed02282` additional test for OP_SIZE in script_valid.json
- `0072d98` script tests: BOOLAND, BOOLOR decode to integer
- `833ff16` script tests: values that overflow to 0 are true
- `4cac5db` script tests: value with trailing 0x00 is true
- `89101c6` script test: test case for 5-byte bools
- `d2d9dc0` script tests: add tests for CHECKMULTISIG limits
- `d789386` Add "it works" test for bitcoin-tx
- `df4d61e` Add bitcoin-tx tests
- `aa41ac2` Test IsPushOnly() with invalid push
- `6022b5d` Make `script_{valid,invalid}.json` validation flags configurable
- `8138cbe` Add automatic script test generation, and actual checksig tests
- `ed27e53` Add coins_tests with a large randomized CCoinViewCache test
- `9df9cf5` Make SCRIPT_VERIFY_STRICTENC compatible with BIP62
- `dcb9846` Extend getchaintips RPC test
- `554147a` Ensure MINIMALDATA invalid tests can only fail one way
- `dfeec18` Test every numeric-accepting opcode for correct handling of the numeric minimal encoding rule
- `2b62e17` Clearly separate PUSHDATA and numeric argument MINIMALDATA tests
- `16d78bd` Add valid invert of invalid every numeric opcode tests
- `f635269` tests: enable alertnotify test for Windows
- `7a41614` tests: allow rpc-tests to get filenames for bitcoind and bitcoin-cli from the environment
- `5122ea7` tests: fix forknotify.py on windows
- `fa7f8cd` tests: remove old pull-tester scripts
- `7667850` tests: replace the old (unused since Travis) tests with new rpc test scripts
- `f4e0aef` Do signature-s negation inside the tests
- `1837987` Optimize -regtest setgenerate block generation
- `2db4c8a` Fix node ranges in the test framework
- `a8b2ce5` regression test only setmocktime RPC call
- `daf03e7` RPC tests: create initial chain with specific timestamps
- `8656dbb` Port/fix txnmall.sh regression test
- `ca81587` Test the exact order of CHECKMULTISIG sig/pubkey evaluation
- `7357893` Prioritize and display -testsafemode status in UI
- `f321d6b` Add key generation/verification to ECC sanity check
- `132ea9b` miner_tests: Disable checkpoints so they don't fail the subsidy-change test
- `bc6cb41` QA RPC tests: Add tests block block proposals
- `f67a9ce` Use deterministically generated script tests
- `11d7a7d` [RPC] add rpc-test for http keep-alive (persistent connections)
- `34318d7` RPC-test based on invalidateblock for mempool coinbase spends
- `76ec867` Use actually valid transactions for script tests
- `c8589bf` Add actual signature tests
- `e2677d7` Fix smartfees test for change to relay policy
- `263b65e` tests: run sanity checks in tests too

Miscellaneous:

- `122549f` Fix incorrect checkpoint data for testnet3
- `5bd02cf` Log used config file to debug.log on startup
- `68ba85f` Updated Debian example bitcoin.conf with config from wiki + removed some cruft and updated comments
- `e5ee8f0` Remove -beta suffix
- `38405ac` Add comment regarding experimental-use service bits
- `be873f6` Issue warning if collecting RandSeed data failed
- `8ae973c` Allocate more space if necessary in RandSeedAddPerfMon
- `675bcd5` Correct comment for 15-of-15 p2sh script size
- `fda3fed` libsecp256k1 integration
- `2e36866` Show nodeid instead of addresses in log (for anonymity) unless otherwise requested
- `cd01a5e` Enable paranoid corruption checks in LevelDB >= 1.16
- `9365937` Add comment about never updating nTimeOffset past 199 samples
- `403c1bf` contrib: remove getwork-based pyminer (as getwork API call has been removed)
- `0c3e101` contrib: Added systemd .service file in order to help distributions integrate bitcoind
- `0a0878d` doc: Add new DNSseed policy
- `2887bff` Update coding style and add .clang-format
- `5cbda4f` Changed LevelDB cursors to use scoped pointers to ensure destruction when going out of scope
- `b4a72a7` contrib/linearize: split output files based on new-timestamp-year or max-file-size
- `e982b57` Use explicit fflush() instead of setvbuf()
- `234bfbf` contrib: Add init scripts and docs for Upstart and OpenRC
- `01c2807` Add warning about the merkle-tree algorithm duplicate txid flaw
- `d6712db` Also create pid file in non-daemon mode
- `772ab0e` contrib: use batched JSON-RPC in linarize-hashes (optimization)
- `7ab4358` Update bash-completion for v0.10
- `6e6a36c` contrib: show pull # in prompt for github-merge script
- `5b9f842` Upgrade leveldb to 1.18, make chainstate databases compatible between ARM and x86 (issue #2293)
- `4e7c219` Catch UTXO set read errors and shutdown
- `867c600` Catch LevelDB errors during flush
- `06ca065` Fix CScriptID(const CScript& in) in empty script case

Credits
=======

Thanks to everyone who contributed to this release:

- 21E14
- Adam Weiss
- Aitor Pazos
- Alexander Jeng
- Alex Morcos
- Alon Muroch
- Andreas Schildbach
- Andrew Poelstra
- Andy Alness
- Ashley Holman
- Benedict Chan
- Ben Holden-Crowther
- Bryan Bishop
- BtcDrak
- Christian von Roques
- Clinton Christian
- Cory Fields
- Cozz Lovan
- daniel
- Daniel Kraft
- David Hill
- Derek701
- dexX7
- dllud
- Dominyk Tiller
- Doug
- elichai
- elkingtowa
- ENikS
- Eric Shaw
- Federico Bond
- Francis GASCHET
- Gavin Andresen
- Giuseppe Mazzotta
- Glenn Willen
- Gregory Maxwell
- gubatron
- HarryWu
- himynameismartin
- Huang Le
- Ian Carroll
- imharrywu
- Jameson Lopp
- Janusz Lenar
- JaSK
- Jeff Garzik
- JL2035
- Johnathan Corgan
- Jonas Schnelli
- jtimon
- Julian Haight
- Kamil Domanski
- kazcw
- kevin
- kiwigb
- Kosta Zertsekel
- LongShao007
- Luke Dashjr
- Mark Friedenbach
- Mathy Vanvoorden
- Matt Corallo
- Matthew Bogosian
- Micha
- Michael Ford
- Mike Hearn
- mrbandrews
- mruddy
- ntrgn
- Otto Allmendinger
- paveljanik
- Pavel Vasin
- Peter Todd
- phantomcircuit
- Philip Kaufmann
- Pieter Wuille
- pryds
- randy-waterhouse
- R E Broadley
- Rose Toomey
- Ross Nicoll
- Roy Badami
- Ruben Dario Ponticelli
- Rune K. Svendsen
- Ryan X. Charles
- Saivann
- sandakersmann
- SergioDemianLerner
- shshshsh
- sinetek
- Stuart Cardall
- Suhas Daftuar
- Tawanda Kembo
- Teran McKinney
- tm314159
- Tom Harding
- Trevin Hofmann
- Whit J
- Wladimir J. van der Laan
- Yoichi Hirai
- Zak Wilcox

As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/).

Awesome news ;D going to Install right now . Contact admis so they unstick the 0.9.3 thread and stick this one .
Also seems like Sirius or whoever controls Bitcoin.org did the needed changes on Version History : https://bitcoin.org/en/version-history

~ Madness

Appreciate your great work

Awesome !!! Will try it today !!!

Watchonly is the one I was looking for :)

Regards

Finally 0.10 is here, thanks for all the great improvements.
I really love the headers-first synchronization and the watch-only support.

Looking forward to the ppa ;)

Any difference from RC4?

Good work, thank you developers! I'm just going to update all my nodes then! :-)

Awesome! I will install it today.

With the new "headers-first synchronization", does that mean we no longer need the bootstrap torrent for initial sync, as I notice it hasn't been mentioned in https://bitcoin.org/en/download anymore?

Thanks for all the developers' works.

Yes, the torrent will be a thing from the past now. Not only due to headers first, but also because the client can now download from several sources at once similar to a BitTorrent client. As a consequence using the torrent would most likely be slower as you can not verifiy the blocks while downloading via the torrent.

Thanks for the updated release! I'm assuming this is a stable release version?

Thanks!

Yes.

Given the feature list the new version seems to be really a major improvement. Great work!

I'm a bit hesitant to update right away though, because there are so many changes some bugs might only be discovered after public use...

Please answer. Can I install 0.10 on top of the previous version so i dont need to download the whole blockchain again or I need a fresh install?

Yes. Read the paragraph "How to Upgrade" in the first post.

Just FYI, there have been Release Candidates in public use since about 4 - 5 weeks.

Please never do this again.

Guys, here is my stupid question: should we install this new version or not?..  :-\

I have downloaded 0.10, but failed check PGP signature of "SHA256SUMS.asc" file. Domain bitcoin.org blocked for my location. I have downloaded through tor. Does it wrong with my download ? Where can I download 0.10 alternativity?

Totally no. We should stick with 0.9.3 until the end of time.



Get a new tor identity and download again. Most probably your exit node messed with the download but a new identity will give you a different exit.

Thank you, everyone and anyone who has worked so hard to release this latest version.  This is the most cutting edge, important piece of software in the world today, bar none, and it is an honor and pleasure to run my very own full node.

FYI - I did a clean install of 10.0 rc2 on my 2013 MacBook Air.  With 20Mbps connection it fully synced in 12 hours.  I hadn't set up the port forwarding, so that was with only 8 inbound connections.

Thanks for all the developpers , it's really appreciated .
Going to download now and enjoy the fast Synchro with the network ;D

i just update my bitcoin core
but my Zemana show this
is this OK sir ?

https://i.imgur.com/mWwNjAy.jpg

I got that error too but with windows default msg and not anti virus . I run it anyway tho
Can any developer confirm that everything is fine and good please ?

Um.... I downloaded and installed new version. It wont synchronize past block 343682 ... help?
This is an upgrade install from previous 9 version

This is such an awesome release. Have been waiting for it for months now :)

FYI, already available in archlinux repositories :)

This.

Important and interesting update, specially for the ones that just focus on the usability and they're not interested in anything else about the bitcoin core.
Faster synchronization can make people consider the usage of bitcoin-qt instead of other wallets like Multibit, Electrum… that don't download the entire blockchain on users system. Being apparently faster to set-up and to let people start sending/receiving bitcoins.

P.S: Thanks, team!

you can't download the 34Go of the blockchain ... in 3 hours.  ::)
you can't recreate the bockchain order in that time, too ... on a "normal" desktop or laptop (even with an SSD).

it says "AS LITTLE AS 3 HOURS" ... it doesnt say 3 hours guaranteed

Downloading now. Some nice improvements there.

great to see an update.. is the 20mb block limit inside this?  haha

great news, will upgrade right now

i hope it won't rescan whole blockchain again after we have updated

Will that be incorporated into Bitcoin Core? I thought the purpose of Bitcoin Core was to allow users to download the full blockchain for what ever purpose. Isn't this why there are light wallets?

With a connection of 1,000 Mbps Up/Down and a decent desktop, why wouldn't one be able to?

Excellent work team, can't wait for the future version as well.

boys wanted to know if I adjourned, I lose my bitcoin address?

There is absolutely no reason you would.

What of multi-sig?

(By the way, thanks for an excellent update!)

Can someone correct the value of the blockchain explain in the description bellow the donwload of bitcoin core ?


It's more than 35Go now ... (and the blockchain is, for now, the same for all users).  ;)

http://imagizer.imageshack.us/a/img537/2126/uTemv2.jpg

even in a 250 000 people town, you don't have a gigabit connexion at "home".
bitcoin core ... is not "only" commercial and industrial building.  ;D

Shout out to the whole Bitcoin Core team for all their work in getting us a stable version.

Will definitely give this a shot tonight.

Could anyone or an expert tell us why we are getting few errors from Anti viruses ?
a member is getting the following :

https://i.imgur.com/mWwNjAy.jpg

and I'am getting the default windows 8.1 which says if I'am sure I wanna run the program because its not trusted . Is it someone thing should I worry about or simply a false positive detection .

~ Madness

*trollmode* details, details, details

*trollmode* Sure you can. Just depends if you're willing to pay for it.

I'm sure you checked the file hashes? Then you can report a false positive to that anti-virus )or whatever it is).

So since they changed the getblocktemplate, what do we do to solo mine now? Just downgrade?

The way I read it, don't upgrade.

Figured. Thanks!

assuming blockchain is the same size, how does this improve the speed of the download?

You can download from multiple sources at once, while before the update bitcoin core would only download from the first node you connected to.

Impressive. Many thanks to the Core team for this new version!

Trying to build on Debian 6 LTS I get:


Any idea how to remedy this?

thanks for updates ::)

Any  way to re inde on this faster or scan quicker becasue seem to continue to crash my system each time I get about 50 to 70% done on it and have re downloaded block chain twice now

I have started yesterday a new node. The full blockchain was downloaded in about 16 hours.

I installed the mac version on my mac 10.6.8 but keeps on crashing after it opens. should i re download the whole blockchain?

What about this error during synchronization?


https://forum.bits.media/index.php?/topic/11513-vyshel-bitcoin-core-0100/page-2#entry235043 (https://forum.bits.media/index.php?/topic/11513-vyshel-bitcoin-core-0100/page-2#entry235043)

My guess is you are running on a version of GCC which is at least outdated by 4 years of hard work. But if you dont post more details, I cant tell you more.

Well I tried this last night around 7:30PM EST and it's still going until now.

Knew it was too good to be true, to hear the reported faster indexing, 3 hours total, yada yada.

Not poopoo-ing on the devs, because they do what they can to support and improve and optimize the software, just keeping it real.

I now see the Torrent link on the top of the page, but wonder if that's any faster than just downloading the entire Blockchain from the new client.

I know this software is meant for advanced users that want to serve as nodes etc, but to take over 12-13 hours before you can even use the client...unacceptable.

Color me disapppointed.  By the way, I have a laptop with core i7 cpu, running Win 7 64 bit, 6 GB DDR 3 RAM on a Verizon FIOS symmetric 50MB internet connection, no SSD harddrive.  Even with no SSD, that shouldn't account half a whole days worth of downloading the blockchain.  I did have Bitcoin Core 0.9.1 shutdown, and then downloaded and installed 0.10.0 over it, then an error message popped, which gave me little choice but to download the entire blockchain.  Pretty much a cancel and not use Bitcoin Core, or download 34 GB worth of data to use the software.

There should an option to download locally or cache the chain in the cloud, just give the users options especially as "the wallet" promoted and developed by the Bitcoin Foundation.

Just ranting, but expecting much better.  This is my 3rd upgrade in 3 years, guess just venting because I didn't have to re-download the entire blockchain in previous installations.

Just my experience, take it for what it's worth.

thanks,
already installed and running!

If you are talking about the bitcoin-0.10.0.torrent, it is for downloading the bitcoin core program only but not the blockchain files.

Synchronizing with network
Everything works great for the moment :)

If you used 0.9.3 version before you should see Synchroznisation with the Network a lot faster .
Check the changelog on the Github page to see what are the other changes ;) gl mate

Argh, that sucks then.  There's gotta be a way to get Core Devs to create a thin client that also has the option to Synchronize the consensus Blockchain, instead of me waiting for blocks to index for 14 hours...

why there is no digital sign? if i run the zip version(all should be the same) the warning pop up

How about a gcc -v:

Yes awesome work guys

100 people working on the core and 0 people working on the demand for bitcoin, you guys are doing great work for your coin if your priorities weren't all messed up :) I think you should start doing some real work and maybe do something positive for your investors like ahh CREATE A DEMAND so people will have a reason, a purpose and a need to buy more bitcoins than they sell. STOP waiting for others to create a demand for your coin.

And before you code and bitcoin developer lovers get all bent out of shape, I have been in bitcoins for a long time, mined them traded them,own informational websites, facebook groups, held seminars and never have I ever used the bitcoin core wallet :) to much work on that core and not enough for the demand. The core wallet is to confusing to people without coding experience, to understand it, and god forbid if they are not super experienced and only have a command line to use they wont get past the git clone, the developers have spent way to much time on the core development that is simply put, NOT userfriendly. Unless its in a graphical interface, it deters users from even using bitcoins so adoption and adaptation is more complex. the value of bitcoin continues to fall with every new release. its time to get your priorities together, because in another 5 years if things keep going this way, there will be no more bitcoins :)

Just updated my full node and it was almost uneventful, thanks.

I only had to update two scripts to use bitcoin-cli instead of bitcoind.

Question: How do I run the daemon only -- without the wallet -- after installing Core on a Windows 7 computer?

[I don't want to use the wallet just now -- only support the network with a full node.]

I should think there's a way to start and run the daemon from a command line prompt.  What's the command, and in what directory do I find it?  Thanks, much.

Edit: In the daemon directory folder, I see two files -- bitcoin-cli & bitcoind .. the former much smaller than the latter.  I'd guess maybe I can just run one of these from a command prompt.. but which one?  Thanks again.

bitcoind is the client without GUI. bitcoin-cli is the command to use if you want to poll info from bitcoind. To run without wallet: bitcoind -disablewallet

More command line options: https://en.bitcoin.it/wiki/Running_Bitcoin

Thanks, Newar.  Given enough time to look for information, I mostly figured this out on my own -- even that crazy part about having to create a configuration file just to get it to work the first time!  But the confirmation's always nice to have.  It's too bad this is not more intuitive, or that there are good instructions/helps posted somewhere obvious -- to step non-techies through how to do this.  That is, run the daemon only on the various platforms.  

I'm more familiar with Linux, and it makes the task super easy.  But on Windows it certainly is not.  And you'd have to think there would be even more folks out there that would run the daemon only -- to support the network -- if they didn't have to load up and keep open the -qt just to do that.  In today's bitcoin world, many of us already have other wallets of choice; we don't want another one loaded up and taking resources, just so we can help the network by running the daemon.

Even now that I have the daemon going on my Windows machine, this is still awkward.  When I start the daemon from a command-line prompt, I find I have to keep that window minimized in the tray for the program to keep on running.  I can't just close the window and it continue running entirely in the background, not cluttering my work space.

And to use bitcoin-cli commands while bitcoind is running, I have to open a second command window, and type in the whole 'change directory (cd)' command line, and then the -cli command at a second prompt.  That's really awkward.

Glad to hear you got it working!

I don't think bitcoind is intended for non-techies to begin with. If you don't want to spend resources on running Bitcoin Core as a full node that is fine. To support the network as a full node you will also have to open port 8333 and have your PC online as much as possible. Those will cost you bandwith and electricity. It's probably cheaper to get a VPS, I would think.

I also don't think it's intended to run on Windows desktop machines, not sure how it works on Windows servers. (I too don't know much about Windows myself, well, later than XP). You're right it's easy on Linux. Even I get it  ;)

Regarding not being able to close the window, otherwise it shuts down, I remember there used to be tools on Windows that could send a window in the right hand corner of the task bar as a small symbol or even run it hidden. Also, running a program as a service (or was it the scheduler, I forgot) meant it would not show as a window or occupying desktop or taskbar real estate. Not sure if this is still possible with the newer releases.

The separation of bitcoind and bitcoin-cli was done (0.9.0) to get a clear separation between server and as the RPC client.

Googling for "bitcoin daemon" or "bitcoin headless" brings up said wiki page in the first few hits. AFAICT everything you need is on that wiki page or the links it contains. Including the creation of the .conf file. (Not sure why you need one, if you run without wallet or any other bells and whistles, btw.). If you feel the documentation there is lacking feel free to improve the wiki.

"RBTray is a small Windows program that runs in the background and allows almost any window to be minimized to the system tray by right clicking its minimize button."


Sourceforge link: http://sourceforge.net/projects/rbtray/files/rbtray/4.3/RBTray-4_3.zip/download (http://sourceforge.net/projects/rbtray/files/rbtray/4.3/RBTray-4_3.zip/download)

I use this for cmd console windows, and a few other things, and it works great. Enjoy -  :)

Time to sync from zero blockchain folder.

Core 2 Duo 3GHz (not mobile !)
2Go RAM
SSD 500Go Samsung
12Mb connexion

Result = 2 days.
CPU and Hard drive work is the mastering ... job (connexion is not the time).

http://imagizer.imageshack.us/a/img537/2686/zoWNp6.jpg

i just  closed bitcoin 0.9.3  but didnt uninstall it
installed 0.10 on top without deleting the blockchain
it took about 5 minutes to "verify blocks"

i was expecting to have to download the whole chain again but it seems to be working
fine using the 34GB chain i already had ?

have i done something wrong ? should i delete it all and do a fresh install ?

it seems to be fine but i dont like to take chances with my coinz

Nope, thats expected. The old blockdata is still fine, would be a shame if you had to download all that again.

I unfortunately didn't have that option, had 0.9.1, shut it down first, then ran installer.

Took me about 14-15 hours total to redownload entire Blockchain, Block folder about 50GB in size.

Not sure what happened there. Usually if data get corrupted you need to re download some blocks and do a rescan. 14-15 hours for a 50Mbit/s connection sounds like a full redownload though.

thats cool ,thanks
i was thinking i did something wrong when i was reading people  complaining about the download length but the upgrade only takes 5 min to install if you already had bitcoin 0.9.3

i dont have top of the range equipment either, the laptop i installed  it  is around 6 years old :)

Not sure if serious or being trolled..  ???

watch-only addresses works, but show only "receive" and "generate", without "spending"

So balances more bigger then should be in real

How to fix?

10 have same bug as was in 8.xx and 9.xx versions.

If you set -dbcache=xxx to high values like 256 or 512 Mb (min = 4, max=1024, default=100) client with a high probability will hang or crash at initial blockchain download (or just sync a few hundreds or thousand blocks after few days or weeks offline) trowing such error:


In 2 varinats:
- just simple instant crash with such error
- no crash but client stop download new blocks (all other look fine), and if you close client (just normal exit, NOT process killing) it crash at exit with same error

With default settings (-dbcache=100) no such errors but at 100mb and current big blocks bitcoin core SO SLOW if data placed on HDD (not SSD) and killing disk and making computer almost unresponsive for other user activity (if it is not dedicated computer/server) while blockchain sync...

If this bug not fixed bitcoin will become  "SSD only" program soon. And it is a problem because of high volume of blokcchain data which keep growing even with some acceleration.  

P.S.
I sow this behavior on WinXP and Windows 7 32bit. Not tested on other systems yet.
And this error not simple run out of free RAM - in all cases i sow this error at least 500-1000 Mb RAM was still free before crash. So it is internal bitcoin (or may be levelDB ?) bug.

You're running out of address space.  A 32 bit program only has access to 4GB of address space. At least 1GB of that is used by the kernel.  Usually another GB is lost to libraries, stack, and other userspace overheads.  Leaving you with maybe 2GB of process address space. It then loses more from running multiple threads, each with their own stacks and heap arenas which use address space even if they're not using actual memory yet.  Then you get the process's own memory usage, and there just isn't much space left for huge caches.

We should probably cap the dbcache maximum on 32 bit hosts so that you don't get the surprises crashes at runtime... but sadly, I don't think it will be possible to accommodate your desire for a super large cache.   Have some patience though, the default cache is way more than adequate for a running node-- cranking it up only makes a real difference on the initial block download, which is a one time event.

Think I fixed it, inserted the following at line 5 of src/leveldb/helpers/memenv.h and it compiles fine.

Well seems if you got over 1k transactions in a mixture of wallets seems to crash client and had nothing but problems with v10 in the end  I had to delete wallet and rescan after and even this took like 12 times or more to finaly get done without it crashing ever time it scanned.

Nope not trolling,

Just tired of seeing the bitcoin developers concentrate so much on a core protocol that is literally utilized by less than 40% of the people using bitcoins right now, and out of the ones that do use it only about 10% of those actually care about bitcoin and do anything for bitcoin. SO you see the priorities of not only the Bitcoin developers, but the ones who actually use the bitcoin core is doing nothing for the value or the demand of bitcoin. So the investors we do have make little to no gains and the ones looking into bitcoin are turned away since there is no demand for bitcoin that would make it a good investment.

You sure this issue related ONLY to 32 bit systems? I mean it already know bug witch was tested and the cause of it clearly tracked to 32bit address limitations? I sow it one time even with ~2000 Mb free RAM... (4 Gb physical RAM, win 32bit, 3.5 Gb available due 32bit limitations, ~2 Gb free)

And my desire not for a super large cache, it about speed up bt disk work on HDDs. High dbcach help with it - not much, but helps.
In theory initial block download one time event, but in practice (i use btc about 2 years now) i already do this 3 times:
- my very first initial block download
- redownload after strange client crush (it was one of 0.8.x versions - not sure about exact reason, it not repeated and i upgrade ver soon) because of database corruptions
- redownload (actuality was DB reindex + some redownload) after big power flux in my city (result in sudden hard reboot) while client sync blocks from last few days - resulting in another blockchain corruption

2nd took > 1 day, 3rd (about 2 month ago) took about 2 days of heavy disk work!

Now I already know redownload usual not needed in such situations and -reindex may be enough, but if data on HDD (not SSD), -reindex takes almost the same time as full initial download, because HDD disk is bottleneck here, not Internet connections speed (if it not very slow of course? but 10-20 Mbit/s already enouhg to make HDD or CPU bottleneck, not network)
To avoid such situations in future i now keep backup of indexed blockchain- which almost doubled used space (~34 Gb working db + ~25 Gb zipped bacup)

And sometimes even sync of last one or few weeks blocks is like a pain in ass  (eg you need to check or send transactions fast, but realize what client was not synced from last week or two and need wait about hour before full sync)

You could stop looking at it as an investment.  ;)

This release has exciting features but ones I like the mos are the 'sendfreetransactions' setting, the fee calculation database, and the switch to  libsecp256k1 library. More security and more fair fees make a LOT of sense!

Yes, and I explained why (the fact that 32 bit systems needs a lower limit was also well known in advance; Bitcoin imposes a hard cap of 1024 on 32bit systems... but it sounds like from your report that this is not low enough). Large cache settings (e.g. 4096MB) are extensively tested on 64 -bit hosts.

Getting corrupted is a separate issue, that shouldn't happen. Any issues causing that should be fixed. FWIW, if you end up corrupted a reindex will work which tends to be faster and less IO intensive because it leaves the blocks in place (doesn't have to write the blocks again)... not a reason to not fix the corruption on unclean shutdown, but perhaps it's a helpful bit of advice for you.

Can you try restating this? What does "in a mixture of wallets" mean?  I've personally tested Bitcoin core with wallets with tens of thousands of transactions without issue, but I'm not sure precisely what you're doing, or what you mean by crash.

I've been trying to download the new client, but whenever I try I get only "The connection was reset. The connection to the server was reset while the page was loading" error. What might be wrong? I'm using the latest Firefox.

I'm scared to download torrent.

Why? You can verify the hash and the PGP signature of the SHASUMS file so you are certain that your copy is good.

Well what are we supposed to look at it as a currency? A transaction process? Its not a currency, and its value as a transaction protocol is not even utilized or promoted by the developers. As for now it is an investment, and since the developers who have made a but ton of money from the investors have seemingly already got paid you (and they) could say its time for them to get off their ass and do thier job. if not for the people who looked at bitcoin as an "investment" where would bitcoin be? NOWHERE, if not for the people who looked at bitcoin as an "investment" where would the developers be financially, most likely worse off than they were 6 years ago. Maybe what you and the bitcoin developers need to realize is they created the monster that is now bitcoin, they made it an investment out of greed. If not it would never have become one would it? So the bottom line is they wanted to make money and steered its real reason of creation from a transaction protocol to an investment, now its time to sleep in the bed they made. Maybe now we have a glimpse of why Satoshi left huh?

And FYI they cant even do their job right 100 people worked on the update and I still have 1 hour transaction times on companies using the bitcoin core.

How can we get Satoshi back??

A transaction network based on a transaction protocol. That's what Bitcoin is.
Then you have investors who speculate on its mass market adoption and lobbyist who insist on calling it a currency which is only one application of the network.
Meanwhile the technology and the ecosystem are making good progress thanks to the developers. Imho an investor is simply a middleman, a time intermediary between now and mass market time.

Yeah, sometimes it seems like the bitcoin-core developers are focussed on developing bitcoin-core.

Something must be done about this crazy situation.

In an unrelated note I heard that Microsoft has huge numbers of developers who do nothing but develop Microsoft software. Maybe you should email them and get it sorted out.

I had been using online wallets and blockchain-free software for the past 18 months, but since this was a major release, I decided to give it a try. I was amazed to see the free space on my HD goes from 339 to 305 Go in about 10 and a half hours. I had never downloaded so much data in so little time!

This should answer your non-technical concerns regarding the Bitcoin Foundation's priorities:

http://blogs.wsj.com/moneybeat/2015/02/24/bitbeat-for-bitcoin-some-good-press-finally/

Finally get some ads and publicity that'll help people become familiar with Bitcoin, thus directly pushing technology to meet the users needs (making Core and Bitcoin more user friendly).

Will get this version later today.

Thanks!

what is bitcoin core????
hmmm  ??? ??? ??? ??? ???

I've been running Bitcoin Core 0.10.0 stable for several days, but this morning I woke up to an error window telling me to see debug.log.  I've had errors before, and always just restart the program and no problem.  Well this time I restarted it and the loading screen comes up and it went through the block verification so fast as if there was no blockchain on my computer, then the program crashed.  I repeated the step and same thing, no error window either time.  I reinstalled 0.10.0, reset the options, pointed it to my data directory, but it still crashes at the loading window with no error message.  Here is a debug log from an attempted start of the program:


Any assistance would be appreciated, cross posting this in the beginners and help section, too.

Do you see this line in older logs as well? It looks like a firewall is interfering with the listening port. I don't know whether this could possibly cause a crash, but you might want to check this.

Onkel Paul

When I look at the peers list in bitcoin-qt, I'm seeing very few 0.10 nodes - looks like adoption of the new bitcoin core is pretty slow, or is that normal?

Onkel Paul

Bitnodes sees about 25% v0.10.0.
https://getaddr.bitnodes.io/dashboard/

Yes, I did see that error in the original log.  I've since performed a clean reinstall and am re-syncing from scratch.  Wallet was backed up, so shouldn't be a problem, I just wonder what happened in the first place.

I think where you are going wrong is thinking the development team of a coin is responsible solely on the core and the wallet, there is more to a coin than just that!

Do you understand the meaning if it aint broke dont fix it, if you have to fix it make sure it works!! ? You had 100 people working on an update and you still have some transaction times between 30 to 120 minutes, (with or without a fee added)so what have they really done? I noticed no change on my end as a user, as a coder I see a lot, but at the end of the rope, users care none about the programming they care about how fast their transactions get processed, if they have to wait 2 hours adaptation and adoption becomes a hard goal to achieve!!!

Bitcoin  needed investors from day one without them bitcoin  would be NOWHERE, investors bought the coins and helped to jump start the block chain, they bought mining hardware and helped secure the chain, without them "you" would have nothing, no transactions to process, no blockchain, and you sill need them, more now than before actually with a difficulty of over 40 billion. So, dont kick the gift horse in the mouth now because you feel you milked that tit dry and dont need it anymore. Because, in todays crytpo industry, attitude like that will bury your precious bitcoin and it will be replaced by a coin with a development team who cares about all the aspects of developing a coin, especially the people who pay the bills (investors)

I can see you are completely uneducated on trading and how it works, let me help you. The only thing bitcoin has is its tradable value, thats why it trades at over 200 bucks a coin ( the investors is why) in all actuality there is no demand for it at all.

Example: When china needs a product from japan they have a demand for the Japanese Yen, thus they buy it, then the value increases.

With bitcoin there is nothing that makes people have a need or a want to buy it "EXCEPT" the fact they can buy a few and sell a few and maybe make a profit doing it. (ITS TRADABLE MARKET) this si not a demand this is a hobby. A demand would be providing a service or a product you can only buy with bitcoins, something we need but you can not buy with cash.

hi there , for some reasons when I click "More details" on a transaction , I get all the needed informations (Amount , TX ID and those stuff about the transaction) but where there is "From : " It's written Unkown ? why I can't see from where the BTC was sent while I can see it fine on the Blockchain ?

[/b][/i]

there is many things now to buy with bitcoin ,without even counting drugs or porn or gambling which is a legal grey area depending where you live but probably still popular even places its banned   ,people have already  purchased property and vehicles with btc and trips into space with virgin airlines etc and its early days still as btc is in its infancy

then youve got overstock and newegg and microsoft and dell and thousands of smaller  places selling all sorts of things around the world ...........for me the biggest financial liberty is being able to bring my btc  on holiday and use it to get local currency without being raped by the banks or greedy money changers with unfavourable rates....

its also incredibly useful for sending people large amounts with $0.04  fee to the other side of the world regardless of amount  ,migrant workers would be a good representation of this as people who work in "rich" countries often need to send some money back to relatives  and bank transfers are expensive and slow ,western union is a bit faster but its still relatively expensive to use and will eventually go extinct like a  dinosuar when more people learn about saving maybe 5-15 %..........

i dont know how anyone can say  bitcoin is only a hobby for a few people trading coins ..... ?? :o

the possibilities are virtually  limitless on what we can do with digital money ,people will look back on this thread in a few years and be blown away in the same fashion we look back in awe at at the 2010 -2012 discussions and the 10k pizza etc

we are witnessing history in the making gentlemen .............:)

I'm currently running version 0.9.3: should I unistall it or may I simply run 0.10 installer over old version?
If possible do you think its better unistalling first or not? and for which reasons?

Thx in advance for your help and sorry for asking noob questions

https://bitcoin.org/en/release/v0.10.0

Read "How to Upgrade"

You can install 0.10 over the old version, just make sure it's not running.

Thanks both for your replies sirs

still no digital sign, when running the exe, windows 7 message for sign pop up

My old 0.9.3 version was stuck at block 345005 (6 das ago now) and it didn't sync anymore.

So upgraded to 0.10, hoping to solve the issue, but problem persist.

It's stuck at 345005, 8 active connections to bicoin network and at the left of sync bar it says "no block source available"

Anyone have a clue of what's the problem here and what may I try to solve it?

Thx in advance

ps: sorry if posted in wrong place

Put this "bitcoin.conf" file (with notepad) in the blockchain folder :


on old bitcoin core ... less connexion is better.

but ... before that, check if CPU and HARD DRIVE activity is zero.
because, on average PC, bitcoin core is SLOW BECAUSE of the hardware and not because of the connexion.

Normal sync. on Bitcoin core 0.9.x is 4 days in my PC and 2 days on the 0.10.0

I already upgraded to v. 0.10.0 : does that conf file you decribed work on 0.10 version as well?

PS: my sync process is not slow ...it doesn't sync at all even if it shows 8 active connections to the network but says "no block source available".

Use the command line  -reindex  on the shortcut of bitcoin core (and then, after the first lauch, delete the command line).

https://en.bitcoin.it/wiki/Running_Bitcoin#Command-line_arguments

Bitcoin core will be examinate the blockchain construction ... and resume the download.
At the worst, it re-download all the blockchain.

I have questions.

#1 why would they want to disable their wallet?
#2 why put it in server mode?
#3 why limit to 2 connections instead of enforcing a single good connection to a fast node with -connect=IP?


Once you started bitcoin core/qt do the peers you see in the debug window know more blocks than you? Are they running 0.10. or older versions?

Not sure on how to do that? ???

Be aware I'm running it on windows 7

I did the steps you suggested even if, for what I know, such a move doesnt make any sense on windows.

Situation is still the same.

Noticed I only have outcoming connection and no incomig ones - number of connections 8 (0 incoming/8 exiting).

A couple of peers I'm connected to use 0.10.0, the other 6 have older version, abd they know blocks than me

Also tried this tool here

https://getaddr.bitnodes.io/


and it says I'm unreachable ....but I'm writing form the same pc where I'm running bitcoincore and with the same connection  :-\

1) Bitcoin core NODE feature
2) Bitcoin core SERVER (miner) feature
3) Because ... this is calling "experience" (i have tried 1,2,4,8,12,15,25,35,50 ... with 0.9.x, only 2 is the faster setting WHEN you are in SYNC mode).

Is it possible that your router or firewall is set up to block incoming connections to port 8333?
(If using a router, you'd probably have to forward port 8333 explicitly unless bitcoin-qt is using UPnP and your router is set up to support it)

Onkel Paul

Any tip on how I may check if these are the reasons and how to forward port 8333 explicitly?

Forward incoming port 8333 on your router to the pc that is running core.



You've already checked, you are unreachable.  The "how to" is up to you to know how to use your router/firewall.

I am currently using version v0.8.6-beta is there a reason for me to upgrade to version 0.10.0? I am a little afraid that my coins may be in danger in case I fail to do it right....

Simply backup your wallet.dat file to a safe location first (which you should always do before upgrading). Your coins will be "recoverable", should anything go amiss.

Yes.

But if you experiment crash or other instability (if you run bitcoin core 24h/24) ... stay at the 0.9.1 instead.  :-\

I need to backup my wallet.dat file every time amount of my coins is changed? Or it is just some universal id of my wallet?

With bitcoin-qt, wallet.dat contains keys for all addresses that have been used already, plus 100 keys for addresses that have not been used yet.
So you really need to make a new backup only after about 100 new addresses have been used. Note that whenever you spend a bit, a new address is being used to receive the "change", so you need to count outgoing transactions, too. Of course, you should do backups much more frequently, but you don't need to back up your wallet after each transaction.

Hierarchical deterministic wallets (see https://en.bitcoin.it/wiki/Deterministic_wallet) compute all addresses from a single 128-bit seed which is normally represented as 12 common english words. For this kind of wallet, backing up the seed (which you can simply write down on a piece of paper) is all that you need.

Onkel Paul

Make a back up at least once a month or so I do and it is good practice to do too and make sure you have plenty of backups and make sure their password protected too and not just a wallet.dat that can be put back on. Just make sure to remember your password to it tho. No need to do a back up every time you receive or spend. Once a month or so is fine

For Windows 7 in order to start bitcoin core with an additional command first close bitcoin core. Once its shut down completly, open "run"  (Win + R) and enter (edit the path if you installed elsewhere):


once you hit "ok" Windows will launch bitcoin core with the additional parameter(s). In the case of reindex it will take a few hours (depending on your CPU speed) to reindex the blockchain that is allready known. I would check the logs first (see below).


This does not matter. As long as you have a connection to other nodes and they have blocks you dont you should be able to sync. You might find a reason for the error in the log files. You can find them if you enter


in the run window and hit ok. It should open an explorer window showing the folder that contains your wallet.dat and other files. Among those files is the debug.log. See if it contains any clues or post the entries for e.g. today.

Currently doing the reindex thing...seems like it is resyncing the whole blockchain.

Thx for the soggestion.

Will let you know when it will end.

today i launched core 0.1, and it stay there stuck at 100%, a bug?

try to rebuild the whole thing...

That is why I am afraid to patch it from my 0.8.6-beta version. While my current wallet can be slow as snail and took hour to start at least I know it will start. Stories like that just worries me more.

Thanks man, Ill install right now.  ;D :D

Every time you add a new address to your wallet you should back it up.

Minor bug: Date of files on windows 64 bit version says 2013 year. Otherwise, it works.

Did you download the correct file? Mine shows


in the signature.

I upgraded to BitCoin Core 0.10.0 64-bit Windows very shortly after it was released. I've been running a full node since it finished syncing after 2 days. I've had a couple days when it reindexed the blockchain, or something, that took a few hours but worked fine after that finished. Now it's frozen at block 346578 and will not sync up. I just reinstalled 0.10.0 and it reindexed blocks but has remained frozen at block 346578. When I check at getaddr.bitnodes.io it says my address is unreachable. I changed it to my IP address instead the address it defaulted to and it now says "23.119.56.197:8333 /Satoshi:0.10.0/."
How can it be unreachable yet I have 10 connections in and 8 out with plenty of traffic ???
I checked Windows Firewall Inbound Rules and verified that I have port 8333 open.
I sure need to receive my BTC deposits from the last 3 days of pool mining. What can I do ??? TIA

Nice! it gets better and better...

I am a technical newbie so I want to ask this: I am a bitcoin Core user, is there a way to send your bitcoins from specified address from your wallet? Not just random one in BTC-Core? I did not see that option anywhere so I am asking, also if that is not possible which other wallet has this option?

Now I'm on the 4th day of being frozen at block 346578.

I downloaded the zip from the website. Let me check now.

https://bitcoin.org/bin/bitcoin-core-0.10.0/bitcoin-0.10.0-win64.zip

Yup, date shows as 2013-06-01 for all files in the zip archive, as of this posting.

Well technically transactions have no "send from" address, but I know what you are refering to and most block explorers show it like that. You can enable "coin control" to select the input you want to spend by hand.

-> Settings -> Options -> Wallet -> check Enable coin control features -> OK

This might require a restart, not sure its been a while since I enabled it and you only have to do this once.

Now if you go to the send panel you will see a new button labeled "Inputs..." if you click it a new window will open showing the available inputs in either a long list or ordered by address ("Tree mode"). I prefer tree mode, but keep in mind that this might result in odd behaviou as change addresses are not listed as a seperate Tree branch. In your case if you want to control the "from" address list mode is probably better.

You dont have to do this. If you dont care you could just not click on the "Inputs..." Button and it will selecte them automatically as if you never had coin control enabled in the first place.



Thats odd, does that match your system time? I just downloaded the same file (copy pasted the link) and it shows the same date (2013-06-01). The hash matches the signed hash though, so its probably related to the way the files are build..?

https://i.imgur.com/2ygQlTd.png

I was refering to the setup file earlier

https://i.imgur.com/m98pRDD.png

Looks like upgrading to 0.10.0 was very premature as it freezes up. I gave up and removed all trace of the thing. I reinstalled it and will not wait another 2 days to see if it's capable of syncing up. If my wallet was not corrupted by 0.10.0 I would definitely have gone back to an earlier version.

This is the first time you mention your wallet.dat got corrupted. Maybe a general HDD problem?

mine has  also become corrupted somehow and reindexing the blockchain is taking up 100% of the cpu for days now
i think the older version  0.9.3 was more stable

Mine too has become corrupt and needed reindexing. Sure it didn't take as long as downloading the whole blockchain but its still a painful process. Nothing else on the HDD had any issues.

I never said my BTC wallet was corrupted. As I understand it 0.10.0 alters it when it gets converted to headers first so one cannot use a 0.10.0 wallet in 0.9.x client. I used the same wallet when I reloaded the entire blockchain which took 3 days. It now works but I will not risk being a full node and I will only open it when I have to. I've emptied it and I'm going to use my CoinBase wallet from now on.

I downloaded new version 0.10.0 core and this is the best and most advanced wallet I ever saw. Especially it opens in mini window now which can be minimized and can do other things easily . Bitcoin was and will always be 2 steps ahead they other crypto currencies.

maybe when he transfer file from usb to an hdd, while the core is still running(even simply copy-paste), happened to me once

I also had to uninstall and reinstall core after 0.10.0 and re-d/l and re-sync the entire block chain.  There was definitely some issues with it, seems this has happened to several people.  I've had no syncing issues since doing the clean re-install.

I never transferred my wallet to a usb. My guess is that my pc was rebooted while 0.10.0 was running.

Thanks for this.
Has been waiting for this upgrades. is this stable one?
will link my node blockchain to here.

Yes. Core 0.10 is the latest stable version.

i don't know why but since 3 days ago my Bitcoin Core 0.10.0 wallet is not connecting to more than 8 nodes while i was having more than 30 connections before. i didn't change anything in my modem/router config.
is anyone else having the same problem?

Could you go to the "Join the network" section on https://getaddr.bitnodes.io/ and check if you are accepting incoming connections?


Not for me.

thank you for your response.
i forwarded the port 8333 to my PC and now i'm connecting to more than 8 nodes and i'm accepting other connections. don't know why that wasn't needed before and it was working flawlessly.

Is there a place to go to see a chart of the percentage of the network that is running 0.10.0? In other words, given that the miners vote by running a particular version, where can we see that represented?

Bitnodes shows that: https://getaddr.bitnodes.io/nodes/

40.26% of reporting nodes running 10 as of this post.

I like to see that.  Thanks for the link.

Does anybody have a similar link that shows what block versions the miners are advertising?  I remember that there is one, I just don't remember where it is. 

Excellent work!

All working well here - many thanks!  :D

And now 42.53%.  This goes very slowly after the people who are actually paying attention have upgraded.  But it does go up, day after day. 

It'll probably get big kicks when the new version gets bundled into various linux distributions for auto-upgrade to people who have the package installed. 

I think you are talking about this :
http://bitcoin.sipa.be/ver-2k.png (1 week)
http://bitcoin.sipa.be/ver-10k.png (5 weeks)
http://bitcoin.sipa.be/ver-50k.png (half a year)
http://bitcoin.sipa.be/ver-ever.png (since genesis)

Thank you, that was it. 

Hey there Inception Coin thank you for sharing those links. I was looking for that as well. :-) Much appreciated.

0.10.0 is huge improvement, so much faster to sync
Optimizations are very very important for bitcoin, currently and in future

Apreciate it, thank you.

I'll try it today!

I will run a full node  soon as I get time  with the new client so more people can download off my  connection because its fast and unlimited usage

it's possible to add a sum of all ingoing and outgoing transaction? so one can know fast how many btc you spent or you have earned

maybe with the next version, right now i need to catch all the red transactions to remember how much i spent, it would be a neat, small feature

Bitcoin Core 0.10.1 has been released
https://bitcointalk.org/index.php?topic=1039713

Hey all, please advise.
Upgrading from 9.2 to 10. it says that I have ip issue and stops opening??? Can anyone point me to the right info to get this running pleae.
Thanks, running on windows 8.0 64 bit

You mean upgrading from 0.9.2 to 0.10, right? ;)
What's the exactly error message you get when you try to run the client?

why does the wallet takes trillion year to get synchronized ???
cant the professional developers find an alternative .

Obviously, your clock is moving very fast! In normal speed(eg:- Earth's), it takes a few hours to few days if you have >130 Kbps with >512 MB RAM.

I don't know how to install bitcoin core, and currently I use portable wallet only.

Which operating system are you using?

You just have to download Bitcoin Core and install it as you do with any other application. What's the problem? ;)
https://bitcoin.org/en/download