achow101 (OP)
Staff
Legendary
Offline
Activity: 3374
Merit: 6535
Just writing some code
|
|
December 12, 2022, 03:24:29 PM |
|
24.0.1 Release NotesDue to last-minute issues ( #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/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/issuesTo receive security and update notifications, please subscribe to: https://bitcoincore.org/en/list/announcements/join/How to UpgradeIf 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. CompatibilityBitcoin 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 policiesThis 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-seensimplification. 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 (February 2016) with the introduction of BIP125 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 changesP2P and network changes- To address a potential denial-of-service, the logic to download headers from peers
has been reworked. This is particularly relevant for nodes starting up for the first time (or for nodes which are starting up after being offline for a long time).
Whenever headers are received from a peer that have a total chainwork that is either less than the node's -minimumchainwork value or is sufficiently below the work at the node's tip, a "presync" phase will begin, in which the node will download the peer's headers and verify the cumulative work on the peer's chain, prior to storing those headers permanently. Once that cumulative work is verified to be sufficiently high, the headers will be redownloaded from that peer and fully validated and stored.
This may result in initial headers sync taking longer for new nodes starting up for the first time, both because the headers will be downloaded twice, and because the effect of a peer disconnecting during the presync phase (or while the node's best headers chain has less than -minimumchainwork), will result in the node needing to use the headers presync mechanism with the next peer as well (downloading the headers twice, again). (#25717)
- With I2P connections, a new, transient address is used for each outbound
connection if -i2pacceptincoming=0. (#25355)
Updated RPCs- The -deprecatedrpc=softforks configuration option has been removed. The
RPC getblockchaininfo no longer returns the softforks field, which was previously deprecated in 23.0. (#23508) Information on soft fork status is now only available via the getdeploymentinfo RPC.
- The deprecatedrpc=exclude_coinbase configuration option has been removed.
The receivedby RPCs (listreceivedbyaddress, listreceivedbylabel, getreceivedbyaddress and getreceivedbylabel) now always return results accounting for received coins from coinbase outputs, without an option to change that behaviour. Excluding coinbases was previously deprecated in 23.0. (#25171)
- The deprecatedrpc=fees configuration option has been removed. The top-level
fee fields fee, modifiedfee, ancestorfees and descendantfees are no longer returned by RPCs getmempoolentry, getrawmempool(verbose=true), getmempoolancestors(verbose=true) and getmempooldescendants(verbose=true). The same fee fields can be accessed through the fees object in the result. The top-level fee fields were previously deprecated in 23.0. (#25204)
- The getpeerinfo RPC has been updated with a new presynced_headers field,
indicating the progress on the presync phase mentioned in the "P2P and network changes" section above.
Changes to wallet related RPCs can be found in the Wallet section below. New RPCs- The sendall RPC spends specific UTXOs to one or more recipients
without creating change. By default, the sendall RPC will spend every UTXO in the wallet. sendall is useful to empty wallets or to create a changeless payment from select UTXOs. When creating a payment from a specific amount for which the recipient incurs the transaction fee, continue to use the subtractfeefromamount option via the send, sendtoaddress, or sendmany RPCs. (#24118)
- A new gettxspendingprevout RPC has been added, which scans the mempool to find
transactions spending any of the given outpoints. (#24408)
- The simulaterawtransaction RPC iterates over the inputs and outputs of the given
transactions, and tallies up the balance change for the given wallet. This can be useful e.g. when verifying that a coin join like transaction doesn't contain unexpected inputs that the wallet will then sign for unintentionally. (#22751)
Updated REST APIs- The /headers/ and /blockfilterheaders/ endpoints have been updated to use
a query parameter instead of path parameter to specify the result count. The count parameter is now optional, and defaults to 5 for both endpoints. The old endpoints are still functional, and have no documented behaviour change.
For /headers, use GET /rest/headers/<BLOCK-HASH>.<bin|hex|json>?count=<COUNT=5> instead of GET /rest/headers/<COUNT>/<BLOCK-HASH>.<bin|hex|json> (deprecated)
For /blockfilterheaders/, use GET /rest/blockfilterheaders/<FILTERTYPE>/<BLOCK-HASH>.<bin|hex|json>?count=<COUNT=5> instead of GET /rest/blockfilterheaders/<FILTERTYPE>/<COUNT>/<BLOCK-HASH>.<bin|hex|json> (deprecated)
(#24098)
Build System- Guix builds are now reproducible across architectures (x86_64 & aarch64). (#21194)
New settings- A new mempoolfullrbf option has been added, which enables the mempool to
accept transaction replacement without enforcing BIP125 replaceability signaling. (#25353) Wallet- The -walletrbf startup option will now default to true. The
wallet will now default to opt-in RBF on transactions that it creates. (#25610)
- The replaceable option for the createrawtransaction and
createpsbt RPCs will now default to true. Transactions created with these RPCs will default to having opt-in RBF enabled. (#25610)
- The wsh() output descriptor was extended with Miniscript support. You can import Miniscript
descriptors for P2WSH in a watchonly wallet to track coins, but you can't spend from them using the Bitcoin Core wallet yet. You can find more about Miniscript on the reference website. (#24148)
- The tr() output descriptor now supports multisig scripts through the multi_a() and
sortedmulti_a() functions. (#24043)
- To help prevent fingerprinting transactions created by the Bitcoin Core wallet, change output
amounts are now randomized. (#24494)
- The listtransactions, gettransaction, and listsinceblock
RPC methods now include a wtxid field (hash of serialized transaction, including witness data) for each transaction. (#24198)
- The listsinceblock, listtransactions and gettransaction output now contain a new
parent_descs field for every "receive" entry. (#25504)
- A new optional include_change parameter was added to the listsinceblock command.
- RPC getreceivedbylabel now returns an error, "Label not found
in wallet" (-4), if the label is not in the address book. (#25122)
Migrating Legacy Wallets to Descriptor WalletsAn 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. GUI changes- A new menu item to restore a wallet from a backup file has been added (gui#471).
- Configuration changes made in the bitcoin GUI (such as the pruning setting,
proxy settings, UPNP preferences) are now saved to <datadir>/settings.json file rather than to the Qt settings backend (windows registry or unix desktop config files), so these settings will now apply to bitcoind, instead of being ignored. (#15936, gui#602)
- Also, the interaction between GUI settings and bitcoin.conf settings is
simplified. Settings from bitcoin.conf are now displayed normally in the GUI settings dialog, instead of in a separate warning message ("Options set in this dialog are overridden by the configuration file: -setting=value"). And these settings can now be edited because settings.json values take precedence over bitcoin.conf values. (#15936)
Low-level changesRPC- The deriveaddresses, getdescriptorinfo, importdescriptors and scantxoutset commands now
accept Miniscript expression within a wsh() descriptor. (#24148)
- The getaddressinfo, decodescript, listdescriptors and listunspent commands may now output
a Miniscript descriptor inside a wsh() where a wsh(raw()) descriptor was previously returned. (#24148)
CreditsThanks to everyone who directly contributed to this release: - /dev/fd0
- 0xb10c
- Adam Jonas
- akankshakashyap
- Ali Sherief
- amadeuszpawlik
- Andreas Kouloumos
- Andrew Chow
- Anthony Towns
- Antoine Poinsot
- Antoine Riard
- Aurèle Oulès
- avirgovi
- Ayush Sharma
- Baas
- Ben Woosley
- BrokenProgrammer
- brunoerg
- brydinh
- Bushstar
- Calvin Kim
- CAnon
- Carl Dong
- chinggg
- Cory Fields
- Daniel Kraft
- Daniela Brozzoni
- darosior
- Dave Scotese
- David Bakin
- dergoegge
- dhruv
- Dimitri
- dontbyte
- Duncan Dean
- eugene
- Eunoia
- Fabian Jahr
- furszy
- Gleb Naumenko
- glozow
- Greg Weber
- Gregory Sanders
- gruve-p
- Hennadii Stepanov
- hiago
- Igor Bubelov
- ishaanam
- Jacob P.
- Jadi
- James O'Beirne
- Janna
- Jarol Rodriguez
- Jeremy Rand
- Jeremy Rubin
- jessebarton
- João Barbosa
- John Newbery
- Jon Atack
- Josiah Baker
- Karl-Johan Alm
- KevinMusgrave
- Kiminuo
- klementtan
- Kolby Moroz
- kouloumos
- Kristaps Kaupe
- Larry Ruane
- Luke Dashjr
- MarcoFalke
- Marnix
- Martin Leitner-Ankerl
- Martin Zumsande
- Michael Dietz
- Michael Folkson
- Michael Ford
- Murch
- mutatrum
- muxator
- Oskar Mendel
- Pablo Greco
- pasta
- Patrick Strateman
- Pavol Rusnak
- Peter Bushnell
- phyBrackets
- Pieter Wuille
- practicalswift
- randymcmillan
- Robert Spigler
- Russell Yanofsky
- S3RK
- Samer Afach
- Sebastian Falbesoner
- Seibart Nedor
- Shashwat
- Sjors Provoost
- Smlep
- sogoagain
- Stacie
- Stéphan Vuylsteke
- Suhail Saqan
- Suhas Daftuar
- t-bast
- TakeshiMusgrave
- Vasil Dimov
- W. J. van der Laan
- w0xlt
- whiteh0rse
- willcl-ark
- William Casarin
- Yancy Ribbens
As well as to everyone that helped with translations on Transifex.
|
|
|
|
|
|
|
|
|
If you want to be a moderator, report many posts with accuracy. You will be noticed.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
Artemis3
Legendary
Offline
Activity: 2016
Merit: 1563
CLEAN non GPL infringing code made in Rust lang
|
|
December 12, 2022, 04:22:16 PM |
|
Why is 23.0 still pinned?
|
█████████████████████████ ██████████████████████████ ██████████████████████████ ███████████████████████████ | BRAIINS OS+| | AUTOTUNING MINING FIRMWARE| | Increase hashrate on your Bitcoin ASICs, improve efficiency as much as 25%, and get 0% pool fees on Braiins Pool | |
|
|
|
NotATether
Legendary
Offline
Activity: 1582
Merit: 6687
bitcoincleanup.com / bitmixlist.org
|
|
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>
|
. .BLACKJACK ♠ FUN. | | | ███▄██████ ██████████████▀ ████████████ █████████████████ ████████████████▄▄ ░█████████████▀░▀▀ ██████████████████ ░██████████████ █████████████████▄ ░██████████████▀ ████████████ ███████████████░██ ██████████ | | CRYPTO CASINO & SPORTS BETTING | | │ | | │ | ▄▄███████▄▄ ▄███████████████▄ ███████████████████ █████████████████████ ███████████████████████ █████████████████████████ █████████████████████████ █████████████████████████ ███████████████████████ █████████████████████ ███████████████████ ▀███████████████▀ ███████████████████ | | .
|
|
|
|
achow101 (OP)
Staff
Legendary
Offline
Activity: 3374
Merit: 6535
Just writing some code
|
|
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?
Asking because I'm running a 24.0 node at the moment <well, ever since that was released really>
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.
|
|
|
|
S_Speche
Newbie
Offline
Activity: 31
Merit: 0
|
|
December 15, 2022, 04:54:26 PM |
|
Do not download Bitcoin Core V24.0.1
It contains the malicious Full-RBF code.
#NoFullRBF
|
|
|
|
NotATether
Legendary
Offline
Activity: 1582
Merit: 6687
bitcoincleanup.com / bitmixlist.org
|
|
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.
|
. .BLACKJACK ♠ FUN. | | | ███▄██████ ██████████████▀ ████████████ █████████████████ ████████████████▄▄ ░█████████████▀░▀▀ ██████████████████ ░██████████████ █████████████████▄ ░██████████████▀ ████████████ ███████████████░██ ██████████ | | CRYPTO CASINO & SPORTS BETTING | | │ | | │ | ▄▄███████▄▄ ▄███████████████▄ ███████████████████ █████████████████████ ███████████████████████ █████████████████████████ █████████████████████████ █████████████████████████ ███████████████████████ █████████████████████ ███████████████████ ▀███████████████▀ ███████████████████ | | .
|
|
|
|
kano
Legendary
Offline
Activity: 4466
Merit: 1800
Linux since 1997 RedHat 4
|
|
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?
|
|
|
|
pooya87
Legendary
Offline
Activity: 3430
Merit: 10504
|
|
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.
|
. .BLACKJACK ♠ FUN. | | | ███▄██████ ██████████████▀ ████████████ █████████████████ ████████████████▄▄ ░█████████████▀░▀▀ ██████████████████ ░██████████████ █████████████████▄ ░██████████████▀ ████████████ ███████████████░██ ██████████ | | CRYPTO CASINO & SPORTS BETTING | | │ | | │ | ▄▄███████▄▄ ▄███████████████▄ ███████████████████ █████████████████████ ███████████████████████ █████████████████████████ █████████████████████████ █████████████████████████ ███████████████████████ █████████████████████ ███████████████████ ▀███████████████▀ ███████████████████ | | .
|
|
|
|
S_Speche
Newbie
Offline
Activity: 31
Merit: 0
|
|
December 16, 2022, 09:45:32 PM Last edit: December 17, 2022, 03:30:33 AM by S_Speche |
|
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 TeamWe 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 LayerIn 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. #NoFullRBFDo 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.
|
|
|
|
pooya87
Legendary
Offline
Activity: 3430
Merit: 10504
|
|
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. 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. 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. 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,
I agree with this part. Specifically since we have CPFP option. 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. 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. 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. 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
|
. .BLACKJACK ♠ FUN. | | | ███▄██████ ██████████████▀ ████████████ █████████████████ ████████████████▄▄ ░█████████████▀░▀▀ ██████████████████ ░██████████████ █████████████████▄ ░██████████████▀ ████████████ ███████████████░██ ██████████ | | CRYPTO CASINO & SPORTS BETTING | | │ | | │ | ▄▄███████▄▄ ▄███████████████▄ ███████████████████ █████████████████████ ███████████████████████ █████████████████████████ █████████████████████████ █████████████████████████ ███████████████████████ █████████████████████ ███████████████████ ▀███████████████▀ ███████████████████ | | .
|
|
|
|
NotATether
Legendary
Offline
Activity: 1582
Merit: 6687
bitcoincleanup.com / bitmixlist.org
|
|
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.
|
. .BLACKJACK ♠ FUN. | | | ███▄██████ ██████████████▀ ████████████ █████████████████ ████████████████▄▄ ░█████████████▀░▀▀ ██████████████████ ░██████████████ █████████████████▄ ░██████████████▀ ████████████ ███████████████░██ ██████████ | | CRYPTO CASINO & SPORTS BETTING | | │ | | │ | ▄▄███████▄▄ ▄███████████████▄ ███████████████████ █████████████████████ ███████████████████████ █████████████████████████ █████████████████████████ █████████████████████████ ███████████████████████ █████████████████████ ███████████████████ ▀███████████████▀ ███████████████████ | | .
|
|
|
|
BlackHatCoiner
Legendary
Online
Activity: 1498
Merit: 7291
Farewell, Leo
|
|
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.
|
. .HUGE. | | | | | | █▀▀▀▀ █ █ █ █ █ █ █ █ █ █ █ █▄▄▄▄ | ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ . CASINO & SPORTSBOOK ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ | ▀▀▀▀█ █ █ █ █ █ █ █ █ █ █ █ ▄▄▄▄█ | | |
|
|
|
pi5hxaeb
Newbie
Offline
Activity: 4
Merit: 51
|
|
December 28, 2022, 05:25:30 AM |
|
After reading a great recap on the matter, 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.
|
|
|
|
vv181
Legendary
Offline
Activity: 1932
Merit: 1273
|
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$ bitcoin-cli getmempoolinfo { ~ "fullrbf": true }
|
|
|
|
MysteryMiner
Legendary
Offline
Activity: 1470
Merit: 1029
Show middle finger to system and then destroy it!
|
|
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.
|
bc1q59y5jp2rrwgxuekc8kjk6s8k2es73uawprre4j
|
|
|
achow101 (OP)
Staff
Legendary
Offline
Activity: 3374
Merit: 6535
Just writing some code
|
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.
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. 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.
|
|
|
|
MysteryMiner
Legendary
Offline
Activity: 1470
Merit: 1029
Show middle finger to system and then destroy it!
|
|
January 03, 2023, 01:09:53 AM |
|
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? 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++. 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?
|
bc1q59y5jp2rrwgxuekc8kjk6s8k2es73uawprre4j
|
|
|
achow101 (OP)
Staff
Legendary
Offline
Activity: 3374
Merit: 6535
Just writing some code
|
|
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.
|
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3071
|
|
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! belated congrats on the new release everyone.
|
Vires in numeris
|
|
|
cygan
Legendary
Offline
Activity: 3136
Merit: 7700
Cashback 15%
|
|
January 14, 2023, 07:15:27 AM Merited by vapourminer (1) |
|
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?
|
. .HUGE. | | | | | | █▀▀▀▀ █ █ █ █ █ █ █ █ █ █ █ █▄▄▄▄ | ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ . CASINO & SPORTSBOOK ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ | ▀▀▀▀█ █ █ █ █ █ █ █ █ █ █ █ ▄▄▄▄█ | | |
|
|
|
ABCbits
Legendary
Offline
Activity: 2856
Merit: 7407
Crypto Swap Exchange
|
|
January 14, 2023, 10:21:38 AM Merited by vapourminer (1) |
|
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.
|
|
|
|
hymperion
|
|
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.
|
|
|
|
achow101 (OP)
Staff
Legendary
Offline
Activity: 3374
Merit: 6535
Just writing some code
|
|
January 17, 2023, 05:31:44 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.
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
Legendary
Offline
Activity: 3430
Merit: 3071
|
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
|
Vires in numeris
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3071
|
|
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!
|
Vires in numeris
|
|
|
Amph
Legendary
Offline
Activity: 3206
Merit: 1069
|
|
February 21, 2023, 09:13:26 AM |
|
i can't sinc anymore with the last version, anyone have the some problem?
|
|
|
|
Amph
Legendary
Offline
Activity: 3206
Merit: 1069
|
|
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
|
|
|
|
superacellar
Newbie
Offline
Activity: 10
Merit: 0
|
|
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
|
|
|
|
kano
Legendary
Offline
Activity: 4466
Merit: 1800
Linux since 1997 RedHat 4
|
|
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
|
|
|
|
achow101 (OP)
Staff
Legendary
Offline
Activity: 3374
Merit: 6535
Just writing some code
|
|
May 25, 2023, 02:56:20 PM |
|
|
|
|
|
kano
Legendary
Offline
Activity: 4466
Merit: 1800
Linux since 1997 RedHat 4
|
|
May 26, 2023, 01:27:57 AM |
|
|
|
|
|
achow101 (OP)
Staff
Legendary
Offline
Activity: 3374
Merit: 6535
Just writing some code
|
|
May 26, 2023, 05:15:08 AM |
|
Probably not. Your problem is likely solvable with a rescan.
|
|
|
|
achow101 (OP)
Staff
Legendary
Offline
Activity: 3374
Merit: 6535
Just writing some code
|
|
May 26, 2023, 03:14:20 PM |
|
|
|
|
|
kano
Legendary
Offline
Activity: 4466
Merit: 1800
Linux since 1997 RedHat 4
|
|
May 27, 2023, 04:14:30 AM |
|
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
Legendary
Offline
Activity: 3094
Merit: 1596
#1 VIP Crypto Casino
|
|
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.
|
|
|
|
achow101 (OP)
Staff
Legendary
Offline
Activity: 3374
Merit: 6535
Just writing some code
|
|
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.
|
|
|
|
kano
Legendary
Offline
Activity: 4466
Merit: 1800
Linux since 1997 RedHat 4
|
|
June 04, 2023, 10:37:44 PM |
|
As stated, I was dealing with unconfirmed transactions.
|
|
|
|
hardworkinfamilyman
Jr. Member
Offline
Activity: 109
Merit: 2
|
|
July 06, 2023, 10:12:12 PM Last edit: December 23, 2023, 08:08:38 PM by hardworkinfamilyman |
|
.
|
|
|
|
|