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:

56

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!

Share:

Was this article helpful?

93 out of 132 found this helpful

Discover more

Blockchain

Blockchain investment: which "platform coin" has more investment value?

In the last lecture, I analyzed the "privacy currency" field in the blockchain industry. In this lecture, I...

Blockchain

Why do institutional investors use the exchange Bakkt as the gateway to the world of encryption?

Bakkt, the cryptocurrency exchange initiated by ICE, the parent company of the New York Stock Exchange, has officiall...

Blockchain

Research Report | Blockchain Economics Panorama and Future: Exchange Compliance

Author: BlockVC industry research team Source: BlockVC Editor's Note: The original title is "Postal Chain E...

Blockchain

Why did the mining pool business become the "sweet bun" of the exchange?

The three major domestic institutes are all involved in the mining pool business. As an exchange, how to use its own ...

Blockchain

Exchange Real Volume Report (on) | TokenInsight

Summary of points: 1. According to the report, 36% of the exchanges (11) have a real trading volume ratio higher than...

Market

What impact does BlackRock's submission of a physical Bitcoin ETF application have on the industry?

According to a public document, on the afternoon of June 15th, New York time, investment management giant BlackRock s...