Skip to content

Latest commit

 

History

History
751 lines (584 loc) · 36.6 KB

release-notes.md

File metadata and controls

751 lines (584 loc) · 36.6 KB

Release notes now being edited on https://github.com/digibyte-core/digibyte-devwiki/wiki/22.0-Release-Notes-draft

After branching off for a major version release of DigiByte Core, use this template to create the initial release notes draft.

The release notes draft is a temporary file that can be added to by anyone. See /doc/developer-notes.md#release-notes for the process.

Create the draft, named "version Release Notes Draft" (e.g. "0.20.0 Release Notes Draft"), as a collaborative wiki in:

https://github.com/digibyte-core/digibyte-devwiki/wiki/

Before the final release, move the notes back to this git repository.

version Release Notes Draft

DigiByte Core version version is now available from:

https://digibyte.org/bin/digibyte-core-*version*/

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:

https://github.com/digibyte-core/digibyte/issues

To receive security and update notifications, please subscribe to:

https://digibyte.org/en/list/announcements/join/

How to Upgrade

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

DigiByte 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 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 another command without running the commands separately.

The nested RPC commands use bracket syntax (i.e. getwalletinfo()) and can be nested (i.e. getblock(getblockhash(1))). Simple queries can be done with square brackets where object values are accessed with either an array index or a non-quoted string (i.e. listunspent()[0][txid]). Both commas and spaces can be used to separate parameters in both the bracket syntax and normal RPC command syntax.

Network Activity Toggle

A RPC command and GUI toggle have been added to enable or disable all p2p network activity. The network status icon in the bottom right hand corner is now the GUI toggle. Clicking the icon will either enable or disable all p2p network activity. If network activity is disabled, the icon will be grayed out with an X on top of it.

Additionally the setnetworkactive RPC command has been added which does the same thing as the GUI icon. The command takes one boolean parameter, true enables networking and false disables it.

Out-of-sync Modal Info Layer

When DigiByte Core is out-of-sync on startup, a semi-transparent information layer will be shown over top of the normal display. This layer contains details about the current sync progress and estimates the amount of time remaining to finish syncing. This layer can also be hidden and subsequently unhidden by clicking on the progress bar at the bottom of the window.

Support for JSON-RPC Named Arguments

Commands sent over the JSON-RPC interface and through the digibyte-cli binary can now use named arguments. This follows the JSON-RPC specification for passing parameters by-name with an object.

digibyte-cli has been updated to support this by parsing name=value arguments when the -named option is given.

Some examples:

src/digibyte-cli -named help command="help"
src/digibyte-cli -named getblockhash height=0
src/digibyte-cli -named getblock blockhash=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
src/digibyte-cli -named sendtoaddress address="(snip)" amount="1.0" subtractfeefromamount=true

The order of arguments doesn't matter in this case. Named arguments are also useful to leave out arguments that should stay at their default value. The rarely-used arguments comment and comment_to to sendtoaddress, for example, can be left out. However, this is not yet implemented for many RPC calls, this is expected to land in a later release.

The RPC server remains fully backwards compatible with positional arguments.

Opt into RBF When Sending

A new startup option, -walletrbf, has been added to allow users to have all transactions sent opt into RBF support. The default value for this option is currently false, so transactions will not opt into RBF by default. The new bumpfee RPC can be used to replace transactions that opt into RBF.

Sensitive Data Is No Longer Stored In Debug Console History

The debug console maintains a history of previously entered commands that can be accessed by pressing the Up-arrow key so that users can easily reuse previously entered commands. Commands which have sensitive information such as passphrases and private keys will now have a (...) in place of the parameters when accessed through the history.

Retaining the Mempool Across Restarts

The mempool will be saved to the data directory prior to shutdown to a mempool.dat file. This file preserves the mempool so that when the node restarts the mempool can be filled with transactions without waiting for new transactions to be created. This will also preserve any changes made to a transaction through commands such as prioritisetransaction so that those changes will not be lost.

Final Alert

The Alert System was disabled and deprecated in DigiByte Core 0.12.1 and removed in 0.13.0. The Alert System was retired with a maximum sequence final alert which causes any nodes supporting the Alert System to display a static hard-coded "Alert Key Compromised" message which also prevents any other alerts from overriding it. This final alert is hard-coded into this release so that all old nodes receive the final alert.

GUI Changes

  • After resetting the options by clicking the Reset Options button in the options dialog or with the -resetguioptions startup option, the user will be prompted to choose the data directory again. This is to ensure that custom data directories will be kept after the option reset which clears the custom data directory set via the choose datadir dialog.

  • Multiple peers can now be selected in the list of peers in the debug window. This allows for users to ban or disconnect multiple peers simultaneously instead of banning them one at a time.

  • An indicator has been added to the bottom right hand corner of the main window to indicate whether the wallet being used is a HD wallet. This icon will be grayed out with an X on top of it if the wallet is not a HD wallet.

Low-level RPC changes

  • importprunedfunds only accepts two required arguments. Some versions accept an optional third arg, which was always ignored. Make sure to never pass more than two arguments.

  • The first boolean argument to getaddednodeinfo has been removed. This is an incompatible change.

  • RPC command getmininginfo loses the "testnet" field in favor of the more generic "chain" (which has been present for years).

  • A new RPC command preciousblock has been added which marks a block as precious. A precious block will be treated as if it were received earlier than a competing block.

  • A new RPC command importmulti has been added which receives an array of JSON objects representing the intention of importing a public key, a private key, an address and script/p2sh

  • Use of getrawtransaction for retrieving confirmed transactions with unspent outputs has been deprecated. For now this will still work, but in the future it may change to only be able to retrieve information about transactions in the mempool or if txindex is enabled.

  • A new RPC command getmemoryinfo has been added which will return information about the memory usage of DigiByte Core. This was added in conjunction with optimizations to memory management. See Pull #8753 for more information.

  • A new RPC command bumpfee has been added which allows replacing an unconfirmed wallet transaction that signaled RBF (see the -walletrbf startup option above) with a new transaction that pays a higher fee, and should be more likely to get confirmed quickly.

HTTP REST Changes

  • UTXO set query (GET /rest/getutxos/<checkmempool>/<txid>-<n>/<txid>-<n> /.../<txid>-<n>.<bin|hex|json>) responses were changed to return status code HTTP_BAD_REQUEST (400) instead of HTTP_INTERNAL_SERVER_ERROR (500) when requests contain invalid parameters.

Minimum Fee Rate Policies

Since the changes in 0.12 to automatically limit the size of the mempool and improve the performance of block creation in mining code it has not been important for relay nodes or miners to set -minrelaytxfee. With this release the following concepts that were tied to this option have been separated out:

  • incremental relay fee used for calculating BIP 125 replacement and mempool limiting. (1000 satoshis/kB)
  • calculation of threshold for a dust output. (effectively 3 * 1000 satoshis/kB)
  • minimum fee rate of a package of transactions to be included in a block created by the mining code. If miners wish to set this minimum they can use the new -blockmintxfee option. (defaults to 1000 satoshis/kB)

The -minrelaytxfee option continues to exist but is recommended to be left unset.

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/DigiByte-Qt (on Mac) or digibyted/digibyte-qt (on Linux).

Upgrading directly from a version of DigiByte 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 DigiByte Core are generally supported.

Compatibility

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

DigiByte Core is extensively tested on multiple operating systems using

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

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

======= Wallet changes

Segwit Wallet

DigiByte 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. dumpwallet/importwallet work, but will (in comments) list the corresponding P2PKH addresses for all keys, even those only used in segwit addresses. 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 0.16.0 will be rejected by previous versions. Also, version 0.16.0 will only create hierarchical deterministic (HD) wallets.

Replace-By-Fee by default in GUI

The send screen now uses BIP125 RBF by default, regardless of -walletrbf. There is a checkbox to mark the transaction as final.

The RPC default remains unchanged: to use RBF, launch with -walletrbf=1 or use the replaceable argument for individual transactions.

Wallets directory configuration (-walletdir)

DigiByte Core now has more flexibility in where the wallets directory can be located. Previously wallet database files were stored at the top level of the digibyte data directory. The behavior is now:

  • For new installations (where the data directory doesn't already exist), wallets will now be stored in a new wallets/ subdirectory inside the data directory by default.
  • For existing nodes (where the data directory already exists), wallets will be stored in the data directory root by default. If a wallets/ subdirectory already exists in the data directory root, then wallets will be stored in the wallets/ subdirectory by default.
  • The location of the wallets directory can be overridden by specifying a -walletdir=<path> option where <path> can be an absolute path to a directory or directory symlink.

Care should be taken when choosing the wallets directory location, as if it becomes unavailable during operation, funds may be lost.

Build: Minimum GCC bumped to 4.8.x

The minimum version of the GCC compiler required to compile DigiByte Core is now 4.8. No effort will be made to support older versions of GCC. See discussion in issue #11732 for more information. The minimum version for the Clang compiler is still 3.3. Other minimum dependency versions can be found in doc/dependencies.md in the repository.

Support for signalling pruned nodes (BIP159)

Pruned nodes can now signal BIP159's NODE_NETWORK_LIMITED using service bits, in preparation for full BIP159 support in later versions. This would allow pruned nodes to serve the most recent blocks. However, the current change does not yet include support for connecting to these pruned peers.

Performance: SHA256 assembly enabled by default

The SHA256 hashing optimizations for architectures supporting SSE4, which lead to ~50% speedups in SHA256 on supported hardware (~5% faster synchronization and block validation), have now been enabled by default. In previous versions they were enabled using the --enable-experimental-asm flag when building, but are now the default and no longer deemed experimental.

GUI changes

  • Uses of "µDGB" in the GUI now also show the more colloquial term "bits", specified in BIP176.
  • The option to reuse a previous address has now been removed. This was justified by the need to "resend" an invoice, but now that we have the request history, that need should be gone.
  • Support for searching by TXID has been added, rather than just address and label.
  • A "Use available balance" option has been added to the send coins dialog, to add the remaining available wallet balance to a transaction output.
  • A toggle for unblinding the password fields on the password dialog has been added. ======= 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. ======= From DigiByte Core 22.0 onwards, macOS versions earlier than 10.14 are no longer supported.

Notable changes

P2P and network changes

  • This release removes support for Tor version 2 hidden services in favor of Tor v3 only, as the Tor network dropped support for Tor v2 with the release of Tor version 0.4.6. Henceforth, DigiByte Core ignores Tor v2 addresses; it neither rumors them over the network to other peers, nor stores them in memory or to peers.dat. (#22050)

  • Added NAT-PMP port mapping support via libnatpmp. (#18077)

Updated RPCs

  • Due to BIP 350 being implemented, behavior for all RPCs that accept addresses is changed when a native witness version 1 (or higher) is passed. These now require a Bech32m encoding instead of a Bech32 one, and Bech32m encoding will be used for such addresses in RPC output as well. No version 1 addresses should be created for mainnet until consensus rules are adopted that give them meaning (e.g. through BIP 341). Once that happens, Bech32m is expected to be used for them, so this shouldn't affect any production systems, but may be observed on other networks where such addresses already have meaning (like signet). (#20861)

  • The getpeerinfo RPC returns two new boolean fields, bip152_hb_to and bip152_hb_from, that respectively indicate whether we selected a peer to be in compact blocks high-bandwidth mode or whether a peer selected us as a compact blocks high-bandwidth peer. High-bandwidth peers send new block announcements via a cmpctblock message rather than the usual inv/headers announcements. See BIP 152 for more details. (#19776)

  • getpeerinfo no longer returns the following fields: addnode, banscore, and whitelisted, which were previously deprecated in 0.21. Instead of addnode, the connection_type field returns manual. Instead of whitelisted, the permissions field indicates if the peer has special privileges. The banscore field has simply been removed. (#20755)

  • The following RPCs: gettxout, getrawtransaction, decoderawtransaction, decodescript, gettransaction, and REST endpoints: /rest/tx, /rest/getutxos, /rest/block deprecated the following fields (which are no longer returned in the responses by default): addresses, reqSigs. The -deprecatedrpc=addresses flag must be passed for these fields to be included in the RPC response. This flag/option will be available only for this major release, after which the deprecation will be removed entirely. Note that these fields are attributes of the scriptPubKey object returned in the RPC response. However, in the response of decodescript these fields are top-level attributes, and included again as attributes of the scriptPubKey object. (#20286)

  • When creating a hex-encoded digibyte transaction using the digibyte-tx utility with the -json option set, the following fields: addresses, reqSigs are no longer returned in the tx output of the response. (#20286)

  • The listbanned RPC now returns two new numeric fields: ban_duration and time_remaining. Respectively, these new fields indicate the duration of a ban and the time remaining until a ban expires, both in seconds. Additionally, the ban_created field is repositioned to come before banned_until. (#21602)

  • The getnodeaddresses RPC now returns a "network" field indicating the network type (ipv4, ipv6, onion, or i2p) for each address. (#21594)

  • getnodeaddresses now also accepts a "network" argument (ipv4, ipv6, onion, or i2p) to return only addresses of the specified network. (#21843)

  • The testmempoolaccept RPC now accepts multiple transactions (still experimental at the moment, API may be unstable). This is intended for testing transaction packages with dependency relationships; it is not recommended for batch-validating independent transactions. In addition to mempool policy, package policies apply: the list cannot contain more than 25 transactions or have a total size exceeding 101K virtual bytes, and cannot conflict with (spend the same inputs as) each other or the mempool, even if it would be a valid BIP125 replace-by-fee. There are some known limitations to the accuracy of the test accept: it's possible for testmempoolaccept to return "allowed"=True for a group of transactions, but "too-long-mempool-chain" if they are actually submitted. (#20833)

  • addmultisigaddress and createmultisig now support up to 20 keys for Segwit addresses. (#20867)

Changes to Wallet or GUI related RPCs can be found in the GUI or Wallet section below.

New RPCs

Build System

New settings

  • The -natpmp option has been added to use NAT-PMP to map the listening port. If both UPnP and NAT-PMP are enabled, a successful allocation from UPnP prevails over one from NAT-PMP. (#18077)

Updated settings

Changes to Wallet or GUI related settings can be found in the GUI or Wallet section below.

  • Passing an invalid -rpcauth argument now cause digibyted to fail to start. (#20461)

Tools and Utilities

  • A new CLI -addrinfo command returns the number of addresses known to the node per network type (including Tor v2 versus v3) and total. This can be useful to see if the node knows enough addresses in a network to use options like -onlynet=<network> or to upgrade to this release of DigiByte Core 22.0 that supports Tor v3 only. (#21595)

  • A new -rpcwaittimeout argument to digibyte-cli sets the timeout in seconds to use with -rpcwait. If the timeout expires, digibyte-cli will report a failure. (#21056)

Wallet

  • A new listdescriptors RPC is available to inspect the contents of descriptor-enabled wallets. The RPC returns public versions of all imported descriptors, including their timestamp and flags. For ranged descriptors, it also returns the range boundaries and the next index to generate addresses from. (#20226)

  • The bumpfee RPC is not available with wallets that have private keys disabled. psbtbumpfee can be used instead. (#20891)

  • The fundrawtransaction, send and walletcreatefundedpsbt RPCs now support an include_unsafe option that when true allows using unsafe inputs to fund the transaction. Note that the resulting transaction may become invalid if one of the unsafe inputs disappears. If that happens, the transaction must be funded with different inputs and republished. (#21359)

  • We now support up to 20 keys in multi() and sortedmulti() descriptors under wsh(). (#20867)

GUI changes

Low-level changes

RPC

  • The RPC server can process a limited number of simultaneous RPC requests. Previously, if this limit was exceeded, the RPC server would respond with status code 500 (HTTP_INTERNAL_SERVER_ERROR). Now it returns status code 503 (HTTP_SERVICE_UNAVAILABLE). (#18335)

  • Error codes have been updated to be more accurate for the following error cases (#18466):

    • signmessage now returns RPC_INVALID_ADDRESS_OR_KEY (-5) if the passed address is invalid. Previously returned RPC_TYPE_ERROR (-3).
    • verifymessage now returns RPC_INVALID_ADDRESS_OR_KEY (-5) if the passed address is invalid. Previously returned RPC_TYPE_ERROR (-3).
    • verifymessage now returns RPC_TYPE_ERROR (-3) if the passed signature is malformed. Previously returned RPC_INVALID_ADDRESS_OR_KEY (-5).

RPC changes

Low-level changes

  • The createrawtransaction RPC will now accept an array or dictionary (kept for compatibility) for the outputs parameter. This means the order of transaction outputs can be specified by the client.
  • The fundrawtransaction RPC will reject the previously deprecated reserveChangeKey option.
  • sendmany now shuffles outputs to improve privacy, so any previously expected behavior with regards to output ordering can no longer be relied upon.
  • The new RPC testmempoolaccept can be used to test acceptance of a transaction to the mempool without adding it.
  • JSON transaction decomposition now includes a weight field which provides the transaction's exact weight. This is included in REST /rest/tx/ and /rest/block/ endpoints when in json mode. This is also included in getblock (with verbosity=2), listsinceblock, listtransactions, and getrawtransaction RPC commands.
  • New fees field introduced in getrawmempool, getmempoolancestors, getmempooldescendants and getmempoolentry when verbosity is set to true with sub-fields ancestor, base, modified and descendant denominated in BTC. This new field deprecates previous fee fields, such as fee, modifiedfee, ancestorfee and descendantfee.
  • The new RPC getzmqnotifications returns information about active ZMQ notifications.

External wallet files

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

Newly created wallet format

If -wallet=<path> 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.

Low-level RPC changes

  • When digibyte is not started with any -wallet=<path> options, the name of the default wallet returned by getwalletinfo and listwallets RPCs is now the empty string "" instead of "wallet.dat". If digibyte is started with any -wallet=<path> options, there is no change in behavior, and the name of any wallet is just its <path> string.

  • Passing an empty string ("") as the address_type parameter to getnewaddress, getrawchangeaddress, addmultisigaddress, fundrawtransaction RPCs is now an error. Previously, this would fall back to using the default address type. It is still possible to pass null or leave the parameter unset to use the default address type.

  • Bare multisig outputs to our keys are no longer automatically treated as incoming payments. As this feature was only available for multisig outputs for which you had all private keys in your wallet, there was generally no use for them compared to single-key schemes. Furthermore, no address format for such outputs is defined, and wallet software can't easily send to it. These outputs will no longer show up in listtransactions, listunspent, or contribute to your balance, unless they are explicitly watched (using importaddress or importmulti with hex script argument). signrawtransaction* also still works for them.

Logging

  • The log timestamp format is now ISO 8601 (e.g. "2018-02-28T12:34:56Z").

  • When running digibyted with -debug but without -daemon, logging to stdout is now the default behavior. Setting -printtoconsole=1 no longer implicitly disables logging to debug.log. Instead, logging to file can be explicitly disabled by setting -debuglogfile=0.

Miner block size removed

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

Python Support

Support for Python 2 has been discontinued for all test files and tools.

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 digibyte 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 logging more informative (practicalswift)
  • #14197 7bee414 [psbt] Convert non-witness UTXOs to witness if witness sig created (achow101)
  • #14377 a3fe125 Check that a separator is found for psbt inputs, outputs, and global map (achow101)
  • #14356 7a590d8 Fix converttopsbt permitsigdata arg, add basic test (instagibbs)
  • #14453 75b5d8c Fix wallet unload during walletpassphrase timeout (promag)

GUI

  • #14403 0242b5a Revert "Force TLS1.0+ for SSL connections" (real-or-random)
  • #14593 df5131b Explicitly disable "Dark Mode" appearance on macOS (fanquake)

Build system

  • #14647 7edebed Remove illegal spacing in darwin.mk (ch4ot1c)
  • #14698 ec71f06 Add digibyte-tx.exe into Windows installer (ken2812221)

Tests and QA

  • #13965 29899ec Fix extended functional tests fail (ken2812221)
  • #14011 9461f98 Disable wallet and address book Qt tests on macOS minimal platform (ryanofsky)
  • #14180 86fadee Run all tests even if wallet is not compiled (MarcoFalke)
  • #14122 8bc1bad Test rpc_help.py failed: Check whether ZMQ is enabled or not (Kvaciral)
  • #14101 96dc936 Use named args in validation acceptance tests (MarcoFalke)
  • #14020 24d796a Add tests for RPC help (promag)
  • #14052 7ff32a6 Add some actual witness in rpc_rawtransaction (MarcoFalke)
  • #14215 b72fbab Use correct python index slices in example test (sdaftuar)
  • #14024 06544fa Add TestNode::assert_debug_log (MarcoFalke)
  • #14658 60f7a97 Add test to ensure node can generate all rpc help texts at runtime (MarcoFalke)
  • #14632 96f15e8 Fix a comment (fridokus)
  • #14700 f9db08e Avoid race in p2p_invalid_block by waiting for the block request (MarcoFalke)
  • #14845 67225e2 Add wallet_balance.py (jnewbery)

Documentation

  • #14161 5f51fd6 doc/descriptors.md tweaks (ryanofsky)
  • #14276 85aacc4 Add autogen.sh in ARM Cross-compilation (walterwhite81) ======= Tests

bitcoin/8.22.0

Credits

Thanks to everyone who directly contributed to this release:

(to be filled in at release time)

  • Andrew Chow
  • Chun Kuan Lee
  • David A. Harding
  • Eric Scrivner
  • fanquake
  • fridokus
  • Glenn Willen
  • Gregory Sanders
  • gustavonalle
  • John Newbery
  • Jon Layton
  • Jonas Schnelli
  • João Barbosa
  • Kaz Wesley
  • Kvaciral
  • Luke Dashjr
  • MarcoFalke
  • MeshCollider
  • Pieter Wuille
  • practicalswift
  • Russell Yanofsky
  • Sjors Provoost
  • Suhas Daftuar
  • Tim Ruffing
  • Walter
  • Wladimir J. van der Laan

0.17

As well as everyone that helped translating on Transifex.

As well as to everyone that helped with translations on Transifex.

bitcoin/8.22.0