Whoever is able to replicate this problem (so, yes, NotATether).

I believe this currently falls under the category of "expected behavior". It's a big wallet, that's gonna take a while to load as it has to read every record from disk in to memory. Although that does seem like a lot longer than I would expect.

The logging could probably be better, although it's hard to figure out the loading percentage since neither BDB nor SQLite seem to expose ways to get the count of records that don't involve iterating the whole db.

If you're able to, can you try profiling it? Some docs here: https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md#performance-profiling-with-perf

The wallet is a non-custodial, as it has always been. It's not as if this is going to change between releases - there's no reason to restate the existing features for every single release. This isn't a new product announcement - it's a new version announcement.

Payments get routed through other nodes on the channels that they have open. In order for you to have paid your friend, they need to have a channel open with someone else, who has a channel open with another node, etc. until you get to someone that has a channel open with you. Payments work through forwarding - you paid node C, who used funds that they have in a channel with someone else, to pay another node, and so on, until your friend gets paid. Each node on this route can take a fee for routing your payment, so the amount that leaves your wallet will generally be a bit more than the amount that your friend receives.

There could be a number of different reasons. It could be that node C is the only one that has a route between you and your friend. It could be that the route through node C was the shortest or cheapest and chosen over other routes. In general, the channel used for payments depends on the route chosen for the payment to take.

Kind of, for some definitions of "spend". Also keep in mind that there are no actual "sats" objects, nor are they uniquely identified or separable.

They can "spend" it insofar as they have the literal funds that you sent them. However they also sent their own funds to the next node in the route so that your friend could get paid. It could be argued that they already spent those funds in order to forward the payment.

removeprunedfunds literally deletes transasctions from the wallet, it can't know about funds or spends that it no longer knows about. If you delete a transaction that spends an output from an older transaction, and don't delete that older one, the wallet is going to think the output in the older one is unspent since it no longer knows about the spending transaction.

It's possible that you are seeing issues because you deleted the wrong transactions or deleted too many transactions.

I would say that the behavior that you saw falls under the category of expected behavior, although perhaps the expected behavior has side effects that users do not think of. Of course there may legitimately be a bug there, but it's hard to make that determination without knowing the state of your wallet and exactly the commands you used.

Miss this part?


I think many linux users also use package managers which will handle this automatically.

Major version 25.0 has been released: https://bitcointalk.org/index.php?topic=5454120.0

25.0 Release Notes

Bitcoin Core version 25.0 is now available from:

https://bitcoincore.org/bin/bitcoin-core-25.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.

Compatibility

Bitcoin Core is supported and extensively tested on operating systems
using the Linux kernel, macOS 10.15+, 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

P2P and network changes

• Transactions of non-witness size 65 bytes and above are now allowed by mempool
  and relay policy. This is to better reflect the actual afforded protections
  against CVE-2017-12842 and open up additional use-cases of smaller transaction sizes. (#26265)

New RPCs

• The scanblocks RPC returns the relevant blockhashes from a set of descriptors by
  scanning all blockfilters in the given range. It can be used in combination with
  the getblockheader and rescanblockchain RPCs to achieve fast wallet rescans. Note
  that this functionality can only be used if a compact block filter index
  (-blockfilterindex=1) has been constructed by the node. (#23549)

Updated RPCs

• All JSON-RPC methods accept a new named
  parameter called args that can
  contain positional parameter values. This is a convenience to allow some
  parameter values to be passed by name without having to name every value. The
  python test framework and bitcoin-cli tool both take advantage of this, so
  for example:
  bitcoin-cli -named createwallet wallet_name=mywallet load_on_startup=1
  Can now be shortened to:
  bitcoin-cli -named createwallet mywallet load_on_startup=1
  
• The verifychain RPC will now return false if the checks didn't fail,
  but couldn't be completed at the desired depth and level. This could be due
  to missing data while pruning, due to an insufficient dbcache or due to
  the node being shutdown before the call could finish. (#25574)
  
• sendrawtransaction has a new, optional argument, maxburnamount with a default value of 0.
  Any transaction containing an unspendable output with a value greater than maxburnamount will
  not be submitted. At present, the outputs deemed unspendable are those with scripts that begin
  with an OP_RETURN code (known as 'datacarriers'), scripts that exceed the maximum script size,
  and scripts that contain invalid opcodes.
  
• The testmempoolaccept RPC now returns 2 additional results within the "fees" result:
  "effective-feerate" is the feerate including fees and sizes of transactions validated together if
  package validation was used, and also includes any modified fees from prioritisetransaction. The
  "effective-includes" result lists the wtxids of transactions whose modified fees and sizes were used
  in the effective-feerate (#26646).
  
• decodescript may now infer a Miniscript descriptor under P2WSH context if it is not lacking
  information. (#27037)
  
• finalizepsbt is now able to finalize a transaction with inputs spending Miniscript-compatible
  P2WSH scripts. (#24149)
  

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

Build System

• The --enable-upnp-default and --enable-natpmp-default options
  have been removed. If you want to use port mapping, you can
  configure it using a .conf file, or by passing the relevant
  options at runtime. (#26896)

Updated settings

• If the -checkblocks or -checklevel options are explicitly provided by the
  user, but the verification checks cannot be completed due to an insufficient
  dbcache, Bitcoin Core will now return an error at startup. (#25574)
  
• Ports specified in -port and -rpcport options are now validated at startup.
  Values that previously worked and were considered valid can now result in errors. (#22087)
  
• Setting -blocksonly will now reduce the maximum mempool memory
  to 5MB (users may still use -maxmempool to override). Previously,
  the default 300MB would be used, leading to unexpected memory usage
  for users running with -blocksonly expecting it to eliminate
  mempool memory usage.
  
  As unused mempool memory is shared with dbcache, this also reduces
  the dbcache size for users running with -blocksonly, potentially
  impacting performance.
  
• Setting -maxconnections=0 will now disable -dnsseed
  and -listen (users may still set them to override).
  

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

New settings

• The shutdownnotify option is used to specify a command to execute synchronously
  before Bitcoin Core has begun its shutdown sequence. (#23395)

Wallet

• The minconf option, which allows a user to specify the minimum number
  of confirmations a UTXO being spent has, and the maxconf option,
  which allows specifying the maximum number of confirmations, have been
  added to the following RPCs in #25375:
  
  • fundrawtransaction
  • send
  • walletcreatefundedpsbt
  • sendall
• Added a new next_index field in the response in listdescriptors to
  have the same format as importdescriptors (#26194)
  
• RPC listunspent now has a new argument include_immature_coinbase
  to include coinbase UTXOs that don't meet the minimum spendability
  depth requirement (which before were silently skipped). (#25730)
  
• Rescans for descriptor wallets are now significantly faster if compact
  block filters (BIP158) are available. Since those are not constructed
  by default, the configuration option "-blockfilterindex=1" has to be
  provided to take advantage of the optimization. This improves the
  performance of the RPC calls rescanblockchain, importdescriptors
  and restorewallet. (#25957)
  
• RPC unloadwallet now fails if a rescan is in progress. (#26618)
  
• Wallet passphrases may now contain null characters.
  Prior to this change, only characters up to the first
  null character were recognized and accepted. (#27068)
  
• Address Purposes strings are now restricted to the currently known values of "send",
  "receive", and "refund". Wallets that have unrecognized purpose strings will have
  loading warnings, and the listlabels RPC will raise an error if an unrecognized purpose
  is requested. (#27217)
  
• In the createwallet, loadwallet, unloadwallet, and restorewallet RPCs, the
  "warning" string field is deprecated in favor of a "warnings" field that
  returns a JSON array of strings to better handle multiple warning messages and
  for consistency with other wallet RPCs. The "warning" field will be fully
  removed from these RPCs in v26. It can be temporarily re-enabled during the
  deprecation period by launching bitcoind with the configuration option
  -deprecatedrpc=walletwarningfield. (#27279)
  
• Descriptor wallets can now spend coins sent to P2WSH Miniscript descriptors. (#24149)
  

GUI changes

• The "Mask values" is a persistent option now. (gui#701)
• The "Mask values" option affects the "Transaction" view now, in addition to the
  "Overview" one. (gui#708)

REST

• A new /rest/deploymentinfo endpoint has been added for fetching various
  state info regarding deployments of consensus changes. (#25412)

Binary verification

• The binary verification script has been updated. In previous releases it
  would verify that the binaries had been signed with a single "release key".
  In this release and moving forward it will verify that the binaries are
  signed by a threshold of trusted keys. For more details and
  examples, see:
  https://github.com/bitcoin/bitcoin/blob/master/contrib/verify-binaries/README.md
  (#27358)

Low-level changes

RPC

• The JSON-RPC server now rejects requests where a parameter is specified multiple
  times with the same name, instead of silently overwriting earlier parameter values
  with later ones. (#26628)
• RPC listsinceblock now accepts an optional label argument
  to fetch incoming transactions having the specified label. (#25934)
• Previously setban, addpeeraddress, walletcreatefundedpsbt, methods
  allowed non-boolean and non-null values to be passed as boolean parameters.
  Any string, number, array, or object value that was passed would be treated
  as false. After this change, passing any value except true, false, or
  null now triggers a JSON value is not of expected type error. (#26213)

Credits

Thanks to everyone who directly contributed to this release:

• 0xb10c
• 721217.xyz
• @RandyMcMillan
• amadeuszpawlik
• Amiti Uttarwar
• Andrew Chow
• Andrew Toth
• Anthony Towns
• Antoine Poinsot
• Aurèle Oulès
• Ben Woosley
• Bitcoin Hodler
• brunoerg
• Bushstar
• Carl Dong
• Chris Geihsler
• Cory Fields
• David Gumberg
• dergoegge
• Dhruv Mehta
• Dimitris Tsapakidis
• dougEfish
• Douglas Chimento
• ekzyis
• Elichai Turkel
• Ethan Heilman
• Fabian Jahr
• FractalEncrypt
• furszy
• Gleb Naumenko
• glozow
• Greg Sanders
• Hennadii Stepanov
• hernanmarino
• ishaanam
• ismaelsadeeq
• James O'Beirne
• jdjkelly@gmail.com
• Jeff Ruane
• Jeffrey Czyz
• Jeremy Rubin
• Jesse Barton
• João Barbosa
• JoaoAJMatos
• John Moffett
• Jon Atack
• Jonas Schnelli
• jonatack
• Joshua Kelly
• josibake
• Juan Pablo Civile
• kdmukai
• klementtan
• Kolby ML
• kouloumos
• Kristaps Kaupe
• laanwj
• Larry Ruane
• Leonardo Araujo
• Leonardo Lazzaro
• Luke Dashjr
• MacroFake
• MarcoFalke
• Martin Leitner-Ankerl
• Martin Zumsande
• Matt Whitlock
• Matthew Zipkin
• Michael Ford
• Miles Liu
• mruddy
• Murray Nesbitt
• muxator
• omahs
• pablomartin4btc
• Pasta
• Pieter Wuille
• Pttn
• Randall Naar
• Riahiamirreza
• roconnor-blockstream
• Russell O'Connor
• Ryan Ofsky
• S3RK
• Sebastian Falbesoner
• Seibart Nedor
• sinetek
• Sjors Provoost
• Skuli Dulfari
• SomberNight
• Stacie Waleyko
• stickies-v
• stratospher
• Suhas Daftuar
• Suriyaa Sundararuban
• TheCharlatan
• Vasil Dimov
• Vasil Stoyanov
• virtu
• w0xlt
• willcl-ark
• yancy
• Yusuf Sahin HAMZA

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

Probably not.

Your problem is likely solvable with a rescan.

Minor version 24.1 has been released: https://bitcointalk.org/index.php?topic=5454008.0

24.1 Release Notes

Bitcoin Core version 24.1 is now available from:

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

This release includes 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.

Compatibility

Bitcoin Core is supported and extensively tested on operating systems
using the Linux kernel, macOS 10.15+, 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.

P2P

• #26878 I2P network optimizations
• #26909 net: prevent peers.dat corruptions by only serializing once
• #27608 p2p: Avoid prematurely clearing download state for other peers
• #27610 Improve performance of p2p inv to send queues

RPC and other APIs

• #26515 rpc: Require NodeStateStats object in getpeerinfo
• #27279 doc: fix/improve warning helps in {create,load,unload,restore}wallet
• #27468 rest: avoid segfault for invalid URI

Build System

• #26944 depends: fix systemtap download URL
• #27462 depends: fix compiling bdb with clang-16 on aarch64

Wallet

• #26595 wallet: be able to specify a wallet name and passphrase to migratewallet
• #26675 wallet: For feebump, ignore abandoned descendant spends
• #26679 wallet: Skip rescanning if wallet is more recent than tip
• #26761 wallet: fully migrate address book entries for watchonly/solvable wallets
• #27053 wallet: reuse change dest when re-creating TX with avoidpartialspends
• #27080 wallet: Zero out wallet master key upon locking so it doesn't persist in memory
• #27473 wallet: Properly handle "unknown" Address Type

GUI changes

• gui#687 Load PSBTs using istreambuf_iterator rather than istream_iterator
• gui#704 Correctly limit overview transaction list

Miscellaneous

• #26880 ci: replace Intel macOS CI job
• #26924 refactor: Add missing includes to fix gcc-13 compile error

Credits

Thanks to everyone who directly contributed to this release:

• Andrew Chow
• Anthony Towns
• Hennadii Stepanov
• John Moffett
• Jon Atack
• Marco Falke
• Martin Zumsande
• Matthew Zipkin
• Michael Ford
• pablomartin4btc
• Sebastian Falbesoner
• Suhas Daftuar
• Thomas Nguyen
• Vasil Dimov

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

23.2 Release Notes

Bitcoin Core version 23.2 is now available from:

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

This release includes 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.

Compatibility

Bitcoin Core is supported and extensively tested on operating systems
using the Linux kernel, macOS 10.15+, 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.

P2P

• #26909 net: prevent peers.dat corruptions by only serializing once
• #27608 p2p: Avoid prematurely clearing download state for other peers
• #27610 Improve performance of p2p inv to send queues

Build system

• #25436 build: suppress array-bounds errors in libxkbcommon
• #25763 bdb: disable Werror for format-security
• #26944 depends: fix systemtap download URL
• #27462 depends: fix compiling bdb with clang-16 on aarch64

Miscellaneous

• #25444 ci: macOS task imrovements
• #26388 ci: Use macos-ventura-xcode:14.1 image for "macOS native" task
• #26924 refactor: Add missing includes to fix gcc-13 compile error

Credits

Thanks to everyone who directly contributed to this release:

• Anthony Towns
• Hennadii Stepanov
• MacroFake
• Martin Zumsande
• Michael Ford
• Suhas Daftuar

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

It will continue from whatever was marked as the last used change address. There is no mechanism for detecting that previously "used" change addresses were actually used.

It goes sequentially, but there may be some situations and bugs that cause it to "skip" indexes. In those cases, it generally is that it "reserved" an address, but didn't end up using it, and failed to "return" it to let that address be used in future transactions. IIRC one such bug was recently fixed.

Can you post the full output?

Are you sure that you are verifying the correct files?

In the initial startup dialog, it does show that. If you don't have enough free space, there will be red warning text saying that there isn't enough free space.

Also, in master, there will be a warning dialog on first start if the disk the datadir is on doesn't have enough free space.

Then this is probably the wrong topic to be making it in. It's basically unrelated to assumeutxo entirely, especially given that users can't even use this feature yet at all.

I don't see where they are not the same. All of the amounts sum to the same value. Your wallet appears to have enabled the avoid_reuse flag, so the values in UTXOs for scripts that have already been used before will be counted in the "used" balance separately from "trusted".

It provides a better user experience. We know that people will install the software and immediately start trying to use it. We know that user education is never a good solution. We need to design the software such that uneducated users still have a good experience, and part of that is making the software usable without having to wait a long time. We want to make software that doesn't result in unnecessary complaints and support requests.

It only checks it by default when the free space check determines that the drive doesn't have enough free space for the full blockchain.

When you uncheck it, it shows a warning that says the entire blockchain will be redownloaded. This isn't "no mention of what may happen".

How does assumeutxo encourage running on low spec hardware? The same system requirements checks are being run regardless.


Regardless, making software that can run on low spec hardware is never a bad thing. Something that can run okay with little resources is something that can run fast on decent hardware. Optimizing is never bad.