from: https://cointelegraph.com/news/new-bitcoin-core-software-update-uses-bech32-addresses-by-default

***

Bitcoin Core 0.19.0 Released: Here’s What’s New

Today, November 24, 2019, marks the official release of Bitcoin Core 0.19.0, the 19th major release of Bitcoin’s original software client launched by Satoshi Nakamoto almost 11 years ago and still the dominant Bitcoin implementation on the network today. (Though due to an issue that came to light in a late stage of the Bitcoin Core 0.19.0 release process, the version released for download is actually 0.19.0.1.) Overseen by Bitcoin Core lead maintainer Wladimir van der Laan, this latest major release was developed by over a hundred contributors over a span of about six months.

The result of 550 merged pull requests, Bitcoin Core 0.19.0 includes a range of performance improvements, modernizations and bug fixes, as well as other changes.

Here’s an overview of some of these changes.

Bech32 Addresses by Default in the GUI

The “bech32” address format (BIP 173) had already been introduced in Bitcoin Core 0.16.0, released in early 2018, but is now for the first time set as the default option in the Bitcoin Core wallet Graphical User Interface (GUI).

Bech32 addresses are the addresses starting with “bc1” (as opposed to addresses starting with a 1 or a 3.) These addresses are also a bit longer, but use fewer different characters than the current address format, as there is no longer a distinction between lowercase and capital letters. (This reduces the potential for human mistakes, for example, when an address is read out loud.) Bech32 addresses are also designed to limit mistakes caused by typos.

Additionally, bech32 offers benefits in the context of SegWit. Some wallets that offer SegWit — including the Bitcoin Core wallet by default up until now — do so by “wrapping” it into P2SH outputs (with addresses starting with a “3”). To spend bitcoin from such an address, users must reveal a piece of code — the “redeem script” — to show that the bitcoin were really locked up in a SegWit output. With the new bech32 addresses, this step can be skipped, which means that spending from a SegWit output will require a little less data to be transmitted over the Bitcoin network and included in the blockchain. This makes transactions from a bech32 output even cheaper than SegWit transactions from a P2SH output.

Since not all bitcoin wallets support sending to bech32 addresses yet, Bitcoin Core 0.19.0 users will still be able to optionally generate a PS2H receiving address instead, through a toggle in the GUI.

Two Block-Only Outbound Connections Extra by Default

Bitcoin nodes connect to several other Bitcoin nodes, together forming the peer-to-peer network. Over this network, the nodes share blocks, transactions and some additional transaction data.

But the peer-to-peer network can be subject to attacks, such as “partitioning attacks.” If an attacker controls a large enough number of Bitcoin nodes, it can potentially “cut off” certain parts of the Bitcoin network (or even specific nodes) by intercepting all traffic to it. The partitioned part of the network could then, for example, be fooled into accepting a minority chain — not the longest chain — as valid, which could, in turn, open the door to double-spend attacks.

A partitioning attack is countered if a node in the partitioned part of the network has even just one connection to an honest node on the main network. It would then receive and relay all transactions and blocks and would reject the minority chain in favor of the majority chain.

One way to realize this, and to make partitioning attacks harder to pull off, is to have nodes establish more connections to one another. More connections do come with more memory and bandwidth requirements, however; there is a trade-off.

Bitcoin Core 0.19.0 increases the default for outgoing connections by two, but — cleverly — these two extra connections are only used to relay blocks — they do not relay transactions or additional transaction data. This increases the added bandwidth requirements minimally, while still making partitioning attacks harder to pull off successfully.

Bloom Filters Deprecated

Bitcoin Core is a full node implementation, which means that it downloads and verifies all Bitcoin blocks. While this is optimally secure, it doesn’t make it very well suited for low-resource computing devices, like mobile phones. Mobile wallets (as well as some desktop wallets) are, therefore, usually “light clients”: these only download transactions and (parts of) blocks that concern them specifically.

One way to do this is with Bloom Filters, used by a couple of wallets today. In short, Bloom Filters are a cryptographic trick used by light clients to request relevant data from more or less random full nodes on the network. Unfortunately, however, it has become clear over the years that Bloom Filters are rather privacy-unfriendly: They essentially reveal all of their addresses to the full node. On top of that, supporting Bloom Filter requests does come at a cost in CPU and disk space for full nodes — with no direct benefit for the full node itself.

For the latter reason in particular, Bitcoin Core 0.19.0 no longer supports Bloom Filter requests by default. Users can still switch the default to support Bloom Filters if they so choose.

It’s also worth noting that the Bitcoin network as a whole will almost certainly continue to support Bloom Filters for years to come, even if no one switches their defaults, simply because older Bitcoin Core nodes typically continue to be in use for years after new versions have been released.

More Support for Compact Client-Side Block Filtering

An alternative to Bloom Filters is a newer solution called “compact client-side block filtering” (BIP 158). Compact client-side block filtering essentially turns the Bloom Filter trick on its head. Instead of light wallets creating filters to send to full nodes, full nodes create filters for each block. Light clients can then use these filters to figure out if transactions relevant to them may have happened in a block. If so, the light wallet will fetch the whole block and pick any relevant transaction data out of it.

Bitcoin Core 0.19.0 continues to move toward supporting compact client-side block filtering. Bitcoin Core nodes could already create the filters locally, but Bitcoin Core 0.19.0 users can now also make them available through a remote procedure call (RPC), for applications running on top of the node (like a wallet).

The filters are not yet available over the peer-to-peer network, however. This means that a Bitcoin Core 0.19.0 node will not automatically send filters to other Bitcoin users’ wallets. This feature could be added to a future Bitcoin Core release — or Bitcoin Core 0.19.0 users could opt to offer the feature through a custom application running on top of their Bitcoin Core node.

Payment Protocol Support Disabled From GUI

The Payment Protocol (BIP 70) was designed several years ago to improve Bitcoin’s payment experience. On top of the regular payment as broadcasted to the Bitcoin network, a user and a merchant would communicate additional details about a payment, such as a human-readable destination address (the name of the merchant) and a refund address in case something went wrong with the purchase.

While Bitcoin Core integrated the Payment Protocol in its GUI, the standard was never widely adopted. Instead, most wallets still use the more basic URI scheme (BIP 21) to receive payments: The clickable link or scannable QR-code format that, for example, communicates the payment address and amount. (The only notable exception today is payment processor BitPay, which does not support the URI scheme but uses a modified version of BIP 70.)

Perhaps more importantly than the lack of adoption, the BIP 70 payments protocol has been suffering a number of security and privacy vulnerabilities over the years. Some wallets have, therefore, actively rejected to implement the protocol. Bitcoin Core, too, had been planning to deprecate BIP 70 for some time, as maintenance of it wasn’t considered worth the effort — but BitPay’s adoption of it stalled this process.

In Bitcoin Core 0.19.0, BIP 70 has been removed from the GUI by default after all. Bitcoin Core 0.19.0 users would have to compile their node with a special configuration to still make use of the feature.

Other…

Besides the changes mentioned above, Bitcoin Core 0.19.0 comes with a long list of smaller improvements and modernizations.

It’s now possible to start a pruned node immediately from setup, for example, which lets users with little disk space easily start up a new Bitcoin node. Bitcoin Core 0.19.0 also includes new features for the Partially Signed Bitcoin Transactions (PSBT) protocol, which is useful for multisignature and CoinJoin transactions. Likewise, there are several improvements in the domain of wallet descriptors, which is particularly useful for programmers working on Bitcoin applications. Bitcoin Core 0.19.0 nodes will also accept and relay transactions that use a future SegWit version to ensure that upcoming upgrades will proceed smoothly.

For a more extensive list of upgrades, also see the Bitcoin Core 0.19.0.1 release notes.

from: https://bitcoinmagazine.com/articles/bitcoin-core-0-19-0-released-heres-whats-new

***

[bitcoin-core-dev] Bitcoin Core 0.19.0 release candidate 3 available

Wladimir J. van der Laan laanwj at gmail.com
Wed Oct 30 15:57:33 UTC 2019

• Previous message: [bitcoin-core-dev] Bitcoin Core 0.19.0 release candidate 1 available
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Binaries for bitcoin Core version 0.19.0rc3 are available from:

    https://bitcoincore.org/bin/bitcoin-core-0.19.0/test.rc3/

Source code can be found in git under the signed tag

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

This is a release candidate for a new major version release.

Preliminary release notes for the release can be found here:

    https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.19.0-Release-Notes-Draft

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

An issue has been opened on github to report experiences while testing:

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

Please report bugs to the issue tracker:

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

Changes since rc1:

### RPC and other APIs
- - #17131 fix -rpcclienttimeout 0 option (fjahr)
- - #17249 Add missing deque include to fix build (jbeich)

### GUI
- - #17135 Make polling in ClientModel asynchronous (promag)
- - #17120 Fix start timer from non QThread (promag)
- - #17257 disable font antialiasing for QR image address (fanquake)

### Tests and QA
- - #17158 Fix fs_tests for unknown locales (carnhofdaki)

### Miscellaneous
- - #17184 util: Filter out macos process serial number (hebasto)
- - #17085 init: Change fallback locale to C.UTF-8 (laanwj)
- - #17095 util: Filter control characters out of log messages (laanwj)

### Documentation
- - #17111 update bips.md with buried BIP9 deployments (MarcoFalke)

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEnerg3HBjJJ+wVHRoHkrtYphs0l0FAl25sqgACgkQHkrtYphs
0l1SWwf9Gzt8JteL+LPqqrgB+KnE7BG8b+q9VTZ0S9zjeHwBunohEg2HF3VPWjIj
K1CpKbiIOiHtRpyIRAN8OM4GmYfUTh+u3Uvk2s+xTyp6SibMx3yQy7tXVY5iSlcE
ht3G29tOewIzx8z2ahCAfX5UKgOastaFRgQlW/zHt4pSwB7OEOFz3F/kHl7om8fR
ezOU5ON+FYthVmJS2wh6VqwzVzGprQ/SA1nBj4KQhJ9NoiGqlasShNaCEws/7ujB
FaKLhrjXQGnMAWbnaPYe2ttAUZnGNaJWmPOkMp2c67jH6+jZXMFIfB6dOvoM2Wvt
auyZbIGF8QqbU+A98fkK/hrEtoXQCQ==
=XHFp
-----END PGP SIGNATURE-----

from: https://lists.linuxfoundation.org/pipermail/bitcoin-core-dev/2019-October/000083.html