Bitcoin Forum
November 03, 2026, 06:34:21 PM *
News: Latest Bitcoin Core release: 32.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Bitcoin Core v32.1 Released  (Read 28 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
achow101 (OP)
Staff
Legendary
*
Offline

Activity: 4032
Merit: 7872


Just writing some code


View Profile WWW
Today at 04:07:16 AM
Merited by ABCbits (2), hosemary (2)
 #1

v32.1 Release Notes

Due to last-minute issues, 32.0, although tagged, was never
fully announced or released.

Bitcoin Core version 32.1 is now available from:

https://bitcoincore.org/bin/bitcoin-core-32.1/

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/bitcoin/bitcoin/issues

To receive security and update notifications, please subscribe to:

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

With the release of this new major version, versions 29.x and
older are at "End of Life" and will no longer receive updates.

In accordance with our security policy, any <strong>easily discoverable</strong> vulnerabilities fixed in this
release will be disclosed as soon as fixed releases are available for all maintained major versions.

Under the regular disclosure schedule, we will disclose the following in two weeks:
  • Medium and high severity vulnerabilities fixed in 30.0. There are 3 of these.
  • Low severity vulnerabilities fixed in 32.1. There are 0 of these.

How to Upgrade

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/Bitcoin-Qt (on macOS)
or bin/ and libexec/ (on Linux).

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

Compatibility

Bitcoin Core is supported and tested on the following operating systems or newer:
Linux Kernel 3.17, macOS 14, and Windows 10 (version 1903). Bitcoin
Core should also work on most other Unix-like systems but is not as
frequently tested on them. It is not recommended to use Bitcoin Core on
unsupported systems.

Notable changes

P2P and network changes
  • Tor hidden services that are created automatically by Bitcoin Core will have
    PoW defenses
    enabled if the Tor daemon supports that. (#33414)
  • To reduce memory and CPU usage during periods of high transaction volume,
    rate-limiting of outgoing transaction relay has been changed to use a global
    backlog instead of being done on a per-peer basis. The default rate-limit
    remains as 14 tx/s (boosted by 2.5x for outbound peers), though this can be
    changed via the -txsendrate configuration option. An additional bandwidth
    rate-limit has also been introduced at 12MB of transactions per 10 minutes,
    with a high burst rate. The size of the global backlog and the token bucket
    values for the rate limits can be queried via the getnetworkinfo RPC.
    (#34628)
  • Fix a possible leak of the originator's IP address for transactions sent with
    sendrawtransaction RPC when -privatebroadcast=1. When Bitcoin Core
    connects to a peer, if that peer has been advertised to support P2P protocol
    v2, then Bitcoin Core tries to use the v2 protocol and if that fails it
    retries the connection using the v1 protocol. When the private broadcast is
    about to send a transaction to an IPv4 or IPv6 peer it overrides the normal
    proxy selection and forces the connection through the Tor proxy (and thus
    through the Tor network, protecting the sender's IP address). However if v2
    protocol is tried and it fails, then the v1 retry connection would be made
    disregarding the "override proxy" request, possibly making an IPv4 or IPv6
    direct connection. In other words, for this to happen the following must be
    true:
    • 1. An IPv4 or IPv6 address has been advertised to the sender, indicating v2
      support.
    • 2. The sender must have Tor configured.
    • 3. The sender's configuration must be such that connections to IPv4 or IPv6
      are made directly (no -proxy= is used for IPv4 or IPv6).
    • 4. The recipient does not support v2 (the flags from 1. are bogus). (#35410)
  • The private-broadcast queue (transactions submitted via sendrawtransaction
    when -privatebroadcast is enabled and not yet echoed back from the network)
    is now capped at 10,000 entries. When full, new submissions are rejected. It
    is up to the caller to inspect the queue via getprivatebroadcastinfo and
    free up space when stuck via abortprivatebroadcast. (#35406)
  • Each transaction sent via private broadcast (-privatebroadcast) is limited
    to 1,000 send attempts. After reaching the limit, broadcasting stops; call
    sendrawtransaction again to retry. Transactions that reach the limit remain
    available through getprivatebroadcastinfo and abortprivatebroadcast.
    (#35680)
  • Support for the legacy ElGamal (type 0) encryption type when creating I2P
    sessions is being sunset by the I2P network and will be removed from bitcoind
    on or before v34. Nodes using I2P with versions of Bitcoin Core earlier than
    v26.1 (PRs #29200, #29209) will soon only be able to connect to other legacy
    ElGamal I2P peers and will be increasingly isolated from the rest of the
    network, with a reduced anonymity set. See #35696 for details. (#35696)
  • The project is currently considering whether to drop support for CJDNS (see
    discussion in #36041). Since its introduction in v23.0, it has not gained
    substantial adoption amongst nodes, and there is some concern about supporting
    a network with such a low number of peers. (#36202)
  • The CJDNS documentation was updated in #34811 to simplify the setup / peer
    discovery process. (#36202)
  • The default maximum number of automatic peer connections (-maxconnections)
    has increased from 125 to 200, providing additional inbound capacity for
    block-relay-only peers. By default, transaction-relaying peers may use at most
    50% of inbound connection slots. This percentage can be configured with the
    new -inboundrelaypercent option, which accepts values from 0 to 100 and
    defaults to 50. The number of automatic outbound connections is unchanged.
    (#28463)
  • Explicitly configured -maxconnections values remain unchanged, but the new
    inbound transaction-relay limit still applies. To retain the previous
    connection limits, use -maxconnections=125 -inboundrelaypercent=100.
    -maxconnections now clamps values above 2,000 with a warning to reduce
    crash risk at very high peer counts. (#35919)

Mempool
  • mempoolfullrbf=1 behaviour has been the default since v28 and the argument has
    been removed since v29 subsequently. The getmempoolinfo RPC stops returning
    the deprecated fullrbf key in the response unless the user requests it via
    the -deprecatedrpc=fullrbf node argument. Also, the bip125-replaceable key
    is removed from the mempool RPCs responses (because it, too, has been
    deprecated since v29) unless the user requests it via -deprecatedrpc=bip125
    node argument. Affected mempool RPCs are getrawmempool,
    getmempoolancestors, getmempooldescendants, and getmempoolentry.
    (#34911)

Updated RPCs
  • createpsbt, walletcreatefundedpsbt, converttopsbt, and psbtbumpfee
    will now default to creating version 2 PSBTs. An optional psbt_version
    argument is added to these RPCs which allows specifying the version of PSBT to
    create. (#21283)
  • 'taproot' has been removed from 'getdeploymentinfo' because its historical
    activation height is no longer used anywhere in the codebase. Applications
    that rely on deployments.taproot to detect Taproot support should either
    assume Taproot to be always active (since Bitcoin Core v24.0), or check for
    TAPROOT in the script_flags array returned by getdeploymentinfo (since
    Bitcoin Core v31.0). (#26201)
  • Bitcoin Core now reports a debug message explaining why transaction inputs are
    non-standard. This information is now returned in the responses of the
    transaction-sending RPCs submitpackage, sendrawtransaction, and
    testmempoolaccept, and is also logged to debug.log (if mempoolrej +
    debug category is enabled) when such transactions are received over the P2P
    network. This does not change the existing error code
    bad-txns-nonstandard-inputs, but instead adds additional debug information
    to it. (#29060)
  • The dumptxoutset RPC now supports writing to a named pipe on UNIX-like
    systems (see mkfifo(1) and mkfifo(3) man pages). This allows the raw UTXO set
    data to be consumed directly by another process (e.g., the
    contrib/utxo-tools/utxo_to_sqlite.py conversion script) without first
    writing it to disk. (#31560)
  • Mempool RPCs (getrawmempool, getmempoolentry, testmempoolaccept,
    submitpackage) now include an additional field vsize_adjusted (which is
    the sigop-adjusted virtual size used for policy) and vsize_bip141 (which
    represents the raw BIP141 virtual size). While vsize is marked as
    DEPRECATED, it was previously erroneously described as the BIP 141 vsize, but
    is actually sigops-adjusted vsize. Use vsize_bip141 to actually get that
    behavior or switch to the explicit vsize_adjusted for retained behavior.
    (#32800)
  • getrawtransaction RPC now includes an additional field vsize_adjusted,
    which is the sigop-adjusted virtual size if the transaction is in the mempool.
    (#32800)
  • The getblockchaininfo RPC now exposes progress for background validation if
    the assumeutxo feature is used. Once a node has synced from snapshot to tip,
    verificationprogress returns 1.0 and initialblockdownload false even
    though the node may still be validating blocks in the background. A new
    object, backgroundvalidation, provides details about the snapshot being
    validated, including snapshot height, number of blocks processed, best block
    hash, chainwork, median time, and verification progress. (#33259)
  • getbalances now includes a nonmempool field under mine, reporting the
    net balance of wallet transactions that are not in the mempool (e.g. due to
    too low a feerate, too many unconfirmed ancestors, or a too-large OP_RETURN
    output). This value is always negative, and is typically an over-estimate
    since it accounts for coins being spent but not for change outputs returning
    to the wallet (which are also outside the mempool). Without this field, funds
    involved in non-mempool transactions could appear to go missing from the
    wallet balance. (#33671)
  • The estimatesmartfee RPC now combines two fee rate estimators: the existing
    block policy fee rate estimator and a new mempool fee rate estimator. (#34075)
  • The new mempool fee rate estimator produces conservative and economical fee
    rate estimates from the current contents of the mempool. It only produces a
    fee rate estimate when recent blocks indicate a healthy mempool, and falls
    back to the higher of the minimum relay fee rate and the current mempool
    minimum fee rate when the mempool is too sparse. Its statistics are persisted
    to fees/mempool_policy_estimator.dat and reloaded on startup.
    estimatesmartfee returns the lower of the two fee rate estimators' results,
    so the mempool fee rate estimator can only lower the block policy fee rate
    estimate. (#34075)
  • estimatesmartfee accepts an options object with fee_rate_estimator.
    Recognized values are "auto" (the default, combined behavior described
    above), "block_policy" (use only the block policy fee rate estimator), and
    "mempool_policy" (use only the mempool fee rate estimator). All unknown
    values are rejected. Users who want the previous behavior can
    select the block policy fee rate estimator explicitly. (#34075)
  • The options object also accepts verbosity. A verbosity of 2 or higher also
    returns mempool_health_statistics. (#34075)
  • When fee_rate_estimator is "auto" and the estimate succeeds, the response
    also includes an estimator field identifying which fee rate estimator
    produced the result. (#34075)
  • Block policy fee estimator data is now stored in
    fees/block_policy_estimates.dat. If the new file does not exist, the legacy
    fee_estimates.dat file is moved to the new path during startup. If both
    files exist, the legacy file is removed. (#34075)
  • Wallet fee rate estimation uses the default combined estimate. (#34075)
  • The -deprecatedrpc=startingheight configuration option has been removed. The
    getpeerinfo RPC no longer returns the startingheight field, which was
    previously deprecated in v31.0. (#34796)
  • The migratewallet RPC now gives the option to not load the descriptor wallet
    after migrating it from a legacy wallet. This will now allow pruned nodes to
    migrate a wallet out of sync below the pruning height. Note that to use the
    new wallet it must be loaded to a full node anyway. (#35266)
  • The getprivatebroadcastinfo and abortprivatebroadcast RPCs now return an
    error -32601, "Method not found", when -privatebroadcast is not enabled at
    startup. (#35267)
  • gettransaction, listtransactions, and listsinceblock now have an
    alternate_wtxids field which lists the wtxids of all transactions that have
    the same txid. When there is only one known witness variant the field is an
    empty array, analogous to walletconflicts and mempoolconflicts. (#35501)
  • getprivatebroadcastinfo now reports an attempts_remaining field for each
    transaction. (#35680)
  • getnetworkinfo now reports the asmap_version if -asmap is in use. The
    version is the hash of the asmap data and can be verified against the hash of
    the raw asmap data file that also gets attested in the
    asmap-data repository with
    sha256sum. (#36249)

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

New RPCs
  • A new exportasmap RPC writes the ASMap data embedded at build time to a
    file. (#33920)
  • A new getopenrpcinfo RPC returns a machine-readable OpenRPC 1.4.1
    description of the RPCs available on the running node, including their
    parameters and result schemas. The new rpc.discover method provides the same
    public document using OpenRPC’s standard service discovery method. To include
    hidden commands and arguments, call getopenrpcinfo with show_hidden=true.
    (#34683)

Build System
  • The next major release is planned to drop support for building Bitcoin Core on
    Windows with MSVC, once clang-cl support is ready. See
    [#36153](https://github.com/bitcoin/bitcoin/issues/36153).
  • The undocumented BITCOIN_GENBUILD_NO_GIT environment variable is no longer
    required and has been removed. The build system now automatically detects when
    it is being built from a source archive or as a subproject of a git-aware
    parent project and skips git metadata fetching. Users who need to disable git
    execution explicitly can still do so by configuring with
    -DCMAKE_DISABLE_FIND_PACKAGE_Git=ON. (#32220)

Updated settings
  • The bip125-replaceable key in the wallet transaction RPCs such as
    listtransactions, listsinceblock, and gettransaction is marked as
    deprecated. Users still have the option to retrieve this key by passing the
    -deprecatedrpc=bip125 startup option. Also, the -walletrbf startup option
    has been marked as deprecated and will be fully removed in the next release.
    Using this option emits a warning in the logs. (#34917)
  • The libevent logging category has been removed. Configurations like
    -debug=libevent or -debugexclude=libevent will log a deprecation warning
    and be ignored. These configurations will result in an error in a future
    release.
  • A new configuration option -rpcmaxconnections (default 16) limits the
    number of simultaneously connected HTTP clients to the server. The application
    will now attempt to reserve file descriptors for the HTTP server sockets. If
    your system has limited resources, consider using a lower setting.
  • A new mining logging category has been added, enabled with -debug=mining.
    The CreateNewBlock(): block weight: ... line, previously logged on every
    block template build regardless of logging configuration, is now logged only
    when this category is enabled. getblocktemplate and Mining IPC users are
    encouraged to enable it to see this log and future mining log.

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

New settings
  • Block validation can now prefetch input prevouts from the chainstate database
    in parallel while connecting blocks, speeding up validation when prevouts need
    to be read from disk. A new -prevoutfetchthreads=<n> option controls the
    number of prefetch worker threads. The default is 8 threads, up to a maximum
    of 16; set it to 0 to disable parallel prefetching. (#35295)

Tools and Utilities
  • CLI -addrinfo now returns the full set of known addresses. In previous
    versions (v22.0 - v30.0) the set of returned addresses was filtered for
    quality and recency. This was changed since it does not match the logic for
    selecting peers to connect to, which does not filter. Note: CLI -addrinfo now
    requires bitcoind v26.0 or later, as it uses the getaddrmaninfo RPC
    internally. Users querying older, unmaintained node versions would need to use
    an older bitcoin-cli version. (#26988)
  • A new bitcoin-util getchainparams command returns hardcoded details about
    the selected chain. (#35610)

Wallet
  • A new RPC addhdkey is added which allows a BIP 32 extended key to be added
    to the wallet without needing to import it as part of a separate descriptor.
    This key will not be used to produce any output scripts unless it is
    explicitly imported as part of a separate descriptor independent of the
    addhdkey RPC. (#29136)
  • A new exportwatchonlywallet RPC creates a watchonly wallet file from an
    existing descriptor wallet. The exported file contains the wallet's public
    descriptors (with derived key caches where needed), transactions, and address
    book data, but no private keys. It can be imported on another node using the
    existing restorewallet RPC. (#32489)
  • The Offline Signing Tutorial has been
    updated to use exportwatchonlywallet for setting up the online watch-only
    wallet, replacing the previous manual descriptor import workflow. (#32489)
  • A new derivehdkey RPC is available to obtain an xpub or xprv for a
    derivation path with at least one hardened step from an HD key known to the
    wallet. This can be used to coordinate a multisig setup, where each signer
    shares an xpub using a different derivation path than the default
    single-signature descriptors. The example in doc/multisig-tutorial.md is
    updated to use this RPC. (#32784)
  • The fee_reason field returned by wallet transaction creation RPCs now
    reports the reason the wallet selected the fee rate ("Fee Rate Estimator",
    "Mempool Min Fee", "User Specified Fee", "Fallback fee" or
    "Minimum Required Fee") instead of the block policy fee rate estimator's
    internal threshold details. Those details remain available in the block
    policy fee rate estimator debug log. (#34075)
  • Wallet names that are relative paths including .. and . elements, and
    wallets named / are no longer allowed. Any users that depended on this
    behavior can instead use absolute paths to their wallet or move their wallet
    to a safer path. (#34544)
  • The send and sendall RPCs are no longer marked as experimental. (#35601)
  • The fundrawtransaction RPC no longer accepts a boolean as the second
    positional argument. This silent no-op fallback was removed and the argument
    is now fully type checked. Passing a boolean will raise an error. (#35836)
  • On non-Windows systems, an authenticated RPC caller allowed to create wallets
    could execute arbitrary commands as the node process account when
    -walletnotify was configured, by crafting a wallet name with regex
    replacement characters. Wallet notification placeholder replacement now treats
    wallet names literally. (#36048)
  • The removeprunedfunds RPC has been deprecated and will be removed in the
    next major release. In order to continue using it, bitcoind must be started
    with the -deprecatedrpc=removeprunedfunds option. (#35605)

GUI changes
  • A menu action has been added to allow creating a watchonly wallet file from an
    existing descriptor wallet. This option mirrors the exportwatchonlywallet
    RPC - the exported file can be imported to another node using the Restore
    Wallet menu action. (gui#872)
  • The "Enable Replace-By-Fee" checkbox has been removed from the Send tab, and
    the send confirmation dialog no longer states whether a transaction signals
    BIP 125 replaceability. Transactions created in the GUI now follow the wallet's
    -walletrbf setting, which defaults to signalling replaceability and is
    deprecated in this release (see Updated settings). (gui#936)
  • The migrate wallet option now allows to disable wallet loading after
    migrating. It is useful in case the node is pruned and the wallet was created
    before the pruned height. (gui#953)
  • The GUI is now built with Qt 6.8.4. (#35709)

Mining
  • The IPC mining interface now rejects out-of-range block template options
    instead of silently clamping them, such as oversized reserved block weight or
    coinbase sigops limits. (#33966)
  • The -blockmaxweight startup option is now rejected when it is lower than
    -blockreservedweight, instead of being silently clamped. (#33966)

IPC Interface
  • BlockTemplate.submitSolution now returns reason and debug rejection
    details in addition to the boolean result. Clients must regenerate IPC
    bindings from the updated mining.capnp schema to use the new method. The
    previous @7 method now returns an error directing clients to update.
    (#34672)
  • BlockTemplate.submitSolution now reports duplicate blocks as failures with
    reason="duplicate", matching Mining.submitBlock, instead of returning
    success for duplicate submissions. (#34672)

Logging
  • BIP 9 bits 5 to 28 inclusive are now ignored for soft fork signaling, as per
    BIP 323. We won't warn about unknown deployments when receiving blocks that
    set any of those bits in their version. (#34779)

REST API
  • REST responses now include Cache-Control headers to guide intermediary
    caches. Immutable responses such as block binary and hex data, block parts,
    block filters, spent transaction outputs, and block-specific deployment info
    are marked cacheable for one day. Responses that can change with active chain
    or node state, as well as errors, are marked no-store. (#34794)

Low-level changes

Indexes
  • The transaction index (-txindex) now stores less data on disk; a fully
    rebuilt index takes less than half the space. The index is backwards
    compatible, so existing users will not see the space saving unless the index
    is recreated. To do so, stop the node, delete the <datadir>/indexes/txindex
    directory, and restart; rebuilding can take up to a few hours depending on
    hardware. Progress can be monitored using the getindexinfo RPC. Once
    rebuilt, the index can no longer be read by previous releases, so downgrading
    will rebuild it again in the old format. When downgrading permanently, delete
    the <datadir>/indexes/txindex directory first, since previous releases do
    not reclaim the space used by entries in the new format. (#35531)
  • The transaction output spender index (-txospenderindex) now uses less disk
    space. Existing indexes remain compatible and no action is required. To
    reclaim the space for data indexed before upgrading, stop the node, delete the
    <datadir>/indexes/txospenderindex/ directory, and restart with
    -txospenderindex enabled to rebuild it. (#35634, #35568)

RPC
  • Libevent has been replaced with a custom HTTP server (#35182). Certain HTTP
    edge cases will observe different behavior to be more RFC-compliant:
    • Stricter enforcement of maximum headers size (8192 bytes)
    • Reject requests with whitespace in header field-names
    • "Line Folding" is rejected (whitespace at start of a header line)
    • Tolerate % at the end of requested URLs
    • Multiple "Content-Length" headers with different values are rejected
  • Clients attempting to connect from addresses not allowed by the -rpcallowip
    option (or its default, localhost) will now be immediately disconnected
    instead of receiving a 403 Forbidden. (#35592)

Credits

Thanks to everyone who directly contributed to this release:
  • 0xb10c
  • Adam Andrews
  • Alexander Wiederin
  • Alfonso Roman Zubeldia
  • ameen-alam
  • amisha
  • Amiti Uttarwar
  • Andreas Kouloumos
  • Andrew Toth
  • Anthony Towns
  • Anthropic Security
  • Antoine Poinsot
  • ArvinFarrelP
  • Ava Chow
  • azuchi
  • benthecarman
  • Ben Woosley
  • Bicaru20
  • b-l-u-e
  • Bortlesboat
  • Brandon Odiwuor
  • Bruno Garcia
  • CaesarCoder
  • Chandra Pratap
  • codeabysss
  • Cory Fields
  • Craig Raw
  • crStiv
  • csjones
  • cyb3ralbert
  • Daniela Brozzoni
  • Daniel Pfeifer
  • Danny van Heumen
  • David Gumberg
  • deadmanoz
  • dergoegge
  • ekzyis
  • Enoch Azariah
  • Eugene Siegel
  • Evan Sultanik
  • Fabian Jahr
  • fanquake
  • frankomosh
  • Gloria Zhao
  • Greg Sanders
  • Guillermo Fernandes
  • GuTS805
  • Hao Xu
  • Hennadii Stepanov
  • Henry Romp
  • Hodlinator
  • HouseOfHufflepuff
  • ImMike
  • ismaelsadeeq
  • janb84
  • jeanpablojp
  • Jean-Philippe Aumasson
  • joaonevess
  • Jon Atack
  • jpk68
  • jrakibi
  • junbyjun1238
  • Kanan
  • kevkevinpal
  • Kyle 🐆
  • l0rinc
  • Laxman Acharya
  • littleyier
  • Luke Dashjr
  • maflcko
  • marcofleon
  • Martin Zumsande
  • Matias Furszyfer
  • Matthew Zipkin
  • Max Edwards
  • Mccalabrese
  • Memetic Money
  • Michael Dietz
  • Muhammad
  • Murch
  • Musa Haruna
  • naiyoma
  • nebula-21
  • nervana21
  • Novo
  • optout
  • Pablo Martin
  • Peter Zafonte
  • Philips Ucheolisah .N
  • Pieter Wuille
  • Pol Espinasa
  • pseudoramdom
  • pythcoiner
  • Renato Britto
  • rkrux
  • Rob Hamilton
  • Robin David
  • Roqqit
  • Ruslan Kasheparov
  • Russell Yanofsky
  • rustaceanrob
  • Sanjana2906
  • satsfy
  • sayed nabhan
  • Sebastian Falbesoner
  • Sebastian van Staa
  • sedited
  • seduless
  • shaurya2k06
  • Shrey
  • Shuvam Pandey
  • Sjors Provoost
  • stickies-v
  • stratospher
  • stringintech
  • taboger
  • takeshikurosawaa
  • Thomas
  • Torkel Rogstad
  • Vasil Dimov
  • vicjuma
  • ViniciusCestarii
  • w0xlt
  • Will Clark
  • winterrdog
  • xyzconstant
  • Yancy
  • yuvicc

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



SHA256SUMS

Code:
16f64d6b179e3988756e0808f8a7877040d2f649036fdd98289537a7b345e07e  bitcoin-32.1-aarch64-linux-gnu-debug.tar.gz
7ed37c7373eb6aa3e3f72842596a1afeba1b223717033cade9842b25773e1922  bitcoin-32.1-aarch64-linux-gnu.tar.gz
a1599a2b4718b12b83dd586e98a5bea22da78bc276f813ab4266b7d89affec91  bitcoin-32.1-arm-linux-gnueabihf-debug.tar.gz
d3eb66edc34be230667d925a30e2b590c0671cd65e0302bfc5c6aa57fd3eb9a6  bitcoin-32.1-arm-linux-gnueabihf.tar.gz
cd3dcdacb4ff861e862b2d7df4786ecef66472e2468dca1673a70dd761e064e7  bitcoin-32.1-arm64-apple-darwin.tar.gz
6fb94e4d2254bf45f0f58a6679c10f16206c5e885be8541fd974d395fe49d46c  bitcoin-32.1-arm64-apple-darwin.zip
ae176c10be5bd5a93c241c25b6bd0e61a449cc199b31714cb31e3e882454c856  bitcoin-32.1-arm64-apple-darwin-codesigning.tar.gz
0bb7c016533d78e39f239636a624b383b6d29f72eae0a2f3d4e6ee8ba774ba41  bitcoin-32.1-arm64-apple-darwin-unsigned.tar.gz
4d18a36efe2fb04ccf64d0208d63c4a582491ee9c2da9dfe782b02ed5afec653  bitcoin-32.1-arm64-apple-darwin-unsigned.zip
4c4dfdbea1e099bf36338a56c33e7441f8b3e618a17bf0a7b4258ecc3b9b9c2d  bitcoin-32.1-codesignatures-32.1.tar.gz
a5f2f61e32cf7f790641c9ec306a3c88ca7b5a556946956b1f35ffd7e27813f9  bitcoin-32.1.tar.gz
03ba7ad6fafb055a402c7ff47a057f756abaf8b0b0ca5098f924844c16695f52  bitcoin-32.1-powerpc64-linux-gnu-debug.tar.gz
8e53a009e08d82c71b07f2464895fd1b04a960f51ff5239bd86c03d5d256c707  bitcoin-32.1-powerpc64-linux-gnu.tar.gz
58f0244f2a579c24cce1a5db4964077efb723ed77a79a0e70782cc3ee9327770  bitcoin-32.1-riscv64-linux-gnu-debug.tar.gz
bb2baffb815972e4ec8f188fa32bd76aec19a3b2c798c1f4093ad619de2d1388  bitcoin-32.1-riscv64-linux-gnu.tar.gz
53b1e6ffd92843ca82ef4a737d7a53cb0a9fab15816a417a41f12fc954071447  bitcoin-32.1-x86_64-apple-darwin.tar.gz
c23e112cfce25918789cfb639b49d896c2d6ab450c226b55f981222ef9744d52  bitcoin-32.1-x86_64-apple-darwin.zip
ada2d2c6c4acb3ba6647212f67acb5011b4e2b6f3aa9f975e3a7ef9f9fc13443  bitcoin-32.1-x86_64-apple-darwin-codesigning.tar.gz
1902cf2d6fc3da5e3dbd6572ec0acd7d1a3a7596695f860dce6ea2397eb90836  bitcoin-32.1-x86_64-apple-darwin-unsigned.tar.gz
96727131d3bfe169513470452be1326392f9a6ab8b419567601b01709dc4a0ae  bitcoin-32.1-x86_64-apple-darwin-unsigned.zip
21c2c22c5a871f9e1076f371c58b99cc9bb0489785f6e519e5c8197c782e371b  bitcoin-32.1-x86_64-linux-gnu-debug.tar.gz
61545c17c3120fb7412f896d248b11993af04ec8817aad3649c55b2afb044963  bitcoin-32.1-x86_64-linux-gnu.tar.gz
d4cc64d500fa7713b5e2f3b9d46a215def3c4ed91aa46bf13e4de1a042bf9aa2  bitcoin-32.1-win64-setup.exe
b5b0c2cd007d69e96880907c79f9ae19ae82728f95fc8c923b4a07dab795b45d  bitcoin-32.1-win64.zip
30bc5c536b7023b8b14208ca7fd38be63b48e6f3e6ab507fc0e8fea0b9c4b035  bitcoin-32.1-win64-codesigning.tar.gz
613fa642aa54ea2164e3baa4736785911c621a3bf12793313610e39349dae1b9  bitcoin-32.1-win64-debug.zip
63f315a0766e3cf2b150f528b02da028530a771162220b67879098fa6084c3f1  bitcoin-32.1-win64-setup-unsigned.exe
4ed46c5791bff47d0dea55bb4034db63574a70211cb59c413cb0b58565c5063d  bitcoin-32.1-win64-unsigned.zip

SHA256SUMS.asc

Code:
-----BEGIN PGP SIGNATURE-----

iQJEBAABCAAuFiEEFSgSMAeFyWRE0zNNF1ZXMuCOXkEFAmrgopsQHG1lQGFjaG93
MTAxLmNvbQAKCRAXVlcy4I5eQQ5UEACcx+s5B9euyrNu6ayBwDtHImjjtHIWucMj
vMpJaft0vxAixlzcvFAnT1IoEo5T8fV4ofF+evJRdhtMBIbk/25qik43z/CXGkgj
sa6oDM54cAaanBC7iTXJrK7kFSmnVVX4hoouA+0XYBn8ea9shK/52UvYb1cLN2jH
SpVtrlyC4NXq228eISAcIkpWtV5oYEj31clwhX5xHiufVGMz/NpiUd0YxTIhWgev
PqRbsQxRHlA2UTHgNbaJhEp7UDwUERBrF3ElW2S9sJoZ6WnPtgbgBNYteQFWj2ze
TiWH7fww4IY/vHZzlP4ztUcK0lAz1PUci1OPGbxojmKjS5xdldh8P/WiZDn1CuJE
fXhUAPCUFhhXVpnBmD/0Es4o/UsNIvDz9b7Sh+pss5/ge1LpBKf9MPyytOBU+4Pi
wF+tbbmqd914QgnStRXtD//uKZC2yl5NLvWo3LiRgJWG4xJpCEllYd7ODVT4AAkG
WPlDAvj71A7cHo+UqLIFeAlLi9hqZKMErMAtpAX6CHFz2lpT48Z6HLe1zJB2Y/Mr
bVRCLZ9COwFOx9uSE0hbPQrwH0OQipJYE9LE8z1O3KQyiWNHpA3CGmrFsjjztMjG
o3+ZDLT27zQdIfBNmIoST24ugBPV+f5ZafFcCZMHQkAtDcEFewDNg3I2nXyghlrd
uHB3n/DopQ==
=ym6S
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----

iQGzBAABCAAdFiEECtg4d8HwzR7pvWYK18x3C4H9IqgFAmrgqksACgkQ18x3C4H9
IqiEFgwAobIh8n8zREJTJmcpGctVVYZhG0MOWz31kTWarpL8mrckzWr7zSO7ZQ6D
npXDCmfa7dWfxKHJPuGAi6TbAcd9JPqw5XwI3gI22S9k+ZWAhbOc10WgzeMNXQ+0
TgdUV8sq7r982Db6EicHBo5wfW1uFp2wjkjTMlEXWewKM4SRquJQXuZ+bfIn2gfK
WybKqaEDObwCwlhxMMbtF+JHK/FH36SZxZ7UPoo5m4A2TekqnImMdxrai+pdz3r6
tM8MXA7WzM//4InBjuYxieCwPKa+43YbG2oDBm79YzMyYeMMWOpQMuOtONydIE4Y
J8zue/KeXwiufzxvJ7I/S/wZJ9cW69yVn+sYG6AEgJefNhCdAaukVUp0jxHLeajM
cpEwvlxOs2LcLK7cl1jfutTegEgvfbztGPcNAjJGwjhBcet1C9gD2+MK4fbegwL3
ZX48c7RUvFZQJM/uDkDXlLMsUCtQ+6/OfbilKmkQ6Ed836FrEqJi+HTKcuGlkLH2
sw3SzKU7
=BT2s
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----

iQJjBAABCABNFiEEz7FuIclQ9n+pXlWPLuufXMCVJsEFAmrgrh8bFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMCwzExxmYW5xdWFrZUBnbWFpbC5jb20ACgkQLuufXMCV
JsFTLQ/+N6E4wyIE09+v99YJEnUOxJmVV2FyB/pA0f9OD2TiaEGoUeo8rPZoIRzX
roPI7k6xHnyGXe9vQZ+g4FtwN6CDo1IbICHSHz8fj84Qm9Y8no2Z+TtsJFlzqkyI
J17DFNVN+lS8SykIIECdQE8dAfcSEbF9EUgfWE5uXrac8xWf7P15cJweuioSX6gK
G8sUDTFmFDyIhWRBmqlEILtctMWi1hjkOjZ3HzoMyeCCmv6mB2VQBKDTSaM6iMsP
568eD4PBdFqmrV/6h2ovRU6lypfMRylLATUUbqg95Z1VfvnSNHiNwNI9Z/pab4Eb
17kEzAZ0JOug4B5qMSqv5D3hWFxPGsxo95WXTN6w90zb1CywfAH/3NMF1Nna0S83
NOlgFRKeJWDiHgNtnYdu0/oFzNQ2RsSztxnyX6vu3ssvr/+mGW3M0GYNkGKtvQrs
fPG+xPYVHY7DlI4qwpj0DusG3bm8ZQKxy6akRy/3yi5idfHteWb8KAyZJL1Jpu3C
fSZbOl7Wuv1qUYckVC8qMgYutpo15p9u9xqLwdhWrFPHLI6KEYae1CrsmHUEK2v9
dQ3oDvHcg/kB8D0QWnNPltShQwr5FVgd0H2y+tLlpOT9JbWvuisS4tpYpICeG4xi
/1yajmWyBxPFyypM/iti784R+pqBaEMVfHBEYg0lf2L6a4svCZ8=
=N3n4
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----

iQJFBAABCAAvFiEE9Pxw8HMQAoQk78IKjkJWWT8XdyAFAmrgsRgRHGd1Z2dlckBn
bWFpbC5jb20ACgkQjkJWWT8XdyD8Dg/7BUatIxEtTcl/kGDf6F8IMO9wpsVq5K6H
UQ4fzyv5YZhPvb/dA4TtgQfJeNFbQYvfLcIlonbn2oQpEuIgJkv+piBVvAADpHUL
xrLYxYKcJpjBJigfwv8qxeadVt7jjfV09h0uaFSizV5IC6ZglHagQaER4mqjB/jk
cL4ulRs2qkZGXXB7ssP5AaglGJ0MnI7/NWOzsSltxlaYpbSIhsUtrVksOzO6UnO6
IYHN67CD/ZPSY2pG60dLIEHdtgqLhFpaBHMnZfRDd8oHWYpkMyp7Tkkp6YhjJS7z
N4r68exQLjzShqRcubaaxAlBzjzlCQwdwKnMigZs2wlwzh5dv1915EMD5m3ON9gx
udAnF3AX39iDV1mltiQig5wvVWWq62sTVTJ1/V4kXSulLHALg8U059g/ijH9b6R6
QSUoIGt/Fe8eB7/nTT2Wq9K/Uo90XDQ79b94Rz3IbvmPv1Wca4Qh24rplOakfvXs
RQdOlJ0d1IQh5Sihq9wZCeGdtV/gXW3Krb92vSrWKyCVGaaYocXW3EzXn4q7/7rc
YunL8lFdk0NkxUkOKz210O0ngubr6jep3XP49WhsOg1EN8w2sJ+Kjl0NvD56KPRw
N/cksthrXuFcmOcAR2QoSex3DW8tE3dxc2rIwalgm4kOZmO9ULYPlFLPNMlyOGvf
PuiKfElY6JY=
=a4Aa
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----

iQJkBAABCABOFiEE5hdzzW4BBA4vG9eM5+KYS2KJyToFAmrgrOcbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMCwzFBxwaW5oZWFkbXpAZ21haWwuY29tAAoJEOfimEti
ick6VLsP/35T+XHhbI4+YJR86teobkI7UdmFi2BFyhSCIrF4OdliCXPZLqIjVZpw
dToSiLYBtG7aUjRDL+lPa0DisfILq5lD1PDWwHJQBsI9BIb1e+EPbdCeUwz4O5iG
QV85siFr7Du4vYl8mym0+MphRCq/8InbT4MD3G69uNoGRxPreNewHTtl5Ody/g59
/dABHGO9+ZmQgPE9yvJ3xPhAPZZbPweckVmmTE3hGhrHpL7W076ZGoeT6CbjGW+0
2hdaG+62DN6HynfM3+1NGohz7sxhkNxP4TQ/f9UCCgkFoPxSX/lpjVlu4bG53Pa1
WQm8JviPjapgd+YPVay5+fg/Xr3I+shEcTLek0PSW435d8KpUoihDaEyUH7xSklV
TrCUXGOV4PQK9rJMTeU0ImNO/CeA+G54D662OV16huUuvjX3EmSk4QPEDKUnf7dy
U93kv1V+7S9Q8alOLJ9Wo6QJOxEDjKr5HFaOFZkPwaltPusOYSlb0gV2tPZcQNp2
w9VjfHOKpUX8knsZGvbUDq0VbdshoP9LgLCK8RpmK3cFULLVqf8nijBlpF+a+Kg5
hpuzDPFYQOVvkncQyAWeggWuCGhLY++PFIbEi2U4WZI5xG5YrD7JYLlCeo6ZaOT8
Q89+yCQL3UQNXueQ/H+l9tYK1ZGDtVewuqZhT2Tp1FhgkwBUrRd/
=sdAz
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----

iQJHBAABCAAxFiEE8s/Eq9C5nYN+67fQm3m0VpHbQXMFAmrgxI8THHNlYi5rdW5n
QGdtYWlsLmNvbQAKCRCbebRWkdtBc8bTEADIdCilfONGEdVxCfl6IaU9EwFwKWAx
Z5y2pz6G+3zqpvyIuD2F6D3KgZ+5IeDBYBV1xqzaM4vWOOliXWVwGILzyQGfv56K
n6L/TjmgQxLmBHcyUJr5FaAQhTcQBxxvAP0O+r0O0uXU/febmy69NPqvic8tYMjI
uMaYe6vH6rUE5sSzNLxX5j1NwGVufECTGDmGOplv0UWazrurgIcqun8eO4wSzw2K
OxEYbxBZanGtChJAbjZzxua/u/i9uBnzPNRFV2qW7iKfK4zfYuccOyirlm9RpeRa
lvXXOy6s/yXY+MP+l7wJzQhkrun7NOjslvFRF51hhOfGouCDyk0qvbyctfiWOhQD
Z4JRNLsgnp2l17nwZaMVUTnu5KoaRZLB+lx/7n6GxZOfB+r3KSSIBDYVfHSKQ9gK
IiMlSL0y459LqTCQM6z4I9CyUrCOyW5Mk5VbOgkrlJ0nvSWq3Pk0/7sHeI9VjsaT
wtArOMinaBmN8MmFZjRqmknFtpZE8eAM6QzJja+Wa8ImjagOimbJmLNJzeWo5V9N
8g3fZNEx7kcBMC3R9Tnkim491+W/eb2tboX0EVjbBtIxZlOfdHCJdm1u4CqbuZel
WrRbRIWTEvd2VO8GDILBTgPfU6H//Gxa22Kt6RJUw3VLd3aauABNj3duVqsnVAtY
C/0KiqjvEYh2cQ==
=q4WF
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE7ZvfetalXiMuhFJCV/+b28wwEAkFAmrgn1AACgkQV/+b28ww
EAkOHg//TO+ZikU4Dda3uqKjKyS8N4T3bayY5EUt25QszslS66krfi9m3rCNes7i
unke0VdAlTFl3mWwFfM7dDrcSLBojAee+g8IqshdJcR0tG2RvK21hPRKYQTvZ1b1
dbOOwclB6BURV0DNmcEqvSdG1c4nPTSNXXlghX2mNlT3lOdt56AQj4oVJieggouN
tXkCjYvHrR7nuIvNw5Nwytu5uFhTRvp6Sn6JGkxx4gVTY0WQvQIl+AgksMWU85bw
4yaXS1kA9SbknFAlaQl7rB9bIY8qht9++YKpQrnhW92u3IyoD1uwz0Sz1as5/KCz
9KUX30g/RoilBAN8s4Hkf6XD69vz1qAujRRYEkEHrXAyjr2W6NkjKydRSOpTCDFD
55UQJCzA/6+41Bgi6Qok4NQpqQR1FFhzyl3GWHvZHyqbvz18BLQgsGmGO4f/oASd
+2M6Q0ebSVMdQGewmsNISEOk7uW6zuqHIdKPVlk+mXSFp+8rmpVWJ81ETxc/KaiK
LQfhe2klDmoacEVQLdl9pN3YiSqQYzNKolyMR+VBDDZm8NYhXbLnTJT/CVPN6s95
L2r58oIQVInqVFR4GRFa+S05/sQFB0ewaAOkAso+KAbliuhgSqfoTo7V+mz/i3XS
Dzryn28xEITTEp825mY0oPD56aI/vw5BaUeII5XuPLPa3rXrcks=
=OmRk
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEoAg2YPI1onAAzTyBzm7EmUXBfqYFAmrgnsgACgkQzm7EmUXB
fqazDxAAuWAKzyvfaOmOsv5F63fww8kke/upPFeK+ZbXcZEBmnarrl4o7qmgmcQQ
lY7Z/2VjosC2mqWU9TOVbO2G0YzRRIS/mu8nStqNIEnVJvtLnsx8l9lYXjgZhI4z
1BBU2bw0tWWXfjEYSE0V+BoJc94fQICP82LC1YxQBh/zvr/n+ol9YFHhGVDEpwwZ
c5HM5ho3Su5ATLwjAh0XMG1vhAI9uxLWugQWn72oWu3dDsJb8zqdsHfrWLKOwWIi
wyc5e/w2n9Xsn/rbqDWS9yzwUaaIEKigkYe99Vdu0fdcop8+QusF9Fe5gDc1m0AP
Hrh/5a/jrKKnVMfxRMHxlyL/SRR87DolPMwFyfRDiGXwCepjIWOQfNUQ28q5z4qK
rearPQI17/Zz+VDH3+V75qHn+R9N/CCV3vJRqfRdced8ekVnIx/okHHb5bzBmvU0
QiQ57rIDZGYE++2KNFaHpPdlx1OiMRtnGozSVt9rx78QKIiOUTvkbhM2NaIddTU8
o3Ul44AeUlGVJ7dYEdaEOz5OfUa6eTZsWsaBIrYgif3Lk9ASqpSRKRXCorUeLUxK
aUsHEd7iUKD5elpCbVsafR2tBGqKItPVknLg6AIR7Gb031afO+ElHFPJjP7xTJiE
siqdKD49AXuOvcTntYCg54//uEMNaYyx68l5gcQDWmKP2mriWHU=
=jOaG
-----END PGP SIGNATURE-----

Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!