Topic: Bitcoin Core 28.0 Released (Read 3103 times)

I am a Portugal based professional in the investment industry and on FUNDS RECLAIMER COMPANY to expand my network and connect with other industry professionals. I would be happy to connect you all with FUNDS RECLAIMER COMPANY and start the dialogue to see how we can cooperate.

Funds Reclaimer Company is a trusted and experienced recovery firm dedicated to helping individuals and businesses reclaim lost funds. Our team of experts utilizes cutting-edge technology and proven strategies to ensure successful recoveries.


A few months ago, I decided to invest a significant amount of 100,000 AUD with a broker called Moneyflip. Initially, everything seemed legitimate, and I was optimistic about the potential returns. However, my experience quickly turned sour when I tried to withdraw my funds. What seemed like a straightforward withdrawal process became a nightmare. Money flip imposed multiple conditions for me to meet before I could access my funds. Each time I ticked off one requirement, another appeared, making the entire process incredibly frustrating. I complied with all their demands, submitted countless documents, and followed every instruction they provided. Yet, my withdrawal was continually delayed or blocked. It became increasingly clear that Moneyflip had no intention of letting me take my money out. Feeling stuck and desperate, I turned to a colleague who had dealt with a similar situation. He recommended FUNDS RECLAIMER COMPANY
, a company that specializes in recovering funds from brokers with shady practices. Although I had never heard of them before, I trusted my colleague’s advice and reached out to Wizard Web Recovery. From the moment I contacted them, I could tell I was in good hands. The team at FUNDS RECLAIMER COMPANY
was highly professional and attentive, taking the time to understand the full details of my case. They explained their process clearly and assured me they had dealt with situations like mine before. They began working on my case immediately, and within a short period, I began to see progress. Thanks to their expertise,FUNDS RECLAIMER COMPANY
 was able to recover the full 100,000 AUD I had invested. Not only did they get my money back, but they also helped me transfer it safely to my Binance wallet, ensuring that I had full control over the funds. It was a huge relief to finally have access to my money after all the stress and delays caused by Moneyflip. This experience taught me an important lesson about the risks of dealing with online brokers and the value of working with professionals when things go wrong. I am extremely grateful toFUNDS RECLAIMER COMPANY
 for their dedication and expertise. If you ever find yourself in a similar situation, I highly recommend reaching out to a trusted recovery service like FUNDS RECLAIMER COMPANY
 they were instrumental in helping me recover my funds and get them safely into my Binance wallet.


WhatsApp:+13612504110

Email:[email protected]
 
Website:https://fundsreclaimercompany.com

As nc50lc already said, I augment it a little bit, you can use dumpprivkey to get the private keys of a legacy (pool of random keys) or HD wallet (based on a hdseed private key), IIRC.

To recreate a legacy wallet if you have such a private keys dump you would need to import the private keys via importprivkey. I haven't tried this with recent versions of Bitcoin Core as legacy wallets are deprecated. You likely need to create an empty wallet and fill it with the individual private keys from your dump file.

To recreate a HD wallet which is not based on descriptors, you would define the saved hdseed key with the command sethdseed. It's still on my agenda to try such a restauration. Likely nc50lc or someone else has documented this already in this forum (a very brief search via ninjastic.space didn't show a recipe immediately and I was a bit too lazy to dig deeper).


With descriptor wallets (preferred to migrate to) you can get the extended private key descriptors via command bitcoin-cli listdescriptors "true". Without "true" you only get the extended public key descriptors, which are suitable for watch-only wallets.

And as already said by others you can recreate all sorts of wallets with importdescriptors because descriptors are quite versatile (and a bit challenging on the learning curve, but what is life without challenges?).

You mean "export" the private key from your wallet? If so, you can't with a descriptor wallet.
For legacy wallet created by older versions, it's dumpprivkey

Directly creating a wallet with the privkey isn't possible but you can create a blank wallet and import your private key there using importdescriptors command.
Create a descriptor (descriptors.md) using your WIF private key with the correct script type and import it using that command (requires a descriptor wallet).
For legacy, use importprivkey

Note: use help to see how to use the given commands; e.g.: help importdescriptors

can anyone tell me which command in the console window i can use to read the private key from my wallet.dat on Bitcoin core?
i have gone through the complete wallet commands, but i am not sure which command would be the right one in this case

and of course which command do i use to restore the wallet using the private key that was read out?

Kudos to the Bitcoin Core team👏! There have been numerous new changes in this release since version 27.1.

Thank you for sharing this valuable update on Bitcoin Core 28.0! Your effort in keeping everyone informed about such significant developments is truly appreciated.These insights on improved security, decentralization, and new features like Testnet4 are highly useful for the community.

Sweet, thank you for posting! There are so many exciting mempool improvements in this release!  Handling multi-party transactions and getting them confirmed will be so much smoother and less chaotic now!

I remember it caused confusion among few people since they could run Bitcoin Core without adding that library/file when using install command on Linux.


You might want to check his trust feedback and other generic/non-sense posts.

I don't know where you got that info, but it always been the default connection count even in older versions.
Maybe you misunderstood the reply above yours?

Here's the DEFAULT_MAX_PEER_CONNECTIONS in Bitcoin Core v28.x branch: https://github.com/bitcoin/bitcoin/blob/28.x/src/net.h#L77
in Bitcoin Core v24.x branch: https://github.com/bitcoin/bitcoin/blob/24.x/src/net.h#L77
in old Bitcoin Core v0.12.0 release:https://github.com/bitcoin/bitcoin/blob/v0.12.0/src/net.h#L63

So many new changes in this release since 27.1. Congratulations to the Bitcoin Core team!

It patches a high-risk vulnerability that put 1 in 6 nodes at risk of DoS attacks, so that fix alone was pretty crucial. The default peer connection limit going up to 125 is also cool —more connections mean better network stability as more people pile in. And with all the new mempool tweaks and GUI changes, the development team is putting in a solid effort

Just updated from 27.1, seems fine so far. I have 125 connections running smoothly!

There's so many mempool improvements in this release Getting multi-party transactions confirmed will be less of a mess now.

Bitcoin Core version 28.0 is now available from:

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

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/

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 bitcoind/bitcoin-qt (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.

Running Bitcoin Core binaries on macOS requires self signing.

cd /path/to/bitcoin-28.0/bin
xattr -d com.apple.quarantine bitcoin-cli bitcoin-qt bitcoin-tx bitcoin-util bitcoin-wallet bitcoind test_bitcoin
codesign -s - bitcoin-cli bitcoin-qt bitcoin-tx bitcoin-util bitcoin-wallet bitcoind test_bitcoin

Compatibility

Bitcoin Core is supported and extensively tested on operating systems
using the Linux Kernel 3.17+, macOS 11.0+, and Windows 7 and newer. 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

Testnet4/BIP94 support

Support for Testnet4 as specified in BIP94
has been added. The network can be selected with the -testnet4 option and
the section header is also named [testnet4].

While the intention is to phase out support for Testnet3 in an upcoming
version, support for it is still available via the known options in this
release. (#29775)

Windows Data Directory

The default data directory on Windows has been moved from C:\Users\Username\AppData\Roaming\Bitcoin
to C:\Users\Username\AppData\Local\Bitcoin. Bitcoin Core will check the existence
of the old directory first and continue to use that directory for backwards
compatibility if it is present. (#27064)

JSON-RPC 2.0 Support

The JSON-RPC server now recognizes JSON-RPC 2.0 requests and responds with
strict adherence to the specification.
See JSON-RPC-interface.md for details. (#27101)

JSON-RPC clients may need to be updated to be compatible with the JSON-RPC server.
Please open an issue on GitHub if any compatibility issues are found.

libbitcoinconsensus Removal

The libbitcoin-consensus library was deprecated in 27.0 and is now completely removed. (#29648)

P2P and Network Changes

• Previously if Bitcoin Core was listening for P2P connections, either using
  default settings or via bind=addr:port it would always also bind to
  127.0.0.1:8334 to listen for Tor connections. It was not possible to switch
  this off, even if the node didn't use Tor. This has been changed and now
  bind=addr:port results in binding on addr:port only. The default behavior
  of binding to 0.0.0.0:8333 and 127.0.0.1:8334 has not been changed.
  
  If you are using a bind=... configuration without bind=...=onion and rely
  on the previous implied behavior to accept incoming Tor connections at
  127.0.0.1:8334, you need to now make this explicit by using
  bind=... bind=127.0.0.1:8334=onion. (#22729)
  
• Bitcoin Core will now fail to start up if any of its P2P binds fail, rather
  than the previous behaviour where it would only abort startup if all P2P
  binds had failed. (#22729)
  
• UNIX domain sockets can now be used for proxy connections. Set -onion or -proxy
  to the local socket path with the prefix unix: (e.g. -onion=unix:/home/me/torsocket).
  (#27375)
  
• UNIX socket paths are now accepted for -zmqpubrawblock and -zmqpubrawtx with
  the format -zmqpubrawtx=unix:/path/to/file (#27679)
  
• Additional "in" and "out" flags have been added to -whitelist to control whether
  permissions apply to inbound connections and/or manual ones (default: inbound only). (#27114)
  
• Transactions having a feerate that is too low will be opportunistically paired with
  their child transactions and submitted as a package, thus enabling the node to download
  1-parent-1-child packages using the existing transaction relay protocol. Combined with
  other mempool policies, this change allows limited "package relay" when a parent transaction
  is below the mempool minimum feerate. Topologically Restricted Until Confirmation (TRUC)
  parents are additionally allowed to be below the minimum relay feerate (i.e., pay 0 fees).
  Use the submitpackage RPC to submit packages directly to the node. Warning: this P2P
  feature is limited (unlike the submitpackage interface, a child with multiple unconfirmed
  parents is not supported) and not yet reliable under adversarial conditions. (#28970)
  

Mempool Policy Changes

• Transactions with version number set to 3 are now treated as standard on all networks (#29496),
  subject to opt-in Topologically Restricted Until Confirmation (TRUC) transaction policy as
  described in BIP 431.  The
  policy includes limits on spending unconfirmed outputs (#28948), eviction of a previous descendant
  if a more incentive-compatible one is submitted (#29306), and a maximum transaction size of 10,000vB
  (#29873). These restrictions simplify the assessment of incentive compatibility of accepting or
  replacing TRUC transactions, thus ensuring any replacements are more profitable for the node and
  making fee-bumping more reliable.
  
• Pay To Anchor (P2A) is a new standard witness output type for spending,
  a newly recognised output template. This allows for key-less anchor
  outputs, with compact spending conditions for additional efficiencies on
  top of an equivalent sh(OP_TRUE) output, in addition to the txid stability
  of the spending transaction.
  N.B. propagation of this output spending on the network will be limited
  until a sufficient number of nodes on the network adopt this upgrade. (#30352)
  
• Limited package RBF is now enabled, where the proposed conflicting package would result in
  a connected component, aka cluster, of size 2 in the mempool. All clusters being conflicted
  against must be of size 2 or lower. (#28984)
  
• The default value of the -mempoolfullrbf configuration option has been changed from 0 to 1,
  i.e. mempoolfullrbf=1. (#30493)
  

Updated RPCs

• The dumptxoutset RPC now returns the UTXO set dump in a new and
  improved format. Correspondingly, the loadtxoutset RPC now expects
  this new format in the dumps it tries to load. Dumps with the old
  format are no longer supported and need to be recreated using the
  new format to be usable. (#29612)
  
• AssumeUTXO mainnet parameters have been added for height 840,000.
  This means the loadtxoutset RPC can now be used on mainnet with
  the matching UTXO set from that height. (#28553)
  
• The warnings field in getblockchaininfo, getmininginfo and
  getnetworkinfo now returns all the active node warnings as an array
  of strings, instead of a single warning. The current behaviour
  can be temporarily restored by running Bitcoin Core with the configuration
  option -deprecatedrpc=warnings. (#29845)
  
• Previously when using the sendrawtransaction RPC and specifying outputs
  that are already in the UTXO set, an RPC error code of -27 with the
  message "Transaction already in block chain" was returned in response.
  The error message has been changed to "Transaction outputs already in utxo set"
  to more accurately describe the source of the issue. (#30212)
  
• The default mode for the estimatesmartfee RPC has been updated from conservative to economical,
  which is expected to reduce over-estimation for many users, particularly if Replace-by-Fee is an option.
  For users that require high confidence in their fee estimates at the cost of potentially over-estimating,
  the conservative mode remains available. (#30275)
  
• RPC scantxoutset now returns 2 new fields in the "unspents" JSON array: blockhash and confirmations.
  See the scantxoutset help for details. (#30515)
  
• RPC submitpackage now allows 2 new arguments to be passed: maxfeerate and maxburnamount. See the
  subtmitpackage help for details. (#28950)
  

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

Updated REST APIs

• Parameter validation for /rest/getutxos has been improved by rejecting
  truncated or overly large txids and malformed outpoint indices via raising
  an HTTP_BAD_REQUEST "Parse error". These requests were previously handled
  silently. (#30482, #30444)

Build System

• GCC 11.1 or later, or Clang 16.0 or later,
  are now required to compile Bitcoin Core. (#29091, #30263)
  
• The minimum required glibc to run Bitcoin Core is now
  2.31. This means that RHEL 8 and Ubuntu 18.04 (Bionic)
  are no-longer supported. (#29987)
  
• --enable-lcov-branch-coverage has been removed, given
  incompatibilities between lcov version 1 & 2. LCOV_OPTS
  should be used to set any options instead. (#30192)
  

Updated Settings

• When running with -alertnotify, an alert can now be raised multiple
  times instead of just once. Previously, it was only raised when unknown
  new consensus rules were activated. Its scope has now been increased to
  include all kernel warnings. Specifically, alerts will now also be raised
  when an invalid chain with a large amount of work has been detected.
  Additional warnings may be added in the future. (#30058)

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

Wallet

• The wallet now detects when wallet transactions conflict with the mempool. Mempool-conflicting
  transactions can be seen in the "mempoolconflicts" field of gettransaction. The inputs
  of mempool-conflicted transactions can now be respent without manually abandoning the
  transactions when the parent transaction is dropped from the mempool, which can cause wallet
  balances to appear higher. (#27307)
  
• A new max_tx_weight option has been added to the RPCs fundrawtransaction, walletcreatefundedpsbt, and send.
  It specifies the maximum transaction weight. If the limit is exceeded during funding, the transaction will not be built.
  The default value is 4,000,000 WU. (#29523)
  
• A new createwalletdescriptor RPC allows users to add new automatically generated
  descriptors to their wallet. This can be used to upgrade wallets created prior to the
  introduction of a new standard descriptor, such as taproot. (#29130)
  
• A new RPC gethdkeys lists all of the BIP32 HD keys in use by all of the descriptors in the wallet.
  These keys can be used in conjunction with createwalletdescriptor to create and add single key
  descriptors to the wallet for a particular key that the wallet already knows. (#29130)
  
• The sendall RPC can now spend unconfirmed change and will include additional fees as necessary
  for the resulting transaction to bump the unconfirmed transactions' feerates to the specified feerate. (#28979)
  
• In RPC bumpfee, if a fee_rate is specified, the feerate is no longer restricted
  to following the wallet's incremental feerate of 5 sat/vb. The feerate must still be
  at least the sum of the original fee and the mempool's incremental feerate. (#27969)
  

GUI Changes

• The "Migrate Wallet" menu allows users to migrate any legacy wallet in their wallet
  directory, regardless of the wallets loaded. (gui#824)
  
• The "Information" window now displays the maximum mempool size along with the
  mempool usage. (gui#825)
  

Low-level Changes

Tests

• The BIP94 timewarp attack mitigation is now active on the regtest network. (#30681)
  
• A new -testdatadir option has been added to test_bitcoin to allow specifying the
  location of unit test data directories. (#26564)
  

Blockstorage

• Block files are now XOR'd by default with a key stored in the blocksdir.
  Previous releases of Bitcoin Core or previous external software will not be able to read the blocksdir with a non-zero XOR-key.
  Refer to the -blocksxor help for more details. (#28052)

Chainstate

• The chainstate database flushes that occur when blocks are pruned will no longer
  empty the database cache. The cache will remain populated longer, which significantly
  reduces the time for initial block download to complete. (#28280)

Dependencies

• The dependency on Boost.Process has been replaced with cpp-subprocess, which is contained in source.
  Builders will no longer need Boost.Process to build with external signer support. (#28981)

Credits

Thanks to everyone who directly contributed to this release:

• 0xb10c
• Alfonso Roman Zubeldia
• Andrew Toth
• AngusP
• Anthony Towns
• Antoine Poinsot
• Anton A
• Ava Chow
• Ayush Singh
• Ben Westgate
• Brandon Odiwuor
• brunoerg
• bstin
• Charlie
• Christopher Bergqvist
• Cory Fields
• crazeteam
• Daniela Brozzoni
• David Gumberg
• dergoegge
• Edil Medeiros
• Epic Curious
• Fabian Jahr
• fanquake
• furszy
• glozow
• Greg Sanders
• hanmz
• Hennadii Stepanov
• Hernan Marino
• Hodlinator
• ishaanam
• ismaelsadeeq
• Jadi
• Jon Atack
• josibake
• jrakibi
• kevkevin
• kevkevinpal
• Konstantin Akimov
• laanwj
• Larry Ruane
• Lőrinc
• Luis Schwab
• Luke Dashjr
• MarcoFalke
• marcofleon
• Marnix
• Martin Saposnic
• Martin Zumsande
• Matt Corallo
• Matthew Zipkin
• Matt Whitlock
• Max Edwards
• Michael Dietz
• Murch
• nanlour
• pablomartin4btc
• Peter Todd
• Pieter Wuille
• @RandyMcMillan
• RoboSchmied
• Roman Zeyde
• Ryan Ofsky
• Sebastian Falbesoner
• Sergi Delgado Segura
• Sjors Provoost
• spicyzboss
• StevenMia
• stickies-v
• stratospher
• Suhas Daftuar
• sunerok
• tdb3
• TheCharlatan
• umiumi
• Vasil Dimov
• virtu
• willcl-ark

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