bitcoinmagazine.com
A new version of the original Bitcoin software released by Satoshi Nakamoto in 2009 has been released. 112 developers worked on
,
Bitcoin Core 24.0 for about seven months to bring tangible improvements to the Bitcoin Core wallet, peer-to-peer (P2P), graphical user interface (GUI), and more.
This article looks at some of the most important changes.
Wallet Updates
Native Miniscript Support
Bitcoin Core 2
.0 introduces Miniscript support by extending the wsh() output descriptor. Although this is an initial and rudimentary integration, the change paves the way for more complex scripts to be implemented in Bitcoin in a simpler and more secure way.
Miniscript can be considered a framework (or template) for Bitcoin Script, the original programming language for Bitcoin. Bitcoin Script is responsible for implementing all the software functions available for Bitcoin, including perhaps the simplest of them all: which can use a particular coin. For each Bitcoin transaction, the sender requests the recipient's address and uses that information to create a script that locks the bitcoin being sent so that only the recipient can use it. Although creating the simple scripts above is quite easy with Bitcoin Script, the more complex the script, the greater the potential for human error. This is where Miniscript comes into play.
Miniscript allows writing a subset of Bitcoin scripts in a structured way. It enables parsing, pooling, and universal signing, among other things, allowing developers to write more advanced scripts more securely. In other words, Miniscript "pins" certain features of predefined Bitcoin scripts into expected behavior, thus limiting potential risks while minimizing unexpected behavior. In fact, it gives developers a "toolkit" to manage and create advanced and complex scripts for Bitcoin instead of doing everything manually with Bitcoin Script.
As of Bitcoin Core 2
.0, users can now create a wallet containing a Miniscript script, create addresses in that wallet, and fund them with bitcoins. However, the Bitcoin Core wallet does not yet support spending from these addresses, which means that the Bitcoin Core-enabled wallets are currently under review.
Immutable Transactions
A new RPC, sendall, has been introduced to allow users to fully consume certain unused transaction inputs (UTXOs). RPC sends the amount held in specified UTXOs to one or more recipients unchanged. (By default, sendall uses the UTXO of each wallet.)
This behavior may be desirable in some situations. First, a user may want to empty their wallet. Calling a new RPC with default settings is just that easy. Second, the user may want to improve their privacy by opting out of the changes.
Changing addresses is difficult because users often lose track of where they came from and can mix them up with other UTXOs in a future transaction. This would create a privacy problem due to the shared input and ownership heuristic, a widely used assumption in chain analysis that assumes that all inputs to a transaction are owned by the same user. In the example output of the change, a user would create a link that would compromise the deanonymization of several of his coins, because a chain analyst could group some of the user's addresses into a wallet. The
immutable payment solves this problem by creating a transaction that consumes all the selected UTXOs. Since there are no changes, the user cannot make the above error. Additionally, an unmodified payment raises reasonable doubt in the chain analyst, who asks if the new output belongs to the same entity that sent the payment (simply transferring money to a new address) or if it is now owned by a different user. .
Change output randomness to avoid fingerprinting.
As explained above, changing outputs can be a privacy leak. Sendall completely minimizes the use of an exchange address, but in fact there are some times when a user owns the UTXO owed. Ensuring that the observer cannot identify which of the outputs is the change address helps the user achieve some privacy, as it is non-trivial to associate the newly created address (result of the change) with the input currently used for this event. .
In general, if there is no UTXO that contains the correct payment amount, most wallets and users intuitively choose the closest to that number. As a result, an observer looking at the blockchain can see which result is a payment (larger) and which is a change (smaller). This comes with many of the risks mentioned above.
To reduce the likelihood that an observer can distinguish between switch output and cluster user addresses, Bitcoin Core now randomizes switch output values.
As of version 24.0, the Bitcoin Core wallet chooses between random payout size and triple payout size. This number indicates the selection of this UTXO for consumption. In practice, this means that sometimes the algorithm will choose a UTXO with a value closer to the payout, and sometimes it will choose a UTXO with a value closer to the triple payout limit. The first scenario creates a typical conversion yield-less-fee scenario, while the second creates the opposite scenario - a conversion yield greater than fee. Since the blockchain observer cannot tell when each scenario will occur at a given moment, the user should have better privacy guarantees.
Paid Updates
RBF offers a Bitcoin user an opportunity every time they send a transaction to the network. Often, the user does not want to pay too much for mining fees and therefore can choose a "middle ground" between the fee paid and the speed of inclusion of the transaction in the block. However, if the payment value selected by the user is too low or the memory is overloaded, the transaction may take too long to be included in the block (or may be completely blocked in the memory pool). RBF allows the user to "raise" their transaction fee in that case, which usually allows for faster payment.
But the RBF under the hood doesn't actually raise the charge. What happens in the background is that the software client sends a new event with the same inputs and most of the same outputs. (Some output values will change; the value of the payment will of course change according to the new number, and usually the difference will be subtracted from the amount that was sent to the change address.)
Historically, nodes only transmit the first version of the payment. such an agreement. With the introduction of RBF, a mechanism was introduced that allows users to indicate that they are sending a transaction that can later be paid, i.e. replaced by a higher fee. This served as a warning to the nodes, telling them that versions of the transaction with higher fees might be sent later and should also be transmitted. The higher paying version of the transaction is likely to be more attractive to miners and so will be chosen first. If this happens and is included in the block, the transaction with the lower payment is removed from the node memory list because it would try to spend twice.
Bitcoin Core 24.0 introduces two RBF feature updates.
First, it now allows users to configure their nodes to forward exchangeable transactions without the RBF flag. This can be done with the new mempoolfullrbf option. It is disabled by default, but those interested in enabling it can turn it on.
Second, RBF is now standard in the Bitcoin Core wallet. Transactions now default to RBF and the -walletrbf startup option defaults to true. Users can opt out of RBF by setting a specific event in its build process or by setting the -walletrbf startup option to false.
Descriptor Wallet Migration
Bitcoin Core 23.0 made descriptor wallets the standard. Descriptions make the user's life easier when backing up the wallet and then restoring the backup to a standard format.
Before descriptors existed, users needed to know their wallet's routing path, which determines how the wallet's master key routes addresses to receive and send bitcoins. Since wallets can have different management paths, it was not enough for the backup to contain only seed statements. Sometimes a user might get lucky and try to restore a backup with a wallet that used the same derivation path, but since that was unlikely, entire websites have sprung up dedicated to helping users figure out which derivation path to use for old and new wallets. . . The
descriptor solves this problem by describing which derivative path the supported wallet uses, greatly improving the user experience. The idea is that the descriptor wallet backup contains all the information needed by the software client to restore it correctly (provided the client has the descriptor).
Bitcoin Core 24.0 now introduces a new tool to migrate legacy wallets to the descriptive wallet format, allowing users to take advantage of this evolving standard to better protect their valuable bitcoins. Although still experimental, a new RPC (migratewallet) has been launched. This document contains more information about its features.
GUI Changes
The Bitcoin Core GUI is notorious for not providing the same level of functionality that remote procedures (RPC) and command line tools can achieve. Bitcoin 2
.0 takes a few steps to change that a bit.
The latest version of Bitcoin Core introduces a new menu item in the GUI that allows users to restore a wallet from a backup, making it easier for non-technical people to restore backups. Previously, this option was only available on the command line.
Another lack of a GUI compared to the RPC interface was related to the settings of the Bitcoin Core client. The famous bitcoin.conf file is the holy grail of Bitcoin Core configuration, but again, it was mostly adjustable via the command line. It was possible to adjust the settings in the GUI, but the warning explained that bitcoin.conf takes precedence over the GUI if both the file and the GUI tried to set the data to the same setting. So, while the GUI provided an easy way to change settings, the configuration file was still the most reliable way to customize the Bitcoin Core client.
Bitcoin Core 24.0 changes that. The new update merges the GUI settings page with the bitcoin.conf file. Now, when a user opens up the client’s settings on the GUI, the settings shown are pulled from the configuration file. Similarly, configuration changes made in the GUI are now reflected in bitcoin.conf. (It is worth pointing out that the relationship there is indirect, because changes in the GUI are actually set to settings.json, a file that takes precedence over bitcoin.conf.)
Changes To P2P Communications
New Logic For Downloading Headers
Bitcoin Core 2
.0 brings an update to the way peers in the network catch up to the tip of the chain, either because they’re booting for the first time or have spent a long time without connecting to the Bitcoin network.
Before this release, a new peer joining Bitcoin would start looking for peers from which to download block headers. The peer doesn’t download entire blocks at first because it is incentivized to check whether it is following the correct chain before downloading the blocks for that chain. Otherwise, it may upload blocks to the wrong chain, wasting resources.
Although downloading headers saves time and resources, a resource exhaustion attack can still occur if a malicious actor sends millions of fake block headers to a peer. Since the client has to download the titles and save them to disk, a large enough data volume can damage the partner's hardware.
To mitigate this threat, Bitcoin Core introduced the concept of checkpoints years ago. Checkpoints determine which blocks must be in the chain for it to be valid. However, this solution is problematic because checkpoints can be abused to remove the longest chain. In Bitcoin, such an option is not desirable, so a different solution had to be devised. Write this new update.
With Bitcoin Core 24.0, partners now download block headers twice. On first run, headers are loaded and discarded (not saved to disk) until enough work is found to indicate that the string the peer is following is valid. In this case, the partner restarts the process, but now the partner stores not only the download but also the block headers to disk. By storing titles on disk only after the peer is sure they are part of a chain with a significant proof-of-work, the peer avoids using large amounts of storage in the event of a potential attack such as resource exhaustion. It also removes the need for checkpoints and is arguably a more elegant solution because it doesn't rely on human input to determine chain validity.
Thanks to Aaron van Wirdum for his suggestion.
🌐 source
إرسال تعليق