Inside Bitcoin

1Bitcoin Core version 0.12.0 is now available from:
2
3  <https://bitcoin.org/bin/bitcoin-core-0.12.0/>
4
5This is a new major version release, bringing new features and other improvements.
6
7Please report bugs using the issue tracker at github:
8
9  <https://github.com/bitcoin/bitcoin/issues>
10
11Upgrading and downgrading
12=========================
13
14How to Upgrade
15--------------
16
17If you are running an older version, shut it down. Wait until it has completely
18shut down (which might take a few minutes for older versions), then run the
19installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or
20bitcoind/bitcoin-qt (on Linux).
21
22Downgrade warning
23-----------------
24
25### Downgrade to a version < 0.10.0
26
27Because release 0.10.0 and later makes use of headers-first synchronization and
28parallel block download (see further), the block files and databases are not
29backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:
30
31* Blocks will be stored on disk out of order (in the order they are
32received, really), which makes it incompatible with some tools or
33other programs. Reindexing using earlier versions will also not work
34anymore as a result of this.
35
36* The block index database will now hold headers for which no block is
37stored on disk, which earlier versions won't support.
38
39If you want to be able to downgrade smoothly, make a backup of your entire data
40directory. Without this your node will need start syncing (or importing from
41bootstrap.dat) anew afterwards. It is possible that the data from a completely
42synchronised 0.10 node may be usable in older versions as-is, but this is not
43supported and may break as soon as the older version attempts to reindex.
44
45This does not affect wallet forward or backward compatibility.
46
47### Downgrade to a version < 0.12.0
48
49Because release 0.12.0 and later will obfuscate the chainstate on every
50fresh sync or reindex, the chainstate is not backwards-compatible with
51pre-0.12 versions of Bitcoin Core or other software.
52
53If you want to downgrade after you have done a reindex with 0.12.0 or later,
54you will need to reindex when you first start Bitcoin Core version 0.11 or
55earlier.
56
57Notable changes
58===============
59
60Signature validation using libsecp256k1
61---------------------------------------
62
63ECDSA signatures inside Bitcoin transactions now use validation using
64[libsecp256k1](https://github.com/bitcoin-core/secp256k1) instead of OpenSSL.
65
66Depending on the platform, this means a significant speedup for raw signature
67validation speed. The advantage is largest on x86_64, where validation is over
68five times faster. In practice, this translates to a raw reindexing and new
69block validation times that are less than half of what it was before.
70
71Libsecp256k1 has undergone very extensive testing and validation.
72
73A side effect of this change is that libconsensus no longer depends on OpenSSL.
74
75Reduce upload traffic
76---------------------
77
78A major part of the outbound traffic is caused by serving historic blocks to
79other nodes in initial block download state.
80
81It is now possible to reduce the total upload traffic via the `-maxuploadtarget`
82parameter. This is *not* a hard limit but a threshold to minimize the outbound
83traffic. When the limit is about to be reached, the uploaded data is cut by not
84serving historic blocks (blocks older than one week).
85Moreover, any SPV peer is disconnected when they request a filtered block.
86
87This option can be specified in MiB per day and is turned off by default
88(`-maxuploadtarget=0`).
89The recommended minimum is 144 * MAX_BLOCK_SIZE (currently 144MB) per day.
90
91Whitelisted peers will never be disconnected, although their traffic counts for
92calculating the target.
93
94A more detailed documentation about keeping traffic low can be found in
95[/doc/reduce-traffic.md](/doc/reduce-traffic.md).
96
97Direct headers announcement (BIP 130)
98-------------------------------------
99
100Between compatible peers, [BIP 130]
101(https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki)
102direct headers announcement is used. This means that blocks are advertised by
103announcing their headers directly, instead of just announcing the hash. In a
104reorganization, all new headers are sent, instead of just the new tip. This
105can often prevent an extra roundtrip before the actual block is downloaded.
106
107Memory pool limiting
108--------------------
109
110Previous versions of Bitcoin Core had their mempool limited by checking
111a transaction's fees against the node's minimum relay fee. There was no
112upper bound on the size of the mempool and attackers could send a large
113number of transactions paying just slighly more than the default minimum
114relay fee to crash nodes with relatively low RAM. A temporary workaround
115for previous versions of Bitcoin Core was to raise the default minimum
116relay fee.
117
118Bitcoin Core 0.12 will have a strict maximum size on the mempool. The
119default value is 300 MB and can be configured with the `-maxmempool`
120parameter. Whenever a transaction would cause the mempool to exceed
121its maximum size, the transaction that (along with in-mempool descendants) has
122the lowest total feerate (as a package) will be evicted and the node's effective
123minimum relay feerate will be increased to match this feerate plus the initial
124minimum relay feerate. The initial minimum relay feerate is set to
1251000 satoshis per kB.
126
127Bitcoin Core 0.12 also introduces new default policy limits on the length and
128size of unconfirmed transaction chains that are allowed in the mempool
129(generally limiting the length of unconfirmed chains to 25 transactions, with a
130total size of 101 KB).  These limits can be overridden using command line
131arguments; see the extended help (`--help -help-debug`) for more information.
132
133Opt-in Replace-by-fee transactions
134----------------------------------
135
136It is now possible to replace transactions in the transaction memory pool of
137Bitcoin Core 0.12 nodes. Bitcoin Core will only allow replacement of
138transactions which have any of their inputs' `nSequence` number set to less
139than `0xffffffff - 1`.  Moreover, a replacement transaction may only be
140accepted when it pays sufficient fee, as described in [BIP 125]
141(https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki).
142
143Transaction replacement can be disabled with a new command line option,
144`-mempoolreplacement=0`.  Transactions signaling replacement under BIP125 will
145still be allowed into the mempool in this configuration, but replacements will
146be rejected.  This option is intended for miners who want to continue the
147transaction selection behavior of previous releases.
148
149The `-mempoolreplacement` option is *not recommended* for wallet users seeking
150to avoid receipt of unconfirmed opt-in transactions, because this option does
151not prevent transactions which are replaceable under BIP 125 from being accepted
152(only subsequent replacements, which other nodes on the network that implement
153BIP 125 are likely to relay and mine).  Wallet users wishing to detect whether
154a transaction is subject to replacement under BIP 125 should instead use the
155updated RPC calls `gettransaction` and `listtransactions`, which now have an
156additional field in the output indicating if a transaction is replaceable under
157BIP125 ("bip125-replaceable").
158
159Note that the wallet in Bitcoin Core 0.12 does not yet have support for
160creating transactions that would be replaceable under BIP 125.
161
162
163RPC: Random-cookie RPC authentication
164-------------------------------------
165
166When no `-rpcpassword` is specified, the daemon now uses a special 'cookie'
167file for authentication. This file is generated with random content when the
168daemon starts, and deleted when it exits. Its contents are used as
169authentication token. Read access to this file controls who can access through
170RPC. By default it is stored in the data directory but its location can be
171overridden with the option `-rpccookiefile`.
172
173This is similar to Tor's CookieAuthentication: see
174https://www.torproject.org/docs/tor-manual.html.en
175
176This allows running bitcoind without having to do any manual configuration.
177
178Relay: Any sequence of pushdatas in OP_RETURN outputs now allowed
179-----------------------------------------------------------------
180
181Previously OP_RETURN outputs with a payload were only relayed and mined if they
182had a single pushdata. This restriction has been lifted to allow any
183combination of data pushes and numeric constant opcodes (OP_1 to OP_16) after
184the OP_RETURN. The limit on OP_RETURN output size is now applied to the entire
185serialized scriptPubKey, 83 bytes by default. (the previous 80 byte default plus
186three bytes overhead)
187
188Relay: New and only new blocks relayed when pruning
189---------------------------------------------------
190
191When running in pruned mode, the client will now relay new blocks. When
192responding to the `getblocks` message, only hashes of blocks that are on disk
193and are likely to remain there for some reasonable time window (1 hour) will be
194returned (previously all relevant hashes were returned).
195
196Relay and Mining: Priority transactions
197---------------------------------------
198
199Bitcoin Core has a heuristic 'priority' based on coin value and age. This
200calculation is used for relaying of transactions which do not pay the
201minimum relay fee, and can be used as an alternative way of sorting
202transactions for mined blocks. Bitcoin Core will relay transactions with
203insufficient fees depending on the setting of `-limitfreerelay=<r>` (default:
204`r=15` kB per minute) and `-blockprioritysize=<s>`.
205
206In Bitcoin Core 0.12, when mempool limit has been reached a higher minimum
207relay fee takes effect to limit memory usage. Transactions which do not meet
208this higher effective minimum relay fee will not be relayed or mined even if
209they rank highly according to the priority heuristic.
210
211The mining of transactions based on their priority is also now disabled by
212default. To re-enable it, simply set `-blockprioritysize=<n>` where is the size
213in bytes of your blocks to reserve for these transactions. The old default was
21450k, so to retain approximately the same policy, you would set
215`-blockprioritysize=50000`.
216
217Additionally, as a result of computational simplifications, the priority value
218used for transactions received with unconfirmed inputs is lower than in prior
219versions due to avoiding recomputing the amounts as input transactions confirm.
220
221External miner policy set via the `prioritisetransaction` RPC to rank
222transactions already in the mempool continues to work as it has previously.
223Note, however, that if mining priority transactions is left disabled, the
224priority delta will be ignored and only the fee metric will be effective.
225
226This internal automatic prioritization handling is being considered for removal
227entirely in Bitcoin Core 0.13, and it is at this time undecided whether the
228more accurate priority calculation for chained unconfirmed transactions will be
229restored. Community direction on this topic is particularly requested to help
230set project priorities.
231
232Automatically use Tor hidden services
233-------------------------------------
234
235Starting with Tor version 0.2.7.1 it is possible, through Tor's control socket
236API, to create and destroy 'ephemeral' hidden services programmatically.
237Bitcoin Core has been updated to make use of this.
238
239This means that if Tor is running (and proper authorization is available),
240Bitcoin Core automatically creates a hidden service to listen on, without
241manual configuration. Bitcoin Core will also use Tor automatically to connect
242to other .onion nodes if the control socket can be successfully opened. This
243will positively affect the number of available .onion nodes and their usage.
244
245This new feature is enabled by default if Bitcoin Core is listening, and
246a connection to Tor can be made. It can be configured with the `-listenonion`,
247`-torcontrol` and `-torpassword` settings. To show verbose debugging
248information, pass `-debug=tor`.
249
250Notifications through ZMQ