Bitcoin version 0.19.0 Core client will be officially released, the bech32 address format is enabled by default and BIP70 is disabled.

According to Wladimir J. van der Laan, chief maintainer of the Bitcoin Core protocol, on github, the latest version of Bitcoin Core client 0.19.0 has been officially completed. This version of the client not only provides some new features (such as BIP158 block filtering). , which is used to replace the BIP 37's Bloom filter), which also partially enhances the privacy features of Bitcoin. It is worth noting that the new version of the client has enabled the bech32 address format compatible with the isolated witness by default, and BIP70 payment is disabled by default. Request for agreement.

It is reported that Bitcoin's next major version of the client v 0.20.0 is expected to be released in May 2020.

The following is the specific update instructions for the 0.19.0 version of the core client:

• Viewpoint | Why decentralized banks will take over the traditional financial ecology?
• Speed ​​reading | Marketers must read: Introduce the concept of decentralized branding; why is it important to adopt large-scale?
• BCH protocol upgrade countdown: More than 68% of BCH nodes support upgrade

The Bitcoin version 0.19.0 Core client is now available at:

Https://bitcoin core.org/bin/bitcoin-core-0.19.0/

This release is updated to include new features, bug fixes, performance improvements, and translation updates.

Developers can escalate errors using GitHub's issue tracker:

Https://github.com/bitcoin/bitcoin/issues

To receive security and update notifications, please subscribe:

Https://bitcoincore.org/en/list/announcements/join/

First, how to update

If you are running an older version of the client, please close it until it is completely closed (older versions may take a few minutes), then run the installer (Windows) or copy overwrite to /Applications/Bitcoin-Qt (Mac system) ) or bitcoind/bitcoin-qt (Linux system).

It is possible to upgrade directly from an older version of the Bitcoin Core client, but it may take some time if you need to migrate the datadir. Older versions of the Bitcoin Core client are usually supported.

Second, compatibility

The Bitcoin Core client has been extensively tested on multiple operating systems, including the Linux kernel operating system, macOS 10.10+, Windows 7, and newer operating systems. It is not recommended to use the Bitcoin Core client on unsupported systems.

Bitcoin Core works on other Unix-like OSs, but tests are relatively rare.

It should be noted that the macOS operating system is lower than the 10.10 version, and it is impossible to run the Bitcoin Core client higher than 0.17.0. This is because 0.17.0 is built using Qt 5.9.x, it does not support lower than 10.10. The version of the macOS operating system.

In addition, when macOS "dark mode" is activated, Bitcoin Core does not change its appearance.

Users running the macOS Catalina system may need to "right click" and then select "Open" to open Bitcoin Core.dmg. This is because Apple has proposed a new signature requirement, and the Bitcoin Core project has not yet complied with this requirement.

Third, significant changes

3, 1 new user documentation

Reduced memory is recommended for configuration adjustments to run the Bitcoin Core client on a limited system of memory. (#16339)

3, 2 new RPC

1. getbalances returns an object containing all the balances ( mine , untrusted_pending and immature ). For more information, see the RPC help section of getbalances. The new RPC is designed to replace the balance fields in getbalance , getunconfirmedbalance and getwalletinfo . These old calls and fields may be removed in a future release. (#15930, #16239)
2. setwalletflag sets and removes the wallet flag, enabling or disabling features specific to existing wallets, such as the new avoid_reuse feature recorded elsewhere in these release notes. (#13756)
3. getblockfilter gets the BIP158 filter of the specified block. This RPC is only enabled when a block filter has been created with the -blockfilterindex configuration option. (#14121)

3, 3 new settings

1. -blockfilterindex allows BIP158 block filters to be created for the entire blockchain. The filter will be created in the background and will currently take up approximately 4GB of space. Note: Although local users can get block filters using getblockfilter RPC, this version of Bitcoin Core does not provide block filters on P2P networks. (#14121)

3, 4 updated settings

1. whitebind and whitelist now accept a list of permissions to provide whitebind that connect using the specified interface or IP address. If no address or CIDR network is used to specify permissions, the implicit default permissions are the same as in earlier versions. For more information on the available permissions, see the bitcoind -help output for both options (#16248)
2. Users who set custom dbcache values ​​can increase their settings slightly without using any real memory. Recent changes have reduced memory usage by about 9% and made chained state calculations more accurate (previously it underestimated memory usage). For example, if the previously set value is "450", using approximately the same amount of real memory, you can now set the value to "500". (#16957)

3, 5 updated RPC

Note: Some of the low-level RPC changes that are primarily used for testing are placed in the low-level changes section below.

1. sendmany no longer has the minconf parameter. This parameter is not well specified, even if the wallet's currency selection is successful, it will cause an RPC error. For users who want to influence currency selection, use the current -spendzeroconfchange , -limitancestorcount , -limitdescendantcount and -walletrejectlongchains configuration parameters. (#15596)
2. getbalance and sendtoaddress , plus the new RPC getbalances and createwallet , now accept an "avoid_reuse" parameter that controls whether the address already used should be included in the operation. In addition, even if this feature has not been enabled with the -avoidpartialspends command line flag, sendtoaddress will avoid some overhead when avoid_reuse is enabled, as failure to use "wrong" UTXO in case of address reuse. (#13756)
3. RPC with the include_watch only parameter or the includeWatching option now defaults to true for read-only wallets. The affected RPCs are: getbalance , listreceivedbyaddress , listreceivedbylabel , listtransactions , listsinceblock , gettransaction , walletcreatefundedpsbt and fundrawtransaction . (#16383)
4. If the wallet flag " avoid_reuse " is enabled, listunspent now returns a "reused" bool for each output. (#13756)
5. getblockstats now uses BlockUndo data instead of the transaction index to make it faster, instead of relying on the -txindex configuration option, and all untrimmed blocks have this feature. (#14802)
6. utxoupdatepsbt now accepts a descriptors parameter that will fill in the input and output scripts and Keys when known. When a descriptor is provided to show that they are using the quarantine witness (segwit) output, the P2SH-witness input will be populated from the UTXO set. See the RPC help text for more information. (#15427)
7. If the transaction fee exceeds the value of the configuration option -maxtxfee , sendrawtransaction and testmempoolaccept will no longer accept the allowhighfees parameter to make the mempool accept failure. When any RPC is called with the maxfeerate parameter, there is now a hard-coded preset maximum rate that can be changed. (#15620)
8. getmempoolancestors , getmempooldescendants , getmempoolentry and getrawmempool no longer return range fields unless the configuration option -deprecatedrpc=size used. Instead, the new vsize field and the virtual size of the transaction will be returned (consistent with other RPCs such as getrawtransaction ). (#15637)
9. getwalletinfo now contains a scanning field, which can be false (no scanning), or an object that contains the duration and progress information of the wallet scan history block to see the transactions that affect its balance. (#15730)
10. gettransaction now accepts the third (boolean) argument verbose . If set to true , a new decode field will be added to the response containing the decoded transaction. When passing verbose , this field is equivalent to RPC decoderawtransaction or RPC getrawtransaction . (#16185, #16866, #16873)
11. createwallet accepts a new passphrase parameter. If set, this will create a new wallet encrypted with the given passphrase. If not set (the default) or set to an empty string, no encryption will be used. (#16394)
12. getchaintxstats RPC now returns the additional key for window_final_block_height . (#16695)
13. getmempoolentry now provides a weight field containing the transaction weights defined in BIP141. (#16647)
14. getnetworkinfo and getpeerinfo commands now contain a new field with a decoded network service flag. (#16786)
15. getdescriptorinfo now returns an extra checksum field containing the checksum of the unmodified descriptor provided by the user. (#15986)
16. joinpsbts now performs an unordered processing of the resulting PSBT input and output sequences. Previously, input and output were added in the order in which PSBT was provided, which made the association of input and output easy and thus unfavorable for privacy (Translator's Note: New joinpsbts enhance privacy protection).
17. If the -walletrbf configuration option is set to true , walletcreatefundedpsbt will now issue a BIP125 Replace-by-Fee signal. (#15911)

3, 6 GUI (Graphical User Interface) changes

1. The GUI wallet now provides a bech32 address by default. The user can change the address type using the GUI switch during invoice generation, or change the default address type using the -addresstype configuration option. (#15711, #16497)
2. In the 0.18.0 version of the wallet, the ./configure flag was introduced to allow BIP70 support to be disabled in the GUI (support is enabled by default). In the 0.19.0 version of the wallet, this flag is now disabled by default. If you want to compile BIP70 in the GUI, you can pass --enable-bip70 to ./configure . (#15584)

3, 7 Deprecated or deleted configuration options

1. -mempoolreplacement has been removed, although the default node behavior remains the same. This option previously allowed the user to block the node from accepting or relaying BIP125 transaction replacements. It is different from the configuration option -walletrbf continues to exist. (#16171)

3, 8 discarded or deleted RPC

1. bumpfee no longer accepts the totalFee option, unless the configuration parameter deprecatedrpc=totalFee , this parameter will be completely removed in subsequent versions. (#15996)
2. bumpfee has a new fee_rate option to replace the deprecated totalFee . (#16727)
3. generate has been officially removed after it was deprecated in Bitcoin Core 0.18. Please use generatetoaddress RPC instead. (#15492)

3, 9 P2P changes

1. BIP 61 rejection messages are deprecated in version 0.18, they are now disabled by default, but you can enable it by setting the -enablebip61 command line option. The BIP61 rejection message will be completely removed in future versions of the client. (#14054)
2. To eliminate the well-known denial of service vectors in Bitcoin Core, especially for nodes with spinning -peerbloomfilters , the new version of the client has -peerbloomfilters the default value of the -peerbloomfilters configuration option to false . This prevents the Bitcoin Core client from sending BIP111 NODE_BLOOM service flags, accepting BIP37 BLOOM filters or serving merkle blocks or transactions matching BLOOM filters. Users who still wish to provide BLOOM filter support can set the configuration option to true to re-enable support for BIP111 and BIP37, or use the updated -whitebind and -whitelist configuration options described elsewhere in this release note. Specific peers enable BIP37 support. In the near future, light clients using public BIP111/BIP37 nodes should still be able to connect to earlier versions of Bitcoin Core and manually enable BIP37 supported nodes, but developers of such software should consider migrating to use specific BIP37. Node or alternative transaction filtering system. (#16152)
3. By default, the Bitcoin Core client will now create two additional outbound connections dedicated to block relays. No transaction or address information will be processed on these connections. These connections are designed to add little extra memory or bandwidth resource requirements, but can make some partitioning attacks more difficult to perform. (#15759)

3, 10 Miscellaneous CLI changes

1. The testnet field in bitcoin-cli -getinfo has been renamed to chain and now returns the current network name defined in BIP70 (main, test, regtest). (#15566)

Fourth, low level changes

4, 1 RPC

1. getblockchaininfo no longer returns the bip9_softforks object. Instead, the information is moved to the softforks object, and another type field describes how the Bitcoin Core client determines if the soft fork is active (for example, BIP9 or BIP90). For more information, see the RPC help. (#16060)
2. getblocktemplate no longer returns a rules array containing CSV and segwit (currently active BIP9 deployment). (#16060)
3. getrpcinfo now returns a logpath field with the path debug.log . (#15483)

4, 2 test

1. The degraded test chain enabled by the -regtest command line flag now requires transactions to not violate standard policies by default. This is the same as the default value used by the main network, making it easier to test the behavior of the main network on the regtest test network. Note that by default, the test network still allows non-standard transactions, and the -acceptnonstdtxn command line flag can be used to locally adjust the policy for both test chains. (#15891)

4, 3 configuration

1. Settings specified in the default section but not specified in a specific part of the network (such as a test network) will now generate an error that prevents the startup, not just a warning, unless the network is the primary network. This will prevent the settings for the primary network from being applied to the test network or the regtest test network. (#15629)
2. On platforms that support thread_local , you can thread_local the log line with the name that caused the log thread. To enable this behavior, use -logthreadnames=1 . (#15849)

4, 4 network

1. When acquiring a transaction announced by multiple peer nodes, clients of earlier versions of Bitcoin Core will receive the order of notifications from these peers and then download the transaction in turn until the transaction is received. In the new version of the client, the download logic has been changed to random access and tends to send download requests to the outbound peer instead of the inbound peer. This fixes an issue where an inbound peer might prevent a node from getting a transaction. (#14897, #15834)
2. If the user is using the Tor hidden service, the Bitcoin Core client will also bind to the standard port 8333 (even if a different port is configured for the transparent network connection), which prevents the node identity from being leaked by using the same non-default port number. (#15651)

4, 5 Mempool and transaction relay

1. Allow each package to have an additional single ancestor transaction. Previously, if a transaction in mempool had 25 sub-transactions, or if it traded more than 101,000 vbytes with all of its children, then as a child transaction, the newly accepted transaction would be ignored. The new client will now allow an additional child transaction, provided it is a direct child and the child transaction size does not exceed 10,000 vbytes. This allows a two-party contractual agreement like Lightning Network to provide each participant with a child-Pays-For-Parent fee output without allowing a malicious participant to fill the entire package. This prevents another participant from spending their output. (#15681)
2. Transactions that are exported as v1 to v16 witness versions (future segregated witness versions) are now accepted into mempool for relaying and mining operations. Attempting to use these outputs is still prohibited by the policy. When this change is widely used, the wallet and service can accept any valid bech32 bitcoin address without worrying that future segregated witness transaction payments will fall into an unconfirmed state. (#15846)
3. Traditional transactions (transactions without quarantine witness input) must now be sent using the traditional encoding format, enforcing the rules specified in BIP144. (#14039)

4, 5 wallet

1. In pruning mode, a rescan triggered by importwallet , importpubkey , importaddress or importprivkey RPC will only fail if the block is pruned. Previously, when -prune was set, it failed. This change allows -prune set to a high value (such as disk size), and any calls to the imported RPC will not fail until the first block is pruned. . (#15870)
2. When creating a transaction with a cost higher than -maxtxfee (default is 0.1btc), the RPC commands walletcreatefundedpsbt and fundrawtransaction will now fail instead of reducing the cost. Note that the feeRate parameter is specified for every 1,000 vbytes of BTC, not for each vbyte of satoshi. (#16257)
3. A new wallet flag, avoid_reuse (default is off) has been added. When enabled, the wallet will distinguish between used and unused addresses, and by default does not use the former in currency selection. When this flag is set on an existing wallet, the blockchain needs to be rescanned to properly mark the previously used destination. Coupled with "avoid some expenses" (features added in Bitcoin Core v0.17.0), this eliminates a serious privacy issue where a malicious user can send a small payment to a previously paid address (the address will then It is included in the irrelevant input of future payments) to track expenses. (#13756)

4, 6 development system changes

1. For current project development, Python requires >=3.5 version. This includes building systems, testing frameworks, and linter. The lowest supported value (version 3.4) was deprecated in March 2019. (#14954)
2. The supported miniUPnPc API version has a minimum of 10. This is compatible with Ubuntu 16.04 LTS and Debian 8 libminiupnpc-dev packages. Please note that on Debian, this package is still vulnerable to CVE-2017-8798 (jessie only) and CVE-2017-1000494 (including jessie and stretch versions). (#15993)

Five, 0.19.0 change log (omitted)

Interested readers can view the original text: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.19.0.md

6. List of developers participating in the contribution

Thanks to all the developers who participated directly in the software release, they are: (Translator's Note: in no particular order)

1. 251
2. Aaron Clauson
3. Akio Nakamura
4. Alistair Mann
5. Amiti Uttarwar
6. Andrew Chow
7. Andrewtoth
8. Anthony Towns
9. Antoine Riard
10. Aseem Sood
11. Ben Carman
12. Ben Woosley
13. Bpay
14. Carl Dong
15. Carnhof Daki
16. Chris Capobianco
17. Chris Moore
18. Chuf
19. Clashic
20. Clashicly
21. Cory Fields
22. Daki Carnhof
23. Dan Gershony
24. Daniel Edgecumbe
25. Daniel Kraft
26. Daniel McNally
27. Darosior
28. David A. Harding
29. David Reikher
30. Douglas Roark
31. Elichai Turkel
32. Emil
33. Emil Engler
34. Ezegom
35. Fabian Jahr
36. Fanquake
37. Felix Weis
38. Ferdinando M. Ametrano
39. Fridokus
40. Gapeman
41. GChuf
42. Gert-Jaap Glasbergen
43. Giulio Lombardo
44. Glenn Willen
45. Graham Krizek
46. Gregory Sanders
47. Grim-trigger
48. Gwillen
49. Hennadii Stepanov
50. Jack Mallers
51. James Hilliard
52. James O'Beirne
53. Jan Beich
54. Jeremy Rubin
55. JeremyRand
56. Jim Posen
57. John Bampton
58. John Newbery
59. Jon Atack
60. Jon Layton
61. Jonas Schnelli
62. Jonathan "Duke" Leto
63. João Barbosa
64. Joonmo Yang
65. Jordan Baczuk
66. Jorge Timón
67. Josu Goñi
68. Julian Fleischer
69. Karl-Johan Alm
70. Kaz Wesley
71. Keepkeyjon
72. Kirill Fomichev
73. Kristaps Kaupe
74. Kristian Kramer
75. Larry Ruane
76. Lenny Maiorani
77. LongShao007
78. Luca Venturini
79. Lucash-dev
80. Luke Dashjr
81. Marcoagner
82. MarcoFalke
83. Marcuswin
84. Martin Ankerl
85. Martin Zumsande
86. Matt Corallo
87. MeshCollider
88. Michael Folkson
89. Miguel Herranz
90. Nathan Marley
91. Neha Narula
92. Nicolas.dorier
93. Nils Loewen
94. Nkustolas
95. Orient
96. Patrick Strateman
97. Peter Bushnell
98. Peter Wagner
99. Pieter Wuille
100. Practicalswift
101. Qmma
102. R8921039
103. RJ Rybarczyk
104. Russell Yanofsky
105. Samuel Dobson
106. Sebastian Falbesoner
107. Setpill
108. Shannon1916
109. Sjors Provoost
110. Soroosh-sdi
111. Steven Roose
112. Suhas Daftuar
113. Tecnovert
114. THETCR
115. Tim Ruffing
116. Tobias Kaderle
117. Torkel Rogstad
118. Ulrich Kempken
119. Whythat
120. William Casarin
121. Wladimir J. van der Laan
122. Zenosage

We will continue to update Blocking; if you have any questions or suggestions, please contact us!