Re: [bitcoin-dev] Revisiting NODE_BLOOM: Proposed BIP

[Wladimir J. van der Laan via bitcoin-dev]

 NODE_BLOOM is distinct from NODE_NETWORK, and it is legal to advertise
 NODE_BLOOM but not NODE_NETWORK (eg for nodes running in pruned mode
 which, nonetheless, provide filtered access to the data which they do have).

But is this useful without having decided on a way to signal which blocks 
pruned nodes do have?

It looks like the part between paranthesis is speculation and should be left to 
a future BIP. 

Wladimir
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Revisiting NODE_BLOOM: Proposed BIP

[Wladimir J. van der Laan via bitcoin-dev]

On Mon, Aug 24, 2015 at 06:15:39PM +, Eric Lombrozo via bitcoin-dev wrote:
 It would be very useful to not only be able to switch filtering on and off
 globally...but to be able to switch on a per-connection basis. But then

You don't necessarily need to send everyone the same nServices bits.
E.g. you could give whitelisted peers special privileges.

But only advertize the intersection of your supported services (eg those you 
offer to the general public) in `addr` messages.

Wladimir
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

[Wladimir J. van der Laan via bitcoin-dev]

On Thu, Jul 23, 2015 at 04:30:06PM +0200, Jorge Timón via bitcoin-dev wrote:

 I think there were some misunderstandings in our previous conversation
 about this topic.
 I completely agree with having a separated repository for libconsensus
 (that's the whole point, alternative implementations can be
 consensus-safe by using it, and in the event of a schism fork[1], they
 can fork just that smaller project without having to relay on Bitcoin
 Core [satoshi] at all).

Indeed.

 But I thought you also wanted Bitcoin Core to use libconsensus instead
 of just having a subtree/subrepository like it currently does with
 libsecp256k1.
 I'm not sure if that would ever be accepted, but in any case we're
 certainly far away from that goal. Here are some things that need to
 happen first:

I don't see any reason why Bitcoin Core would not use the consensus library. 
Eating our own dogfood and such.

Biggest risk, as I've said before, is that the refactoring loading to a (more 
complete) consensus library will result in code that is no longer bug-for-bug 
compatible with previous versions, thus defeating its entire purpose and 
introducing fork risk.

If that can be avoided - for example by going from here to there using pure 
code moves, as you're trying to do - I'm all for it.

 2) Finish libconsensus's API: expose more things than VerifyScript, at
 the very least, also expose VerifyTx, VerifyHeader and VerifyBlock.
 Feedback from alternative implementations like libbitcoin is extremely
 valuable here. Some related closed-for-now PRs:

Agreed.

 3) Move libconsensus to a separate repository as a
 subtree/subrepository of Bitcoin Core.

If the rest is done, this is the easy part :)

 Unfortunately and ironically again, safer, small and incremental
 changes are less interesting for reviewers.
 For example, I've been trying to move consensus code to the consensus
 folder for a long time. The correctness of a MOVEONLY change is
 trivial to review for anyone who knows how to copy/paste in its
 favorite editor and how to use git diff, but will I ever get answers
 to my questions in [1]?

Code review capacity is still our greatest bottleneck.
And I don't see any way out of that, unfortunately.

 I know there's many people who really care about this, Cory Fields,
 Wladimir and Pieter Wuille to name a few have reviewed many of this
 changes (I've just got used to publicly whine about lack of review on
 this front and policy encapsulation [very related fronts] as an
 attempt to get some attention: not always, but begging for review
 actually works some times).

I do really care about this.

Wladimir

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

[Wladimir J. van der Laan via bitcoin-dev]

On Mon, Jul 27, 2015 at 11:40:42PM -0700, Eric Voskuil via bitcoin-dev wrote:

 It's a performance sacrifice, and then there's the OpenSSL dependency,
 but these are both optional within our stack - so the application
 developer has the option. So the only downside is that we are
 maintaining the conditional compilation.

Now that BIP66 became active, and only strict DER signatures are allowed, the 
OpenSSL dependency can be removed from consensus.

Pieter Wuille will do an announcement on this soon.

Wladimir
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

[Wladimir J. van der Laan via bitcoin-dev]

Eric Voskuil, Alice Larson, others:

Personal attacks or bullying of any kind are not tolerated on this mailing list.

This list is meant to be a low-volume community for technical proposals and 
discussion regarding Bitcoin. See the archive for say, 2012, for example.

What Peter Todd or anyone else is doing on Twitter or other places is not 
relevant here. This list is not a pillory for your issues, nor a place to 
exhibit your personal hobby horses.

Wladimir

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core 0.11.2 released

[Wladimir J. van der Laan via bitcoin-dev]

I'm not sure that's the right way to go about verifing gpg keys.
Copy/pasting from webpages is going to run into padding/character set 
conversion issues, resulting in potential false negatives. If you want to 
verify mails, you have to verify the original mail, which archives don't make 
easy (or even possible).

So I'd do this:

The binary release signing key is signed by my normal key:

$ gpg --list-sigs 36C2E964

pub   4096R/36C2E964 2015-06-24 [expires: 2017-02-13]
uid  Wladimir J. van der Laan (Bitcoin Core binary release 
signing key) <laa...@gmail.com>
sig 336C2E964 2015-06-24  Wladimir J. van der Laan (Bitcoin Core 
binary release signing key) <laa...@gmail.com>
sig  2346C9A6 2015-06-24  Wladimir J. van der Laan 
<laa...@visucore.com>

My normal key in turn is signed by a lot of different people.

$ gpg --list-sigs 2346C9A6

...

Also, both keys can be found on bitcoin.org in the list of developers, as well
as linked on the download page:

https://bitcoin.org/en/download

Wladimir

On Fri, Nov 13, 2015 at 06:10:29PM -0800, Dave Scotese via bitcoin-dev wrote:
> I decided to try to certify Wladimir's PGP keys (the old one (2346C9A6)
> first, and then the new one (36C2E964), since it was signed with the old
> one).
> 
> I visited
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009045.html
> to see that the new key was referenced in a message signed by the old one.
> I figure it's safe to assume that if the old key actually signed that
> message, then the core dev using  <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>> is an
> actual core dev (that's all I'd be worried about).  So I copied the text
> from --BEGIN PGP SIGNED MESSAGE- to -END PGP SIGNATURE- to
> my clipboard and asked Kleopatra (on Windows) to verify it.  It says the
> signature is bad.  If I alter the text of the email (so the signature would
> be have to be different to be valid), it says exactly the same thing.  So
> maybe something is wrong with Kleopatra on Windows.
> 
> However, the SHA256SUMS.asc file I got from the magnet link posted in the
> email (below)  verifies just fine using the new key (36C2E964).  So I
> figure Kleopatra is not broken.  It recognizes that the old key was used to
> create the signature in that old email, but it says it's invalid.  Has
> Wladimir been secretly replaced by someone who doesn't have access to the
> private key for 2346C9A6?  Can you make a (bad) signature look like it was
> made using a key you don't have? The whole reason for signing is so that we
> will know if something like that happened.  So did I do something wrong?
> (I mean, besides using Windows).
> 
> I believe this is the expected result if someone took something Wladimir
> signed and ripped off the signature and pasted it below this new message to
> make everyone think the new message was genuine.  Maybe Wladimir made an
> edit after the signature was attached.  Or maybe it got changed when it
> went through the email system.  It would be nice to know.  Anyway, I fell
> back on Windows security and ran the install because it said it verified
> that the publisher was "The Bitcoin Foundation".
> 
> 
> On Fri, Nov 13, 2015 at 5:13 AM, Wladimir J. van der Laan via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > Bitcoin Core version 0.11.2 is now available from:
> >
> >   <https://bitcoin.org/bin/bitcoin-core-0.11.2/>
> >
> > Alternatively, through bittorrent:
> >
> >
> > magnet:?xt=urn:btih:d6d3387160f7e14f6f27dc40ae84cf566ebf631b=bitcoin-core-0.11.2=udp%3A%2F%
> > 2Ftracker.openbittorrent.com%3A80%2Fannounce=udp%3A%2F%
> > 2Ftracker.publicbt.com%3A80%2Fannounce=udp%3A%2F%2Ftracker.ccc.de
> > %3A80%2Fannounce=udp%3A%2F%2Ftracker.coppersurfer.tk
> > %3A6969=udp%3A%2F%2Fopen.demonii.com
> > %3A1337=https%3A%2F%2Fbitcoin.org%2Fbin%2F
> >
> > This is a new minor version release, bringing bug fixes, the BIP65
> > (CLTV) consensus change, and relay policy preparation for BIP113. It is
> > recommended to upgrade to this version as soon as possible.
> >
> > 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 ove

[bitcoin-dev] Bitcoin Core 0.10.4 release candidate 1 available

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Binaries for bitcoin Core version 0.10.4rc1 are now available from:

https://bitcoin.org/bin/bitcoin-core-0.10.4/test/

Source code can be found on github under the signed tag

https://github.com/bitcoin/bitcoin/tree/v0.10.4rc1

This is a new minor version release, bringing bug fixes, the BIP65 (CLTV)
consensus change, and relay policy preparation for BIP113.

Preliminary release notes for the 0.10.4 release can be found here:

https://github.com/bitcoin/bitcoin/blob/0.10/doc/release-notes.md

Release candidates are test versions for releases. When no critical problems
are found, this release candidate will be tagged as 0.10.4.

Please report bugs using the issue tracker at github:

https://github.com/bitcoin/bitcoin/issues

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCgAGBQJWQfjkAAoJEHSBCwEjRsmmEPIIAJPrtqsFZ8h9yZ9z4zKyarT7
1TLdr5Pvd0j5JRtqE6ZlKrHNTNu5QON4vM7Nk/JXIb0kZGSjjMYevBzlWJxkqn7G
EM9EwmDwInRFgTnYiPG5/L/i0PZkeZn/8GIHZUHeRQ1MPhuy1t7fUmJ3ZXgQmrQp
imwg5ZKqF6HwHEb89nvxKCsqHEntUxP4uZaWcapWL7nKyDRtXjBuyWwNzceixlpo
c8cy944V2aXjjFQh4NStfEoxYHMgkcxyRAm9RWOt2v6PfV0l6SuYSaNsSgLWVhuv
GTsO6CX1gdqNpctEl8g3fkfihhN+eY7A+WBbyj+i//6kQb03xMZiy+CRmUfA31g=
=xKpy
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Bitcoin Core 0.11.2 release candidate 1 available

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Binaries for bitcoin Core version 0.11.2rc1 are now available from:

https://bitcoin.org/bin/bitcoin-core-0.11.2/test/

Source code can be found on github under the signed tag

https://github.com/bitcoin/bitcoin/tree/v0.11.2rc1

This is a new minor version release, bringing bug fixes, the BIP65 (CLTV)
consensus change, and relay policy preparation for BIP113.

Preliminary release notes for the 0.11.2 release can be found here:

https://github.com/bitcoin/bitcoin/blob/0.11/doc/release-notes.md

Release candidates are test versions for releases. When no critical problems
are found, this release candidate will be tagged as 0.11.2.

Please report bugs using the issue tracker at github:

https://github.com/bitcoin/bitcoin/issues

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCgAGBQJWQHgdAAoJEHSBCwEjRsmmkZkH/joklzUWXNCS/CKjfhnDaSAL
kTuGpcBPcmGyLZ+n7YHIwXKi5Jjuy91ADbYKUQHtOI5oDK+5XY0SD5YDfQv+jx8a
m3J5rxePV6VXcXKtNURXRmmk71zGhIZvZ0ynUlgLqvP7WFM+FcH5BJF2sk2amFlK
2WIzJapJMXzOyYehb9ISb2qXtuSGDyevpfeDJVMNIqoQekS1r8jOPXJiT66G4HZZ
SvUMPZAjgOtjKUQK98nF1xzRggkWiP1rjeBVdvlYiTmCopYrNiB5scPmSf2guCrx
7IH5fLbQ7JDow49dcd2ILTYFgMF03HvPvtlwz9dvOx5JYOaCw0He5CnXzZgFmV0=
=uO43
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Bitcoin Core 0.10.3 released

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version 0.10.3 is now available from:

  

This is a new minor version release, bringing security fixes and translation 
updates.

Please report bugs using the issue tracker at github:

  

Upgrading and downgrading
=

How to Upgrade
- --

If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or
bitcoind/bitcoin-qt (on Linux).

Downgrade warning
- --

Because release 0.10.0 and later makes use of headers-first synchronization and
parallel block download (see further), the block files and databases are not
backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:

* Blocks will be stored on disk out of order (in the order they are
received, really), which makes it incompatible with some tools or
other programs. Reindexing using earlier versions will also not work
anymore as a result of this.

* The block index database will now hold headers for which no block is
stored on disk, which earlier versions won't support.

If you want to be able to downgrade smoothly, make a backup of your entire data
directory. Without this your node will need start syncing (or importing from
bootstrap.dat) anew afterwards. It is possible that the data from a completely
synchronised 0.10 node may be usable in older versions as-is, but this is not
supported and may break as soon as the older version attempts to reindex.

This does not affect wallet forward or backward compatibility.

Notable changes
===

Fix buffer overflow in bundled upnp
- 

Bundled miniupnpc was updated to 1.9.20151008. This fixes a buffer overflow in
the XML parser during initial network discovery.

Details can be found here: http://talosintel.com/reports/TALOS-2015-0035/

This applies to the distributed executables only, not when building from source 
or
using distribution provided packages.

Additionally, upnp has been disabled by default. This may result in a lower
number of reachable nodes on IPv4, however this prevents future libupnpc
vulnerabilities from being a structural risk to the network
(see https://github.com/bitcoin/bitcoin/pull/6795).

Test for LowS signatures before relaying
- -

Make the node require the canonical 'low-s' encoding for ECDSA signatures when
relaying or mining.  This removes a nuisance malleability vector.

Consensus behavior is unchanged.

If widely deployed this change would eliminate the last remaining known vector
for nuisance malleability on SIGHASH_ALL P2PKH transactions. On the down-side
it will block most transactions made by sufficiently out of date software.

Unlike the other avenues to change txids on transactions this
one was randomly violated by all deployed bitcoin software prior to
its discovery. So, while other malleability vectors where made
non-standard as soon as they were discovered, this one has remained
permitted. Even BIP62 did not propose applying this rule to
old version transactions, but conforming implementations have become
much more common since BIP62 was initially written.

Bitcoin Core has produced compatible signatures since a28fb70e in
September 2013, but this didn't make it into a release until 0.9
in March 2014; Bitcoinj has done so for a similar span of time.
Bitcoinjs and electrum have been more recently updated.

This does not replace the need for BIP62 or similar, as miners can
still cooperate to break transactions.  Nor does it replace the
need for wallet software to handle malleability sanely[1]. This
only eliminates the cheap and irritating DOS attack.

[1] On the Malleability of Bitcoin Transactions
Marcin Andrychowicz, Stefan Dziembowski, Daniel Malinowski, Łukasz Mazurek
http://fc15.ifca.ai/preproceedings/bitcoin/paper_9.pdf

Minimum relay fee default increase
- ---

The default for the `-minrelaytxfee` setting has been increased from `0.1`
to `0.5`.

This is necessitated by the current transaction flooding, causing
outrageous memory usage on nodes due to the mempool ballooning. This is a
temporary measure, bridging the time until a dynamic method for determining
this fee is merged (which will be in 0.12).

(see https://github.com/bitcoin/bitcoin/pull/6793, as well as the 0.11.0
release notes, in which this value was suggested)

0.10.3 Change log
=

Detailed release notes follow. This overview includes changes that affect 
external
behavior, not code moves, refactors or string updates.

- - #6186 `e4a7d51` Fix two problems in CSubnet parsing
- - #6153 `ebd7d8d` Parameter interaction: disable upnp if -proxy set
- - #6203 `ecc96f5` Remove P2SH 

Re: [bitcoin-dev] Memory leaks?

[Wladimir J. van der Laan via bitcoin-dev]

On Tue, Oct 13, 2015 at 02:56:08PM -0700, Jonathan Toomim (Toomim Bros) via 
bitcoin-dev wrote:
> I just noticed that several of my running bitcoind processes were using 
> around 3+ GB of RAM, even though the mempool itself seemed to be under 
> control.
> 
> @prime:~/bin$ ./bitcoin-cli getmempoolinfo
> {
> "size" : 1896,
> "bytes" : 37341328
> }
> 
> [total memory usage not shown -- I restarted bitcoind as soon as I noticed, 
> and didn't copy it down from top]

This is *most likely* the mempool, but is just not reported correctly.

In the meantime you can mitigate the mempool growth by setting `-mintxfee`, see
https://github.com/bitcoin/bitcoin/blob/v0.11.0/doc/release-notes.md#transaction-flooding

This will be the default in 0.11.1 and 0.10.3. 0.12.0 will have better mempool 
management, as well as more precise reporting (as paveljanik already mentions.)

Wladimir
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Bitcoin Core 0.11.1 release candidate 2 available

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version 0.11.1 release candidate 2 is now available from:

  

This is a release candidate for a new minor version release, bringing security
fixes.
(release candidate 1 was never released as binaries)

Please report bugs using the issue tracker at github:

  

Preliminary release notes for 0.11.1 follow:

Upgrading and downgrading
=

How to Upgrade
- --

If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or
bitcoind/bitcoin-qt (on Linux).

Downgrade warning
- --

Because release 0.10.0 and later makes use of headers-first synchronization and
parallel block download (see further), the block files and databases are not
backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:

* Blocks will be stored on disk out of order (in the order they are
received, really), which makes it incompatible with some tools or
other programs. Reindexing using earlier versions will also not work
anymore as a result of this.

* The block index database will now hold headers for which no block is
stored on disk, which earlier versions won't support.

If you want to be able to downgrade smoothly, make a backup of your entire data
directory. Without this your node will need start syncing (or importing from
bootstrap.dat) anew afterwards. It is possible that the data from a completely
synchronised 0.10 node may be usable in older versions as-is, but this is not
supported and may break as soon as the older version attempts to reindex.

This does not affect wallet forward or backward compatibility. There are no
known problems when downgrading from 0.11.x to 0.10.x.

Notable changes
===

Fix buffer overflow in bundled upnp
- 

Bundled miniupnpc was updated to 1.9.20151008. This fixes a buffer overflow in
the XML parser during initial network discovery.

Details can be found here: http://talosintel.com/reports/TALOS-2015-0035/

This applies to the distributed executables only, not when building from source 
or
using distribution provided packages.

Additionally, upnp has been disabled by default. This may result in a lower
number of reachable nodes on IPv4, however this prevents future libupnpc
vulnerabilities from being a structural risk to the network
(see https://github.com/bitcoin/bitcoin/pull/6795).

Test for LowS signatures before relaying
- -

Make the node require the canonical 'low-s' encoding for ECDSA signatures when
relaying or mining.  This removes a nuisance malleability vector.

Consensus behavior is unchanged.

If widely deployed this change would eliminate the last remaining known vector
for nuisance malleability on SIGHASH_ALL P2PKH transactions. On the down-side
it will block most transactions made by sufficiently out of date software.

Unlike the other avenues to change txids on transactions this
one was randomly violated by all deployed bitcoin software prior to
its discovery. So, while other malleability vectors where made
non-standard as soon as they were discovered, this one has remained
permitted. Even BIP62 did not propose applying this rule to
old version transactions, but conforming implementations have become
much more common since BIP62 was initially written.

Bitcoin Core has produced compatible signatures since a28fb70e in
September 2013, but this didn't make it into a release until 0.9
in March 2014; Bitcoinj has done so for a similar span of time.
Bitcoinjs and electrum have been more recently updated.

This does not replace the need for BIP62 or similar, as miners can
still cooperate to break transactions.  Nor does it replace the
need for wallet software to handle malleability sanely[1]. This
only eliminates the cheap and irritating DOS attack.

[1] On the Malleability of Bitcoin Transactions
Marcin Andrychowicz, Stefan Dziembowski, Daniel Malinowski, Łukasz Mazurek
http://fc15.ifca.ai/preproceedings/bitcoin/paper_9.pdf

Minimum relay fee default increase
- ---

The default for the `-minrelaytxfee` setting has been increased from `0.1`
to `0.5`.

This is necessitated by the current transaction flooding, causing
outrageous memory usage on nodes due to the mempool ballooning. This is a
temporary measure, bridging the time until a dynamic method for determining
this fee is merged (which will be in 0.12).

(see https://github.com/bitcoin/bitcoin/pull/6793, as well as the 0.11
release notes, in which this value was suggested)

0.11.1 Change log
=

Detailed release notes follow. This overview includes changes that affect
behavior, not code moves, refactors and 

[bitcoin-dev] Bitcoin Core 0.10.3 release candidate 2 available

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version 0.10.3 release candidate 2 is now available from:

  

(release candidate 1 never had binaries available)

This is a release candidate for a new minor version release, bringing security
fixes and translation updates.

Please report bugs using the issue tracker at github:

  

Preliminary releae notes follow:

Upgrading and downgrading
=

How to Upgrade
- --

If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or
bitcoind/bitcoin-qt (on Linux).

Downgrade warning
- --

Because release 0.10.0 and later makes use of headers-first synchronization and
parallel block download (see further), the block files and databases are not
backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:

* Blocks will be stored on disk out of order (in the order they are
received, really), which makes it incompatible with some tools or
other programs. Reindexing using earlier versions will also not work
anymore as a result of this.

* The block index database will now hold headers for which no block is
stored on disk, which earlier versions won't support.

If you want to be able to downgrade smoothly, make a backup of your entire data
directory. Without this your node will need start syncing (or importing from
bootstrap.dat) anew afterwards. It is possible that the data from a completely
synchronised 0.10 node may be usable in older versions as-is, but this is not
supported and may break as soon as the older version attempts to reindex.

This does not affect wallet forward or backward compatibility.

Notable changes
===

Fix buffer overflow in bundled upnp
- 

Bundled miniupnpc was updated to 1.9.20151008. This fixes a buffer overflow in
the XML parser during initial network discovery.

Details can be found here: http://talosintel.com/reports/TALOS-2015-0035/

This applies to the distributed executables only, not when building from source 
or
using distribution provided packages.

Additionally, upnp has been disabled by default. This may result in a lower
number of reachable nodes on IPv4, however this prevents future libupnpc
vulnerabilities from being a structural risk to the network
(see https://github.com/bitcoin/bitcoin/pull/6795).

Test for LowS signatures before relaying
- -

Make the node require the canonical 'low-s' encoding for ECDSA signatures when
relaying or mining.  This removes a nuisance malleability vector.

Consensus behavior is unchanged.

If widely deployed this change would eliminate the last remaining known vector
for nuisance malleability on SIGHASH_ALL P2PKH transactions. On the down-side
it will block most transactions made by sufficiently out of date software.

Unlike the other avenues to change txids on transactions this
one was randomly violated by all deployed bitcoin software prior to
its discovery. So, while other malleability vectors where made
non-standard as soon as they were discovered, this one has remained
permitted. Even BIP62 did not propose applying this rule to
old version transactions, but conforming implementations have become
much more common since BIP62 was initially written.

Bitcoin Core has produced compatible signatures since a28fb70e in
September 2013, but this didn't make it into a release until 0.9
in March 2014; Bitcoinj has done so for a similar span of time.
Bitcoinjs and electrum have been more recently updated.

This does not replace the need for BIP62 or similar, as miners can
still cooperate to break transactions.  Nor does it replace the
need for wallet software to handle malleability sanely[1]. This
only eliminates the cheap and irritating DOS attack.

[1] On the Malleability of Bitcoin Transactions
Marcin Andrychowicz, Stefan Dziembowski, Daniel Malinowski, Łukasz Mazurek
http://fc15.ifca.ai/preproceedings/bitcoin/paper_9.pdf

Minimum relay fee default increase
- ---

The default for the `-minrelaytxfee` setting has been increased from `0.1`
to `0.5`.

This is necessitated by the current transaction flooding, causing
outrageous memory usage on nodes due to the mempool ballooning. This is a
temporary measure, bridging the time until a dynamic method for determining
this fee is merged (which will be in 0.12).

(see https://github.com/bitcoin/bitcoin/pull/6793, as well as the 0.11.0
release notes, in which this value was suggested)

0.10.3 Change log
=

Detailed release notes follow. This overview includes changes that affect 
external
behavior, not code moves, refactors or string updates.

- - #6186 `e4a7d51` Fix two 

[bitcoin-dev] ALERT: Vulnerability in UPnP library used by Bitcoin Core

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


TL;DR disable UPnP in Bitcoin Core as soon as possible, if you still have it 
enabled.

Upgrading to 0.11.1rc2 or 0.10.3rc2 will also solve the issue, as they bundle a 
newer libupnpc (as well as disable upnp usage by default.) However these 
versions are still in the release candidate cycle, there is some risk in using 
test versions.

See https://bitcoin.org/en/alert/2015-10-12-upnp-vulnerability for details

Wladimir
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCgAGBQJWG+rxAAoJEHSBCwEjRsmmh14H/jWEqINoAdb9CNE5pOiFv9FG
X51SCeZ/OCQXJ5qQGgcpMfP1w2fPFJwzrrJFIp9D8MUYXc9f6ZHo0A0Uc8LmPlrW
46Wu/TgN0N5XpJ8yDzDk1GxU3fGhGEX897SOxrt8NEUcrJBC1kaLlG01ma2Mf+VJ
wXsn++pgWO/9CCQzRIBNdJf1a8qnMsyRbryW7IsLNGiR4GRKzt9Hcp/p2vVxYFdD
bjVAWsEFnRga0ho0Kpnp5RxFZxVkL03ls6yj9wqZtlMHVGuyVWiwFqMjOV30wBfv
uENkWe/6veIU+Y3PmbuPJv79kRW2xTGZTl1RIKgJAdxVWPJy58a999AToIs/BWM=
=XC8t
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Censorship

[Wladimir J. van der Laan via bitcoin-dev]

On Fri, Aug 21, 2015 at 01:03:33PM -0500, sisadm101--- via bitcoin-dev wrote:
> is from a one sided point of view? There doesn't seem to be a solution at
> this time, but I find it dissapointing that many (in this very email list)

Please, this has drifted so far from the goal of this list: bitcoin 
development, and technical and academic debate about that.

Meta-discussion of communities has no place here.

I'd say: in the spirit of permissionlessness, everyone can create a community 
or list about bitcoin. If you don't agree with the admin, create your own. 
That's more constructive use of everyone's time and energy than trying to 
pressure people to change their behavior on their own home turf.

Wladimir
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Open Block Chain Licence, BIP[xxxx] Draft

[Wladimir J. van der Laan via bitcoin-dev]

On Tue, Sep 01, 2015 at 02:30:17PM +0100, Ahmed Zsales via bitcoin-dev wrote:
> Hello,
> 
> We believe the network requires a block chain licence to supplement the
> existing MIT Licence which we believe only covers the core reference client
> software.

As long as it's an open system, one can't require a specific license for 
everything added to the chain.

You could of course make the BIP advisory, but I'm not sure what that would 
help. You still wouldn't have any certainty what license the contents of block 
# would be under.

Wladimir
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Your Gmaxwell exchange

[Wladimir J. van der Laan via bitcoin-dev]

On Mon, Aug 31, 2015 at 01:55:43PM -0500, Justus Ranvier via bitcoin-dev wrote:

> * They should own their bitcoins, meaning that they retain exclusive
> control over their balances. Even more precisely, the network must
> always honour the conditions of the scripts associated with unspent outputs.
> 
> * Their fraction of the Bitcoin ledger must not be diluted.
> 
> * When they decide to spend their coins, they will be able to do so
> without requiring permission from a third party.

All of these properties are contingent on the system being decentralized. 
Asking random end-users if they care if bitcoin is decentralized is like asking 
random people if they care if their drinking water is dihydrogen monoxide.

Both miner and full node over-centralization could result in

- Permission requirements to submit transactions (miners can be pressured to 
adhere to KYC rules)

- Transactions being reversed without consent (reorgs by the miner cartel)

- ...even dilution of their fraction of their ledger (if changing the rules 
becomes normal, I'm sure some smoothtalker could come up with arguments to 
raise the 21M cap. Another option would be to force the remaining people that 
are able to run full nodes to comply)

Bitcoin's properties don't come from magic. All its attractive properties are 
derived from decentralization, on spreading responsibility as widely globally 
as possible. Without that, it's just an inefficient ledger database.

Wladimir
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] 2015-09-24 #bitcoin-dev Weekly Development Meeting Minutes

[Wladimir J. van der Laan via bitcoin-dev]

Hello Daniel,

On Thu, Sep 24, 2015 at 05:29:02PM -0700, Daniel Stadulis via bitcoin-dev wrote:
> If you weren't able to attend the first, weekly development meeting, the
> following are the minutes:

Thanks for writing up the meeting minutes and posting them to the list!

We should probably put them on the wiki, as well.

Wladimir

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fwd: Bitcoin Core 0.12.0 release schedule

[Wladimir J. van der Laan via bitcoin-dev]

On Thu, Oct 01, 2015 at 11:41:25AM +0200, Marcel Jamin wrote:
> I guess the question then becomes why bitcoin still is <1.0.0

I'll interpret the question as "why is the Bitcoin Core software still <1.0.0". 
Bitcoin the currency doesn't have a version, the block/transaction versions are 
at v3/v1 respectively, and the highest network protocol version is 70011. 

Mostly because we don't use the numbers as a signaling mechanism. They just 
count up, every half year.

Otherwise, one'd have to ask hard questions like 'is the software mature enough 
to be called 1.0.0', which would lead to long arguments, all of which would 
eventually lead to nothing more than potentially increasing a number. We're 
horribly stressed-out as is.

Wladimir
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core 0.12.0 release schedule

[Wladimir J. van der Laan via bitcoin-dev]

On Wed, Sep 30, 2015 at 05:57:42PM +, Luke Dashjr wrote:
> On Thursday, September 24, 2015 11:25:56 AM Wladimir J. van der Laan via 
> bitcoin-dev wrote:
> > 2015-12-01
> > ---
> > - Feature freeze
> 
> Where is "Consensus freeze"? Shouldn't this be put off until after the HK 
> workshop in case a hardfork is decided on? Or have we de-coupled it from the 
> release process entirely anyway (since old versions need an update for it 
> too)?

In principle, "feature freeze" means that any large code changes will no longer 
go into 0.12, unless fixing critical bugs. 

I'm not keen on postponing 0.12 for such reasons - after the HK workshop I'm 
sure that it will take some development/testing/review before code makes it 
into anything. Apart from that there's a good point to decouple consensus 
changes from Bitcoin Core major releases.

We've seen lot of release date drift due to "this and this change needs to make 
it in" in the past, that was a major reason to switch to a time-based instead 
of feature-based release schedule.

We can always do a 0.12.1.

Wladimir
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

[Wladimir J. van der Laan via bitcoin-dev]

On Sun, Sep 27, 2015 at 02:50:31PM -0400, Peter Todd via bitcoin-dev wrote:

> It's time to deploy BIP65 CHECKLOCKTIMEVERIFY.

There appears to be common agreement on that.

The only source of some controversy is how to deploy: versionbits versus
IsSuperMajority. I think the versionbits proposal should first have code
out there for longer before we consider it for concrete softforks. Haste-ing
along versionbits because CLTV is wanted would be risky.

> I've backported the CLTV op-code and a IsSuperMajority() soft-fork to
> the v0.10 and v0.11 branches, pull-reqs #6706 and #6707 respectively. A
> pull-req for git HEAD for the soft-fork deployment has been open since
> June 28th, #6351 - the opcode implementation itself was merged two
> months ago.

> We should release a v0.10.3 and v0.11.1 with CLTV and get the ball
> rolling on miner adoption. We have consensus that we need CLTV, we have
> a well tested implementation, and we have a well-tested deployment
> mechanism. 

As you say, the underlying code has been merged for months in master, and #6351
seems to have had quite some eyes on it already.

It does need to be made sure that the backports are correct, however.
Although the tests do provide some assurance, I think those two pulls
require more review.

After they are merged, a 0.10.3 and 0.11.1 release can be rolled out (with RC
cycle).

> We also don't need to wait for other soft-fork proposals to
> catch up - starting the CLTV deployment process isn't going to delay
> future soft-forks, or for that matter, hard-forks.
> 
> I think it's possible to safely get CLTV live on mainnet before the end
> of the year. It's time we get this over with and done.

Wladimir

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Bitcoin Core 0.12.0 release schedule

[Wladimir J. van der Laan via bitcoin-dev]

Hello all,

The next major release of Bitcoin Core, 0.12.0 is planned for the end of the 
year. Let's propose a more detailed schedule:

2015-11-01
---
- Open Transifex translations for 0.12
- Soft translation string freeze (no large or unnecessary changes)
- Finalize and close translation for 0.10

2015-12-01
---
- Feature freeze
- Translation string freeze

In December at least I will probably not get much done code-wise (Scaling 
Bitcoin Hongkong, 32C3, end of year festivities, etc), and I'm sure I'm not the 
only one, so let's leave that for last pre-RC bugfixes and polishing.

2016-01-06
---
- Split off `0.12` branch from `master`
- Start RC cycle, tag and release `0.12.0rc1`
- Start merging for 0.13 on master branch

2016-02-01
---
- Release 0.12.0 final (aim)

Wladimir


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Weekly development meetings on IRC

[Wladimir J. van der Laan via bitcoin-dev]

On Fri, Sep 18, 2015 at 03:07:10AM +0200, Wladimir J. van der Laan wrote:
> Hello,
> 
> At Monday's code sprint we had a good idea to schedule a regular developer 
> meeting in #bitcoin-dev.
> 
> Attendance is of course voluntary, but it may be good to have a time that 
> many people are expected to be present and current issues can be discussed.
> 
> Any preference for days/times?
> 
> What about e.g. every week 15:00-16:00 UTC on Thursday?

>From Jonasschnelli's doodle ( http://doodle.com/poll/cihug53sa8u4h2in#table ) 
>it appears that Thursday 19:00 UTC - 20:00 UTC is the most popular time.

I think scheduling the meeting in UTC (=Iceland time) makes sense 
internationally because different locales have different DST or no DST at all, 
so all in all that makes it more complex. It's true that this can make a 
convenient time less convenient half of the year, for some people, but I don't 
think there's a time that works for everyone anyway...

Wladimir
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Weekly development meetings on IRC: schedule

[Wladimir J. van der Laan via bitcoin-dev]

Hello,

There was overwhelming response that weekly IRC meetings are a good thing.

Thanks to the doodle site we were able to select a time slot that everyone 
(that voted) is available:

Thursday 19:00-20:00 UTC, every week, starting September 24 (next Thursday)

I created a shared Google Calendar here:
https://www.google.com/calendar/embed?src=MTFwcXZkZ3BkOTlubGliZjliYTg2MXZ1OHNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ

The timezone of this calendar is Reykyavik (Iceland) which is UTC+0. However, 
you can use the button on the lower right to add the calendar to your own 
calendar, which will then show the meeting in your own timezone.

See you then,

Wladimir

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Weekly development meetings on IRC

[Wladimir J. van der Laan via bitcoin-dev]

On Mon, Sep 21, 2015 at 03:51:29PM +0200, gb wrote:
> 
> Although the planning for this a bit far along now, one consideration I
> might add from experience on working with other transglobal IT projects

Nah, we can always change the scheduling later... But let's first try it out 
with one time.

W
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

[Wladimir J. van der Laan via bitcoin-dev]

On Mon, Dec 07, 2015 at 10:02:17PM +, Gregory Maxwell via bitcoin-dev wrote:
> The Scaling Bitcoin Workshop in HK is just wrapping up. Many fascinating
> proposals were presented. I think this would be a good time to share my
> view of the near term arc for capacity increases in the Bitcoin system. I
> believe we’re in a fantastic place right now and that the community
> is ready to deliver on a clear forward path with a shared vision that
> addresses the needs of the system while upholding its values.

Thanks for writing this up. Putting the progress, ongoing work and plans related
to scaling in context, in one place, was badly needed.

> TL;DR:  I propose we work immediately towards the segwit 4MB block
> soft-fork which increases capacity and scalability, and recent speedups
> and incoming relay improvements make segwit a reasonable risk. BIP9
> and segwit will also make further improvements easier and faster to
> deploy. We’ll continue to set the stage for non-bandwidth-increase-based
> scaling, while building additional tools that would make bandwidth
> increases safer long term. Further work will prepare Bitcoin for further
> increases, which will become possible when justified, while also providing
> the groundwork to make them justifiable.

Sounds good to me.

There are multiple ways to get involved in ongoing work, where the community
can help to make this happen sooner:

- Review the versionbits BIP 
https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki:

  - Compare and test with implementation: 
https://github.com/bitcoin/bitcoin/pull/6816

- Review CSV BIPs (BIP68 
https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki / 
   BIP112 https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki),

  - Compare and test implementation: 

https://github.com/bitcoin/bitcoin/pull/6564  BIP-112: Mempool-only 
CHECKSEQUENCEVERIFY
https://github.com/bitcoin/bitcoin/pull/6312  BIP-68: Mempool-only sequence 
number constraint verification 
https://github.com/bitcoin/bitcoin/pull/7184  [WIP] Implement SequenceLocks 
functions for BIP 68

- Segwit BIP is being written, but has not yet been published.

  - Gregory linked to an implementation but as he mentions it is not completely
finished yet. ETA for a Segwit testnet is later this month, then you can 
test as well.

Wladimir
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Weekly developer meetings over holidays

[Wladimir J. van der Laan via bitcoin-dev]

Next two weekly developer meetings would fall on:

- Thursday December 24th
- Thursday December 31th

In my timezone they're xmas eve and new year's eve respectively, so at least I
won't be there, and I'm sure they're inconvenient for most people.

So: let's have a two week hiatus, and continue January 7th.

Wladimir
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core 0.12.0 release candidate 1 available

[Wladimir J. van der Laan via bitcoin-dev]

On Sun, Jan 17, 2016 at 11:57:28PM +0100, xor--- via bitcoin-dev wrote:
> On Sunday, January 17, 2016 11:08:08 AM Wladimir J. van der Laan via bitcoin-
> dev wrote:
> > Preliminary release notes for the release can be found here:
> > 
> > https://github.com/bitcoin/bitcoin/blob/0.12/doc/release-notes.md
> 
> 
> The part which lists raw Git pull requests says:
> > #6057 ac5476e re-enable wallet in autoprune
> 
> But the main, handwritten part does not mention this.
> Is pruning really finished, i.e. could I safely use it as a wallet "end-user"?

It has been tested in git for almost half a year. This RC is the first binary
release that contains the functionality.

It is extremely unlikely that the wallet will eat your coins (always backup
nevertheless), but I can't guarantee there won't be some issue where the wallet
and chain get out of sync and you're forced to redownload the blockchain.

> IMHO it would be one of the most interesting feature for users, as it could 
> fix the issue of taking >60 GB of disk space.
> 
> So if it is finished, please mention that
> - it's finished
> - how to enable it.

How to enable it is still the same as mentioned in the 0.11 release notes:
https://github.com/bitcoin/bitcoin/blob/v0.11.0/doc/release-notes.md#block-file-pruning

Wladimir
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Bitcoin Core 0.12.0 release candidate 1 available

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Binaries for bitcoin Core version 0.12.0rc1 are available from:

https://bitcoin.org/bin/bitcoin-core-0.12.0/test/

Source code can be found on github under the signed tag

https://github.com/bitcoin/bitcoin/tree/v0.12.0rc1

This is a release candidate for a new major version release, bringing new
features, bug fixes, as well as other improvements.

Preliminary release notes for the release can be found here:

https://github.com/bitcoin/bitcoin/blob/0.12/doc/release-notes.md

Release candidates are test versions for releases. When no critical problems
are found, this release candidate will be tagged as 0.12.0.

Please report bugs using the issue tracker at github:

https://github.com/bitcoin/bitcoin/issues

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCgAGBQJWm2fGAAoJEHSBCwEjRsmm274H/2BH3QD4AlJ87mQ8g6bzzv7h
S8m/EEDmpOuMgM6uF5PzWQ84yNfSyMItq7Y3cU8p9Fv+JD6ic1ZQPPQ0MQc3KtDx
EeF3wQ2iJe/ggBFcwrz0eIxfEOEo1mi5ooWMVSsnCKQU0IpMtq7ToMvhi/39ACnj
GsVRBJYlFoRCBh1LKkcyID7Fh7JstMgMrLEcrCy46T9h2EQEevlLydkwY26ENYUO
BasWXMaysdeKieO5S6tM6MD/50Bd19jHvjzvkeRY5+nZIdrNR1b5n7diCLEUa7b4
79oIqjdKF+4ns5Qgc+iVhIktthRyrHLrWxX7N8Ky+hSVj1OAKFZfdp4skgAzQUE=
=oVOV
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Bitcoin Core 0.12.0 release candidate 3 available

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Binaries for bitcoin Core version 0.12.0rc3 are available from:

https://bitcoin.org/bin/bitcoin-core-0.12.0/test/

Source code can be found on github under the signed tag

https://github.com/bitcoin/bitcoin/tree/v0.12.0rc3

This is a release candidate for a new major version release, bringing new
features, bug fixes, as well as other improvements.

Preliminary release notes for the release can be found here:

https://github.com/bitcoin/bitcoin/blob/0.12/doc/release-notes.md

Release candidates are test versions for releases. When no critical problems
are found, this release candidate will be tagged as 0.12.0.

Diff since rc2:
- - #7440 `c76bfff` Rename permitrbf to mempoolreplacement and provide minimal 
string-list forward compatibility
- - #7415 `cb83beb` net: Hardcoded seeds update January 2016
- - #7438 `e2d9a58` Do not absolutely protect local peers; decide group ties 
based on time
- - #7439 `86755bc` Add whitelistforcerelay to control forced relaying. [#7099 
redux]
- - #7424 `aa26ee0` Add security/export checks to gitian and fix current 
failures
- - #7384 `294f432` [qt] Peertable: Increase SUBVERSION_COLUMN_WIDTH

Also, a new certificate was used to sign the Windows installer, which should 
solve
Win7 compatibility issues.

Thanks to the gitian builders for keeping up so quickly, thanks
to them there are executables so quickly after tagging.

Please report bugs using the issue tracker at github:

https://github.com/bitcoin/bitcoin/issues

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCgAGBQJWtIe6AAoJEHSBCwEjRsmmuX0IAJP7JJ4OozZZ5psY7QF35ouV
E0Vxws470pFyn+iFvz1OwLbeSyhIiLvR1xHZCrFkLbt5vrolJGILQb5xWaFfqDVv
uXIPDzbQ+mJ/cPr2BXWrkjkVC33TBuwiLGethDDb4xlQhSki79EvZqbTkhIz7HxX
jrW8d+zUq+2pOilhqDyZGlzCRhQOZI6W+TFwo4jEunZN+m1BSD2/vhVxIZQzP6jf
Vt6xw23SFbTH+b9dY3Skho/A+gdXSitVpYmDttbOlcIX4AQ7lUmsaqFeaV4z92d+
YqipqLiNkGqXdEYFikyQgM24J4fYm4htZhTBg5y5W8tsIWO6z36tUXVBxmqq6A0=
=mevA
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What is OpenSSL still used for?

[Wladimir J. van der Laan via bitcoin-dev]

> > In the release notes for 0.12, it says that we have moved from
> > using OpenSSL to libsecp256k1 for signature validation. So what
> > else is it being used for that we need to keep it as a dependency?
> 
> Openssl was dropped from the consensus layer (ECC) in 0.12, though, it
> still used for...
> 
> 1) ... getting random numbers (randomize the ECC signing context)
> 2) [wallet only] ... AES256 encryption of private keys
> 3) [GUI only] ... SSL/X.509 for BIP70 (payment protocol)
> 
> Openssl dependency for 1) and 2) could be removed. There are some –
> outdated – relevant PRs:
> 
> Entropy: https://github.com/bitcoin/bitcoin/pull/5885
> AES: https://github.com/bitcoin/bitcoin/pull/5949
> 
> I guess for point 3) [BIP70] it makes sense to keep openssl.

Exactly - the plan is that OpenSSL will, in due time, be a dependency only if 
the
GUI is enabled. Most of the work for that is already done but it has to be made
up to date and carefully tested and integrated.

Wladimir
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core 0.12.0 release candidate 1 available

[Wladimir J. van der Laan via bitcoin-dev]

> 
> So I'm interested whether this limitation has been lifted, and the whole 
> feature is considered as finished.

Yes, it's exactly that limitation that has been lifted!

> If yes, I would highly recommend advertising it in the new release notes - as 
> said, the disk space reduction is a big deal.

Good idea, has been added by Marco Falke in commit fa31133,

Wladimir
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Bitcoin Core 0.12.0 release candidate 2 available

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Binaries for bitcoin Core version 0.12.0rc2 are available from:

https://bitcoin.org/bin/bitcoin-core-0.12.0/test/

Source code can be found on github under the signed tag

https://github.com/bitcoin/bitcoin/tree/v0.12.0rc2

This is a release candidate for a new major version release, bringing new
features, bug fixes, as well as other improvements.

Preliminary release notes for the release can be found here:

https://github.com/bitcoin/bitcoin/blob/0.12/doc/release-notes.md

Release candidates are test versions for releases. When no critical problems
are found, this release candidate will be tagged as 0.12.0.

Diff since rc1:
- - #7222 `e25b158` RPC: indicate which transactions are replaceable
- - #7386 `da83ecd` Add option `-permitrbf` to set transaction replacement 
policy
- - #7290 `b16b5bc` Add missing options help
- - #7387 `f4b2ce8` Get rid of inaccurate ScriptSigArgsExpected
- - #7381 `621bbd8` [walletdb] Fix syntax error in key parser
- - #7327 `b16b5bc` [Wallet] Transaction View: LastMonth calculation fixed
- - #7364 `7726c48` [qt] Windows: Make rpcconsole monospace font larger

Please report bugs using the issue tracker at github:

https://github.com/bitcoin/bitcoin/issues

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCgAGBQJWphBHAAoJEHSBCwEjRsmmh0EIALopACCwaCYRt9vl6fadDLxL
JMTyEPsGUaEX82iwuXeAhdReyvZDlC00ACZy6agp7oOuS1ryqOeYAsc33N+WtHE0
iETNyvRZVD1ASopHkdJrRW1a9X63Yvcvk/d6nVbO5auUAG5gPUFLrSTrqpSzR2D4
QtY1ofifXrYdqdQmPFJ5hnWg/Z1rko99sD8Pu3ebD6Dof5zuvJKHkLmXunGGXn/n
GOn8roS5LXEFHwCcL0zgNzfDywt/dhKiUHMKSNPsnz5qEDRg7WPzsNiQA/HVDlcp
v6akQ4ykZ56Lik8cVLi0NRW2dozSDti/XKBfWQHqWjGUJGUOS+lPJaWLv81oMwc=
=WlQm
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Bitcoin Core 0.12.0 release candidate 5 available

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Binaries for bitcoin Core version 0.12.0rc5 are available from:

https://bitcoin.org/bin/bitcoin-core-0.12.0/test/

Source code can be found on github under the signed tag

https://github.com/bitcoin/bitcoin/tree/v0.12.0rc5

This is a release candidate for a new major version release, bringing new
features, bug fixes, as well as other improvements.

Preliminary release notes for the release can be found here:

https://github.com/bitcoin/bitcoin/blob/0.12/doc/release-notes.md

Release candidates are test versions for releases. When no critical problems
are found, this release candidate will be tagged as 0.12.0.

Diff since rc3 (rc4 was DOA):

- - #7472 `b2f2b85` rpc: Add WWW-Authenticate header to 401 response (Wladimir 
J. van der Laan)
- - #7469 `9cb31e6` net.h fix spelling: misbeha{b,v}ing (Matt)
- - #7482 `e16f5b4` Ensure headers count is correct (Suhas Daftuar)
- - #7500 `889e5b3` Correctly report high-S violations (Pieter Wuille)
- - #7491 `00ec73e` wallet: Ignore MarkConflict if block hash is not known 
(Wladimir J. van der Laan)
- - #7502 `1329963` Update the wallet best block marker before pruning (Pieter 
Wuille)
- - #7468 `947c4ff` [rpc-tests] Change solve() to use rehash (Brad Andrews)

Please report bugs using the issue tracker at github:

https://github.com/bitcoin/bitcoin/issues

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCgAGBQJWwbHqAAoJEHSBCwEjRsmmVJwH/3gvb5LAAL88R7ZbcKAzehdc
BnAmCTWX+mJENWq9MX3OWmddetbZSBU0x9MzV6atQHMTmcxmMkCIzZrysoSq3uDg
1IylViVPSr+36PPv2k1/chTun0yRWUGwLEz09JZscFILa0oJODvDISiOp0NEkDup
bewkpkrpzxroAqlTFNuSUl9KDCQPXUGvqCDH7RwHC3D8L8apVIT6bE8FHW8je278
Qjf3Z5AehXVzOyrhg02tT0Ow3EueKtNDASmopX+aM70ErzUbxe8/mYP3GAsQwbMi
WVdx7dvUdQQkNDIWGLH/V0AJlkbxDfBmAI0Ti2J9LxtbCOZdGAzId2aPpEOrfnU=
=UUfq
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] IRC meetings moved to #bitcoin-core-dev

[Wladimir J. van der Laan via bitcoin-dev]

It seems that MeetingBot was deactivated in #bitcoin-dev, so the
last two weeks the weekly developer meeting (Thursday 19:00-20:00 UTC)
was held in #bitcoin-core-dev.

Let's keep it at that.

Wladimir

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Proposed release schedule 0.13.0

[Wladimir J. van der Laan via bitcoin-dev]

Proposed release schedule for 0.13.0:

2015-05-01
---
- Open Transifex translations for 0.13
- Soft translation string freeze (no large or unnecessary string changes until 
release)
- Finalize and close translations for 0.11

2015-05-15
---
- Feature freeze (bug fixes only until release)
- Translation string freeze (no more source language changes until release)

2016-06-06
---
- Split off `0.13` branch from `master`
- Start RC cycle, tag and release `0.13.0rc1`
- Start merging for 0.14 on master branch

2016-07-01
---
- Release 0.13.0 final (aim)

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Bitcoin Core 0.12.1 released

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version 0.12.1 is now available from:

  

Or through bittorrent:

  
magnet:?xt=urn:btih:25c4df2a822e840e972a50a31095632d87efadab=bitcoin-core-0.12.1=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969=https%3A%2F%2Fbitcoin.org%2Fbin%2F
 

This is a new minor version release, including the BIP9, BIP68 and BIP112
softfork, various bugfixes and updated translations.

Please report bugs using the issue tracker at github:

  

To receive security and update notifications, please subscribe to
https://bitcoincore.org/en/list/announcements/join/.

Upgrading and downgrading
=

How to Upgrade
- --

If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or
bitcoind/bitcoin-qt (on Linux).

Downgrade warning
- -

### Downgrade to a version < 0.12.0

Because release 0.12.0 and later will obfuscate the chainstate on every
fresh sync or reindex, the chainstate is not backwards-compatible with
pre-0.12 versions of Bitcoin Core or other software.

If you want to downgrade after you have done a reindex with 0.12.0 or later,
you will need to reindex when you first start Bitcoin Core version 0.11 or
earlier.

Notable changes
===

First version bits BIP9 softfork deployment
- ---

This release includes a soft fork deployment to enforce [BIP68][],
[BIP112][] and [BIP113][] using the [BIP9][] deployment mechanism.

The deployment sets the block version number to 0x2001 between
midnight 1st May 2016 and midnight 1st May 2017 to signal readiness for 
deployment. The version number consists of 0x2000 to indicate version
bits together with setting bit 0 to indicate support for this combined
deployment, shown as "csv" in the `getblockchaininfo` RPC call.

For more information about the soft forking change, please see


This specific backport pull-request can be viewed at


[BIP9]: https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
[BIP68]: https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
[BIP112]: https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki
[BIP113]: https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki

BIP68 soft fork to enforce sequence locks for relative locktime
- ---

[BIP68][] introduces relative lock-time consensus-enforced semantics of
the sequence number field to enable a signed transaction input to remain
invalid for a defined period of time after confirmation of its corresponding
outpoint.

For more information about the implementation, see


BIP112 soft fork to enforce OP_CHECKSEQUENCEVERIFY
- --

[BIP112][] redefines the existing OP_NOP3 as OP_CHECKSEQUENCEVERIFY (CSV)
for a new opcode in the Bitcoin scripting system that in combination with
[BIP68][] allows execution pathways of a script to be restricted based
on the age of the output being spent.

For more information about the implementation, see


BIP113 locktime enforcement soft fork
- -

Bitcoin Core 0.11.2 previously introduced mempool-only locktime
enforcement using GetMedianTimePast(). This release seeks to
consensus enforce the rule.

Bitcoin transactions currently may specify a locktime indicating when
they may be added to a valid block.  Current consensus rules require
that blocks have a block header time greater than the locktime specified
in any transaction in that block.

Miners get to choose what time they use for their header time, with the
consensus rule being that no node will accept a block whose time is more
than two hours in the future.  This creates a incentive for miners to
set their header times to future values in order to include locktimed
transactions which weren't supposed to be included for up to two more
hours.

The consensus rules also specify that valid blocks may have a header
time greater than that of the median of the 11 previous blocks.  This
GetMedianTimePast() time has a key feature we generally associate with
time: it can't go backwards.

[BIP113][] specifies a soft fork enforced in this release that
weakens this perverse incentive for individual miners to use a future
time by requiring that valid blocks have a computed GetMedianTimePast()

[bitcoin-dev] Bitcoin Core 0.13.0 release candidate 2 available

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Binaries for bitcoin Core version 0.13.0rc2 are available from:

https://bitcoin.org/bin/bitcoin-core-0.13.0/test.rc2/

Source code can be found on github under the signed tag

https://github.com/bitcoin/bitcoin/tree/v0.13.0rc2

This is a release candidate for a new major version release, bringing new
features, bug fixes, as well as other improvements.

Preliminary release notes for the release can be found at

https://github.com/bitcoin/bitcoin/blob/0.13/doc/release-notes.md

Release candidates are test versions for releases. When no critical problems
are found, this release candidate will be tagged as 0.13.0.

Please report bugs using the issue tracker at github:

https://github.com/bitcoin/bitcoin/issues

Notable changes since rc1:

### Build system
- - #8373 `1fe7f40` Fix OSX non-deterministic dmg (theuni)
- - #8358 `cfd1280` Gbuild: Set memory explicitly (default is too low) 
(MarcoFalke)

### GUI
- - #8407 `45eba4b` Add dbcache migration path (jonasschnelli)

### Wallet
- - #8378 `ebea651` Move SetMinVersion for FEATURE_HD to SetHDMasterKey 
(pstratem)
- - #8390 `73adfe3` Correct hdmasterkeyid/masterkeyid name confusion 
(jonasschnelli)
- - #8206 `18b8ee1` Add HD xpriv to dumpwallet (jonasschnelli)
- - #8389 `c3c82c4` Create a new HD seed after encrypting the wallet 
(jonasschnelli)

### P2P protocol and network code
- - #8408 `b7e2011` Prevent fingerprinting, disk-DoS with compact blocks 
(sdaftuar)

### Consensus
- - #8412 `8360d5b` libconsensus: Expose a flag for BIP112 (jtimon)

### Mining
- - #8362 `86edc20` Scale legacy sigop count in CreateNewBlock (sdaftuar)

### Block and transaction handling
- - #8381 `f84ee3d` Make witness v0 outputs non-standard (jl2012)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCgAGBQJXngBiAAoJEHSBCwEjRsmmS5kIAMFiXFua9ruR8Vwu1fNgnWTb
X4tsNOdPScm7jwsFavcwygqZQlDNDURjcocQFcehHgEickBrk6eaplTuB4VJidPG
Aqw+nLrd6M//Ohy+7eke7aCg5/QV7poplM3glwow4gQfoSBvL0ywMEhWEzGL7EPH
FH5pyY9o4QZw5wGdvMWxvYVTLPZkm0W2cSWCHZ0WgzWvTkZ7aMzSQ5F5TXPfjzED
DNuQQRMm9H1H3LJkmWAwjCXLzKNMzjmefLujyEII388s6UoWnA1ufosqb1kMqL+h
kuEelzef4cMBZEvHgfzsvlLmba2DLr7xhwudd3HK2NHSmO/wAUdhbQOQSts9NoY=
=rN68
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Bitcoin Core 0.13.0 release candidate 3 available

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Binaries for bitcoin Core version 0.13.0rc3 are available from:

https://bitcoin.org/bin/bitcoin-core-0.13.0/test.rc3/

Source code can be found on github under the signed tag

https://github.com/bitcoin/bitcoin/tree/v0.13.0rc3

This is a release candidate for a new major version release, bringing new
features, bug fixes, as well as other improvements.

Preliminary release notes for the release can be found at

https://github.com/bitcoin/bitcoin/blob/0.13/doc/release-notes.md

Release candidates are test versions for releases. When no critical problems
are found, this release candidate will be tagged as 0.13.0.

Please report bugs using the issue tracker at github:

https://github.com/bitcoin/bitcoin/issues

Notable changes since rc2:

### Block and transaction handling

- - #8364 `3f65ba2` Treat high-sigop transactions as larger rather than 
rejecting them (sipa)

### Tests and QA

- - #8444 `cd0910b` Fix p2p-feefilter.py for changed tx relay behavior 
(sdaftuar)

### Mining

- - #8489 `8b0eee6` Bugfix: Use pre-BIP141 sigops until segwit activates (GBT) 
(luke-jr)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCgAGBQJXrsS5AAoJEHSBCwEjRsmmH1oH/3PKk2rJIgMhsf4a8fuGJD7H
+j+ugsdRpjRGK8XKgnCisLQ8UJc2Z7dRbRYfdUb1ibkkCccMQJdmS6JAahWTe+Hb
N8GbODwZ5m4LrP2PA1gqNE/pwix/pqBY4GfR+TxXEbegNUNYDkvUzeUidcYGMAZd
LEAFrVnvsTAOQiwK3/pwa+sdWVNc0Jx/hHSZhouUtFmaqjXdg5M8ShmnRjyhVovI
GeuJ2s/3+uMtIX0g+kIOv16e0qYHJtIJMexMV5x4x1oWpXMYi2YeVDFSAkcKxA/z
5JOqlhDBK2lVMOKw8kYcNXKpvhXg9UBKImJDS0S4Bye8nMLQC6VEnkscOd7bupU=
=ae21
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Bitcoin Core 0.13.0 released

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version 0.13.0 is now available from:

  

Or through bittorrent:

  
magnet:?xt=urn:btih:35367ed2db6c41f7af9c1ed2dd54ae29d99bc632=bitcoin-core-0.13.0=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969=https%3A%2F%2Fbitcoin.org%2Fbin%2F

This is a new major version release, including new features, various bugfixes
and performance improvements, as well as updated translations.

Please report bugs using the issue tracker at github:

  

To receive security and update notifications, please subscribe to:

  

Compatibility
==

Microsoft ended support for Windows XP on [April 8th, 
2014](https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support),
an OS initially released in 2001. This means that not even critical security
updates will be released anymore. Without security updates, using a bitcoin
wallet on a XP machine is irresponsible at least.

In addition to that, with 0.12.x there have been varied reports of Bitcoin Core
randomly crashing on Windows XP. It is [not 
clear](https://github.com/bitcoin/bitcoin/issues/7681#issuecomment-217439891)
what the source of these crashes is, but it is likely that upstream
libraries such as Qt are no longer being tested on XP.

We do not have time nor resources to provide support for an OS that is
end-of-life. From 0.13.0 on, Windows XP is no longer supported. Users are
suggested to upgrade to a newer verion of Windows, or install an alternative OS
that is supported.

No attempt is made to prevent installing or running the software on Windows XP,
you can still do so at your own risk, but do not expect it to work: do not
report issues about Windows XP to the issue tracker.

Notable changes
===

Database cache memory increased
- 

As a result of growth of the UTXO set, performance with the prior default
database cache of 100 MiB has suffered.
For this reason the default was changed to 300 MiB in this release.

For nodes on low-memory systems, the database cache can be changed back to
100 MiB (or to another value) by either:

- - Adding `dbcache=100` in bitcoin.conf
- - Changing it in the GUI under `Options → Size of database cache`

Note that the database cache setting has the most performance impact
during initial sync of a node, and when catching up after downtime.


bitcoin-cli: arguments privacy
- --

The RPC command line client gained a new argument, `-stdin`
to read extra arguments from standard input, one per line until EOF/Ctrl-D.
For example:

$ src/bitcoin-cli -stdin walletpassphrase
mysecretcode
120
. press Ctrl-D here to end input
$

It is recommended to use this for sensitive information such as wallet
passphrases, as command-line arguments can usually be read from the process
table by any user on the system.


C++11 and Python 3
- --

Various code modernizations have been done. The Bitcoin Core code base has
started using C++11. This means that a C++11-capable compiler is now needed for
building. Effectively this means GCC 4.7 or higher, or Clang 3.3 or higher.

When cross-compiling for a target that doesn't have C++11 libraries, configure 
with
`./configure --enable-glibc-back-compat ... LDFLAGS=-static-libstdc++`.

For running the functional tests in `qa/rpc-tests`, Python3.4 or higher is now
required.


Linux ARM builds
- 

Due to popular request, Linux ARM builds have been added to the uploaded
executables.

The following extra files can be found in the download directory or torrent:

- - `bitcoin-${VERSION}-arm-linux-gnueabihf.tar.gz`: Linux binaries for the most
  common 32-bit ARM architecture.
- - `bitcoin-${VERSION}-aarch64-linux-gnu.tar.gz`: Linux binaries for the most
  common 64-bit ARM architecture.

ARM builds are still experimental. If you have problems on a certain device or
Linux distribution combination please report them on the bug tracker, it may be
possible to resolve them.

Note that Android is not considered ARM Linux in this context. The executables
are not expected to work out of the box on Android.


Compact Block support (BIP 152)
- ---

Support for block relay using the Compact Blocks protocol has been implemented
in PR 8068.

The primary goal is reducing the bandwidth spikes at relay time, though in many
cases it also reduces propagation delay. It is automatically enabled between
compatible peers.
[BIP 152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki)

As a side-effect, ordinary non-mining nodes will download and upload blocks
faster if those blocks 

Re: [bitcoin-dev] Completing the retirement of the alert system

[Wladimir J. van der Laan via bitcoin-dev]

On Sat, Sep 10, 2016 at 12:42:30AM +, Gregory Maxwell via bitcoin-dev wrote:
> The alert system was a centralized facility to allow trusted parties
> to send messages to be displayed in wallet software (and, very early
> on, actually remotely trigger the software to stop transacting).
> 
> It has been removed completely in Bitcoin Core after being disabled for a 
> while.

As it has been disabled in relevant software I think it's mostly symbolic at
this point, but yes, it makes sense to 'officially' retire the key. Let's
pin the date and make it widely known.

Doing this in organized fashion is much better than the whodunit that would
undoubtly follow when the key would simply leak, which could happen at any
time, as no one can know who it has spread to over all those years.

Re: timing, I'd say leave three months grace time after this announcement for
altcoins and such that may have accidentally have copied it to remove it, then
at the beginning of 2017 broadcast the final alert.

After that it's neutered, it's up to each of us that has the key to reveal it
or not or when. It's a historical curiosity then.

Wladimir
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Bitcoin Core 0.13.2 released

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version 0.13.2 is now available from:

  

Or by bittorrent:

  
magnet:?xt=urn:btih:746697d03db3ff531158b1133bab5d1e4cef4e5a=bitcoin-core-0.13.2=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969=https%3A%2F%2Fbitcoin.org%2Fbin%2F

This is a new minor version release, including various bugfixes and
performance improvements, as well as updated translations.

Please report bugs using the issue tracker at github:

  

To receive security and update notifications, please subscribe to:

  

Compatibility
==

Microsoft ended support for Windows XP on [April 8th, 
2014](https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support),
an OS initially released in 2001. This means that not even critical security
updates will be released anymore. Without security updates, using a bitcoin
wallet on a XP machine is irresponsible at least.

In addition to that, with 0.12.x there have been varied reports of Bitcoin Core
randomly crashing on Windows XP. It is [not 
clear](https://github.com/bitcoin/bitcoin/issues/7681#issuecomment-217439891)
what the source of these crashes is, but it is likely that upstream
libraries such as Qt are no longer being tested on XP.

We do not have time nor resources to provide support for an OS that is
end-of-life. From 0.13.0 on, Windows XP is no longer supported. Users are
suggested to upgrade to a newer version of Windows, or install an alternative OS
that is supported.

No attempt is made to prevent installing or running the software on Windows XP,
you can still do so at your own risk, but do not expect it to work: do not
report issues about Windows XP to the issue tracker.

- From 0.13.1 onwards OS X 10.7 is no longer supported. 0.13.0 was intended to 
work on 10.7+, 
but severe issues with the libc++ version on 10.7.x keep it from running 
reliably. 
0.13.1 now requires 10.8+, and will communicate that to 10.7 users, rather than 
crashing unexpectedly.

Notable changes
===

Change to wallet handling of mempool rejection
- ---

When a newly created transaction failed to enter the mempool due to
the limits on chains of unconfirmed transactions the sending RPC
calls would return an error.  The transaction would still be queued
in the wallet and, once some of the parent transactions were
confirmed, broadcast after the software was restarted.

This behavior has been changed to return success and to reattempt
mempool insertion at the same time transaction rebroadcast is
attempted, avoiding a need for a restart.

Transactions in the wallet which cannot be accepted into the mempool
can be abandoned with the previously existing abandontransaction RPC
(or in the GUI via a context menu on the transaction).


0.13.2 Change log
=

Detailed release notes follow. This overview includes changes that affect
behavior, not code moves, refactors and string updates. For convenience in 
locating
the code changes and accompanying discussion, both the pull request and
git merge commit are mentioned.

### Consensus
- - #9293 `e591c10` [0.13 Backport #9053] IBD using chainwork instead of height 
and not using header timestamp (gmaxwell)
- - #9053 `5b93eee` IBD using chainwork instead of height and not using header 
timestamps (gmaxwell)

### RPC and other APIs
- - #8845 `1d048b9` Don't return the address of a P2SH of a P2SH (jnewbery)
- - #9041 `87fbced` keypoololdest denote Unix epoch, not GMT (s-matthew-english)
- - #9122 `f82c81b` fix getnettotals RPC description about timemillis 
(visvirial)
- - #9042 `5bcb05d` [rpc] ParseHash: Fail when length is not 64 (MarcoFalke)
- - #9194 `f26dab7` Add option to return non-segwit serialization via rpc 
(instagibbs)
- - #9347 `b711390` [0.13.2] wallet/rpc backports (MarcoFalke)
- - #9292 `c365556` Complain when unknown rpcserialversion is specified (sipa)
- - #9322 `49a612f` [qa] Don't set unknown rpcserialversion (MarcoFalke)

### Block and transaction handling
- - #8357 `ce0d817` [mempool] Fix relaypriority calculation error (maiiz)
- - #9267 `0a4aa87` [0.13 backport #9239] Disable fee estimates for a confirm 
target of 1 block (morcos)
- - #9196 `0c09d9f` Send tip change notification from invalidateblock 
(ryanofsky)

### P2P protocol and network code
- - #8995 `9ef3875` Add missing cs_main lock to ::GETBLOCKTXN processing 
(TheBlueMatt)
- - #9234 `94531b5` torcontrol: Explicitly request RSA1024 private key (laanwj)
- - #8637 `2cad5db` Compact Block Tweaks (rebase of #8235) (sipa)
- - #9058 `286e548` Fixes for p2p-compactblocks.py test timeouts on travis 
(#8842) (ryanofsky)
- - #8865 

[bitcoin-dev] Bitcoin Core 0.14.1 released

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version 0.14.1 is now available from:

  

Or, by torrent:

  
magnet:?xt=urn:btih:0482be8fc8e1c0b02162871e3591efc3d1d34585=bitcoin-core-0.14.1=udp%3A%2F%2Fpublic.popcorn-tracker.org%3A6969%2Fannounce=http%3A%2F%2Fatrack.pow7.com%2Fannounce=http%3A%2F%2Fbt.henbt.com%3A2710%2Fannounce=http%3A%2F%2Fmgtracker.org%3A6969%2Fannounce=http%3A%2F%2Fopen.touki.ru%2Fannounce.php=http%3A%2F%2Fp4p.arenabg.ch%3A1337%2Fannounce=http%3A%2F%2Fpow7.com%3A80%2Fannounce=http%3A%2F%2Ftracker.dutchtracking.nl%3A80%2Fannounce

This is a new minor version release, including various bugfixes and
performance improvements, as well as updated translations.

Please report bugs using the issue tracker at github:

  

To receive security and update notifications, please subscribe to:

  

Compatibility
==

Bitcoin Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.8+, and Windows Vista and later.

Microsoft ended support for Windows XP on [April 8th, 
2014](https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support),
No attempt is made to prevent installing or running the software on Windows XP, 
you
can still do so at your own risk but be aware that there are known 
instabilities and issues.
Please do not report issues about Windows XP to the issue tracker.

Bitcoin Core should also work on most other Unix-like systems but is not
frequently tested on them.

Notable changes
===

RPC changes
- ---

- - The first positional argument of `createrawtransaction` was renamed from
  `transactions` to `inputs`.

- - The argument of `disconnectnode` was renamed from `node` to `address`.

These interface changes break compatibility with 0.14.0, when the named
arguments functionality, introduced in 0.14.0, is used. Client software
using these calls with named arguments needs to be updated.

Mining
- --

In previous versions, getblocktemplate required segwit support from downstream
clients/miners once the feature activated on the network. In this version, it
now supports non-segwit clients even after activation, by removing all segwit
transactions from the returned block template. This allows non-segwit miners to
continue functioning correctly even after segwit has activated.

Due to the limitations in previous versions, getblocktemplate also recommended
non-segwit clients to not signal for the segwit version-bit. Since this is no
longer an issue, getblocktemplate now always recommends signalling segwit for
all miners. This is safe because ability to enforce the rule is the only
required criteria for safe activation, not actually producing segwit-enabled
blocks.

UTXO memory accounting
- --

Memory usage for the UTXO cache is being calculated more accurately, so that
the configured limit (`-dbcache`) will be respected when memory usage peaks
during cache flushes.  The memory accounting in prior releases is estimated to
only account for half the actual peak utilization.

The default `-dbcache` has also been changed in this release to 450MiB.  Users
who currently set `-dbcache` to a high value (e.g. to keep the UTXO more fully
cached in memory) should consider increasing this setting in order to achieve
the same cache performance as prior releases.  Users on low-memory systems
(such as systems with 1GB or less) should consider specifying a lower value for
this parameter.

Additional information relating to running on low-memory systems can be found
here:
[reducing-bitcoind-memory-usage.md](https://gist.github.com/laanwj/efe29c7661ce9b6620a7).

0.14.1 Change log
=

Detailed release notes follow. This overview includes changes that affect
behavior, not code moves, refactors and string updates. For convenience in 
locating
the code changes and accompanying discussion, both the pull request and
git merge commit are mentioned.

### RPC and other APIs
- - #10084 `142fbb2` Rename first named arg of createrawtransaction (MarcoFalke)
- - #10139 `f15268d` Remove auth cookie on shutdown (practicalswift)
- - #10146 `2fea10a` Better error handling for submitblock (rawodb, gmaxwell)
- - #10144 `d947afc` Prioritisetransaction wasn't always updating ancestor fee 
(sdaftuar)
- - #10204 `3c79602` Rename disconnectnode argument (jnewbery)

### Block and transaction handling
- - #10126 `0b5e162` Compensate for memory peak at flush time (sipa)
- - #9912 `fc3d7db` Optimize GetWitnessHash() for non-segwit transactions 
(sdaftuar)
- - #10133 `ab864d3` Clean up calculations of pcoinsTip memory usage (morcos)

### P2P protocol and network code
- - #9953/#10013 `d2548a4` Fix shutdown hang with >= 8 -addnodes set 
(TheBlueMatt)
- - #10176 `30fa231` net: gracefully handle NodeId wrapping (theuni)

### Build system
- - #9973 `e9611d1` depends: fix zlib build 

[bitcoin-dev] Bitcoin Core 0.14.0 released

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version 0.14.0 is now available from:

  

Or from the torrent,


magnet:?xt=urn:btih:2dbf4181022baa0629f9313787d0a4294e6acac4=bitcoin-core-0.14.0=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969=https%3A%2F%2Fbitcoin.org%2Fbin%2F

This is a new major version release, including new features, various bugfixes
and performance improvements, as well as updated translations.

Please report bugs using the issue tracker at github:

  

To receive security and update notifications, please subscribe to:

  

Compatibility
==

Bitcoin Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.8+, and Windows Vista and later.

Microsoft ended support for Windows XP on [April 8th, 
2014](https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support),
No attempt is made to prevent installing or running the software on Windows XP, 
you
can still do so at your own risk but be aware that there are known 
instabilities and issues.
Please do not report issues about Windows XP to the issue tracker.

Bitcoin Core should also work on most other Unix-like systems but is not
frequently tested on them.

Notable changes
===

Performance Improvements
- --

Validation speed and network propagation performance have been greatly
improved, leading to much shorter sync and initial block download times.

- - The script signature cache has been reimplemented as a "cuckoo cache",
  allowing for more signatures to be cached and faster lookups.
- - Assumed-valid blocks have been introduced which allows script validation to
  be skipped for ancestors of known-good blocks, without changing the security
  model. See below for more details.
- - In some cases, compact blocks are now relayed before being fully validated 
as
  per BIP152.
- - P2P networking has been refactored with a focus on concurrency and
  throughput. Network operations are no longer bottlenecked by validation. As a
  result, block fetching is several times faster than previous releases in many
  cases.
- - The UTXO cache now claims unused mempool memory. This speeds up initial 
block
  download as UTXO lookups are a major bottleneck there, and there is no use for
  the mempool at that stage.


Manual Pruning
- --

Bitcoin Core has supported automatically pruning the blockchain since 0.11. 
Pruning
the blockchain allows for significant storage space savings as the vast 
majority of
the downloaded data can be discarded after processing so very little of it 
remains
on the disk.

Manual block pruning can now be enabled by setting `-prune=1`. Once that is set,
the RPC command `pruneblockchain` can be used to prune the blockchain up to the
specified height or timestamp.

`getinfo` Deprecated
- 

The `getinfo` RPC command has been deprecated. Each field in the RPC call
has been moved to another command's output with that command also giving
additional information that `getinfo` did not provide. The following table
shows where each field has been moved to:

|`getinfo` field   | Moved to  |
|--|---|
`"version"`| `getnetworkinfo()["version"]`
`"protocolversion"`| `getnetworkinfo()["protocolversion"]`
`"walletversion"`  | `getwalletinfo()["walletversion"]`
`"balance"`| `getwalletinfo()["balance"]`
`"blocks"` | `getblockchaininfo()["blocks"]`
`"timeoffset"` | `getnetworkinfo()["timeoffset"]`
`"connections"`| `getnetworkinfo()["connections"]`
`"proxy"`  | `getnetworkinfo()["networks"][0]["proxy"]`
`"difficulty"` | `getblockchaininfo()["difficulty"]`
`"testnet"`| `getblockchaininfo()["chain"] == "test"`
`"keypoololdest"`  | `getwalletinfo()["keypoololdest"]`
`"keypoolsize"`| `getwalletinfo()["keypoolsize"]`
`"unlocked_until"` | `getwalletinfo()["unlocked_until"]`
`"paytxfee"`   | `getwalletinfo()["paytxfee"]`
`"relayfee"`   | `getnetworkinfo()["relayfee"]`
`"errors"` | `getnetworkinfo()["warnings"]`

ZMQ On Windows
- --

Previously the ZeroMQ notification system was unavailable on Windows
due to various issues with ZMQ. These have been fixed upstream and
now ZMQ can be used on Windows. Please see [this 
document](https://github.com/bitcoin/bitcoin/blob/master/doc/zmq.md) for
help with using ZMQ in general.

Nested RPC Commands in Debug Console
- 

The ability to nest RPC commands has been added to the debug console. This
allows users to have the output of a command become the input to 

[bitcoin-dev] Bitcoin Core 0.14.2 released

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version 0.14.2 is now available from:

  

Or by torrent:

  
magnet:?xt=urn:btih:b4fc7820df95b8b39603ad246c241272ec403619=bitcoin-core-0.14.2=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce

This is a new minor version release, including various bugfixes and
performance improvements, as well as updated translations.

Please report bugs using the issue tracker at github:

  

To receive security and update notifications, please subscribe to:

  

Compatibility
==

Bitcoin Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.8+, and Windows Vista and later.

Microsoft ended support for Windows XP on [April 8th, 
2014](https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support),
No attempt is made to prevent installing or running the software on Windows XP, 
you
can still do so at your own risk but be aware that there are known 
instabilities and issues.
Please do not report issues about Windows XP to the issue tracker.

Bitcoin Core should also work on most other Unix-like systems but is not
frequently tested on them.

Notable changes
===

miniupnp CVE-2017-8798
- 

Bundled miniupnpc was updated to 2.0.20170509. This fixes an integer signedness 
error
(present in MiniUPnPc v1.4.20101221 through v2.0) that allows remote attackers
(within the LAN) to cause a denial of service or possibly have unspecified
other impact.

This only affects users that have explicitly enabled UPnP through the GUI
setting or through the `-upnp` option, as since the last UPnP vulnerability
(in Bitcoin Core 0.10.3) it has been disabled by default.

If you use this option, it is recommended to upgrade to this version as soon as
possible.

Known Bugs
==

Since 0.14.0 the approximate transaction fee shown in Bitcoin-Qt when using coin
control and smart fee estimation does not reflect any change in target from the
smart fee slider. It will only present an approximate fee calculated using the
default target. The fee calculated using the correct target is still applied to
the transaction and shown in the final send confirmation dialog.

0.14.2 Change log
=

Detailed release notes follow. This overview includes changes that affect
behavior, not code moves, refactors and string updates. For convenience in 
locating
the code changes and accompanying discussion, both the pull request and
git merge commit are mentioned.

### RPC and other APIs
- - #10410 `321419b` Fix importwallet edge case rescan bug (ryanofsky)

### P2P protocol and network code
- - #10424 `37a8fc5` Populate services in GetLocalAddress (morcos)
- - #10441 `9e3ad50` Only enforce expected services for half of outgoing 
connections (theuni)

### Build system
- - #10414 `ffb0c4b` miniupnpc 2.0.20170509 (fanquake)
- - #10228 `ae479bc` Regenerate bitcoin-config.h as necessary (theuni)

### Miscellaneous
- - #10245 `44a17f2` Minor fix in build documentation for FreeBSD 11 (shigeya)
- - #10215 `0aee4a1` Check interruptNet during dnsseed lookups (TheBlueMatt)

### GUI
- - #10231 `1e936d7` Reduce a significant cs_main lock freeze (jonasschnelli)

### Wallet
- - #10294 `1847642` Unset change position when there is no change (instagibbs)

Credits
===

Thanks to everyone who directly contributed to this release:

- - Alex Morcos
- - Cory Fields
- - fanquake
- - Gregory Sanders
- - Jonas Schnelli
- - Matt Corallo
- - Russell Yanofsky
- - Shigeya Suzuki
- - Wladimir J. van der Laan

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


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCgAGBQJZRRTMAAoJEB5K7WKYbNJdqk0IANF5Q49ID3B77b0CwSKzjTxk
Ktp0qgvtig0ZMnzVlgjULUsRW8EbecWCQwmgRo8uUoCGmNS2u7u+s28kIIkicELE
BpWcW4eC6NdCCjB1CSnmX/tno4gFwOZutVj/XUXJCBEuBbo6fIK0cVDas5vw8UVa
gXL5ytwXeCws3z9f3iiD1Nl0k+J+dRb0sJ2u0A1+XqoMFfInMUFiP/fa9XWaimKo
62jD07IJDKtH4PEKG8v+FLZounRP7t1lhU0AiQ0Uj67mBmllwWD0KeZi0f4SokMX
aezEH+2UIW3Ph/QbG+ktZYUzbDALnRIHEBP4GQUuWiUPZKo3vAS3yhvh1nvYUW4=
=VBdE
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Bitcoin Core 0.15.0 released

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version *0.15.0* is now available from:

  

and

  

Or through bittorrent:


magnet:?xt=urn:btih:e17a5823dd84fe5100386c69e91bc0671e4b4ed2=bitcoin-core-0.15.0=udp%3A%2F%2Ftracker.skyts.net%3A6969%2Fannounce=udp%3A%2F%2Ftracker.safe.moe%3A6969%2Fannounce=udp%3A%2F%2Ftracker.piratepublic.com%3A1337%2Fannounce=udp%3A%2F%2Ftracker.pirateparty.gr%3A6969%2Fannounce=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce

This is a new major version release, including new features, various bugfixes
and performance improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  

To receive security and update notifications, please subscribe to:

  

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

The first time you run version 0.15.0, your chainstate database will be 
converted to a
new format, which will take anywhere from a few minutes to half an hour,
depending on the speed of your machine.

The file format of `fee_estimates.dat` changed in version 0.15.0. Hence, a
downgrade from version 0.15.0 or upgrade to version 0.15.0 will cause all fee
estimates to be discarded.

Note that the block database format also changed in version 0.8.0 and there is 
no
automatic upgrade code from before version 0.8 to version 0.15.0. Upgrading
directly from 0.7.x and earlier without redownloading the blockchain is not 
supported.
However, as usual, old wallet versions are still supported.

Downgrading warning
- ---

The chainstate database for this release is not compatible with previous
releases, so if you run 0.15 and then decide to switch back to any
older version, you will need to run the old release with the 
`-reindex-chainstate`
option to rebuild the chainstate data structures in the old format.

If your node has pruning enabled, this will entail re-downloading and
processing the entire blockchain.

Compatibility
==

Bitcoin Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.8+, and Windows Vista and later. Windows XP is not 
supported.

Bitcoin Core should also work on most other Unix-like systems but is not
frequently tested on them.

Notes for 0.15.0


Current SegWit support
- --

Version 0.15.0 supports adding a segregated witness address via the 
`addwitnessaddress` RPC, but
please note that this is a testing/expert RPC, which does not guarantee 
recovery from backup. Only use
this RPC if you know what you are doing. More complete wallet support for 
segregated witness is coming
in a next version.

Rescanning with encrypted wallets
- -

As in previous versions, when using an encrypted HD wallet, the keypool cannot 
be topped up without unlocking
the wallet. This means that currently, in order to recover from a backup of an 
encrypted HD wallet, the user
must unlock the wallet with a really long timeout and manually trigger a 
rescan, otherwise they risk missing
some keys when auto-topup cannot run. Unfortunately there is no `rescan` RPC in 
this version, that will be
included in a future version, so for now a rescan can be triggered using one of 
the `import*` commands, using
a dummy address generated by another (trusted) wallet.

Notable changes
===

Performance Improvements
- 

Version 0.15 contains a number of significant performance improvements, which 
make
Initial Block Download, startup, transaction and block validation much faster:

- - The chainstate database (which is used for tracking UTXOs) has been changed
  from a per-transaction model to a per-output model (See [PR 
10195](https://github.com/bitcoin/bitcoin/pull/10195)). Advantages of this model
  are that it:
- avoids the CPU overhead of deserializing and serializing the unused 
outputs;
- has more predictable memory usage;
- uses simpler code;
- is adaptable to various future cache flushing strategies.

  As a result, validating the blockchain during Initial Block Download (IBD) 
and reindex
  is ~30-40% faster, uses 10-20% less memory, and flushes to disk far less 
frequently.
  The only downside is that the on-disk database is 15% larger. During the 
conversion from the previous format
  a few extra gigabytes may be used.
- - Earlier versions experienced a spike in memory usage while flushing UTXO 
updates to disk.
  As a result, only half of the available memory was actually used as cache, 
and the other half was
  

[bitcoin-dev] Bitcoin Core 0.15.1 released

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version *0.15.1* is now available from:

  

or

  

Or through bittorrent:

  
magnet:?xt=urn:btih:e83dfdfca54def4e29f5355e8c3f9a7aa45ecbaf=bitcoin-core-0.15.1=udp%3A%2F%2Ftracker.openbittorrent.com%3A80=udp%3A%2F%2Ftracker.opentrackr.org%3A1337=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969=udp%3A%2F%2Fzer0day.ch%3A1337=udp%3A%2F%2Fexplodie.org%3A6969

This is a new minor version release, including various bugfixes and
performance improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  

To receive security and update notifications, please subscribe to:

  

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

The first time you run version 0.15.0 or higher, your chainstate database will
be converted to a new format, which will take anywhere from a few minutes to
half an hour, depending on the speed of your machine.

The file format of `fee_estimates.dat` changed in version 0.15.0. Hence, a
downgrade from version 0.15 or upgrade to version 0.15 will cause all fee
estimates to be discarded.

Note that the block database format also changed in version 0.8.0 and there is 
no
automatic upgrade code from before version 0.8 to version 0.15.0. Upgrading
directly from 0.7.x and earlier without redownloading the blockchain is not 
supported.
However, as usual, old wallet versions are still supported.

Downgrading warning
- ---

The chainstate database for this release is not compatible with previous
releases, so if you run 0.15 and then decide to switch back to any
older version, you will need to run the old release with the 
`-reindex-chainstate`
option to rebuild the chainstate data structures in the old format.

If your node has pruning enabled, this will entail re-downloading and
processing the entire blockchain.

Compatibility
==

Bitcoin Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.8+, and Windows Vista and later. Windows XP is not 
supported.

Bitcoin Core should also work on most other Unix-like systems but is not
frequently tested on them.


Notable changes
===

Network fork safety enhancements
- 

A number of changes to the way Bitcoin Core deals with peer connections and 
invalid blocks
have been made, as a safety precaution against blockchain forks and misbehaving 
peers.

- - Unrequested blocks with less work than the minimum-chain-work are now no 
longer processed even
if they have more work than the tip (a potential issue during IBD where the tip 
may have low-work).
This prevents peers wasting the resources of a node. 

- - Peers which provide a chain with less work than the minimum-chain-work 
during IBD will now be disconnected.

- - For a given outbound peer, we now check whether their best known block has 
at least as much work as our tip. If it
doesn't, and if we still haven't heard about a block with sufficient work after 
a 20 minute timeout, then we send
a single getheaders message, and wait 2 more minutes. If after two minutes 
their best known block has insufficient
work, we disconnect that peer. We protect 4 of our outbound peers from being 
disconnected by this logic to prevent
excessive network topology changes as a result of this algorithm, while still 
ensuring that we have a reasonable
number of nodes not known to be on bogus chains.

- - Outbound (non-manual) peers that serve us block headers that are already 
known to be invalid (other than compact
block announcements, because BIP 152 explicitly permits nodes to relay compact 
blocks before fully validating them)
will now be disconnected.

- - If the chain tip has not been advanced for over 30 minutes, we now assume 
the tip may be stale and will try to connect
to an additional outbound peer. A periodic check ensures that if this extra 
peer connection is in use, we will disconnect
the peer that least recently announced a new block.

- - The set of all known invalid-themselves blocks (i.e. blocks which we 
attempted to connect but which were found to be
invalid) are now tracked and used to check if new headers build on an invalid 
chain. This ensures that everything that
descends from an invalid block is marked as such.


Miner block size limiting deprecated
- 

Though blockmaxweight has been preferred for limiting the size of blocks 
returned by
getblocktemplate since 0.13.0, blockmaxsize 

[bitcoin-dev] Bitcoin Core 0.16.1 released

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version 0.16.1 is now available from:

  

Or through bittorrent:

  
magnet:?xt=urn:btih:91069028aaf9f6bb3279e71bfd9ab164922e578e=bitcoin-core-0.16.1=udp%3A%2F%2Ftracker.openbittorrent.com%3A80=udp%3A%2F%2Ftracker.opentrackr.org%3A1337=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969=udp%3A%2F%2Fzer0day.ch%3A1337=udp%3A%2F%2Fexplodie.org%3A6969
 

This is a new minor version release, with various bugfixes
as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  

To receive security and update notifications, please subscribe to:

  

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

The first time you run version 0.15.0 or newer, your chainstate database will 
be converted to a
new format, which will take anywhere from a few minutes to half an hour,
depending on the speed of your machine.

Note that the block database format also changed in version 0.8.0 and there is 
no
automatic upgrade code from before version 0.8 to version 0.15.0 or higher. 
Upgrading
directly from 0.7.x and earlier without re-downloading the blockchain is not 
supported.
However, as usual, old wallet versions are still supported.

Downgrading warning
- ---

Wallets created in 0.16 and later are not compatible with versions prior to 0.16
and will not work if you try to use newly created wallets in older versions. 
Existing
wallets that were created with older versions are not affected by this.

Compatibility
==

Bitcoin Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.8+, and Windows Vista and later. Windows XP is not 
supported.

Bitcoin Core should also work on most other Unix-like systems but is not
frequently tested on them.

Notable changes
===

Miner block size removed
- 

The `-blockmaxsize` option for miners to limit their blocks' sizes was
deprecated in version 0.15.1, and has now been removed. Miners should use the
`-blockmaxweight` option if they want to limit the weight of their blocks'
weights.

0.16.1 change log
- --

### Policy
- - #11423 `d353dd1` [Policy] Several transaction standardness rules (jl2012)

### Mining
- - #12756 `e802c22` [config] Remove blockmaxsize option (jnewbery)

### Block and transaction handling
- - #13199 `c71e535` Bugfix: ensure consistency of m_failed_blocks after 
reconsiderblock (sdaftuar)
- - #13023 `bb79aaf` Fix some concurrency issues in ActivateBestChain() (skeees)

### P2P protocol and network code
- - #12626 `f60e84d` Limit the number of IPs addrman learns from each DNS 
seeder (EthanHeilman)

### Wallet
- - #13265 `5d8de76` Exit SyncMetaData if there are no transactions to sync 
(laanwj)
- - #13030 `5ff571e` Fix zapwallettxes/multiwallet interaction. (jnewbery)

### GUI
- - #12999 `1720eb3` Show the Window when double clicking the taskbar icon 
(ken2812221)
- - #12650 `f118a7a` Fix issue: "default port not shown correctly in settings 
dialog" (251Labs)
- - #13251 `ea487f9` Rephrase Bech32 checkbox texts, and enable it with legacy 
address default (fanquake)

### Build system
- - #12474 `b0f692f` Allow depends system to support armv7l (hkjn)
- - #12585 `72a3290` depends: Switch to downloading expat from GitHub (fanquake)
- - #12648 `46ca8f3` test: Update trusted git root (MarcoFalke)
- - #11995 `686cb86` depends: Fix Qt build with Xcode 9 (fanquake)
- - #12636 `845838c` backport: #11995 Fix Qt build with Xcode 9 (fanquake)
- - #12946 `e055bc0` depends: Fix Qt build with XCode 9.3 (fanquake)
- - #12998 `7847b92` Default to defining endian-conversion DECLs in compat w/o 
config (TheBlueMatt)

### Tests and QA
- - #12447 `01f931b` Add missing signal.h header (laanwj)
- - #12545 `1286f3e` Use wait_until to ensure ping goes out (Empact)
- - #12804 `4bdb0ce` Fix intermittent rpc_net.py failure. (jnewbery)
- - #12553 `0e98f96` Prefer wait_until over polling with time.sleep (Empact)
- - #12486 `cfebd40` Round target fee to 8 decimals in assert_fee_amount 
(kallewoof)
- - #12843 `df38b13` Test starting bitcoind with -h and -version (jnewbery)
- - #12475 `41c29f6` Fix python TypeError in script.py (MarcoFalke)
- - #12638 `0a76ed2` Cache only chain and wallet for regtest datadir 
(MarcoFalke)
- - #12902 `7460945` Handle potential cookie race when starting node (sdaftuar)
- - #12904 `6c26df0` Ensure bitcoind processes are cleaned up when tests end 
(sdaftuar)
- - #13049 `9ea62a3` Backports (MarcoFalke)
- - #13201 `b8aacd6` Handle disconnect_node 

[bitcoin-dev] Bitcoin Core 0.16.2 released

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version 0.16.2 is now available from:

  

or through bittorrent:


magnet:?xt=urn:btih:b64eacae7d6e5f7ba50de3da8aca4368c27f0823=bitcoin-core-0.16.2=udp%3A%2F%2Ftracker.openbittorrent.com%3A80=udp%3A%2F%2Ftracker.opentrackr.org%3A1337=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969=udp%3A%2F%2Fzer0day.ch%3A1337=udp%3A%2F%2Fexplodie.org%3A6969

This is a new minor version release, with various bugfixes
as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  

To receive security and update notifications, please subscribe to:

  

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

The first time you run version 0.15.0 or newer, your chainstate database will 
be converted to a
new format, which will take anywhere from a few minutes to half an hour,
depending on the speed of your machine.

Note that the block database format also changed in version 0.8.0 and there is 
no
automatic upgrade code from before version 0.8 to version 0.15.0 or higher. 
Upgrading
directly from 0.7.x and earlier without re-downloading the blockchain is not 
supported.
However, as usual, old wallet versions are still supported.

Downgrading warning
- ---

Wallets created in 0.16 and later are not compatible with versions prior to 0.16
and will not work if you try to use newly created wallets in older versions. 
Existing
wallets that were created with older versions are not affected by this.

Compatibility
==

Bitcoin Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.8+, and Windows Vista and later. Windows XP is not 
supported.

Bitcoin Core should also work on most other Unix-like systems but is not
frequently tested on them.

0.16.2 change log
- --

### Wallet
- - #13622 `c04a4a5` Remove mapRequest tracking that just effects Qt display. 
(TheBlueMatt)
- - #12905 `cfc6f74` [rpcwallet] Clamp walletpassphrase value at 100M seconds 
(sdaftuar)
- - #13437 `ed82e71` wallet: Erase wtxOrderd wtx pointer on removeprunedfunds 
(MarcoFalke)

### RPC and other APIs
- - #13451 `cbd2f70` rpc: expose CBlockIndex::nTx in getblock(header) 
(instagibbs)
- - #13507 `f7401c8` RPC: Fix parameter count check for importpubkey (kristapsk)
- - #13452 `6b9dc8c` rpc: have verifytxoutproof check the number of txns in 
proof structure (instagibbs)
- - #12837 `bf1f150` rpc: fix type mistmatch in `listreceivedbyaddress` 
(joemphilips)
- - #12743 `657dfc5` Fix csBestBlock/cvBlockChange waiting in rpc/mining (sipa)

### GUI
- - #12432 `f78e7f6` [qt] send: Clear All also resets coin control options 
(Sjors)
- - #12617 `21dd512` gui: Show messages as text not html (laanwj)
- - #12793 `cf6feb7` qt: Avoid reseting on resetguisettigs=0 (MarcoFalke)

### Build system
- - #13544 `9fd3e00` depends: Update Qt download url (fanquake)
- - #12573 `88d1a64` Fix compilation when compiler do not support 
`__builtin_clz*` (532479301)

### Tests and QA
- - #13061 `170b309` Make tests pass after 2020 (bmwiedemann)
- - #13192 `79c4fff` [tests] Fixed intermittent failure in `p2p_sendheaders.py` 
(lmanners)
- - #13300 `d9c5630` qa: Initialize lockstack to prevent null pointer deref 
(MarcoFalke)
- - #13545 `e15e3a9` tests: Fix test case `streams_serializedata_xor` Remove 
Boost dependency. (practicalswift)
- - #13304 `cbdabef` qa: Fix `wallet_listreceivedby` race (MarcoFalke)

### Miscellaneous
- - #12887 `2291774` Add newlines to end of log messages (jnewbery)
- - #12859 `18b0c69` Bugfix: Include  for `std::unique_ptr` (luke-jr)
- - #13131 `ce8aa54` Add Windows shutdown handler (ken2812221)
- - #13652 `20461fc` rpc: Fix that CWallet::AbandonTransaction would leave the 
grandchildren, etc. active (Empact)

Credits
===

Thanks to everyone who directly contributed to this release:

- - 532479301
- - Ben Woosley
- - Bernhard M. Wiedemann
- - Chun Kuan Lee
- - Cory Fields
- - fanquake
- - Gregory Sanders
- - joemphilips
- - John Newbery
- - Kristaps Kaupe
- - lmanners
- - Luke Dashjr
- - MarcoFalke
- - Matt Corallo
- - Pieter Wuille
- - practicalswift
- - Sjors Provoost
- - Suhas Daftuar
- - Wladimir J. van der Laan

And to those that reported security issues:

- - Braydon Fuller
- - Himanshu Mehta

As well as everyone that helped translating on 
[Transifex](https://www.transifex.com/projects/p/bitcoin/).
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCgAGBQJbXfGUAAoJEB5K7WKYbNJdmLUIAJc+Emy+4SWk00lPshKW+1vF

[bitcoin-dev] Bitcoin Core 0.16.0 released

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version 0.16.0 is now available from:

  

or through bittorrent:

  
magnet:?xt=urn:btih:6493ae7a15b4d32bb4eca1dfaf6dcc0c143492cb=bitcoin-core-0.16.0=udp%3A%2F%2Ftracker.openbittorrent.com%3A80=udp%3A%2F%2Ftracker.opentrackr.org%3A1337=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969=udp%3A%2F%2Fzer0day.ch%3A1337=udp%3A%2F%2Fexplodie.org%3A6969

This is a new major version release, including new features, various bugfixes
and performance improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  

To receive security and update notifications, please subscribe to:

  

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

The first time you run version 0.15.0 or newer, your chainstate database will 
be converted to a
new format, which will take anywhere from a few minutes to half an hour,
depending on the speed of your machine.

Note that the block database format also changed in version 0.8.0 and there is 
no
automatic upgrade code from before version 0.8 to version 0.15.0 or higher. 
Upgrading
directly from 0.7.x and earlier without re-downloading the blockchain is not 
supported.
However, as usual, old wallet versions are still supported.

Downgrading warning
- ---

Wallets created in 0.16 and later are not compatible with versions prior to 0.16
and will not work if you try to use newly created wallets in older versions. 
Existing
wallets that were created with older versions are not affected by this.

Compatibility
==

Bitcoin Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.8+, and Windows Vista and later. Windows XP is not 
supported.

Bitcoin Core should also work on most other Unix-like systems but is not
frequently tested on them.

Notable changes
===

Wallet changes
- ---

### Segwit Wallet

Bitcoin Core 0.16.0 introduces full support for segwit in the wallet and user 
interfaces. A new `-addresstype` argument has been added, which supports 
`legacy`, `p2sh-segwit` (default), and `bech32` addresses. It controls what 
kind of addresses are produced by `getnewaddress`, `getaccountaddress`, and 
`createmultisigaddress`. A `-changetype` argument has also been added, with the 
same options, and by default equal to `-addresstype`, to control which kind of 
change is used.

A new `address_type` parameter has been added to the `getnewaddress` and 
`addmultisigaddress` RPCs to specify which type of address to generate.
A `change_type` argument has been added to the `fundrawtransaction` RPC to 
override the `-changetype` argument for specific transactions.

- - All segwit addresses created through `getnewaddress` or `*multisig` RPCs 
explicitly get their redeemscripts added to the wallet file. This means that 
downgrading after creating a segwit address will work, as long as the wallet 
file is up to date.
- - All segwit keys in the wallet get an implicit redeemscript added, without 
it being written to the file. This means recovery of an old backup will work, 
as long as you use new software.
- - All keypool keys that are seen used in transactions explicitly get their 
redeemscripts added to the wallet files. This means that downgrading after 
recovering from a backup that includes a segwit address will work

Note that some RPCs do not yet support segwit addresses. Notably, 
`signmessage`/`verifymessage` doesn't support segwit addresses, nor does 
`importmulti` at this time. Support for segwit in those RPCs will continue to 
be added in future versions.

P2WPKH change outputs are now used by default if any destination in the 
transaction is a P2WPKH or P2WSH output. This is done to ensure the change 
output is as indistinguishable from the other outputs as possible in either 
case.

### BIP173 (Bech32) Address support ("bc1..." addresses)

Full support for native segwit addresses (BIP173 / Bech32) has now been added.
This includes the ability to send to BIP173 addresses (including non-v0 ones), 
and generating these
addresses (including as default new addresses, see above).

A checkbox has been added to the GUI to select whether a Bech32 address or 
P2SH-wrapped address should be generated when using segwit addresses. When 
launched with `-addresstype=bech32` it is checked by default. When launched 
with `-addresstype=legacy` it is unchecked and disabled.

### HD-wallets by default

Due to a backward-incompatible change in the wallet database, wallets created
with version 

[bitcoin-dev] Bitcoin Core 0.17.0.1 released

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version 0.17.0.1 is now available from:

  

or through BitTorrent:

  
magnet:?xt=urn:btih:70749cf2cf2922a21208b4ae760c9f2f9d1e7f11=bitcoin-core-0.17.0.1=udp%3A%2F%2Ftracker.openbittorrent.com%3A80=udp%3A%2F%2Ftracker.opentrackr.org%3A1337=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969=udp%3A%2F%2Fzer0day.ch%3A1337=udp%3A%2F%2Fexplodie.org%3A6969

This is a new major version release, including new features, various bugfixes
and performance improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  

To receive security and update notifications, please subscribe to:

  

Notable changes
===

An issue was solved with OSX dmg generation, affecting macOS 10.12 to 10.14,
which could cause Finder to crash on install.

There are no significant changes for other operating systems.

0.17.0.1 change log
===

### Build system
- - #14416 `eb2cc84` Fix OSX dmg issue (10.12 to 10.14) (jonasschnelli)

### Documentation
- - #14509 `1b5af2c` [0.17] doc: use SegWit in getblocktemplate example (Sjors)

Credits
===

Thanks to everyone who directly contributed to this release:

- - Jonas Schnelli
- - Pieter Wuille
- - Sjors Provoost
- - Wladimir J. van der Laan

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEnerg3HBjJJ+wVHRoHkrtYphs0l0FAlvYRjgACgkQHkrtYphs
0l1Gigf/dRF0wlT/Ht3hkRs4vo4FqBy6fNeTbn0G20uiK/L0XYdj9fDoVrbzuDHX
1cszwwUyj3E/wLredII3sEIaMN3ttcsl80ngqeE4VATMFUkjXscihh3kxGzSLZ1b
lrxsnLJuQao/L6TEwtRhe2AkKBJao7Q5Eamz9z1ZdFvOGZmRbzSiJqCaXt9NPPl+
JGcug0xBcEP12pele6itXzxxXjESjcRc/o7ETEuiThVJdTlRQA+mqQFAgvOgtqhr
IrRB2m7gkw7eCabCVbV3ueX/4MEEvSnq/N00W1T82r2zNYM1caUmsLn6TDdO55sp
pSs3DKcTxNj//S/Axwo79TVrrSdb5A==
=d2U1
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Bitcoin Core 0.14.3 released

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version *0.14.3* is now available from:

  

or through bitorrent:

  
magnet:?xt=urn:btih:171edf5f51820900f24fc72620deaa07ee497dee=bitcoin-core-0.14.3=udp%3A%2F%2Ftracker.openbittorrent.com%3A80=udp%3A%2F%2Ftracker.opentrackr.org%3A1337=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969=udp%3A%2F%2Fzer0day.ch%3A1337=udp%3A%2F%2Fexplodie.org%3A6969

This is a new minor version release, including various bugfixes and
performance improvements.

Please report bugs using the issue tracker at github:

  

To receive security and update notifications, please subscribe to:

  

Compatibility
==

Bitcoin Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.8+, and Windows Vista and later.

Microsoft ended support for Windows XP on [April 8th, 
2014](https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support),
No attempt is made to prevent installing or running the software on Windows XP, 
you
can still do so at your own risk but be aware that there are known 
instabilities and issues.
Please do not report issues about Windows XP to the issue tracker.

Bitcoin Core should also work on most other Unix-like systems but is not
frequently tested on them.

Notable changes
===

Denial-of-Service vulnerability CVE-2018-17144
 ---

A denial-of-service vulnerability exploitable by miners has been discovered in
Bitcoin Core versions 0.14.0 up to 0.16.2. It is recommended to upgrade any of
the vulnerable versions to 0.14.3, 0.15.2 or 0.16.3 as soon as possible.

Known Bugs
==

Since 0.14.0 the approximate transaction fee shown in Bitcoin-Qt when using coin
control and smart fee estimation does not reflect any change in target from the
smart fee slider. It will only present an approximate fee calculated using the
default target. The fee calculated using the correct target is still applied to
the transaction and shown in the final send confirmation dialog.

0.14.3 Change log
=

Detailed release notes follow. This overview includes changes that affect
behavior, not code moves, refactors and string updates. For convenience in 
locating
the code changes and accompanying discussion, both the pull request and
git merge commit are mentioned.

### Consensus
- - #14247 `52965fb` Fix crash bug with duplicate inputs within a transaction 
(TheBlueMatt, sdaftuar)
 
### RPC and other APIs

- - #10445 `87a21d5` Fix: make CCoinsViewDbCursor::Seek work for missing keys 
(Pieter Wuille, Gregory Maxwell)
- - #9853 Return correct error codes in setban(), fundrawtransaction(), 
removeprunedfunds(), bumpfee(), blockchain.cpp (John Newbery)


### P2P protocol and network code

- - #10234 `d289b56` [net] listbanned RPC and QT should show correct banned 
subnets (John Newbery)

### Build system


### Miscellaneous

- - #10451 `3612219` contrib/init/bitcoind.openrcconf: Don't disable wallet by 
default (Luke Dashjr)
- - #10250 `e23cef0` Fix some empty vector references (Pieter Wuille)
- - #10196 `d28d583` PrioritiseTransaction updates the mempool tx counter 
(Suhas Daftuar)
- - #9497 `e207342` Fix CCheckQueue IsIdle (potential) race condition and 
remove dangerous constructors. (Jeremy Rubin)

### GUI

- - #9481 `7abe7bb` Give fallback fee a reasonable indent (Luke Dashjr)
- - #9481 `3e4d7bf` Qt/Send: Figure a decent warning colour from theme (Luke 
Dashjr)
- - #9481 `e207342` Show more significant warning if we fall back to the 
default fee (Jonas Schnelli)

### Wallet

- - #10308 `28b8b8b` Securely erase potentially sensitive keys/values (tjps)
- - #10265 `ff13f59` Make sure pindex is non-null before possibly referencing 
in LogPrintf call. (Karl-Johan Alm)

Credits
===

Thanks to everyone who directly contributed to this release:

- - Cory Fields
- - CryptAxe
- - fanquake
- - Jeremy Rubin
- - John Newbery
- - Jonas Schnelli
- - Gregory Maxwell
- - Karl-Johan Alm
- - Luke Dashjr
- - MarcoFalke
- - Matt Corallo
- - Mikerah
- - Pieter Wuille
- - practicalswift
- - Suhas Daftuar
- - Thomas Snider
- - Tjps
- - Wladimir J. van der Laan

And to those that reported security issues:

- - awemany (for CVE-2018-17144, previously credited as "anonymous reporter")

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEnerg3HBjJJ+wVHRoHkrtYphs0l0FAluuSowACgkQHkrtYphs
0l3XtggArfc/1tCcIunvUIyooq7nb27AwltySOBFCFH/R1v6mcSN6ZHAEKC3uBA6
WkhrGChV8XqNELKau7w1riubPjMHNTj0k4+DBtaDNN41EAF+1bhHWbxQ4006tZHb
WN2coxX+iNPI9uj3m0MnbulZpy+c7w1azO8eULcZjkqkccRBl6p4Y3uePr7CbbKU
/h517ziI7UwYChKsF3tC7CX+3vDi7oyfZd5QCKmtEFicS4j0UADtsLdF2GlMkpyD
yffAq/jpDXrIMWXrseZe60UPTijaA2mokk8/SdGy0hKn9Qx/VB0EIYKVPMD4gDUg
iSFcmsELYzBzk01Jg29GLzCbI7rQYw==
=MOiO
-END PGP SIGNATURE-
___

[bitcoin-dev] Bitcoin Core 0.15.2 released

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version *0.15.2* is now available from:

  

or through bittorrent:

  
magnet:?xt=urn:btih:c0a23591e04ce45dd6349f3abc34df948c45537c=bitcoin-core-0.15.2=udp%3A%2F%2Ftracker.openbittorrent.com%3A80=udp%3A%2F%2Ftracker.opentrackr.org%3A1337=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969=udp%3A%2F%2Fzer0day.ch%3A1337=udp%3A%2F%2Fexplodie.org%3A6969

This is a new minor version release, including various bugfixes and
performance improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  

To receive security and update notifications, please subscribe to:

  

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

The first time you run version 0.15.0 or higher, your chainstate database will
be converted to a new format, which will take anywhere from a few minutes to
half an hour, depending on the speed of your machine.

The file format of `fee_estimates.dat` changed in version 0.15.0. Hence, a
downgrade from version 0.15 or upgrade to version 0.15 will cause all fee
estimates to be discarded.

Note that the block database format also changed in version 0.8.0 and there is 
no
automatic upgrade code from before version 0.8 to version 0.15.0. Upgrading
directly from 0.7.x and earlier without redownloading the blockchain is not 
supported.
However, as usual, old wallet versions are still supported.

Downgrading warning
- ---

The chainstate database for this release is not compatible with previous
releases, so if you run 0.15 and then decide to switch back to any
older version, you will need to run the old release with the 
`-reindex-chainstate`
option to rebuild the chainstate data structures in the old format.

If your node has pruning enabled, this will entail re-downloading and
processing the entire blockchain.

Compatibility
==

Bitcoin Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.8+, and Windows Vista and later. Windows XP is not 
supported.

Bitcoin Core should also work on most other Unix-like systems but is not
frequently tested on them.


Notable changes
===

Denial-of-Service vulnerability CVE-2018-17144
- ---

A denial-of-service vulnerability exploitable by miners has been discovered in
Bitcoin Core versions 0.14.0 up to 0.16.2. It is recommended to upgrade any of
the vulnerable versions to 0.15.2 or 0.16.3 as soon as possible.

0.15.2 Change log
=

### Build system

- - #11995 `9bb1a16` depends: Fix Qt build with XCode 9.2(fanquake)
- - #12946 `93b9a61` depends: Fix Qt build with XCode 9.3(fanquake)
- - #13544 `9fd3e00` depends: Update Qt download url (fanquake)
- - #11847 `cb7ef31` Make boost::multi_index comparators const (sdaftuar)

### Consensus
- - #14247 `4b8a3f5` Fix crash bug with duplicate inputs within a transaction 
(TheBlueMatt, sdaftuar)
 
### RPC
- - #11676 `7af2457` contrib/init: Update openrc-run filename (Luke Dashjr)
- - #11277 `7026845` Fix uninitialized URI in batch RPC requests (Russell 
Yanofsky)
 
### Wallet
- - #11289 `3f1db56` Wrap dumpwallet warning and note scripts aren't dumped 
(MeshCollider)
- - #11289 `42ea47d` Add wallet backup text to import*, add* and dumpwallet 
RPCs (MeshCollider)
- - #11590 `6372a75` [Wallet] always show help-line of wallet encryption calls 
(Jonas Schnelli)

### bitcoin-tx

- - #11554 `a69cc07` Sanity-check script sizes in bitcoin-tx (TheBlueMatt)

### Tests
- - #11277 `3a6cdd4` Add test for multiwallet batch RPC calls (Russell Yanofsky)
- - #11647 `1c8c7f8` Add missing batch rpc calls to python coverage logs 
(Russell Yanofsky)
- - #11277 `1036c43` Add missing multiwallet rpc calls to python coverage logs 
(Russell Yanofsky)
- - #11277 `305f768` Limit AuthServiceProxyWrapper.\_\_getattr\_\_ wrapping 
(Russell Yanofsky)
- - #11277 `2eea279` Make AuthServiceProxy.\_batch method usable (Russell 
Yanofsky)

Credits
===

Thanks to everyone who directly contributed to this release:

- - fanquake
- - Jonas Schnelli
- - Luke Dashjr
- - Matt Corallo
- - MeshCollider
- - Russell Yanofsky
- - Suhas Daftuar
- - Wladimir J. van der Laan

And to those that reported security issues:

- - awemany (for CVE-2018-17144, previously credited as "anonymous reporter")

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEnerg3HBjJJ+wVHRoHkrtYphs0l0FAluuSdQACgkQHkrtYphs
0l30rwgApv6HCvWRnKCfoXTYjIFaBXoxFU8/SPlms/3YYvc5JF8/+DeVXfYgd1nW
Mgw1j0I3m52Am5JmV368uSpbfQYoUSUkWuZX62al9AXC8EBEbqPBWkeIJgvD3cpS

[bitcoin-dev] Bitcoin Core 0.17.0 released

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version 0.17.0 is now available from:

  

or through BitTorrent:

  
magnet:?xt=urn:btih:1c72f17bc1667a2ce81860b75135e491f6637d05=bitcoin-core-0.17.0=udp%3A%2F%2Ftracker.openbittorrent.com%3A80=udp%3A%2F%2Ftracker.opentrackr.org%3A1337=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969=udp%3A%2F%2Fzer0day.ch%3A1337=udp%3A%2F%2Fexplodie.org%3A6969

This is a new major version release, including new features, various bugfixes
and performance improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  

To receive security and update notifications, please subscribe to:

  

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

If your node has a txindex, the txindex db will be migrated the first time you 
run 0.17.0 or newer, which may take up to a few hours. Your node will not be 
functional until this migration completes.

The first time you run version 0.15.0 or newer, your chainstate database will 
be converted to a
new format, which will take anywhere from a few minutes to half an hour,
depending on the speed of your machine.

Note that the block database format also changed in version 0.8.0 and there is 
no
automatic upgrade code from before version 0.8 to version 0.15.0. Upgrading
directly from 0.7.x and earlier without redownloading the blockchain is not 
supported.
However, as usual, old wallet versions are still supported.

Downgrading warning
- ---

The chainstate database for this release is not compatible with previous
releases, so if you run 0.15 and then decide to switch back to any
older version, you will need to run the old release with the 
`-reindex-chainstate`
option to rebuild the chainstate data structures in the old format.

If your node has pruning enabled, this will entail re-downloading and
processing the entire blockchain.

Compatibility
==

Bitcoin Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.10+, and Windows 7 and newer (Windows XP is not 
supported).

Bitcoin Core should also work on most other Unix-like systems but is not
frequently tested on them.

- From 0.17.0 onwards macOS <10.10 is no longer supported. 0.17.0 is built 
using Qt 5.9.x, which doesn't
support versions of macOS older than 10.10.

Known issues


- - Upgrading from 0.13.0 or older currently results in memory blow-up during 
the roll-back of blocks to the SegWit activation point. In these cases, a full 
`-reindex` is necessary.

- - The GUI suffers from visual glitches in the new MacOS dark mode. This has 
to do with our Qt theme handling and is not a new problem in 0.17.0, but is 
expected to be resolved in 0.17.1.

Notable changes
===

Changed configuration options
- -

- - `-includeconf=` can be used to include additional configuration files.
  Only works inside the `bitcoin.conf` file, not inside included files or from
  command-line. Multiple files may be included. Can be disabled from command-
  line via `-noincludeconf`. Note that multi-argument commands like
  `-includeconf` will override preceding `-noincludeconf`, i.e.
  ```
  noincludeconf=1
  includeconf=relative.conf
  ```

  as bitcoin.conf will still include `relative.conf`.

GUI changes
- ---

- - Block storage can be limited under Preferences, in the Main tab. Undoing 
this setting requires downloading the full blockchain again. This mode is 
incompatible with -txindex and -rescan.

External wallet files
- -

The `-wallet=` option now accepts full paths instead of requiring wallets
to be located in the -walletdir directory.

Newly created wallet format
- ---

If `-wallet=` is specified with a path that does not exist, it will now
create a wallet directory at the specified location (containing a wallet.dat
data file, a db.log file, and database/log.?? files) instead of just
creating a data file at the path and storing log files in the parent
directory. This should make backing up wallets more straightforward than
before because the specified wallet path can just be directly archived without
having to look in the parent directory for transaction log files.

For backwards compatibility, wallet paths that are names of existing data files
in the `-walletdir` directory will continue to be accepted and interpreted the
same as before.

Dynamic loading and creation of wallets
- ---

Previously, wallets 

[bitcoin-dev] Bitcoin Core 0.16.3 released

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version 0.16.3 is now available from:

  

or through bittorrent


magnet:?xt=urn:btih:a6015029671a445a7a07026b3e4a0fe54c2b2df3=bitcoin-core-0.16.3=udp%3A%2F%2Ftracker.openbittorrent.com%3A80=udp%3A%2F%2Ftracker.opentrackr.org%3A1337=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969=udp%3A%2F%2Fzer0day.ch%3A1337=udp%3A%2F%2Fexplodie.org%3A6969

This is a new minor version release, with various bugfixes.

Please report bugs using the issue tracker at GitHub:

  

To receive security and update notifications, please subscribe to:

  

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

The first time you run version 0.15.0 or newer, your chainstate database will 
be converted to a
new format, which will take anywhere from a few minutes to half an hour,
depending on the speed of your machine.

Note that the block database format also changed in version 0.8.0 and there is 
no
automatic upgrade code from before version 0.8 to version 0.15.0 or higher. 
Upgrading
directly from 0.7.x and earlier without re-downloading the blockchain is not 
supported.
However, as usual, old wallet versions are still supported.

Downgrading warning
- ---

Wallets created in 0.16 and later are not compatible with versions prior to 0.16
and will not work if you try to use newly created wallets in older versions. 
Existing
wallets that were created with older versions are not affected by this.

Compatibility
==

Bitcoin Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.8+, and Windows Vista and later. Windows XP is not 
supported.

Bitcoin Core should also work on most other Unix-like systems but is not
frequently tested on them.

Notable changes
===

Denial-of-Service vulnerability
- ---

A denial-of-service vulnerability (CVE-2018-17144) exploitable by miners has
been discovered in Bitcoin Core versions 0.14.0 up to 0.16.2. It is recommended
to upgrade any of the vulnerable versions to 0.16.3 as soon as possible.

0.16.3 change log
- --

### Consensus
- - #14249 `696b936` Fix crash bug with duplicate inputs within a transaction 
(TheBlueMatt, sdaftuar)

### RPC and other APIs
- - #13547 `212ef1f` Make `signrawtransaction*` give an error when amount is 
needed but missing (ajtowns)

### Miscellaneous
- - #13655 `1cdbea7` bitcoinconsensus: invalid flags error should be set to 
`bitcoinconsensus_err` (afk11)

### Documentation
- - #13844 `11b9dbb` correct the help output for -prune (hebasto)

Credits
===

Thanks to everyone who directly contributed to this release:

- - Anthony Towns
- - Hennadii Stepanov
- - Matt Corallo
- - Suhas Daftuar
- - Thomas Kerin
- - Wladimir J. van der Laan

And to those that reported security issues:

- - (anonymous reporter)

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEnerg3HBjJJ+wVHRoHkrtYphs0l0FAluhaKgACgkQHkrtYphs
0l1r5gf+IVeOOWeZd61ARt+0pfy2KnDRgKh7x0RJ7AFl6mWyply21zUQQx+Q6leB
P0IkzH31ssA9oKMUW6J0s8VavQ22OqHwbqrPRDXazf7auJ81jeR6Tmfkev4xg5fC
jyRQH4klctT0jDT1P+vtMejP50iqRxDC3TP9X9sXKZupGyHQuhu8XoXGZ1JF+PEX
Ba/sLiz3+d/0n6KiplI4ycnEZC5Q2hRw4O4c/2wjIdqd5hEhSH2ylmztYs2TM388
NoaPEIL9niIjwAUI4bBYNebwyRStcqoK4JEdZhvM1aXd39eymPsYUTtUcr5HL9n6
zFo8I0CXoVWT0bOGsubmo58/o2xcSg==
=9rAz
-END PGP SIGNATURE-

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Bitcoin Core 0.17.1 released

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version 0.17.1 is now available from:

  

or through BitTorrent:


magnet:?xt=urn:btih:c56c87ccfaa8e6fbccc90d549121e61efd97cb6f=bitcoin-core-0.17.1=udp%3A%2F%2Ftracker.openbittorrent.com%3A80=udp%3A%2F%2Ftracker.opentrackr.org%3A1337=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969=udp%3A%2F%2Fzer0day.ch%3A1337=udp%3A%2F%2Fexplodie.org%3A6969


This is a new minor version release, with various bugfixes
and performance improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  

To receive security and update notifications, please subscribe to:

  

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

If your node has a txindex, the txindex db will be migrated the first time you 
run 0.17.0 or newer, which may take up to a few hours. Your node will not be 
functional until this migration completes.

The first time you run version 0.15.0 or newer, your chainstate database will 
be converted to a
new format, which will take anywhere from a few minutes to half an hour,
depending on the speed of your machine.

Note that the block database format also changed in version 0.8.0 and there is 
no
automatic upgrade code from before version 0.8 to version 0.15.0. Upgrading
directly from 0.7.x and earlier without redownloading the blockchain is not 
supported.
However, as usual, old wallet versions are still supported.

Downgrading warning
- ---

The chainstate database for this release is not compatible with previous
releases, so if you run 0.15 and then decide to switch back to any
older version, you will need to run the old release with the 
`-reindex-chainstate`
option to rebuild the chainstate data structures in the old format.

If your node has pruning enabled, this will entail re-downloading and
processing the entire blockchain.

Compatibility
==

Bitcoin Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.10+, and Windows 7 and newer (Windows XP is not 
supported).

Bitcoin Core should also work on most other Unix-like systems but is not
frequently tested on them.

- From 0.17.0 onwards macOS <10.10 is no longer supported. 0.17.0 is built 
using Qt 5.9.x, which doesn't
support versions of macOS older than 10.10.

Notable changes
===

`listtransactions` label support
- 

The `listtransactions` RPC `account` parameter which was deprecated in 0.17.0
and renamed to `dummy` has been un-deprecated and renamed again to `label`.

When bitcoin is configured with the `-deprecatedrpc=accounts` setting, 
specifying
a label/account/dummy argument will return both outgoing and incoming
transactions. Without the `-deprecatedrpc=accounts` setting, it will only return
incoming transactions (because it used to be possible to create transactions
spending from specific accounts, but this is no longer possible with labels).

When `-deprecatedrpc=accounts` is set, it's possible to pass the empty string ""
to list transactions that don't have any label. Without
`-deprecatedrpc=accounts`, passing the empty string is an error because 
returning
only non-labeled transactions is not generally useful behavior and can cause
confusion.

0.17.1 change log
=

### P2P protocol and network code
- - #14685 `9406502` Fix a deserialization overflow edge case (kazcw)
- - #14728 `b901578` Fix uninitialized read when stringifying an addrLocal 
(kazcw)

### Wallet
- - #14441 `5150acc` Restore ability to list incoming transactions by label 
(jnewbery)
- - #13546 `91fa15a` Fix use of uninitialized value `bnb_used` in 
CWallet::CreateTransaction(…) (practicalswift)
- - #14310 `bb90695` Ensure wallet is unlocked before signing (gustavonalle)
- - #14690 `5782fdc` Throw error if CPubKey is invalid during PSBT keypath 
serialization (instagibbs)
- - #14852 `2528443` backport: [tests] Add `wallet_balance.py` (MarcoFalke)
- - #14196 `3362a95` psbt: always drop the unnecessary utxo and convert 
non-witness utxo to witness when necessary (achow101)
- - #14588 `70ee1f8` Refactor PSBT signing logic to enforce invariant and fix 
signing bug (gwillen)
- - #14424 `89a9a9d` Stop requiring imported pubkey to sign non-PKH schemes 
(sipa, MeshCollider)

### RPC and other APIs
- - #14417 `fb9ad04` Fix listreceivedbyaddress not taking address as a string 
(etscrivner)
- - #14596 `de5e48a` Bugfix: RPC: Add `address_type` named param for 
createmultisig (luke-jr)
- - #14618 `9666dba` Make HTTP RPC debug 

[bitcoin-dev] BIP proposal - addrv2 message

[Wladimir J. van der Laan via bitcoin-dev]

See https://gist.github.com/laanwj/4fe8470881d7b9499eedc48dc9ef1ad1 for 
formatted version,

Look under "Considerations" for topics that might still need to be discussed.


  BIP: ???
  Layer: Peer Services
  Title: addrv2 message
  Author: Wladimir J. van der Laan 
  Comments-Summary: No comments yet.
  Comments-URI: 
  Status: Draft
  Type: Standards Track
  Created: 2018-06-01
  License: BSD-2-Clause


==Introduction==

===Abstract===

This document proposes a new P2P message to gossip longer node addresses over 
the P2P network.
This is required to support new-generation Onion addresses, I2P, and 
potentially other networks
that have longer endpoint addresses than fit in the 128 bits of the current 
addr message.

===Copyright===

This BIP is licensed under the 2-clause BSD license.

===Motivation===

Tor v3 hidden services are part of the stable release of Tor since version 
0.3.2.9. They have
various advantages compared to the old hidden services, among which better 
encryption and privacy
[https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt Tor 
Rendezvous Specification - Version 3].
These services have 256 bit addresses and thus do not fit in the existing 
addr message, which encapsulates onion addresses in OnionCat IPv6 
addresses.

Other transport-layer protocols such as I2P have always used longer
addresses. This change would make it possible to gossip such addresses over the
P2P network, so that other peers can connect to them.

==Specification==


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119[https://tools.ietf.org/html/rfc2119 
RFC 2119].


The addrv2 message is defined as a message where pchCommand 
== "addrv2".
It is serialized in the standard encoding for P2P messages.
Its format is similar to the current addr message format
[https://bitcoin.org/en/developer-reference#addr Bitcoin Developer 
Reference: addr message], with the difference that the 
fixed 16-byte IP address is replaced by a network ID and a variable-length 
address, and the time and services format has been changed to VARINT.

This means that the message contains a serialized std::vector of 
the following structure:

{| class="wikitable" style="width: auto; text-align: center; font-size: 
smaller; table-layout: fixed;"
!Type
!Name
!Description
|-
| VARINT (unsigned)
| time
| Time that this node was last seen as connected to the network. A time in Unix 
epoch time format, up to 64 bits wide.
|-
| VARINT (unsigned)
| services
| Service bits. A 64-wide bit field.
|-
| uint8_t
| networkID
| Network identifier. An 8-bit value that specifies which network is addressed.
|-
| std::vector
| addr
| Network address. The interpretation depends on networkID.
|-
| uint16_t
| port
| Network port. If not relevant for the network this MUST be 0.
|}

One message can contain up to 1,000 addresses. Clients SHOULD reject messages 
with more addresses.

Field addr has a variable length, with a maximum of 32 bytes (256 
bits). Clients SHOULD reject
longer addresses.

The list of reserved network IDs is as follows:

{| class="wikitable" style="width: auto; text-align: center; font-size: 
smaller; table-layout: fixed;"
!Network ID
!Enumeration
!Address length (bytes)
!Description
|-
| 0x01
| IPV4
| 4
| IPv4 address (globally routed internet)
|-
| 0x02
| IPV6
| 16
| IPv6 address (globally routed internet)
|-
| 0x03
| TORV2
| 10
| Tor v2 hidden service address
|-
| 0x04
| TORV3
| 32
| Tor v3 hidden service address
|-
| 0x05
| I2P
| 32
| I2P overlay network address
|-
| 0x06
| CJDNS
| 16
| Cjdns overlay network address
|}

To allow for future extensibility, clients MUST ignore address types that they 
do not know about.
Client MAY store and gossip address formats that they do not know about. 
Further network ID numbers MUST be reserved in a new BIP document.

Clients SHOULD reject addresses that have a different length than specified in 
this table for a specific address ID, as these are meaningless.

See the appendices for the address encodings to be used for the various 
networks.

==Compatibility==

Send addrv2 messages only, and exclusively, when the peer has a 
certain protocol version (or higher):

//! gossiping using `addrv2` messages starts with this version
static const int GOSSIP_ADDRV2_VERSION = 70016;

For older peers keep sending the legacy addr message, ignoring 
addresses with the newly introduced address types.

==Reference implementation==

The reference implementation is available at (to be done)

==Considerations==

(to be discussed)

* ''Client MAY store and gossip address formats that they do not know about'': 
does it ever make sense to gossip addresses outside a certain overlay network? 
Say, I2P addresses to Tor? I'm not sure. Especially for networks that have no 
exit nodes as there is no overlap with the globally routed internet at all.

* Lower precision of time field? 

[bitcoin-dev] Bitcoin Core 0.18.0 released

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version 0.18.0 is now available from:

  

or through bittorrent:


magnet:?xt=urn:btih:a25c86ffa7a512b6d074287f74762b77f91cef4c=bitcoin-core-0.18.0=udp%3A%2F%2Ftracker.openbittorrent.com%3A80=udp%3A%2F%2Ftracker.opentrackr.org%3A1337=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969=udp%3A%2F%2Fzer0day.ch%3A1337=udp%3A%2F%2Fexplodie.org%3A6969

This is a new major version release, including new features, various bug
fixes and performance improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  

To receive security and update notifications, please subscribe to:

  

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

The first time you run version 0.15.0 or newer, your chainstate database
will be converted to a new format, which will take anywhere from a few
minutes to half an hour, depending on the speed of your machine.

Note that the block database format also changed in version 0.8.0 and
there is no automatic upgrade code from before version 0.8 to version
0.15.0 or later. Upgrading directly from 0.7.x and earlier without
redownloading the blockchain is not supported.  However, as usual, old
wallet versions are still supported.

Compatibility
==

Bitcoin Core is supported and extensively tested on operating systems
using the Linux kernel, macOS 10.10+, and Windows 7 and newer. It is not
recommended to use Bitcoin Core on unsupported systems.

Bitcoin Core should also work on most other Unix-like systems but is not
as frequently tested on them.

- From 0.17.0 onwards, macOS <10.10 is no longer supported. 0.17.0 is
built using Qt 5.9.x, which doesn't support versions of macOS older than
10.10. Additionally, Bitcoin Core does not yet change appearance when
macOS "dark mode" is activated.

In addition to previously-supported CPU platforms, this release's
pre-compiled distribution also provides binaries for the RISC-V
platform.

If you are using the `systemd` unit configuration file located at
`contrib/init/bitcoind.service`, it has been changed to use
`/var/lib/bitcoind` as the data directory instead of
`~bitcoin/.bitcoin`. When switching over to the new configuration file,
please make sure that the filesystem on which `/var/lib/bitcoind` will
exist has enough space (check using `df -h /var/lib/bitcoind`), and
optionally copy over your existing data directory. See the [systemd init
file section](#systemd-init-file) for more details.

Known issues


Wallet GUI
- --

For advanced users who have both (1) enabled coin control features, and
(2) are using multiple wallets loaded at the same time: The coin control
input selection dialog can erroneously retain wrong-wallet state when
switching wallets using the dropdown menu. For now, it is recommended
not to use coin control features with multiple wallets loaded.

Notable changes
===

Mining
- --

- - Calls to `getblocktemplate` will fail if the segwit rule is not
  specified.  Calling `getblocktemplate` without segwit specified is
  almost certainly a misconfiguration since doing so results in lower
  rewards for the miner.  Failed calls will produce an error message
  describing how to enable the segwit rule.

Configuration option changes
- 

- - A warning is printed if an unrecognized section name is used in the
  configuration file.  Recognized sections are `[test]`, `[main]`, and
  `[regtest]`.

- - Four new options are available for configuring the maximum number of
  messages that ZMQ will queue in memory (the "high water mark") before
  dropping additional messages.  The default value is 1,000, the same as
  was used for previous releases.  See the [ZMQ
  
documentation](https://github.com/bitcoin/bitcoin/blob/master/doc/zmq.md#usage)
  for details.

- - The `rpcallowip` option can no longer be used to automatically listen
  on all network interfaces.  Instead, the `rpcbind` parameter must be
  used to specify the IP addresses to listen on.  Listening for RPC
  commands over a public network connection is insecure and should be
  disabled, so a warning is now printed if a user selects such a
  configuration.  If you need to expose RPC in order to use a tool like
  Docker, ensure you only bind RPC to your localhost, e.g. `docker run
  [...] -p 127.0.0.1:8332:8332` (this is an extra `:8332` over the
  normal Docker port specification).

- - The `rpcpassword` option now causes a startup error if the password
  set in the configuration 

[bitcoin-dev] Bitcoin Core 0.18.1 released

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version 0.18.1 is now available from:

  

Or through BitTorrent:


magnet:?xt=urn:btih:c3ba0cfee3ef8413098ac5e81db08a2670e9da8c=bitcoin-core-0.18.1=udp%3A%2F%2Ftracker.openbittorrent.com%3A80=udp%3A%2F%2Ftracker.opentrackr.org%3A1337=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969=udp%3A%2F%2Fzer0day.ch%3A1337=udp%3A%2F%2Fexplodie.org%3A6969

This is a new minor version release, including new features, various bug
fixes and performance improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  

To receive security and update notifications, please subscribe to:

  

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

The first time you run version 0.15.0 or newer, your chainstate database
will be converted to a new format, which will take anywhere from a few
minutes to half an hour, depending on the speed of your machine.

Note that the block database format also changed in version 0.8.0 and
there is no automatic upgrade code from before version 0.8 to version
0.15.0 or later. Upgrading directly from 0.7.x and earlier without
redownloading the blockchain is not supported.  However, as usual, old
wallet versions are still supported.

Compatibility
==

Bitcoin Core is supported and extensively tested on operating systems
using the Linux kernel, macOS 10.10+, and Windows 7 and newer. It is not
recommended to use Bitcoin Core on unsupported systems.

Bitcoin Core should also work on most other Unix-like systems but is not
as frequently tested on them.

- From 0.17.0 onwards, macOS <10.10 is no longer supported. 0.17.0 is
built using Qt 5.9.x, which doesn't support versions of macOS older than
10.10. Additionally, Bitcoin Core does not yet change appearance when
macOS "dark mode" is activated.

Known issues


Wallet GUI
- --

For advanced users who have both (1) enabled coin control features, and
(2) are using multiple wallets loaded at the same time: The coin control
input selection dialog can erroneously retain wrong-wallet state when
switching wallets using the dropdown menu. For now, it is recommended
not to use coin control features with multiple wallets loaded.

0.18.1 change log
=

### P2P protocol and network code
- - #15990 Add tests and documentation for blocksonly (MarcoFalke)
- - #16021 Avoid logging transaction decode errors to stderr (MarcoFalke)
- - #16405 fix: tor: Call `event_base_loopbreak` from the event's callback 
(promag)
- - #16412 Make poll in InterruptibleRecv only filter for POLLIN events 
(tecnovert)

### Wallet
- - #15913 Add -ignorepartialspends to list of ignored wallet options (luke-jr)

### RPC and other APIs
- - #15991 Bugfix: fix pruneblockchain returned prune height (jonasschnelli)
- - #15899 Document iswitness flag and fix bug in converttopsbt (MarcoFalke)
- - #16026 Ensure that uncompressed public keys in a multisig always returns a 
legacy address (achow101)
- - #14039 Disallow extended encoding for non-witness transactions (sipa)
- - #16210 add 2nd arg to signrawtransactionwithkey examples (dooglus)
- - #16250 signrawtransactionwithkey: report error when missing 
redeemScript/witnessScript (ajtowns)

### GUI
- - #16044 fix the bug of OPEN CONFIGURATION FILE on Mac (shannon1916)
- - #15957 Show "No wallets available" in open menu instead of nothing 
(meshcollider)
- - #16118 Enable open wallet menu on setWalletController (promag)
- - #16135 Set progressDialog to nullptr (promag)
- - #16231 Fix open wallet menu initialization order (promag) 
- - #16254 Set `AA_EnableHighDpiScaling` attribute early (hebasto) 
- - #16122 Enable console line edit on setClientModel (promag) 
- - #16348 Assert QMetaObject::invokeMethod result (promag)

### Build system
- - #15985 Add test for GCC bug 90348 (sipa)
- - #15947 Install bitcoin-wallet manpage (domob1812)
- - #15983 build with -fstack-reuse=none (MarcoFalke)

### Tests and QA
- - #15826 Pure python EC (sipa)
- - #15893 Add test for superfluous witness record in deserialization 
(instagibbs)
- - #14818 Bugfix: test/functional/rpc_psbt: Remove check for specific error 
message that depends on uncertain assumptions (luke-jr)
- - #15831 Add test that addmultisigaddress fails for watchonly addresses 
(MarcoFalke)

### Documentation
- - #15890 Remove text about txes always relayed from -whitelist (harding)

### Miscellaneous
- - #16095 Catch by reference not value in wallettool (kristapsk)
- - #16205 Replace fprintf with tfm::format (MarcoFalke)

[bitcoin-dev] Bitcoin Core 0.19.1 released

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

0.19.1 Release Notes
===

Bitcoin Core version 0.19.1 is now available from:

  

or through BitTorrent:

  
magnet:?xt=urn:btih:8b6ad1da5bbb24656234efc2370abc14781a6f83=bitcoin-core-0.19.1=udp%3A%2F%2Ftracker.openbittorrent.com%3A80=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969

This minor release includes various bug fixes and performance
improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  

To receive security and update notifications, please subscribe to:

  

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

Upgrading directly from a version of Bitcoin Core that has reached its EOL is
possible, but it might take some time if the datadir needs to be migrated. Old
wallet versions of Bitcoin Core are generally supported.

Compatibility
==

Bitcoin Core is supported and extensively tested on operating systems using
the Linux kernel, macOS 10.10+, and Windows 7 and newer. It is not recommended
to use Bitcoin Core on unsupported systems.

Bitcoin Core should also work on most other Unix-like systems but is not
as frequently tested on them.

- From Bitcoin Core 0.17.0 onwards, macOS versions earlier than 10.10 are no
longer supported, as Bitcoin Core is now built using Qt 5.9.x which requires
macOS 10.10+. Additionally, Bitcoin Core does not yet change appearance when
macOS "dark mode" is activated.

In addition to previously supported CPU platforms, this release's pre-compiled
distribution provides binaries for the RISC-V platform.

0.19.1 change log
=

### Wallet
- - #17643 Fix origfee return for bumpfee with feerate arg (instagibbs)
- - #16963 Fix `unique_ptr` usage in boost::signals2 (promag)
- - #17258 Fix issue with conflicted mempool tx in listsinceblock (adamjonas, 
mchrostowski)
- - #17924 Bug: IsUsedDestination shouldn't use key id as script id for 
ScriptHash (instagibbs)
- - #17621 IsUsedDestination should count any known single-key address 
(instagibbs)
- - #17843 Reset reused transactions cache (fjahr)

### RPC and other APIs
- - #17687 cli: Fix fatal leveldb error when specifying -blockfilterindex=basic 
twice (brakmic)
- - #17728 require second argument only for scantxoutset start action (achow101)
- - #17445 zmq: Fix due to invalid argument and multiple notifiers (promag)
- - #17524 psbt: handle unspendable psbts (achow101)
- - #17156 psbt: check that various indexes and amounts are within bounds 
(achow101)

### GUI
- - #17427 Fix missing qRegisterMetaType for `size_t` (hebasto)
- - #17695 disable File-\>CreateWallet during startup (fanquake)
- - #17634 Fix comparison function signature (hebasto)
- - #18062 Fix unintialized WalletView::progressDialog (promag)

### Tests and QA
- - #17416 Appveyor improvement - text file for vcpkg package list (sipsorcery)
- - #17488 fix "bitcoind already running" warnings on macOS (fanquake)
- - #17980 add missing #include to fix compiler errors (kallewoof)

### Platform support
- - #17736 Update msvc build for Visual Studio 2019 v16.4 (sipsorcery)
- - #17364 Updates to appveyor config for VS2019 and Qt5.9.8 + msvc project 
fixes (sipsorcery)
- - #17887 bug-fix macos: give free bytes to `F_PREALLOCATE` (kallewoof)

### Miscellaneous
- - #17897 init: Stop indexes on shutdown after ChainStateFlushed callback 
(jimpo)
- - #17450 util: Add missing headers to util/fees.cpp (hebasto)
- - #17654 Unbreak build with Boost 1.72.0 (jbeich)
- - #17857 scripts: Fix symbol-check & security-check argument passing 
(fanquake)
- - #17762 Log to net category for exceptions in ProcessMessages (laanwj)
- - #18100 Update univalue subtree (MarcoFalke)

Credits
===

Thanks to everyone who directly contributed to this release:

- - Aaron Clauson
- - Adam Jonas
- - Andrew Chow
- - Fabian Jahr
- - fanquake
- - Gregory Sanders
- - Harris
- - Hennadii Stepanov
- - Jan Beich
- - Jim Posen
- - João Barbosa
- - Karl-Johan Alm
- - Luke Dashjr
- - MarcoFalke
- - Michael Chrostowski
- - Russell Yanofsky
- - Wladimir J. van der Laan

As well as to everyone that helped with translations on
[Transifex](https://www.transifex.com/bitcoin/bitcoin/).

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEnerg3HBjJJ+wVHRoHkrtYphs0l0FAl5mN1QACgkQHkrtYphs

[bitcoin-dev] Bitcoin Core 0.20.1 released

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

0.20.1 Release Notes


Bitcoin Core version 0.20.1 is now available from:

  

Or through BitTorrent:


magnet:?xt=urn:btih:6e2c72d73d763465a725e3ae941b2b937edd0300=bitcoin-core-0.20.1=https%3A%2F%2Fopenbittorrent.com%2F=udp%3A%2F%2Ftracker.openbittorrent.com%3A80=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969

This minor release includes various bug fixes and performance
improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  

To receive security and update notifications, please subscribe to:

  

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 in some cases), then run the
installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
or `bitcoind`/`bitcoin-qt` (on Linux).

Upgrading directly from a version of Bitcoin Core that has reached its EOL is
possible, but it might take some time if the data directory needs to be 
migrated. Old
wallet versions of Bitcoin Core are generally supported.

Compatibility
==

Bitcoin Core is supported and extensively tested on operating systems
using the Linux kernel, macOS 10.12+, and Windows 7 and newer.  Bitcoin
Core should also work on most other Unix-like systems but is not as
frequently tested on them.  It is not recommended to use Bitcoin Core on
unsupported systems.

- From Bitcoin Core 0.20.0 onwards, macOS versions earlier than 10.12 are no
longer supported. Additionally, Bitcoin Core does not yet change appearance
when macOS "dark mode" is activated.

Known Bugs
==

The process for generating the source code release ("tarball") has changed in an
effort to make it more complete, however, there are a few regressions in
this release:

- - The generated `configure` script is currently missing, and you will need to
  install autotools and run `./autogen.sh` before you can run
  `./configure`. This is the same as when checking out from git.

- - Instead of running `make` simply, you should instead run
  `BITCOIN_GENBUILD_NO_GIT=1 make`.

Notable changes
===

Changes regarding misbehaving peers
- ---

Peers that misbehave (e.g. send us invalid blocks) are now referred to as
discouraged nodes in log output, as they're not (and weren't) strictly banned:
incoming connections are still allowed from them, but they're preferred for
eviction.

Furthermore, a few additional changes are introduced to how discouraged
addresses are treated:

- - Discouraging an address does not time out automatically after 24 hours
  (or the `-bantime` setting). Depending on traffic from other peers,
  discouragement may time out at an indeterminate time.

- - Discouragement is not persisted over restarts.

- - There is no method to list discouraged addresses. They are not returned by
  the `listbanned` RPC. That RPC also no longer reports the `ban_reason`
  field, as `"manually added"` is the only remaining option.

- - Discouragement cannot be removed with the `setban remove` RPC command.
  If you need to remove a discouragement, you can remove all discouragements by
  stop-starting your node.

Notification changes
- 

`-walletnotify` notifications are now sent for wallet transactions that are
removed from the mempool because they conflict with a new block. These
notifications were sent previously before the v0.19 release, but had been
broken since that release (bug
[#18325](https://github.com/bitcoin/bitcoin/issues/18325)).

PSBT changes
- 

PSBTs will contain both the non-witness utxo and the witness utxo for segwit
inputs in order to restore compatibility with wallet software that are now
requiring the full previous transaction for segwit inputs. The witness utxo
is still provided to maintain compatibility with software which relied on its
existence to determine whether an input was segwit.

0.20.1 change log
=

### Mining
- - #19019 Fix GBT: Restore "!segwit" and "csv" to "rules" key (luke-jr)

### P2P protocol and network code
- - #19219 Replace automatic bans with discouragement filter (sipa)

### Wallet
- - #19300 Handle concurrent wallet loading (promag)
- - #18982 Minimal fix to restore conflicted transaction notifications 
(ryanofsky)

### RPC and other APIs
- - #19524 Increment input value sum only once per UTXO in decodepsbt (fanquake)
- - #19517 psbt: Increment input value sum only once per UTXO in decodepsbt 
(achow101)
- - 

[bitcoin-dev] Bitcoin Core 0.20.0 released

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

0.20.0 Release Notes


Bitcoin Core version 0.20.0 is now available from:

  

Or through BitTorrent:


magnet:?xt=urn:btih:1845a0c66b6a728e183b9bd8c5d8c1611dddaaa3=bitcoin-core-0.20.0=https%3A%2F%2Fopenbittorrent.com%2F=udp%3A%2F%2Ftracker.openbittorrent.com%3A80=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969

This release includes new features, various bug fixes and performance
improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  

To receive security and update notifications, please subscribe to:

  

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 in some cases), then run the
installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
or `bitcoind`/`bitcoin-qt` (on Linux).

Upgrading directly from a version of Bitcoin Core that has reached its EOL is
possible, but it might take some time if the data directory needs to be 
migrated. Old
wallet versions of Bitcoin Core are generally supported.

Compatibility
==

Bitcoin Core is supported and extensively tested on operating systems
using the Linux kernel, macOS 10.12+, and Windows 7 and newer.  Bitcoin
Core should also work on most other Unix-like systems but is not as
frequently tested on them.  It is not recommended to use Bitcoin Core on
unsupported systems.

- From Bitcoin Core 0.20.0 onwards, macOS versions earlier than 10.12 are no
longer supported. Additionally, Bitcoin Core does not yet change appearance
when macOS "dark mode" is activated.

Known Bugs
==

The process for generating the source code release ("tarball") has changed in an
effort to make it more complete, however, there are a few regressions in
this release:

- - The generated `configure` script is currently missing, and you will need to
  install autotools and run `./autogen.sh` before you can run
  `./configure`. This is the same as when checking out from git.

- - Instead of running `make` simply, you should instead run
  `BITCOIN_GENBUILD_NO_GIT=1 make`.

Notable changes
===

P2P and network changes
- ---

 Removal of BIP61 reject network messages from Bitcoin Core

The `-enablebip61` command line option to enable BIP61 has been removed.
(#17004)

This feature has been disabled by default since Bitcoin Core version 0.18.0.
Nodes on the network can not generally be trusted to send valid messages
(including reject messages), so this should only ever be used when
connected to a trusted node.  Please use the alternatives recommended
below if you rely on this removed feature:

- - Testing or debugging of implementations of the Bitcoin P2P network protocol
  should be done by inspecting the log messages that are produced by a recent
  version of Bitcoin Core. Bitcoin Core logs debug messages
  (`-debug=`) to a stream (`-printtoconsole`) or to a file
  (`-debuglogfile=`).

- - Testing the validity of a block can be achieved by specific RPCs:

  - `submitblock`

  - `getblocktemplate` with `'mode'` set to `'proposal'` for blocks with
potentially invalid POW

- - Testing the validity of a transaction can be achieved by specific RPCs:

  - `sendrawtransaction`

  - `testmempoolaccept`

- - Wallets should not assume a transaction has propagated to the network
  just because there are no reject messages.  Instead, listen for the
  transaction to be announced by other peers on the network.  Wallets
  should not assume a lack of reject messages means a transaction pays
  an appropriate fee.  Instead, set fees using fee estimation and use
  replace-by-fee to increase a transaction's fee if it hasn't confirmed
  within the desired amount of time.

The removal of BIP61 reject message support also has the following minor RPC
and logging implications:

- - `testmempoolaccept` and `sendrawtransaction` no longer return the P2P reject
  code when a transaction is not accepted to the mempool. They still return the
  verbal reject reason.

- - Log messages that previously reported the reject code when a transaction was
  not accepted to the mempool now no longer report the reject code. The reason
  for rejection is still reported.

Updated RPCs
- 

- - The RPCs which accept descriptors now accept the new `sortedmulti(...)` 
descriptor
  type which supports multisig scripts where the public keys are sorted
  lexicographically in the resulting script.  (#17056)

- - The `walletprocesspsbt` 

[bitcoin-dev] Bitcoin Core 0.21.0 released

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

0.21.0 Release Notes


Bitcoin Core version 0.21.0 is now available from:

  

Or through BitTorrent:


magnet:?xt=urn:btih:665c5bdc6f49948e47c1098d91ace98bd216150e=bitcoin-core-0.21.0=udp%3A%2F%2Ftracker.openbittorrent.com%3A80=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969

This release includes new features, various bug fixes and performance
improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  

To receive security and update notifications, please subscribe to:

  

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 in some cases), then run the
installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
or `bitcoind`/`bitcoin-qt` (on Linux).

Upgrading directly from a version of Bitcoin Core that has reached its EOL is
possible, but it might take some time if the data directory needs to be 
migrated. Old
wallet versions of Bitcoin Core are generally supported.

Compatibility
==

Bitcoin Core is supported and extensively tested on operating systems
using the Linux kernel, macOS 10.12+, and Windows 7 and newer.  Bitcoin
Core should also work on most other Unix-like systems but is not as
frequently tested on them.  It is not recommended to use Bitcoin Core on
unsupported systems.

- From Bitcoin Core 0.20.0 onwards, macOS versions earlier than 10.12 are no
longer supported. Additionally, Bitcoin Core does not yet change appearance
when macOS "dark mode" is activated.

The node's known peers are persisted to disk in a file called `peers.dat`. The
format of this file has been changed in a backwards-incompatible way in order to
accommodate the storage of Tor v3 and other BIP155 addresses. This means that if
the file is modified by 0.21.0 or newer then older versions will not be able to
read it. Those old versions, in the event of a downgrade, will log an error
message "Incorrect keysize in addrman deserialization" and will continue normal
operation as if the file was missing, creating a new empty one. (#19954, #20284)

Notable changes
===

P2P and network changes
- ---

- - The mempool now tracks whether transactions submitted via the wallet or RPCs
  have been successfully broadcast. Every 10-15 minutes, the node will try to
  announce unbroadcast transactions until a peer requests it via a `getdata`
  message or the transaction is removed from the mempool for other reasons.
  The node will not track the broadcast status of transactions submitted to the
  node using P2P relay. This version reduces the initial broadcast guarantees
  for wallet transactions submitted via P2P to a node running the wallet. 
(#18038)

- - The size of the set of transactions that peers have announced and we 
consider
  for requests has been reduced from 10 to 5000 (per peer), and further
  announcements will be ignored when that limit is reached. If you need to dump
  (very) large batches of transactions, exceptions can be made for trusted
  peers using the "relay" network permission. For localhost for example it can
  be enabled using the command line option `-whitelist=relay@127.0.0.1`.
  (#19988)

- - This release adds support for Tor version 3 hidden services, and rumoring 
them
  over the network to other peers using
  [BIP155](https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki).
  Version 2 hidden services are still fully supported by Bitcoin Core, but the
  Tor network will start
  [deprecating](https://blog.torproject.org/v2-deprecation-timeline) them in the
  coming months. (#19954)

- - The Tor onion service that is automatically created by setting the
  `-listenonion` configuration parameter will now be created as a Tor v3 service
  instead of Tor v2. The private key that was used for Tor v2 (if any) will be
  left untouched in the `onion_private_key` file in the data directory (see
  `-datadir`) and can be removed if not needed. Bitcoin Core will no longer
  attempt to read it. The private key for the Tor v3 service will be saved in a
  file named `onion_v3_private_key`. To use the deprecated Tor v2 service (not
  recommended), the `onion_private_key` can be copied over
  `onion_v3_private_key`, e.g.
  `cp -f onion_private_key onion_v3_private_key`. (#19954)

- - The client writes a file (`anchors.dat`) at shutdown with the network 
addresses
  of the node’s two outbound block-relay-only peers (so called "anchors").