What’s New in Bitcoin Core 0.13.0?

in #bitcoin • 8 years ago (edited)

What’s New in Bitcoin Core 0.13.0?

As you may already noticed, Bitcoin Core 0.13 was tagged for release. Bitcoin Core 0.13.0 was in developent more than five months and is loaded with new features! These are the most important ones:

  • Preparation for segregated witness

    The most significant code change is the inclusion of the segregated witness (segwit) code in preparation for an upcoming soft fork. This release will not activate segwit, and if segwit is activated, this release will not act any differently, so those who want to use or enforce segwit will need to upgrade to a later release that does contain the activation mechanism.

    By including the segwit code in Bitcoin Core 0.13.0, users gain several advantages:

    1. Easier upgrade to segwit: The code differences (“diff”) from this release to a subsequent release that includes segwit will be small. This allows users who modify their version of Bitcoin Core to easily convert any modifications they make to Bitcoin Core 0.13.0 to the release that contains segwit (which is expected to be 0.13.1).
    2. Easier segwit testing: Although this release won’t run segwit code on mainnet, it does run the code on testnet and in regression testing mode (regtest), which makes it easy for developers, administrators, and testers to use segwit in a safe environment with a version of Bitcoin Core that will be very close to the first version that is ready for miners to activate segwit.
    3. Full integration with other features: all the other features included in this release – such as feefiltering, compact block relay, child-pays-for-parent mining, and official binaries for Linux on ARM – are integrated with the segwit code and will probably be in production for two or more months before segwit activates, providing extra time for potential problems to be discovered through community review and testing.

    MORE INFORMATION:

  • Compact block relay

    Prior to Bitcoin Core 0.13.0, a running full node would (by default) receive many transactions twice:

    1. Before the transaction was confirmed, as an individual transaction being relayed across the network.
    2. After the transaction was confirmed, as part of a group of transactions contained in a newly-mined block being relayed across the network.

    There’s no need for the node to receive the transaction a second time if it still has the first copy. Compact block relay (BIP152) can eliminate this redundancy by allowing a node to receive from its peers an ordered list of what transactions are included in a new block. With this knowledge, the node can use the transactions it has already received to partly or fully reconstruct the transactions part of the block for itself. If the node doesn’t receive all the transactions it needs to fully reconstruct the block, it requests the missing transactions from its peers, and then uses them to complete the block.

    For several years now, Bitcoin Core nodes have used a minimum relay fee rate to help determine what unconfirmed transactions they’ll process, relay, and store in their individual memory pools. Each node gets to decide its own minimum relay fee rate, and if they receive a transaction whose fee rate is below that limit, they don’t add it to their memory pools or relay it to their other peers (although another mechanism called transaction priority historically allowed some transactions that pay a low fee to be accepted into mempools and relayed).

    Prior to Bitcoin Core 0.13.0, nodes didn’t tell each other what minimum fee rate they were using, which could lead to wasted bandwidth. For example, Alice sends Bob a transaction without realizing that the transaction’s fee rate is below Bob’s minimum. Because of the way Bitcoin transactions are relayed, Bob has no way of knowing that the transaction is below his limit until he has already downloaded the whole transaction, at which point he stops processing the transaction because its fee rate is too low, so both his bandwidth and Alice’s bandwidth end up being wasted.

    Bitcoin Core 0.13.0 supports a new message that has been added to the peer-to-peer (P2P) protocol, the feefilter message, which has been designed to help eliminate this wasted bandwidth. This P2P message allows Bob to tell Alice what he is currently using as his minimum relay fee rate so that Alice will not bother trying to relay to him any transactions that pay a fee below his rate.

    Compact blocks provides three very important benefits to the network:

    1. By reducing the amount of bandwidth used by transaction relay nodes, compact blocks help offset the expected increase in bandwidth that will occur when the segwit capacity increases are enabled by miners. This offset should allow nodes to continue operating on the network after segwit even if they’re presently near their current bandwidth caps.
    2. By eliminating the bandwidth spike that occurs when nodes receive a new block, compact blocks may make it easier to keep a node operating on connections with limited peak bandwidth. For example, several users have reported that receiving a new block slows down other important activity on their network, such as video conferencing, so some of those users shut down Bitcoin Core before starting those activities. Compact blocks may eliminate those bandwidth spikes and make running Bitcoin Core less inconvenient for those users.
    3. Faster propagation of blocks across the network, by dramatically reducing the amount of data that needs to be transported when a new block is found.

    MORE INFORMATION:

    • Release notes
    • Compact Block Relay FAQ
    • BIP152, which describes the compact blocks protocol
    • Bitcoin FIBRE, an open source protocol and implementation that builds upon compact blocks to minimize latency for new block announcements between peers on managed networks. FIBRE was designed and implemented alongside compact block relay version 1 and it is being used to test improvements for a subsequent version of compact block relay.

  • Fee filtering

    For several years now, Bitcoin Core nodes have used a minimum relay fee rate to help determine what unconfirmed transactions they’ll process, relay, and store in their individual memory pools. Each node gets to decide its own minimum relay fee rate, and if they receive a transaction whose fee rate is below that limit, they don’t add it to their memory pools or relay it to their other peers (although another mechanism called transaction priority historically allowed some transactions that pay a low fee to be accepted into mempools and relayed).

    Prior to Bitcoin Core 0.13.0, nodes didn’t tell each other what minimum fee rate they were using, which could lead to wasted bandwidth. For example, Alice sends Bob a transaction without realizing that the transaction’s fee rate is below Bob’s minimum. Because of the way Bitcoin transactions are relayed, Bob has no way of knowing that the transaction is below his limit until he has already downloaded the whole transaction, at which point he stops processing the transaction because its fee rate is too low, so both his bandwidth and Alice’s bandwidth end up being wasted.

    Bitcoin Core 0.13.0 supports a new message that has been added to the peer-to-peer (P2P) protocol, the feefilter message, which has been designed to help eliminate this wasted bandwidth. This P2P message allows Bob to tell Alice what he is currently using as his minimum relay fee rate so that Alice will not bother trying to relay to him any transactions that pay a fee below his rate.

    MORE INFORMATION:

  • BIP32 HD wallet support

    When Bitcoin Core starts for the first time, it will now generate a BIP32 Hierarchical Deterministic (HD) wallet where every private key in the wallet is derived from a single piece of information using a repeatable (deterministic) process. This means backing up that single piece of information will back up every private key your wallet will ever generate, ensuring that you can recover any bitcoins controlled by those private keys in the future.

    Backups are hard to get right, so please note the following information:

    • If you upgrade from any version of Bitcoin Core before 0.13.0, you will continue using the old style of wallet where each private key is generated individually, with (by default) up to 100 of them pre-generated in advance to make backups easier—meaning you need to create additional backups every 100 transactions, since each default-style transaction uses one private key.
    • If you create a new wallet with 0.13.0 (or above) and you change from the default unencrypted wallet to an encrypted wallet, a new HD wallet will be generated for you. You will still have access to any bitcoins sent to the unencrypted wallet, but you will need to backup the wallet again.

    If you aren’t sure whether you’re using an HD wallet, you can check using the getwalletinfo RPC:

    • If you use the Bitcoin Core graphical user interface, you can click the Help menu, choose the Debug option, click the Console tab, and then type in getwalletinfo.
    • If you use the bitcoin-cli command to access the RPC interface, you can type bitcoin-cli getwalletinfo.

    In either case, if you see a line labeled “masterkeyid”, then you’re using an HD wallet; if you don’t see it, then you’re using a wallet with individually generated keys.

    Backing up an HD wallet ensures that you will be able to re-generate any private keys produced by that wallet in the future, but that is the only information you can recover from the backup in the future. Any additional information you enter into your wallet after you make the backup, such as descriptions of transactions you sent or received, will be lost if you have to restore from the HD wallet backup, so we recommend that you continue to make regular backups of your wallet in order to preserve that information.

    Importantly, if you manually import any private keys to your wallet, they cannot be recovered using any backups made prior to the import, so you will need to make a new wallet backup and use that.

MORE INFORMATION:

  • Release notes

  • Deterministic wallets (Bitcoin Wiki)

  • BIP32: Hierarchical Deterministic Wallets

  • More intelligent transaction selection for mining

    Ancestor fee rate mining is the new default transaction selection method for mining in Bitcoin Core 0.13.0. Miners can use it to select which transactions to put in their next block, providing two important benefits:

    1. For miners often more revenue can be earned from transaction fees per block because ancestor fee rate mining is able to prioritize certain higher-fee transactions.
    2. For users as a side benefit of miners choosing transactions more intelligently, it becomes possible for the recipient of an unconfirmed transaction to incentivize miners to mine that transaction.

    Bitcoin has rule that says if Alice spends a bitcoin to Bob, the transaction where Alice originally receives the bitcoin must appear earlier in the blockchain than the transaction where she spends that bitcoin to Bob. In other words, the parent transaction must appear earlier in the blockchain than its child transaction, forming an ancestor relationship.

    Both the child and parent transactions can appear in the same block, but if they do, the parent must appear earlier in that block than the child. This means that if an unconfirmed child transaction pays a high fee, miners should be incentivized by this existing Bitcoin rule to mine that transaction’s unconfirmed parent (even if it pays a low fee) in order to get the child’s high fee.

    This incentivization scheme is often called Child Pays For Parent (CPFP). In the simplest version, miners group a transaction and all of its ancestors together, calculating their total fee-per-byte in order to determine whether mining them together pays a high enough fee to outbid other individual transactions the miner wants to include in its next block.

    A key advantage of ancestor fee rate mining is that the two transactions don’t need to be created by the same person. For example, if Bob is waiting for confirmation of a transaction that Alice sent him, Bob can independently create a child transaction that incentivizes miners to confirm his transaction and Alice’s transaction together.

    It is important to note that ancestor fee rate mining doesn’t guarantee that a low-fee transaction will be mined just because it has a high-fee child or other descendent. In particular, almost all miners and nodes will ignore transactions that don’t pay a minimal amount of fee per kilobyte of data (the exact ratio varies by node), so if a parent transaction is ignored because the fee it pays is below this limit, then its children will not be mined no matter how high a fee they pay.

    MORE INFORMATION:

  • Official builds for Linux on ARM

    The official Bitcoin Core binaries built and cryptographically signed by multiple contributors through the Gitian process now includes two new platforms:

    • bitcoin-${VERSION}-arm-linux-gnueabihf.tar.gz: Linux binaries for the most common 32-bit ARM architecture.
    • bitcoin-${VERSION}-aarch64-linux-gnu.tar.gz: Linux binaries for the most common 64-bit ARM architecture.

    If you have the GNU C compiler installed, you can run the following command to figure out which platform you’re using: gcc -print-multiarch

    Or you if use a Debian-based system, you can try the following command: dpkg-architecture -q DEB_HOST_GNU_SYSTEM

    These binaries are designed for Linux using GNU libc6; they are not expected to run by default on Android or other operating systems.

    The new builds are still experimental, so please report any problems that you encounter.

    MORE INFORMATION:

  • Conclusion

    For details on all the changes made in Bitcoin Core 0.13.0, please read the release notes. To download, please visit the download page or the files directory

    With the release of Bitcoin Core 0.13.0, we begin the six-month release cycle for the next version of Bitcoin Core (expected to be 0.14.0). With the participation of the community, we will also be choosing the BIP9 parameters for segregated witness and releasing a minor version (expected to be 0.13.1) with segwit fully enabled.

    If you are interested in contributing to Bitcoin Core, please see our contributing page and the document How to contribute code to Bitcoin Core. If you don’t know where to get started or have any other questions, please stop by either our IRC or Slack chatrooms and we’ll do our best to help you.

  • Hashes for verification

    These are the SHA-256 hashes of the released files:

f94123e37530f9de25988ff93e5568a93aa5146f689e63fb0ec1f962cf0bbfcd  bitcoin-0.13.0-aarch64-linux-gnu.tar.gz
7c657ec6f6a5dbb93b9394da510d5dff8dd461df8b80a9410f994bc53c876303  bitcoin-0.13.0-arm-linux-gnueabihf.tar.gz
d6da2801dd9d92183beea16d0f57edcea85fc749cdc2abec543096c8635ad244  bitcoin-0.13.0-i686-pc-linux-gnu.tar.gz
2f67ac67b935368e06f2f3b83f0173be641eef799e45d0a267efc0b9802ca8d2  bitcoin-0.13.0-osx64.tar.gz
e7fed095f1fb833d167697c19527d735e43ab2688564887b80b76c3c349f85b0  bitcoin-0.13.0-osx.dmg
0c7d7049689bb17f4256f1e5ec20777f42acef61814d434b38e6c17091161cda  bitcoin-0.13.0.tar.gz
213e6626ad1f7a0c7a0ae2216edd9c8f7b9617c84287c17c15290feca0b8f13b  bitcoin-0.13.0-win32-setup.exe
5c5bd6d31e4f764e33f2f3034e97e34789c3066a62319ae8d6a6011251187f7c  bitcoin-0.13.0-win32.zip
c94f351fd5266e07d2132d45dd831d87d0e7fdb673d5a0ba48638e2f9f8339fc  bitcoin-0.13.0-win64-setup.exe
54606c9a4fd32b826ceab4da9335d7a34a380859fa9495bf35a9e9c0dd9b6298  bitcoin-0.13.0-win64.zip
bcc1e42d61f88621301bbb00512376287f9df4568255f8b98bc10547dced96c8  bitcoin-0.13.0-x86_64-linux-gnu.tar.gz

#blockchain #crypto-news #money #steem
8 years ago in #bitcoin by
$0.02
  • Past Payouts $0.02
  • - Author $0.02
  • - Curators $0.00
12 votes
Reply 4
Sort:  
  • Trending
    • [-]
     8 years ago  

    This post has been linked to from another place on Steem.

    Learn more about linkback bot v0.3

    Upvote if you want the bot to continue posting linkbacks for your posts. Flag if otherwise. Built by @ontofractal

    [-]
     8 years ago  

    Upvote n supported 👍
    Like ❤️