Due to last-minute issues, 32.0, although tagged, was never<br />fully announced or released.<br /><br />Bitcoin Core version 32.1 is now available from:<br /><br />  &lt;https://bitcoincore.org/bin/bitcoin-core-32.1/&gt;<br /><br />This release includes new features, various bug fixes and performance<br />improvements, as well as updated translations.<br /><br />Please report bugs using the issue tracker at GitHub:<br /><br />  &lt;https://github.com/bitcoin/bitcoin/issues&gt;<br /><br />To receive security and update notifications, please subscribe to:<br /><br />  &lt;https://bitcoincore.org/en/list/announcements/join/&gt;<br /><br />With the release of this new major version, versions 29.x and<br />older are at "End of Life" and will no longer receive updates.<br /><br />In accordance with our [security policy](https://bitcoincore.org/en/security-advisories/), any **easily discoverable** vulnerabilities fixed in this<br />release will be disclosed as soon as fixed releases are available for all maintained major versions.<br /><br />Under the regular disclosure schedule, we will disclose the following in two weeks:<br /><br />* Medium and high severity vulnerabilities fixed in 30.0. There are 3 of these.<br /><br />* Low severity vulnerabilities fixed in 32.1. There are 0 of these.<br /><br />How to Upgrade<br />==============<br /><br />If you are running an older version, shut it down. Wait until it has completely<br />shut down (which might take a few minutes in some cases), then run the<br />installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on macOS)<br />or `bin/` and `libexec/` (on Linux).<br /><br />Upgrading directly from a version of Bitcoin Core that has reached its EOL is<br />possible, but it might take some time if the data directory needs to be migrated. Old<br />wallet versions of Bitcoin Core are generally supported.<br /><br />Compatibility<br />==============<br /><br />Bitcoin Core is supported and tested on the following operating systems or newer:<br />Linux Kernel 3.17, macOS 14, and Windows 10 (version 1903). Bitcoin<br />Core should also work on most other Unix-like systems but is not as<br />frequently tested on them. It is not recommended to use Bitcoin Core on<br />unsupported systems.<br /><br />Notable changes<br />===============<br /><br />P2P and network changes<br />-----------------------<br /><br />- Tor hidden services that are created automatically by Bitcoin Core will have<br />  [PoW defenses](https://tpo.pages.torproject.net/onion-services/ecosystem/technology/security/pow/)<br />  enabled if the Tor daemon supports that. (#33414)<br />- To reduce memory and CPU usage during periods of high transaction volume,<br />  rate-limiting of outgoing transaction relay has been changed to use a global<br />  backlog instead of being done on a per-peer basis. The default rate-limit<br />  remains as 14 tx/s (boosted by 2.5x for outbound peers), though this can be<br />  changed via the `-txsendrate` configuration option. An additional bandwidth<br />  rate-limit has also been introduced at 12MB of transactions per 10 minutes,<br />  with a high burst rate. The size of the global backlog and the token bucket<br />  values for the rate limits can be queried via the `getnetworkinfo` RPC.<br />  (#34628)<br />- Fix a possible leak of the originator's IP address for transactions sent with<br />  `sendrawtransaction` RPC when `-privatebroadcast=1`. When Bitcoin Core<br />  connects to a peer, if that peer has been advertised to support P2P protocol<br />  v2, then Bitcoin Core tries to use the v2 protocol and if that fails it<br />  retries the connection using the v1 protocol. When the private broadcast is<br />  about to send a transaction to an IPv4 or IPv6 peer it overrides the normal<br />  proxy selection and forces the connection through the Tor proxy (and thus<br />  through the Tor network, protecting the sender's IP address). However if v2<br />  protocol is tried and it fails, then the v1 retry connection would be made<br />  disregarding the "override proxy" request, possibly making an IPv4 or IPv6<br />  direct connection. In other words, for this to happen the following must be<br />  true:<br />  1. An IPv4 or IPv6 address has been advertised to the sender, indicating v2<br />     support.<br />  2. The sender must have Tor configured.<br />  3. The sender's configuration must be such that connections to IPv4 or IPv6<br />     are made directly (no `-proxy=` is used for IPv4 or IPv6).<br />  4. The recipient does not support v2 (the flags from 1. are bogus). (#35410)<br />- The private-broadcast queue (transactions submitted via `sendrawtransaction`<br />  when `-privatebroadcast` is enabled and not yet echoed back from the network)<br />  is now capped at 10,000 entries. When full, new submissions are rejected. It<br />  is up to the caller to inspect the queue via `getprivatebroadcastinfo` and<br />  free up space when stuck via `abortprivatebroadcast`. (#35406)<br />- Each transaction sent via private broadcast (`-privatebroadcast`) is limited<br />  to 1,000 send attempts. After reaching the limit, broadcasting stops; call<br />  `sendrawtransaction` again to retry. Transactions that reach the limit remain<br />  available through `getprivatebroadcastinfo` and `abortprivatebroadcast`.<br />  (#35680)<br />- Support for the legacy ElGamal (type 0) encryption type when creating I2P<br />  sessions is being sunset by the I2P network and will be removed from bitcoind<br />  on or before v34. Nodes using I2P with versions of Bitcoin Core earlier than<br />  v26.1 (PRs #29200, #29209) will soon only be able to connect to other legacy<br />  ElGamal I2P peers and will be increasingly isolated from the rest of the<br />  network, with a reduced anonymity set. See #35696 for details. (#35696)<br />- The project is currently considering whether to drop support for CJDNS (see<br />  discussion in #36041). Since its introduction in v23.0, it has not gained<br />  substantial adoption amongst nodes, and there is some concern about supporting<br />  a network with such a low number of peers. (#36202)<br />- The CJDNS documentation was updated in #34811 to simplify the setup / peer<br />  discovery process. (#36202)<br />- The default maximum number of automatic peer connections (`-maxconnections`)<br />  has increased from 125 to 200, providing additional inbound capacity for<br />  block-relay-only peers. By default, transaction-relaying peers may use at most<br />  50% of inbound connection slots. This percentage can be configured with the<br />  new `-inboundrelaypercent` option, which accepts values from 0 to 100 and<br />  defaults to 50. The number of automatic outbound connections is unchanged.<br />  (#28463)<br />- Explicitly configured `-maxconnections` values remain unchanged, but the new<br />  inbound transaction-relay limit still applies. To retain the previous<br />  connection limits, use `-maxconnections=125 -inboundrelaypercent=100`.<br />`-maxconnections` now clamps values above 2,000 with a warning to reduce<br />  crash risk at very high peer counts. (#35919)<br /><br />Mempool<br />-------<br /><br />- mempoolfullrbf=1 behaviour has been the default since v28 and the argument has<br />  been removed since v29 subsequently. The `getmempoolinfo` RPC stops returning<br />  the deprecated `fullrbf` key in the response unless the user requests it via<br />  the `-deprecatedrpc=fullrbf` node argument. Also, the `bip125-replaceable` key<br />  is removed from the mempool RPCs responses (because it, too, has been<br />  deprecated since v29) unless the user requests it via `-deprecatedrpc=bip125`<br />  node argument. Affected mempool RPCs are `getrawmempool`,<br />  `getmempoolancestors`, `getmempooldescendants`, and `getmempoolentry`.<br />  (#34911)<br /><br />Updated RPCs<br />------------<br /><br />- `createpsbt`, `walletcreatefundedpsbt`, `converttopsbt`, and `psbtbumpfee`<br />  will now default to creating version 2 PSBTs. An optional `psbt_version`<br />  argument is added to these RPCs which allows specifying the version of PSBT to<br />  create. (#21283)<br />- 'taproot' has been removed from 'getdeploymentinfo' because its historical<br />  activation height is no longer used anywhere in the codebase. Applications<br />  that rely on `deployments.taproot` to detect Taproot support should either<br />  assume Taproot to be always active (since Bitcoin Core v24.0), or check for<br />  `TAPROOT` in the `script_flags` array returned by `getdeploymentinfo` (since<br />  Bitcoin Core v31.0). (#26201)<br />- Bitcoin Core now reports a debug message explaining why transaction inputs are<br />  non-standard. This information is now returned in the responses of the<br />  transaction-sending RPCs `submitpackage`, `sendrawtransaction`, and<br />  `testmempoolaccept`, and is also logged to `debug.log` (if `mempoolrej` +<br />  debug category is enabled) when such transactions are received over the P2P<br />  network. This does not change the existing error code<br />  `bad-txns-nonstandard-inputs`, but instead adds additional debug information<br />  to it. (#29060)<br />- The `dumptxoutset` RPC now supports writing to a named pipe on UNIX-like<br />  systems (see mkfifo(1) and mkfifo(3) man pages). This allows the raw UTXO set<br />  data to be consumed directly by another process (e.g., the<br />  `contrib/utxo-tools/utxo_to_sqlite.py` conversion script) without first<br />  writing it to disk. (#31560)<br />- Mempool RPCs (`getrawmempool`, `getmempoolentry`, `testmempoolaccept`,<br />  `submitpackage`) now include an additional field `vsize_adjusted` (which is<br />  the sigop-adjusted virtual size used for policy) and `vsize_bip141` (which<br />  represents the raw BIP141 virtual size). While `vsize` is marked as<br />  DEPRECATED, it was previously erroneously described as the BIP 141 vsize, but<br />  is actually sigops-adjusted vsize. Use `vsize_bip141` to actually get that<br />  behavior or switch to the explicit `vsize_adjusted` for retained behavior.<br />  (#32800)<br />- `getrawtransaction` RPC now includes an additional field `vsize_adjusted`,<br />  which is the sigop-adjusted virtual size if the transaction is in the mempool.<br />  (#32800)<br />- The `getblockchaininfo` RPC now exposes progress for background validation if<br />  the `assumeutxo` feature is used. Once a node has synced from snapshot to tip,<br />  `verificationprogress` returns 1.0 and `initialblockdownload` false even<br />  though the node may still be validating blocks in the background. A new<br />  object, `backgroundvalidation`, provides details about the snapshot being<br />  validated, including snapshot height, number of blocks processed, best block<br />  hash, chainwork, median time, and verification progress. (#33259)<br />- `getbalances` now includes a `nonmempool` field under `mine`, reporting the<br />  net balance of wallet transactions that are not in the mempool (e.g. due to<br />  too low a feerate, too many unconfirmed ancestors, or a too-large `OP_RETURN`<br />  output). This value is always negative, and is typically an over-estimate<br />  since it accounts for coins being spent but not for change outputs returning<br />  to the wallet (which are also outside the mempool). Without this field, funds<br />  involved in non-mempool transactions could appear to go missing from the<br />  wallet balance. (#33671)<br />- The `estimatesmartfee` RPC now combines two fee rate estimators: the existing<br />  block policy fee rate estimator and a new mempool fee rate estimator. (#34075)<br />- The new mempool fee rate estimator produces conservative and economical fee<br />  rate estimates from the current contents of the mempool. It only produces a<br />  fee rate estimate when recent blocks indicate a healthy mempool, and falls<br />  back to the higher of the minimum relay fee rate and the current mempool<br />  minimum fee rate when the mempool is too sparse. Its statistics are persisted<br />  to `fees/mempool_policy_estimator.dat` and reloaded on startup.<br />  `estimatesmartfee` returns the lower of the two fee rate estimators' results,<br />  so the mempool fee rate estimator can only lower the block policy fee rate<br />  estimate. (#34075)<br />- `estimatesmartfee` accepts an `options` object with `fee_rate_estimator`.<br />  Recognized values are `"auto"` (the default, combined behavior described<br />  above), `"block_policy"` (use only the block policy fee rate estimator), and<br />  `"mempool_policy"` (use only the mempool fee rate estimator). All unknown<br />  values are rejected. Users who want the previous behavior can<br />  select the block policy fee rate estimator explicitly. (#34075)<br />- The options object also accepts `verbosity`. A verbosity of `2` or higher also<br />  returns `mempool_health_statistics`. (#34075)<br />- When `fee_rate_estimator` is `"auto"` and the estimate succeeds, the response<br />  also includes an `estimator` field identifying which fee rate estimator<br />  produced the result. (#34075)<br />- Block policy fee estimator data is now stored in<br />  `fees/block_policy_estimates.dat`. If the new file does not exist, the legacy<br />  `fee_estimates.dat` file is moved to the new path during startup. If both<br />  files exist, the legacy file is removed. (#34075)<br />- Wallet fee rate estimation uses the default combined estimate. (#34075)<br /><br />- The `-deprecatedrpc=startingheight` configuration option has been removed. The<br />  `getpeerinfo` RPC no longer returns the `startingheight` field, which was<br />  previously deprecated in v31.0. (#34796)<br />- The `migratewallet` RPC now gives the option to not load the descriptor wallet<br />  after migrating it from a legacy wallet. This will now allow pruned nodes to<br />  migrate a wallet out of sync below the pruning height. Note that to use the<br />  new wallet it must be loaded to a full node anyway. (#35266)<br />- The `getprivatebroadcastinfo` and `abortprivatebroadcast` RPCs now return an<br />  error `-32601`, "Method not found", when `-privatebroadcast` is not enabled at<br />  startup. (#35267)<br />- `gettransaction`, `listtransactions`, and `listsinceblock` now have an<br />  `alternate_wtxids` field which lists the wtxids of all transactions that have<br />  the same txid. When there is only one known witness variant the field is an<br />  empty array, analogous to `walletconflicts` and `mempoolconflicts`. (#35501)<br />- `getprivatebroadcastinfo` now reports an `attempts_remaining` field for each<br />  transaction. (#35680)<br />- `getnetworkinfo` now reports the `asmap_version` if `-asmap` is in use. The<br />  version is the hash of the asmap data and can be verified against the hash of<br />  the raw asmap data file that also gets attested in the<br />  [asmap-data](https://github.com/bitcoin-core/asmap-data) repository with<br />  `sha256sum`. (#36249)<br /><br />Changes to wallet related RPCs can be found in the Wallet section below.<br /><br />New RPCs<br />--------<br /><br />- A new `exportasmap` RPC writes the ASMap data embedded at build time to a<br />  file. (#33920)<br />- A new `getopenrpcinfo` RPC returns a machine-readable OpenRPC 1.4.1<br />  description of the RPCs available on the running node, including their<br />  parameters and result schemas. The new `rpc.discover` method provides the same<br />  public document using OpenRPC’s standard service discovery method. To include<br />  hidden commands and arguments, call `getopenrpcinfo` with `show_hidden=true`.<br />  (#34683)<br /><br />Build System<br />------------<br /><br />- The next major release is planned to drop support for building Bitcoin Core on<br />  Windows with MSVC, once clang-cl support is ready. See<br />  [#36153](https://github.com/bitcoin/bitcoin/issues/36153).<br />- The undocumented `BITCOIN_GENBUILD_NO_GIT` environment variable is no longer<br />  required and has been removed. The build system now automatically detects when<br />  it is being built from a source archive or as a subproject of a git-aware<br />  parent project and skips git metadata fetching. Users who need to disable git<br />  execution explicitly can still do so by configuring with<br />  `-DCMAKE_DISABLE_FIND_PACKAGE_Git=ON`. (#32220)<br /><br />Updated settings<br />----------------<br /><br />- The `bip125-replaceable` key in the wallet transaction RPCs such as<br />  `listtransactions`, `listsinceblock`, and `gettransaction` is marked as<br />  deprecated. Users still have the option to retrieve this key by passing the<br />  `-deprecatedrpc=bip125` startup option. Also, the `-walletrbf` startup option<br />  has been marked as deprecated and will be fully removed in the next release.<br />  Using this option emits a warning in the logs. (#34917)<br />- The `libevent` logging category has been removed. Configurations like<br />  `-debug=libevent` or `-debugexclude=libevent` will log a deprecation warning<br />  and be ignored. These configurations will result in an error in a future<br />  release.<br />- A new configuration option `-rpcmaxconnections` (default `16`) limits the<br />  number of simultaneously connected HTTP clients to the server. The application<br />  will now attempt to reserve file descriptors for the HTTP server sockets. If<br />  your system has limited resources, consider using a lower setting.<br />- A new `mining` logging category has been added, enabled with `-debug=mining`.<br />  The `CreateNewBlock(): block weight: ...` line, previously logged on every<br />  block template build regardless of logging configuration, is now logged only<br />  when this category is enabled. `getblocktemplate` and Mining IPC users are<br />  encouraged to enable it to see this log and future mining log.<br /><br />Changes to GUI or wallet related settings can be found in the GUI or Wallet section below.<br /><br />New settings<br />------------<br /><br />- Block validation can now prefetch input prevouts from the chainstate database<br />  in parallel while connecting blocks, speeding up validation when prevouts need<br />  to be read from disk. A new `-prevoutfetchthreads=&lt;n&gt;` option controls the<br />  number of prefetch worker threads. The default is 8 threads, up to a maximum<br />  of 16; set it to 0 to disable parallel prefetching. (#35295)<br /><br />Tools and Utilities<br />-------------------<br /><br />- CLI -addrinfo now returns the full set of known addresses. In previous<br />  versions (v22.0 - v30.0) the set of returned addresses was filtered for<br />  quality and recency. This was changed since it does not match the logic for<br />  selecting peers to connect to, which does not filter. Note: CLI -addrinfo now<br />  requires bitcoind v26.0 or later, as it uses the getaddrmaninfo RPC<br />  internally. Users querying older, unmaintained node versions would need to use<br />  an older bitcoin-cli version. (#26988)<br />- A new `bitcoin-util getchainparams` command returns hardcoded details about<br />  the selected chain. (#35610)<br /><br />Wallet<br />------<br /><br />- A new RPC `addhdkey` is added which allows a BIP 32 extended key to be added<br />  to the wallet without needing to import it as part of a separate descriptor.<br />  This key will not be used to produce any output scripts unless it is<br />  explicitly imported as part of a separate descriptor independent of the<br />  `addhdkey` RPC. (#29136)<br />- A new `exportwatchonlywallet` RPC creates a watchonly wallet file from an<br />  existing descriptor wallet. The exported file contains the wallet's public<br />  descriptors (with derived key caches where needed), transactions, and address<br />  book data, but no private keys. It can be imported on another node using the<br />  existing `restorewallet` RPC. (#32489)<br />- The [Offline Signing Tutorial](/doc/offline-signing-tutorial.md) has been<br />  updated to use `exportwatchonlywallet` for setting up the online watch-only<br />  wallet, replacing the previous manual descriptor import workflow. (#32489)<br />- A new `derivehdkey` RPC is available to obtain an xpub or xprv for a<br />  derivation path with at least one hardened step from an HD key known to the<br />  wallet. This can be used to coordinate a multisig setup, where each signer<br />  shares an xpub using a different derivation path than the default<br />  single-signature descriptors. The example in `doc/multisig-tutorial.md` is<br />  updated to use this RPC. (#32784)<br />- The `fee_reason` field returned by wallet transaction creation RPCs now<br />  reports the reason the wallet selected the fee rate ("Fee Rate Estimator",<br />  "Mempool Min Fee", "User Specified Fee", "Fallback fee" or<br />  "Minimum Required Fee") instead of the block policy fee rate estimator's<br />  internal threshold details. Those details remain available in the block<br />  policy fee rate estimator debug log. (#34075)<br />- Wallet names that are relative paths including `..` and `.` elements, and<br />  wallets named `/` are no longer allowed. Any users that depended on this<br />  behavior can instead use absolute paths to their wallet or move their wallet<br />  to a safer path. (#34544)<br />- The `send` and `sendall` RPCs are no longer marked as experimental. (#35601)<br />- The `fundrawtransaction` RPC no longer accepts a boolean as the second<br />  positional argument. This silent no-op fallback was removed and the argument<br />  is now fully type checked. Passing a boolean will raise an error. (#35836)<br />- On non-Windows systems, an authenticated RPC caller allowed to create wallets<br />  could execute arbitrary commands as the node process account when<br />  `-walletnotify` was configured, by crafting a wallet name with regex<br />  replacement characters. Wallet notification placeholder replacement now treats<br />  wallet names literally. (#36048)<br />- The `removeprunedfunds` RPC has been deprecated and will be removed in the<br />  next major release. In order to continue using it, `bitcoind` must be started<br />  with the `-deprecatedrpc=removeprunedfunds` option. (#35605)<br /><br />GUI changes<br />-----------<br /><br />- A menu action has been added to allow creating a watchonly wallet file from an<br />  existing descriptor wallet. This option mirrors the `exportwatchonlywallet`<br />  RPC - the exported file can be imported to another node using the Restore<br />  Wallet menu action. (gui#872)<br />- The "Enable Replace-By-Fee" checkbox has been removed from the Send tab, and<br />  the send confirmation dialog no longer states whether a transaction signals<br />  BIP 125 replaceability. Transactions created in the GUI now follow the wallet's<br />  `-walletrbf` setting, which defaults to signalling replaceability and is<br />  deprecated in this release (see Updated settings). (gui#936)<br />- The migrate wallet option now allows to disable wallet loading after<br />  migrating. It is useful in case the node is pruned and the wallet was created<br />  before the pruned height. (gui#953)<br />- The GUI is now built with Qt 6.8.4. (#35709)<br /><br />Mining<br />------<br /><br />- The IPC mining interface now rejects out-of-range block template options<br />  instead of silently clamping them, such as oversized reserved block weight or<br />  coinbase sigops limits. (#33966)<br />- The `-blockmaxweight` startup option is now rejected when it is lower than<br />  `-blockreservedweight`, instead of being silently clamped. (#33966)<br /><br /><br />IPC Interface<br />-------------<br /><br />- `BlockTemplate.submitSolution` now returns `reason` and `debug` rejection<br />  details in addition to the boolean result. Clients must regenerate IPC<br />  bindings from the updated `mining.capnp` schema to use the new method. The<br />  previous `@7` method now returns an error directing clients to update.<br />  (#34672)<br />- `BlockTemplate.submitSolution` now reports duplicate blocks as failures with<br />  `reason="duplicate"`, matching `Mining.submitBlock`, instead of returning<br />  success for duplicate submissions. (#34672)<br /><br />Logging<br />-------<br /><br />- BIP 9 bits 5 to 28 inclusive are now ignored for soft fork signaling, as per<br />  BIP 323. We won't warn about unknown deployments when receiving blocks that<br />  set any of those bits in their version. (#34779)<br /><br />REST API<br />--------<br /><br />- REST responses now include `Cache-Control` headers to guide intermediary<br />  caches. Immutable responses such as block binary and hex data, block parts,<br />  block filters, spent transaction outputs, and block-specific deployment info<br />  are marked cacheable for one day. Responses that can change with active chain<br />  or node state, as well as errors, are marked `no-store`. (#34794)<br /><br />Low-level changes<br />=================<br /><br />Indexes<br />-------<br /><br />- The transaction index (`-txindex`) now stores less data on disk; a fully<br />  rebuilt index takes less than half the space. The index is backwards<br />  compatible, so existing users will not see the space saving unless the index<br />  is recreated. To do so, stop the node, delete the `&lt;datadir&gt;/indexes/txindex`<br />  directory, and restart; rebuilding can take up to a few hours depending on<br />  hardware. Progress can be monitored using the `getindexinfo` RPC. Once<br />  rebuilt, the index can no longer be read by previous releases, so downgrading<br />  will rebuild it again in the old format. When downgrading permanently, delete<br />  the `&lt;datadir&gt;/indexes/txindex` directory first, since previous releases do<br />  not reclaim the space used by entries in the new format. (#35531)<br />- The transaction output spender index (`-txospenderindex`) now uses less disk<br />  space. Existing indexes remain compatible and no action is required. To<br />  reclaim the space for data indexed before upgrading, stop the node, delete the<br />  `&lt;datadir&gt;/indexes/txospenderindex/` directory, and restart with<br />  `-txospenderindex` enabled to rebuild it. (#35634, #35568)<br /><br />RPC<br />---<br /><br />- Libevent has been replaced with a custom HTTP server (#35182). Certain HTTP<br />  edge cases will observe different behavior to be more RFC-compliant:<br />  - Stricter enforcement of maximum headers size (8192 bytes)<br />  - Reject requests with whitespace in header field-names<br />  - "Line Folding" is rejected (whitespace at start of a header line)<br />  - Tolerate `%` at the end of requested URLs<br />  - Multiple "Content-Length" headers with different values are rejected<br />- Clients attempting to connect from addresses not allowed by the `-rpcallowip`<br />  option (or its default, `localhost`) will now be immediately disconnected<br />  instead of receiving a `403 Forbidden`. (#35592)<br /><br />Credits<br />=======<br /><br />Thanks to everyone who directly contributed to this release:<br /><br />- 0xb10c<br />- Adam Andrews<br />- Alexander Wiederin<br />- Alfonso Roman Zubeldia<br />- ameen-alam<br />- amisha<br />- Amiti Uttarwar<br />- Andreas Kouloumos<br />- Andrew Toth<br />- Anthony Towns<br />- Anthropic Security<br />- Antoine Poinsot<br />- ArvinFarrelP<br />- Ava Chow<br />- azuchi<br />- benthecarman<br />- Ben Woosley<br />- Bicaru20<br />- b-l-u-e<br />- Bortlesboat<br />- Brandon Odiwuor<br />- Bruno Garcia<br />- CaesarCoder<br />- Chandra Pratap<br />- codeabysss<br />- Cory Fields<br />- Craig Raw<br />- crStiv<br />- csjones<br />- cyb3ralbert<br />- Daniela Brozzoni<br />- Daniel Pfeifer<br />- Danny van Heumen<br />- David Gumberg<br />- deadmanoz<br />- dergoegge<br />- ekzyis<br />- Enoch Azariah<br />- Eugene Siegel<br />- Evan Sultanik<br />- Fabian Jahr<br />- fanquake<br />- frankomosh<br />- Gloria Zhao<br />- Greg Sanders<br />- Guillermo Fernandes<br />- GuTS805<br />- Hao Xu<br />- Hennadii Stepanov<br />- Henry Romp<br />- Hodlinator<br />- HouseOfHufflepuff<br />- ImMike<br />- ismaelsadeeq<br />- janb84<br />- jeanpablojp<br />- Jean-Philippe Aumasson<br />- joaonevess<br />- Jon Atack<br />- jpk68<br />- jrakibi<br />- junbyjun1238<br />- Kanan<br />- kevkevinpal<br />- Kyle 🐆<br />- l0rinc<br />- Laxman Acharya<br />- littleyier<br />- Luke Dashjr<br />- maflcko<br />- marcofleon<br />- Martin Zumsande<br />- Matias Furszyfer<br />- Matthew Zipkin<br />- Max Edwards<br />- Mccalabrese<br />- Memetic Money<br />- Michael Dietz<br />- Muhammad<br />- Murch<br />- Musa Haruna<br />- naiyoma<br />- nebula-21<br />- nervana21<br />- Novo<br />- optout<br />- Pablo Martin<br />- Peter Zafonte<br />- Philips Ucheolisah .N<br />- Pieter Wuille<br />- Pol Espinasa<br />- pseudoramdom<br />- pythcoiner<br />- Renato Britto<br />- rkrux<br />- Rob Hamilton<br />- Robin David<br />- Roqqit<br />- Ruslan Kasheparov<br />- Russell Yanofsky<br />- rustaceanrob<br />- Sanjana2906<br />- satsfy<br />- sayed nabhan<br />- Sebastian Falbesoner<br />- Sebastian van Staa<br />- sedited<br />- seduless<br />- shaurya2k06<br />- Shrey<br />- Shuvam Pandey<br />- Sjors Provoost<br />- stickies-v<br />- stratospher<br />- stringintech<br />- taboger<br />- takeshikurosawaa<br />- Thomas<br />- Torkel Rogstad<br />- Vasil Dimov<br />- vicjuma<br />- ViniciusCestarii<br />- w0xlt<br />- Will Clark<br />- winterrdog<br />- xyzconstant<br />- Yancy<br />- yuvicc<br /><br />As well as to everyone that helped with translations on<br />[Transifex](https://explore.transifex.com/bitcoin/bitcoin/).

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoindev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href="https://groups.google.com/d/msgid/bitcoindev/c47ceea6-99de-41fe-a97c-928881963eccn%40googlegroups.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/msgid/bitcoindev/c47ceea6-99de-41fe-a97c-928881963eccn%40googlegroups.com</a>.<br />