Title: Bitcoin Core 24.0.1 Released Post by: achow101 on December 12, 2022, 03:24:29 PM 24.0.1 Release Notes
Due to last-minute issues (#26616 (https://github.com/bitcoin/bitcoin/pull/26616)), 24.0, although tagged, was never fully announced or released. Bitcoin Core version 24.0.1 is now available from: https://bitcoincore.org/bin/bitcoin-core-24.0.1/ (https://bitcoincore.org/bin/bitcoin-core-24.0.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 (https://github.com/bitcoin/bitcoin/issues) To receive security and update notifications, please subscribe to: https://bitcoincore.org/en/list/announcements/join/ (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. Notice of new option for transaction replacement policies This version of Bitcoin Core adds a new mempoolfullrbf configuration option which allows users to change the policy their individual node will use for relaying and mining unconfirmed transactions. The option defaults to the same policy that was used in previous releases and no changes to node policy will occur if everyone uses the default. Some Bitcoin services today expect that the first version of an unconfirmed transaction that they see will be the version of the transaction that ultimately gets confirmed---a transaction acceptance policy sometimes called "first-seen". The Bitcoin Protocol does not, and cannot, provide any assurance that the first version of an unconfirmed transaction seen by a particular node will be the version that gets confirmed. If there are multiple versions of the same unconfirmed transaction available, only the miner who includes one of those transactions in a block gets to decide which version of the transaction gets confirmed. Despite this lack of assurance, multiple merchants and services today still make this assumption. There are several benefits to users from removing this first-seen simplification. One key benefit, the ability for the sender of a transaction to replace it with an alternative version paying higher fees, was realized in Bitcoin Core 0.12.0 (https://bitcoincore.org/en/releases/0.12.0/#opt-in-replace-by-fee-transactions) (February 2016) with the introduction of BIP125 (https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki) opt-in Replace By Fee (RBF). Since then, there has been discussion about completely removing the first-seen simplification and allowing users to replace any of their older unconfirmed transactions with newer transactions, a feature called full-RBF. This release includes a mempoolfullrbf configuration option that allows enabling full-RBF, although it defaults to off (allowing only opt-in RBF). Several alternative node implementations have already enabled full-RBF by default for years, and several contributors to Bitcoin Core are advocating for enabling full-RBF by default in a future version of Bitcoin Core. As more nodes that participate in relay and mining begin enabling full-RBF, replacement of unconfirmed transactions by ones offering higher fees may rapidly become more reliable. Contributors to this project strongly recommend that merchants and services not accept unconfirmed transactions as final, and if they insist on doing so, to take the appropriate steps to ensure they have some recourse or plan for when their assumptions do not hold. Notable changes P2P and network changes
Updated RPCs
Changes to wallet related RPCs can be found in the Wallet section below. New RPCs
Updated REST APIs
Build System
New settings
Wallet
Migrating Legacy Wallets to Descriptor Wallets An experimental RPC migratewallet has been added to migrate Legacy (non-descriptor) wallets to Descriptor wallets. More information about the migration process is available in the documentation (https://github.com/bitcoin/bitcoin/blob/master/doc/managing-wallets.md#migrating-legacy-wallets-to-descriptor-wallets). GUI changes
Low-level changes RPC
Credits Thanks to everyone who directly contributed to this release:
As well as to everyone that helped with translations on Transifex (https://www.transifex.com/bitcoin/bitcoin/). Title: Re: Bitcoin Core 24.0.1 Released Post by: Artemis3 on December 12, 2022, 04:22:16 PM Why is 23.0 still pinned?
Title: Re: Bitcoin Core 24.0.1 Released Post by: NotATether on December 13, 2022, 05:50:35 PM What exactly were the security issues that you found in 24.0 at the last minute?
Asking because I'm running a 24.0 node at the moment <well, ever since that was released really> Title: Re: Bitcoin Core 24.0.1 Released Post by: achow101 on December 13, 2022, 06:15:41 PM Why is 23.0 still pinned? Only moderators of "Bitcoin Discussion" and forum admins can sticky topics here. I am not one of them. What exactly were the security issues that you found in 24.0 at the last minute? There was a crashing bug in MacOS 13, a bug in the wallet that would either crash or create an incorrect transaction depending on some details for that transaction, and a p2p issue with relaying transactions too soon.Asking because I'm running a 24.0 node at the moment <well, ever since that was released really> Title: Re: Bitcoin Core 24.0.1 Released Post by: S_Speche on December 15, 2022, 04:54:26 PM Do not download Bitcoin Core V24.0.1 It contains the malicious Full-RBF code. #NoFullRBF Title: Re: Bitcoin Core 24.0.1 Released Post by: NotATether on December 15, 2022, 05:48:15 PM Do not download Bitcoin Core V24.0.1 It contains the malicious Full-RBF code. #NoFullRBF Wut? FullRBF is disabled by default and you have to go out of your way to manually enable it via a config switch or command line option. If you don't like the feature, just fork Bitcoin again. There is nothing any of us can do to reverse course. This is the decentralized consensus after all. Title: Re: Bitcoin Core 24.0.1 Released Post by: kano on December 16, 2022, 10:11:59 AM Well, the only question I have is who voted for Full-RBF? ... since it is available now and on the road map to go on by default soon.
Or was it just 'core' decided again? :) Title: Re: Bitcoin Core 24.0.1 Released Post by: pooya87 on December 16, 2022, 11:17:53 AM If you don't like the feature, just fork Bitcoin again. There is nothing any of us can do to reverse course. This is the decentralized consensus after all. This is misleading because RBF is not a consensus rule to need any kind of fork to change. It is part of the standard rules which is how nodes treat the transactions they receive in their mempool. Kind of like fees.Title: Re: Bitcoin Core 24.0.1 Released Post by: S_Speche on December 16, 2022, 09:45:32 PM Wut? FullRBF is disabled by default and you have to go out of your way to manually enable it via a config switch or command line option. If you don't like the feature, just fork Bitcoin again. There is nothing any of us can do to reverse course. This is the decentralized consensus after all. As other users have commented, A Fork is not a proper solution for this attack. Consensus was broken when Core devs decided to go against Bitcoin´s White Paper: For our purposes, the earliest transaction is the one that counts, so we don't care about later attempts to double-spend. Each Attack is an opportunity for Bitcoin and bitcoiners to gain self awareness, this is a perfect example as self awareness is the only posible solution. We need better Bitcoin education. First I'll post my arguments against Full-RBF and then I'll propose a solution: Full-RBF was deliberately included on Core V24.0 without reaching consensus. It opens a door to centralization under Blockstream: Bitcoin is not Lightning. Lighting is a L2 solution for scalability of micropayments. Bitcoin L1 is the truly secure, high value layer. Full-RBF solves NO problem: RBF already existed, there was no reason for Full-RBF to be deployed. Full-RBF enables ANY transaction to be double spendable, any honest transaction could be replaced by a malicious higher fee one. This could result in censorship, seizure of funds by an state actor or theft. For understanding this last argument I´ll explain one of Bitcoins limitations which should be publicly known if we believe in self custody: Because of how Bitcoin's cryptography works, You'll not find substantial attack worthy unspent UTXO. This is because whales know that any pvt key gets easier to extract through brute force if you already use it to sign a transaction. Any system has its limitations and Bitcoin is not the exception. However Bitcoin has been doing great so far with its own. Any transaction awaiting in the mempool is vulnerable due to this same reason. This is why the first seen rule was included on Bitcoin's white paper. If a state agent is able to extract a PVT key from a transacción on the mempool in less than 10 minutes on 2022, or in X years from now is not an argument. Full-RBF is opening the back door towards censorship and seizure of Bitcoin's transactions. Now I'll share with you my suggested solution for this attack. It's a multi layer solution and strong community support is required. But bitcoiners are strong, and Bitcoin will came out stronger than ever: Social Layer: Any Bitcoiner that cares for Bitcoin to remain being Bitcoin, and to continue its path towards the wolrd's store of value, must share their disagreement with Core's breach of consensus. I suggest the hashtag #NoFullRBF on every Bitcoin related publication. A campaign for the quick removal of all links to the V24.0 and V24.0.1 Core versions from this and all other sites. A strong educational campaign and continuing program on UTXOs, PVT and Public key's limitations and inner mechanics. Best practices for self custody, unexpended transactions vulnerabilities, etc. Core Dev Layer: Core must work in a Non Full-RBF V25 client to be released as soon as posible. Bitcoin Core must remove all links to their malicious Full-RBF code as soon as possible. Any Dev incapable of summarize, or being concise and clear on their argumentation for Full-RBF must be ignored. It´s a common attack tactic on social layers, to write long speeches with unintelligible language for others to feel dumb. Don't you fall for this tactic. Also personal attacks must be contained from these discussions. I'll take part if it is necessary. Full-RBF Nodes Monitor Team We need a new Dev team in charge of creating the tools for Bitcoin's community to be able to follow the number of nodes running Full-RBF in real time. A team Operational for the rest of Bitcoin's History. (Thanks Peter Todd) As the number of Full-RBF Attacker Nodes must never go over 10% of the total node count. Protocol Layer In case we are unable to contain attacker nodes under 10% we will need to adapt the Timechain. I propose a 5 minute block time with all the necessary adjustments for the monetary policy to remain unchanged. This has profound ramifications in terms of orphan Blocks because of networks latency, propagation and reaction times which needs to be studied further. This is a scenario I prefer to avoid. #NoFullRBF Do not download Bitcoin Core V24 If your are running V24 Uninstall immediately! Security must not be compromised in favor of UX, Scalability, or any other reason unrelated to Bitcoin's value itself. Title: Re: Bitcoin Core 24.0.1 Released Post by: pooya87 on December 17, 2022, 09:46:13 AM Consensus was broken when Core devs decided to go against Bitcoin´s White Paper: For our purposes, the earliest transaction is the one that counts, so we don't care about later attempts to double-spend. Unconfirmed transactions have never been safe ever. With or without RBF this fact is not changing and what you insist on calling "attack" is not a thing.Quote Full-RBF was deliberately included on Core V24.0 without reaching consensus. Options that have nothing to do with the consensus rules do not need to reach any kind of consensus.Quote It opens a door to centralization under Blockstream: Bitcoin is not Lightning. Lighting is a L2 solution for scalability of micropayments. Bitcoin L1 is the truly secure, high value layer. Nonsense.Quote Full-RBF solves NO problem: RBF already existed, there was no reason for Full-RBF to be deployed. I agree with this part. Specifically since we have CPFP option.Full-RBF enables ANY transaction to be double spendable, Quote any honest transaction could be replaced by a malicious higher fee one. This could result in censorship, seizure of funds by an state actor or theft. Complete nonsense.Sender is in control of their keys so nobody can censor or seize their funds. The receiver also is not in the possession of the unconfirmed transaction so there is nothing there to censor or seize either. After the confirmation there is still no way to censor or seize the coins that are in their possession since they would control the key. Quote Because of how Bitcoin's cryptography works, You'll not find substantial attack worthy unspent UTXO. This is because whales know that any pvt key gets easier to extract through brute force if you already use it to sign a transaction. Complete nonsense.There is no way to "brute force" any private key by having the signature, one signature or a million doesn't change that. Quote Any transaction awaiting in the mempool is vulnerable due to this same reason. This is why the first seen rule was included on Bitcoin's white paper. Complete nonsense. You either didn't read bitcoin's white paper or misunderstood it all, don't just read point #2, continue reading #3 and #4. That is how bitcoin works (confirmed transactions in blocks protected by Poof of Work) not by unconfirmed txs in the mempool based on which one was seen first, in fact this last part is the flaw that Satoshi is pointing out in other systems that bitcoin solves with PoW.Quote If a state agent is able to extract a PVT key from a transacción on the mempool in less than 10 minutes on 2022, or in X years from now is not an argument. Full-RBF is opening the back door towards censorship and seizure of Bitcoin's transactions. If that becomes a possibility, the same imaginary "state agent" would also mine the block containing the double spent transaction without needing Full-RBF :DTitle: Re: Bitcoin Core 24.0.1 Released Post by: NotATether on December 21, 2022, 01:16:14 PM First I'll post my arguments against Full-RBF and then I'll propose a solution: Full-RBF was deliberately included on Core V24.0 without reaching consensus. It opens a door to centralization under Blockstream: Bitcoin is not Lightning. Lighting is a L2 solution for scalability of micropayments. Bitcoin L1 is the truly secure, high value layer. Full-RBF solves NO problem: RBF already existed, there was no reason for Full-RBF to be deployed. Full-RBF enables ANY transaction to be double spendable, any honest transaction could be replaced by a malicious higher fee one. This could result in censorship, seizure of funds by an state actor or theft. For understanding this last argument I´ll explain one of Bitcoins limitations which should be publicly known if we believe in self custody: Because of how Bitcoin's cryptography works, You'll not find substantial attack worthy unspent UTXO. This is because whales know that any pvt key gets easier to extract through brute force if you already use it to sign a transaction. Any system has its limitations and Bitcoin is not the exception. However Bitcoin has been doing great so far with its own. Any transaction awaiting in the mempool is vulnerable due to this same reason. This is why the first seen rule was included on Bitcoin's white paper. If a state agent is able to extract a PVT key from a transacción on the mempool in less than 10 minutes on 2022, or in X years from now is not an argument. Full-RBF is opening the back door towards censorship and seizure of Bitcoin's transactions. ~ You raise some good points here, particularly the "full-RBF enables any transaction to be double spendable" part, but you'd need to have access to the private key in order to replace an RBF transaction, so you'd have to be the original owner of the key anyway. (For the record, I don't consider the argument said by other people that zero-conf transactions are essential to some businesses - all on-chain transactions start off as zero-conf anyway. But this one that you suggested is an interesting scenario.) Are there people who actively rely on non-RBF transactions to prevent entities such state actors from diverting their transaction? So far, I haven't heard of any instances myself. I think people would be more convinced of any potential dangers if someone engineered an demonstration of extracting a wallet.dat password through some side-channel attack, followed by replacing some existing RBF transaction by another one. Perhaps bumping from 1sat/byte to 2sats/byte to give enough time for experiment setup. Title: Re: Bitcoin Core 24.0.1 Released Post by: BlackHatCoiner on December 25, 2022, 01:47:09 PM Full-RBF was deliberately included on Core V24.0 without reaching consensus. Which is something you don't understand yourself? There's no consensus for local settings. You are and always were free to treat non-RBF as RBF since v0.1, and in fact there's no way for the rest of the nodes to even know you're doing it. It's just now a setting instead of a hardcoded value. You're free to have it disabled, and if there weren't already nodes who did this, it's likely that there won't be now either. Also, do not derail this thread. Continue here: Full RBF (https://bitcointalk.org/index.php?topic=5403730.0). Title: Re: Bitcoin Core 24.0.1 Released Post by: pi5hxaeb on December 28, 2022, 05:25:30 AM After reading a great recap on the matter (https://github.com/glozow/bitcoin-notes/blob/full-rbf/full-rbf.md), I just activated Full RBF on Core 24.0.1 (by adding mempoolfullrbf=1 to bitcoin.conf)
Does anyone know of any command for bitcoind to check whether the Full RBF option is enabled? I just want to get confirmation. Title: Re: Bitcoin Core 24.0.1 Released Post by: vv181 on December 28, 2022, 07:54:58 PM Does anyone know of any command for bitcoind to check whether the Full RBF option is enabled? I just want to get confirmation. Use $ bitcoin-cli getmempoolinfo Code: $ bitcoin-cli getmempoolinfo Title: Re: Bitcoin Core 24.0.1 Released Post by: MysteryMiner on January 02, 2023, 08:47:23 PM There was 24.0.1 version and newer version is 22.1 and guess what, newest version is 23.1
These incompetent soy milk drinking wannabe programmers cannot get even the version numbers straight. For a person who was around Bitcoin from early months but now is not too involved in Bitcoin cannot get the software right. Some older machines I own require update because they get alert for unknown rules activated. But I simply cannot trust software that is released by persons who cannot get version numbers right, change domain names and code signing certificates. The race to increase major version number like Firefox and Chrome does tells about quality of them as developers. Title: Re: Bitcoin Core 24.0.1 Released Post by: achow101 on January 03, 2023, 12:52:20 AM There was 24.0.1 version and newer version is 22.1 and guess what, newest version is 23.1 22.1 and 23.1 are bug fix releases for the previous major versions of 22.0 and 23.0. They contain bug and security fixes that were backported on top of older versions. The purpose of such releases is to allow people to still safely use older versions. Users may still wish to do so because they may still be auditing newer versions, or newer versions contain features that they are not yet comfortable with, or maybe something was deprecated and removed that they are still relying on. In these releases, very little has changed except for some bug fixes that were deemed to be important.These incompetent soy milk drinking wannabe programmers cannot get even the version numbers straight. For a person who was around Bitcoin from early months but now is not too involved in Bitcoin cannot get the software right. Some older machines I own require update because they get alert for unknown rules activated. But I simply cannot trust software that is released by persons who cannot get version numbers right, change domain names and code signing certificates. Minor releases has nothing to do with "soy milk drinking wannabe programmers cannot get even the version numbers straight". It is, in fact, a standard procedure that we do, and is a common practice in the software development industry. Just as an example, the Linux kernel is currently 6.1.2. But there are still releases for 5.x and 4.x kernel versions because they support older major versions. They make bug fix backports to the older versions so that users who wish to still use those older versions are not left out to dry if there are important bugs that are found. This is what Bitcoin Core does as well. The race to increase major version number like Firefox and Chrome does tells about quality of them as developers. There is no such race, and never has been. The major version number has been incremented periodically, every 6 months or so. That's been the release cadence for the past decade (more than that, actually), and so it's natural that the version number has reached 24 already. Nothing to do with "race to increase major version". This would be plainly obvious if you just look at the release history of the software.Title: Re: Bitcoin Core 24.0.1 Released Post by: MysteryMiner on January 03, 2023, 01:09:53 AM Quote 22.1 and 23.1 are bug fix releases for the previous major versions of 22.0 and 23.0. They contain bug and security fixes that were backported on top of older versions. The purpose of such releases is to allow people to still safely use older versions. Users may still wish to do so because they may still be auditing newer versions, or newer versions contain features that they are not yet comfortable with, or maybe something was deprecated and removed that they are still relying on. In these releases, very little has changed except for some bug fixes that were deemed to be important. It was never done such for Bitcoin. So the there is real base for concerns some users about full RBF feature that developers decided to basically continue to work on older releases?Quote Minor releases has nothing to do with "soy milk drinking wannabe programmers cannot get even the version numbers straight". It is, in fact, a standard procedure that we do, and is a common practice in the software development industry. Standard practice was to release 2.0 version after 1.x is abandoned and in Visual C++ 6.0 New Project menu is selected. I remember Bitcoin always had 0.xx.x versioning schema until someone dropped zero from front and we arrived from pre-1.0 versions to version 22 overnight. If this is not Firefox then what? Also some Intel fanboys decided to rename Bitcoin to Bitcoin Core. And do not tell that Bitcoin and Bitcoin are two different things. The reference implementation of Bitcoin De Facto are Bitcoin. Just like when we are talking about DC++ there is no need to separate DC++ protocol from DC++ client, even if the protocol is compatible with other clients like RevConnect or StrongDC++.Quote Just as an example, the Linux kernel is currently 6.1.2. But there are still releases for 5.x and 4.x kernel versions because they support older major versions. They make bug fix backports to the older versions so that users who wish to still use those older versions are not left out to dry if there are important bugs that are found. If I want to run 2.4 or 2.6 Linux kernel versions, I take out old Slackware or Mandrake CD-ROMs and run them. Also Linux stayed on 2.4 and 2.6 kernel versions for long time. I do not remember 2.8 versions, but probably because I mostly work with embedded systems now. Even Linux kernel development now is infested with soy drinking transvestites messing up version numbers.So where we are now? What is the bestest Bitcoin version? Title: Re: Bitcoin Core 24.0.1 Released Post by: achow101 on January 03, 2023, 03:15:43 AM It was never done such for Bitcoin. Are you daft? Look at the list of releases: https://bitcoincore.org/en/releases/. You see all those 0.x.1, 0.x.2, and 0.x.3 releases? Those are minor releases, in the same way 22.1 and 23.1 are minor releases.So the there is real base for concerns some users about full RBF feature that developers decided to basically continue to work on older releases? No, there is no such concern. There were already plans to do 22.1 and 23.1 before that controversy started.Standard practice was to release 2.0 version after 1.x is abandoned A lot of projects maintain older major versions. Like the Linux kernel as I mentioned.I remember Bitcoin always had 0.xx.x versioning schema until someone dropped zero from front and we arrived from pre-1.0 versions to version 22 overnight. If this is not Firefox then what? It was dropped because the 0 wasn't doing anything useful. 0.x releases were referred to as major releases and the x the major version number. The change was to make those two concepts align. It has nothing to do with trying to inflate version numbers. No one gives a shit about that.-snip- At this point, I think you're just trolling. Hurling insults as you are is completely unhelpful. So I will be deleting any further posts from you in this thread.Title: Re: Bitcoin Core 24.0.1 Released Post by: Carlton Banks on January 04, 2023, 06:26:02 PM It was never done such for Bitcoin. Are you daft?no need for a question mark, and you also misplaced the position of the words 'you' and 'are' in the sentence. Strange, as your english language skills are always very good achow101! :D belated congrats on the new release everyone. Title: Re: Bitcoin Core 24.0.1 Released Post by: cygan on January 14, 2023, 07:15:27 AM 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? Title: Re: Bitcoin Core 24.0.1 Released Post by: ABCbits on January 14, 2023, 10:21:38 AM 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. Title: Re: Bitcoin Core 24.0.1 Released Post by: hymperion on January 17, 2023, 03:21:53 PM 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. Title: Re: Bitcoin Core 24.0.1 Released Post by: achow101 on January 17, 2023, 05:31:44 PM was there a specific and approved BIP that provided for the default activation of the FullRBF? 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.Otherwise, this change to what bitcoin should be, right or wrong, is not correct. 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. Title: Re: Bitcoin Core 24.0.1 Released Post by: Carlton Banks on January 17, 2023, 09:19:10 PM 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 ::) Title: Re: Bitcoin Core 24.0.1 Released Post by: Carlton Banks on January 28, 2023, 03:38:09 PM 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! Title: Re: Bitcoin Core 24.0.1 Released Post by: Amph on February 21, 2023, 09:13:26 AM i can't sinc anymore with the last version, anyone have the some problem?
Title: Re: Bitcoin Core 24.0.1 Released Post by: Amph on February 22, 2023, 10:34:20 AM 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 Title: Re: Bitcoin Core 24.0.1 Released Post by: superacellar on May 02, 2023, 07:53:35 AM How to remove abandoned tx listed on? I just want to remove that from all the tx list
Title: Re: Bitcoin Core 24.0.1 Released Post by: kano on May 08, 2023, 07:04:40 AM 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 Title: Re: Bitcoin Core 24.0.1 Released Post by: achow101 on May 25, 2023, 02:56:20 PM Minor version 24.1 has been released: https://bitcointalk.org/index.php?topic=5454008.0
Title: Re: Bitcoin Core 24.0.1 Released Post by: kano on May 26, 2023, 01:27:57 AM 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 Title: Re: Bitcoin Core 24.0.1 Released Post by: achow101 on May 26, 2023, 05:15:08 AM 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 Your problem is likely solvable with a rescan. Title: Re: Bitcoin Core 24.0.1 Released Post by: achow101 on May 26, 2023, 03:14:20 PM Major version 25.0 has been released: https://bitcointalk.org/index.php?topic=5454120.0
Title: Re: Bitcoin Core 24.0.1 Released Post by: kano on May 27, 2023, 04:14:30 AM 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 Your problem is likely solvable with a rescan. 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. Title: Re: Bitcoin Core 24.0.1 Released Post by: DeathAngel on May 27, 2023, 04:43:52 PM 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. Title: Re: Bitcoin Core 24.0.1 Released Post by: achow101 on May 27, 2023, 06:23:24 PM 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. Title: Re: Bitcoin Core 24.0.1 Released Post by: kano on June 04, 2023, 10:37:44 PM As stated, I was dealing with unconfirmed transactions.
Title: Wishing you the best of luck in all your endeavors Post by: hardworkinfamilyman on July 06, 2023, 10:12:12 PM .
|