Bitcoin Core 24.0.1 Released

[ABCbits]

if you have 2 different receiving addresses on the core wallet, can you send satoshis 'internally' from one to the other addy?

Yes, you can do that. I just tried on testnet version.

is there anything in particular that needs to be taken into account?

Can't think anything since Bitcoin Core already makes it clear by specific "Payment to yourself" if you check the transaction on "Transaction" tab.

[1715079062]

1715079062

[1715079062]

1715079062

[1715079062]

1715079062

[hymperion]

was there a specific and approved BIP that provided for the default activation of the FullRBF?

Otherwise, this change to what bitcoin should be, right or wrong, is not correct.

[achow101]

was there a specific and approved BIP that provided for the default activation of the FullRBF?

Otherwise, this change to what bitcoin should be, right or wrong, is not correct.

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.

[Carlton Banks]

it's not a consensus change and so does not require an activation mechanism nor does it change what Bitcoin is.

and it's really just safely reinforcing what Bitcoin already is (and always was)


miners can mine any transaction they like, including a different version of the same transaction. That means that RBF was really just a way of shepherding something that miners have always been able to do.

Sure, the Bitcoin source code didn't have that functionality, but because RBF doesn't need consensus rules at all, the miners could just change the code themselves.

and if there was 2 versions of the same transaction, one with low fees and another with higher fees out on the network, why not mine that one?


the whole fullRBF thing was probably the stupidest Bitcoin discussion ever, the people arguing against it didn't really understand what they were even saying

[Carlton Banks]

slightly more small-fry....

my Raspberry Pi 3 node now ALWAYS verifies new blocks before the progress= log line returns 0.999999

presumably, some performance optimization in 24.0 has made this possible? nothing from the changelog stood out, possibly some library improvement. I'm running with disablewallet and 450MiB of dbcache (RPi3 has just 1G RAM)

so I don't know who to congratulate, but well done to everybody anyway!

[Amph]

i can't sinc anymore with the last version, anyone have the some problem?

[Amph]

i can't sinc anymore with the last version, anyone have the some problem?

No, i can sync whether on mainnet, testnet or signet. You might want to ask help on "Bitcoin Technical Support" board while providing some information (e.g. debug log, how do you connect to internet).

i didn't change anything about internet connection or firewall therefore it's not that, there was a warning about consensus when i switched from 23 to 24 version, then the warning disappeared and now it's not synching anymore

[superacellar]

How to remove abandoned tx listed on? I just want to remove that from all the tx list

[kano]

Be wary that trying to remove them can corrupt your wallet.

I've had the download version of 24.0.1 do that, so it clearly has bad wallet bugs in it.

About a month ago, I made a txn with too low fee using 23.0 bitcoin-cli, that didn't get confirmed for over a day.

So I then upgraded to 24.0.1 and ran bitcoin-qt with fullrbf enabled.
It wouldn't allow me to rbf the txn, so I checked the other options available in bitcoin-cli

I used both bitcoin-cli removeprunedfunds and bitcoin-cli abandontransaction and added my new higher fee transcation.
At this point it showed the old lower fee txn as not the chosen one and the higher fee transaction as the chosen one
(can't remember the text flag names it uses)

After the higher fee txn had been confirmed in a block, my wallet now shows an old (274685 blocks ago) txn as unspent, that was spent.

So be wary of messing with transactions with this version ... especially with using removeprunedfunds and abandontransaction

[achow101]

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

[kano]

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

Does it fix the above (rather drastic) problem?
https://bitcointalk.org/index.php?topic=5428062.msg62212412#msg62212412

[achow101]

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

Does it fix the above (rather drastic) problem?
https://bitcointalk.org/index.php?topic=5428062.msg62212412#msg62212412

Probably not.

Your problem is likely solvable with a rescan.

[achow101]

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

[kano]

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

Does it fix the above (rather drastic) problem?
https://bitcointalk.org/index.php?topic=5428062.msg62212412#msg62212412

Probably not.

Your problem is likely solvable with a rescan.

Well no doubt a rescan should fix it - alas I only realised that the number was wrong coz it was over 10BTC, I have no idea if there are smaller amounts in the wallet that have been affected.

But that does pretty much imply that anyone using those buggy commands would have to always do a rescan to be sure their wallet isn't wrong.

[DeathAngel]

if you have 2 different receiving addresses on the core wallet, can you send satoshis 'internally' from one to the other addy?
is there anything in particular that needs to be taken into account?

I did this a few months ago, I won’t be selling anything until at least mid 2025 so wanted to consolidate & have all coins in one address.

[achow101]

But that does pretty much imply that anyone using those buggy commands would have to always do a rescan to be sure their wallet isn't wrong.

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.

[kano]

As stated, I was dealing with unconfirmed transactions.

[hardworkinfamilyman]

.