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.

Didn't read the article, but from the snippet you've posted, it's simply incorrect.

Assumeutxo is neither a new type of node, nor a pruning. It's about making the software usable without having to wait multiple days for it to sync. It doesn't reduce the hardware requirements to run, in fact, using assumeutxo probably requires more resources than without it.

Assumeutxo allows a node to start with a preset UTXO set (provided by the user, and does not necessarily correspond to a hardcoded hash in the binary, this detail has not been worked out yet). This UTXO set is the state of the chain at a particular block hash and height. The node can then begin syncing from that particular block. The idea is that the block will be recent, so the node will be caught up to tip very quickly, thus allowing the user to make and receive transactions way faster than if they had to wait for the entire blockchain to sync.

The point is to make the software usable much faster. A major complaint that we've heard from users is that it takes ages to sync. Users often don't have the patience to wait and will start giving out addresses. Then they panic when they don't see incoming coins because they haven't synced yet and they come into this forum, or github, or reddit freaking out about losing money, all just because they haven't waited for the node to sync. Assumeutxo reduces that because it "syncs" faster.

Obviously there's a trust requirement in this - users have to trust that the UTXO set that they are using is correct. Assumeutxo mitigates this by actually syncing the full blockchain in the background. While the user is using the state provided by the UTXO set and the chain state extended from it, a second chain state is built in the background from syncing and validating the blockchain. Once that background validation reaches the preset UTXO set's height, it checks that the two states are the same (same UTXOs, same blocks), and will kill the software and give the user an error if they are not.

This is, in fact, not pruning, and unrelated to pruning. Of course, it should be possible to do it with pruning, but I don't know if that's been implemented yet. Furthermore, two chain states are being maintained in memory and on disk while the background validation is going. This means that the resource usage is actually higher, not lower.

There are transactions which were malleated that are in the blockchain. But that doesn't mean there are two versions of one transaction - there's only one "version" of the transaction in the blockchain, and it just happens to be one that was not the original broadcast by the original creator.


Malleability is the "default" because changing that would be a hard fork. Non-segwit transactions are malleable by default, there is no way to fix this in a way similar to what segwit does without making a backwards incompatible change.

No. As I said in my previous post, a malleated transaction is just a transaction that has a conflict. When there are transaction conflicts, only one of the conflicting transactions can be confirmed and added to the blockchain. There will not be different copies of the same transaction in the blockchain.

Malleation can only occur on unconfirmed transaction. When an unconfirmed transaction is malleated, the malleated one could also confirm, which would invalidate the original. Likewise, the original could confirm and therefore invalidate the malleated one. Both cannot be confirmed as that would mean the same coins have been spent twice.


It seems like you are thinking of malleation as "transaction X but slightly altered". However that's not a good way to look at it if you want to understand how malleated transactions are treated. You need to think of malleated transactions as double spends. They are simply transactions that spend the same inputs as another transaction. It just so happens to be that someone other than the original creator can produce these kinds of double spends. Since malleated transactions are just double spends, all of the same rules regarding double spends apply - only one of the transactions can be confirmed, etc.

Transaction malleability can affect two major things: wallet software, and contracting protocols.

There are two kinds of transaction malleation: 3rd party malleation, and 1st party malleation. In 3rd party malleation, anyone can change a transaction's id by modifying parts of it that are not covered by a signature. This includes the signature itself. In 1st party malleation, the transaction ID is modified by the sender(s). This is trivially done by re-signing the transaction but using a different nonce in the signature.

While malleation is modifying a transaction so its txid changes, a different way to view it is a transaction that double spends the original but happens to send the Bitcoin to the same outputs. This is how nodes and wallets view the transaction, there is nothing special to mark transactions as being malleated nor does there need to be, they just look like and should be treated as double spends. Additionally, malleation is only an issue for unconfirmed transactions. Once a transaction confirms, the block commits to the transaction ids of all of the transactions in the block so there is no "show a different transaction ID". Again, these must be considered as double spends because that's what they are. There's really no "original transaction" or "modified transaction", they're two distinct transactions that conflict with each other (spend the same inputs), that just so happen to have the same outputs.

Malleability first became a noticeable issue when wallet software would have issues because of malleated transactions. Back then, wallet software in general was not very good at handling double spends. This would result in issues such as wallets thinking they had access to more coins than they actually did, wallets continuously displaying and trying to rebroadcast conflicts that are no longer valid, and wallets trying to spend coins that no longer exist. These are all generally annoyances but shouldn't be the cause of significant concern, and they aren't unique to malleated transactions, any double spending could result in these issues. But since anyone could malleate a transaction, these annoyances could be done on a large scale by a single person. This is generally no longer an issue as wallet developers are aware of transaction conflicts and have made changes to their wallets to deal with them more gracefully.

Transaction malleation was also noticed to be a major hindrance in contracting protocols such as Lightning. These protocols rely on the transaction ID not changing as they are pre-signing transactions that refer to a transaction that has not been broadcast yet. If the first transaction is malleated, and the counterparty is not cooperating (perhaps they malleated the first), then funds could be lost. Resolving these issues so that such protocols can work would require a solution that removes both 3rd and 1st party malleation.

There were a couple of attempts to remove malleation. BIP 62 was one of them. It tried to enumerate many different malleation techniques and essentially outlaw them. However this is not necessarily a good solution since it still allows malleation in ways that may not have been thought of. So it was withdrawn.

Segwit is different from BIP 62 in that it resolves the vast majority of malleation issues by removing most things that could cause malleation from the txid calculation itself. Segwit made it so that signatures, scripts, and stack items are all stored in a separate part of the transaction which everyone would ignore for the purposes of transaction id calculation. It further does this only for a subset of scripts so that it can remain backwards compatible. In this way, instead of figuring out what could be malleable and explicitly enumerating them, it just takes everything that could be malleable and puts it somewhere else. However Segwit is not a perfect solution, things that were malleable previously still are malleable, you have to opt-in to using Segwit and non-malleability. Furthermore, there are still ways to make segwit things malleable, but they basically require trying to make things that are malleable rather than malleability being the default as with non-segwit.

No. Malleability does not apply to anything that's confirmed and it does not actually hide anything.

It's a key-value store of outpoint to transaction output. Outpoints consist of the txid and output index, and transaction output is the amount in satoshis and the output script. These are the pieces from previous transactions that's needed to verify a transaction.

Still enforcing

Multisigs with timelocks and other script constructions do not do what OP_VAULT enables.

There are constructions for vaults today, however they involve the use of presigned transactions and destroying keys. This is generally fragile and has several pitfalls, the obvious being loss of the presigned transactions means loss of the funds. It turns the transactions into secret data, and transactions are much larger, so this becomes harder to deal with. There are other issues such as the vault cannot be reused (the key was destroyed after setup, so no new inputs can be signed for) and the destinations and amounts cannot be changed after the setup. OP_VAULT solves these things.

OP_VAULT makes it so that the secret data in the vault is still just private keys. Because it's a script, it can be reused and receive coins even after setup. The destinations of the coins can be determined during unvaulting, not during setup.

Actually it doesn't. There aren't any additional changes to RBF required that aren't already planned and in the works. Ephemeral anchors requires package relay and validation, which is already largely in progress. It just adds one additional rule for detecting and handling the anchor output. Otherwise, OP_TRUE outputs are already valid, as are 0-value outputs and spending them. It's just a policy change, there's no consensus meaning applied to ephemeral anchors.

There are two methods for recovering the coins. The first is to double spend the unvault, and the second is to recover during the spend delay. In the first method, you would double spend the OP_VAULT input with a transaction that sends those funds to the recovery address. Doing this requires package RBF to be implemented (and this is something that is already in progress) as well as ephemeral anchors. The recovery just needs to pay a package feerate that's higher than the unvaulting. However, even if this fails (or is not done) and the unvaulting transaction is confirmed, there is still an additional delay before the unvaulted coins can actually be moved to their final destinations. During this time, the coins still be swept to the recovery address by a transaction that spends the OP_UNVAULT output and sends everything to the recovery address. This does not require RBF, and the only consensus changes are those required to implement the semantics of the opcodes themselves.

---

I also want to note that the author of this proposal has been working on vault constructions for a very long time. It's highly likely that if you think of an "obvious" construction, he's likely thought or heard of it already. The motivation of this proposal is that there is no way to construct a vault that meets the "idealized vault" described in the paper using today's consensus and policy rules.

For starters, full rbf is not default on. It is an option that is default off. Secondly, it's not a consensus change and so does not require an activation mechanism nor does it change what Bitcoin is.

To answer your question, there is no BIP. Most mempool policy behaviors do not have a BIP, so it is not unusual that this change does not either. BIPs are generally only written for policy things that require transaction creators to make their transactions in a specific way in order to invoke a policy rule, such as BIP 125 which required setting particular sequence numbers or the proposed tx version 3 for package RBF. Other common mempool policies such as the minimum feerate, dust feerate, mempool size, eviction timer, low S, minimal if, p2sh push only, etc. all do not have BIPs.

The default data directory location is in your user account's home directory, which is presumably on the low storage device. You can change it to use a different location, presumably one on the high storage device by adding -datadir=<path> to your startup command where <path> is the path to the directory that you want Bitcoin Core's data to be stored.