Loading...

Follow Bitcoin.org Blog on Feedspot

Continue with Google
Continue with Facebook
Or

Valid


As one of the most-visited websites in the Bitcoin ecosystem, Bitcoin.org helps millions of people each month, learn more about Bitcoin. One of our goals in 2018 is to modernize the design of the site in an effort to continue to provide rich content and information to users in an efficient way, as Bitcoin technology continues to evolve.

Below are three new homepage designs we’d like to vote on. Each version shows what the homepage would look like on a desktop, handheld or tablet device. The version that receives the most votes will then be further extended into the subpages of the site:

Please help spread the word and choose your favorite design.

Voting will be open until 0:00 UTC on Sunday, February 4th.

You can also view the results.

About Bitcoin.org

Bitcoin.org was originally registered and owned by Satoshi Nakamoto and Martti Malmi. When Satoshi left the project, he gave ownership of the domain to additional people, separate from the Bitcoin developers, to spread responsibility and prevent any one person or group from easily gaining control over the Bitcoin project. Since then, the site has been developed and maintained by different members of the Bitcoin community.

There have been over 3,200 commits from 180 contributors from all over the world. In addition to this, over 950 translators have helped to make the site display natively to visitors by default in their own languages —now 25 different languages and growing.

Interested in getting involved?

Learn how you can participate.

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

For many years, bitcoin.org has hosted and prominently encouraged users to adopt Bitcoin Core, the leading Bitcoin full node software today. In the near future, we plan to promote Bitcoin Knots as an alternative to Bitcoin Core. Bitcoin Knots is a compatible derivative of Bitcoin Core with many added improvements. This will mean the software presented on the download page will be Knots and not Core. Knots is reasonably robust and reliable software (although understandably less well-tested) and we recommend you upgrade if you feel comfortable doing so.

We hope that by supporting Knots, we can help reduce the strong dependence on Core. Users that download Knots will be helping to make the Bitcoin network more resilient and reliable. If you’re a developer, we hope you will contribute to Bitcoin Knots. Future releases of the Core software can be downloaded from the Bitcoin Core official site.

Additionally, the “choose your wallet” page may be revised to give more focus on full-node-based wallets, as well as preference for mobile wallets which help users secure their bitcoins by making it easy and convenient for them to use their own full node.

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

On 2017-10-11 at noon (UTC), Bitcoin.org is planning to publish a banner on every page of the site warning users about the risks of using services that will default to the so-called Segwit2x1 (S2X) contentious hard fork. S2X companies will be called out by name. To ensure that we only warn users against companies that will actually put user deposits at risk, we urge all companies to publicly clarify their stance before the above date, either by a highly-visible public statement or by commenting on Bitcoin.org issue #1835 (or by doing both).

In particular, we need to know that:

  1. The company will not under any circumstances list “Segwit2x” as “BTC” and/or “Bitcoin”. Note that Bitcoin is not ruled by miners, and miner actions cannot be used as a justification to redefine Bitcoin.
  2. The company will not by default do anything that would deprive users of their bitcoins (by eg. using S2X software without addressing replay attacks2, selling user bitcoins automatically, crediting BTC deposits only as S2X deposits, etc.). Providing access to S2X-coins is acceptable, however.
  3. The company will continue to provide normal service to Bitcoin (ie. non-S2X) users.

Although bitcoin.org condemns contentious hard fork attempts such as S2X, we consider it tolerable for companies to support S2X in ways that do not contradict the above three points, such as by supporting both Bitcoin and S2X simultaneously as separate cryptocurrencies.

By default, we will be using the following list of companies known to support S2X in our warning:

  • 1Hash (China)
  • Abra (United States)
  • ANX (Hong Kong)
  • Bitangel.com /Chandler Guo (China)
  • BitClub Network (Hong Kong)
  • Bitcoin.com (St. Kitts & Nevis)
  • Bitex (Argentina)
  • bitFlyer (Japan)
  • Bitfury (United States)
  • Bitmain (China)
  • BitPay (United States)
  • BitPesa (Kenya)
  • BitOasis (United Arab Emirates)
  • Bitso (Mexico)
  • Bixin.com (China)
  • Blockchain (UK)
  • Bloq (United States)
  • BTC.com (China)
  • BTCC (China)
  • BTC.TOP (China)
  • BTER.com (China)
  • Circle (United States)
  • Civic (United States)
  • Coinbase (United States)
  • Coins.ph (Phillipines)
  • CryptoFacilities (UK)
  • Decentral (Canada)
  • Digital Currency Group (United States)
  • Filament (United States)
  • Genesis Global Trading (United States)
  • Genesis Mining (Hong Kong)
  • GoCoin (Isle of Man)
  • Grayscale Investments (United States)
  • Jaxx (Canada)
  • Korbit (South Korea)
  • Luno (Singapore)
  • MONI (Finland)
  • Netki (United States)
  • OB1 (United States)
  • Purse (United States)
  • Ripio (Argentina)
  • Safello (Sweden)
  • SFOX (United States)
  • ShapeShift (Switzerland)
  • SurBTC (Chile)
  • Unocoin (India)
  • Veem (United States)
  • ViaBTC (China)
  • Xapo (United States)
  • Yours (United States)
Notes
  1. “SegWit2x” has nothing to do with SegWit. SegWit is already activated, and was supported by an entirely different set of people.
  2. S2X claims to have replay protection, but their version requires extra manual steps in order to prevent loss of BTC. If you use S2X software without careful engineering, you are likely to lose any associated BTC.
Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Bitcoin Core version 0.14.2 is now available.

This is a new minor version release, including various bugfixes and performance improvements, as well as updated translations.

Please report bugs using the issue tracker on GitHub.

Subscribe here to receive security and update notifications.

Compatibility

Bitcoin Core is extensively tested on multiple operating systems using the Linux kernel, macOS 10.8+, and Windows Vista and later.

Microsoft ended support for Windows XP on April 8th, 2014, No attempt is made to prevent installing or running the software on Windows XP, you can still do so at your own risk but be aware that there are known instabilities and issues. Please do not report issues about Windows XP to the issue tracker.

Bitcoin Core should also work on most other Unix-like systems but is not frequently tested on them.

Notable changes miniupnp CVE-2017-8798

Bundled miniupnpc was updated to 2.0.20170509. This fixes an integer signedness error (present in MiniUPnPc v1.4.20101221 through v2.0) that allows remote attackers (within the LAN) to cause a denial of service or possibly have unspecified other impact.

This only affects users that have explicitly enabled UPnP through the GUI setting or through the -upnp option, as since the last UPnP vulnerability (in Bitcoin Core 0.10.3) it has been disabled by default.

If you use this option, it is recommended to upgrade to this version as soon as possible.

Known Bugs

Since 0.14.0 the approximate transaction fee shown in Bitcoin-Qt when using coin control and smart fee estimation does not reflect any change in target from the smart fee slider. It will only present an approximate fee calculated using the default target. The fee calculated using the correct target is still applied to the transaction and shown in the final send confirmation dialog.

0.14.2 Change log

Detailed release notes follow. This overview includes changes that affect behavior, not code moves, refactors and string updates. For convenience in locating the code changes and accompanying discussion, both the pull request and git merge commit are mentioned.

RPC and other APIs
  • #10410 321419b Fix importwallet edge case rescan bug (ryanofsky)
P2P protocol and network code
  • #10424 37a8fc5 Populate services in GetLocalAddress (morcos)
  • #10441 9e3ad50 Only enforce expected services for half of outgoing connections (theuni)
Build system
  • #10414 ffb0c4b miniupnpc 2.0.20170509 (fanquake)
  • #10228 ae479bc Regenerate bitcoin-config.h as necessary (theuni)
Miscellaneous
  • #10245 44a17f2 Minor fix in build documentation for FreeBSD 11 (shigeya)
  • #10215 0aee4a1 Check interruptNet during dnsseed lookups (TheBlueMatt)
GUI
  • #10231 1e936d7 Reduce a significant cs_main lock freeze (jonasschnelli)
Wallet
  • #10294 1847642 Unset change position when there is no change (instagibbs)
Credits

Thanks to everyone who directly contributed to this release:

  • Alex Morcos
  • Cory Fields
  • fanquake
  • Gregory Sanders
  • Jonas Schnelli
  • Matt Corallo
  • Russell Yanofsky
  • Shigeya Suzuki
  • Wladimir J. van der Laan

As well as everyone that helped translating on Transifex.

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Bitcoin Core version 0.14.1 is now available.

This is a new minor version release, including various bugfixes and performance improvements, as well as updated translations.

Please report bugs using the issue tracker on GitHub.

Subscribe here to receive security and update notifications.

Compatibility

Bitcoin Core is extensively tested on multiple operating systems using the Linux kernel, macOS 10.8+, and Windows Vista and later.

Microsoft ended support for Windows XP on April 8th, 2014, No attempt is made to prevent installing or running the software on Windows XP, you can still do so at your own risk but be aware that there are known instabilities and issues. Please do not report issues about Windows XP to the issue tracker.

Bitcoin Core should also work on most other Unix-like systems but is not frequently tested on them.

Notable changes RPC changes
  • The first positional argument of createrawtransaction was renamed from transactions to inputs.
  • The argument of disconnectnode was renamed from node to address.

These interface changes break compatibility with 0.14.0, when the named arguments functionality, introduced in 0.14.0, is used. Client software using these calls with named arguments needs to be updated.

Mining

In previous versions, getblocktemplate required segwit support from downstream clients/miners once the feature activated on the network. In this version, it now supports non-segwit clients even after activation, by removing all segwit transactions from the returned block template. This allows non-segwit miners to continue functioning correctly even after segwit has activated.

Due to the limitations in previous versions, getblocktemplate also recommended non-segwit clients to not signal for the segwit version-bit. Since this is no longer an issue, getblocktemplate now always recommends signalling segwit for all miners. This is safe because ability to enforce the rule is the only required criteria for safe activation, not actually producing segwit-enabled blocks.

UTXO memory accounting

Memory usage for the UTXO cache is being calculated more accurately, so that the configured limit (-dbcache) will be respected when memory usage peaks during cache flushes. The memory accounting in prior releases is estimated to only account for half the actual peak utilization.

The default -dbcache has also been changed in this release to 450MiB. Users who currently set -dbcache to a high value (e.g. to keep the UTXO more fully cached in memory) should consider increasing this setting in order to achieve the same cache performance as prior releases. Users on low-memory systems (such as systems with 1GB or less) should consider specifying a lower value for this parameter.

Additional information relating to running on low-memory systems can be found here: reducing-bitcoind-memory-usage.md.

0.14.1 Change log

Detailed release notes follow. This overview includes changes that affect behavior, not code moves, refactors and string updates. For convenience in locating the code changes and accompanying discussion, both the pull request and git merge commit are mentioned.

RPC and other APIs
  • #10084 142fbb2 Rename first named arg of createrawtransaction (MarcoFalke)
  • #10139 f15268d Remove auth cookie on shutdown (practicalswift)
  • #10146 2fea10a Better error handling for submitblock (rawodb, gmaxwell)
  • #10144 d947afc Prioritisetransaction wasn’t always updating ancestor fee (sdaftuar)
  • #10204 3c79602 Rename disconnectnode argument (jnewbery)
Block and transaction handling
  • #10126 0b5e162 Compensate for memory peak at flush time (sipa)
  • #9912 fc3d7db Optimize GetWitnessHash() for non-segwit transactions (sdaftuar)
  • #10133 ab864d3 Clean up calculations of pcoinsTip memory usage (morcos)
P2P protocol and network code
  • #9953/#10013 d2548a4 Fix shutdown hang with >= 8 -addnodes set (TheBlueMatt)
  • #10176 30fa231 net: gracefully handle NodeId wrapping (theuni)
Build system
  • #9973 e9611d1 depends: fix zlib build on osx (theuni)
GUI
  • #10060 ddc2dd1 Ensure an item exists on the rpcconsole stack before adding (achow101)
Mining
  • #9955/#10006 569596c Don’t require segwit in getblocktemplate for segwit signalling or mining (sdaftuar)
  • #9959/#10127 b5c3440 Prevent slowdown in CreateNewBlock on large mempools (sdaftuar)
Tests and QA
  • #10157 55f641c Fix the mempool_packages.py test (sdaftuar)
Miscellaneous
  • #10037 4d8e660 Trivial: Fix typo in help getrawtransaction RPC (keystrike)
  • #10120 e4c9a90 util: Work around (virtual) memory exhaustion on 32-bit w/ glibc (laanwj)
  • #10130 ecc5232 bitcoin-tx input verification (awemany, jnewbery)
Credits

Thanks to everyone who directly contributed to this release:

  • Alex Morcos
  • Andrew Chow
  • Awemany
  • Cory Fields
  • Gregory Maxwell
  • James Evans
  • John Newbery
  • MarcoFalke
  • Matt Corallo
  • Pieter Wuille
  • practicalswift
  • rawodb
  • Suhas Daftuar
  • Wladimir J. van der Laan

As well as everyone that helped translating on Transifex.

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Bitcoin Core version 0.14.0 is now available.

This is a new major version release, including new features, various bugfixes and performance improvements, as well as updated translations.

Please report bugs using the issue tracker on GitHub.

Subscribe here to receive security and update notifications.

Compatibility

Bitcoin Core is extensively tested on multiple operating systems using the Linux kernel, macOS 10.8+, and Windows Vista and later.

Microsoft ended support for Windows XP on April 8th, 2014, No attempt is made to prevent installing or running the software on Windows XP, you can still do so at your own risk but be aware that there are known instabilities and issues. Please do not report issues about Windows XP to the issue tracker.

Bitcoin Core should also work on most other Unix-like systems but is not frequently tested on them.

Notable changes Performance Improvements

Validation speed and network propagation performance have been greatly improved, leading to much shorter sync and initial block download times.

  • The script signature cache has been reimplemented as a “cuckoo cache”, allowing for more signatures to be cached and faster lookups.
  • Assumed-valid blocks have been introduced which allows script validation to be skipped for ancestors of known-good blocks, without changing the security model. See below for more details.
  • In some cases, compact blocks are now relayed before being fully validated as per BIP152.
  • P2P networking has been refactored with a focus on concurrency and throughput. Network operations are no longer bottlenecked by validation. As a result, block fetching is several times faster than previous releases in many cases.
  • The UTXO cache now claims unused mempool memory. This speeds up initial block download as UTXO lookups are a major bottleneck there, and there is no use for the mempool at that stage.
Manual Pruning

Bitcoin Core has supported automatically pruning the blockchain since 0.11. Pruning the blockchain allows for significant storage space savings as the vast majority of the downloaded data can be discarded after processing so very little of it remains on the disk.

Manual block pruning can now be enabled by setting -prune=1. Once that is set, the RPC command pruneblockchain can be used to prune the blockchain up to the specified height or timestamp.

getinfo has been deprecated

The getinfo RPC command has been deprecated. Each field in the RPC call has been moved to another command’s output with that command also giving additional information that getinfo did not provide. The following table shows where each field has been moved to:

ZMQ On Windows

Previously the ZeroMQ notification system was unavailable on Windows due to various issues with ZMQ. These have been fixed upstream and now ZMQ can be used on Windows. Please see this document for help with using ZMQ in general.

Nested RPC Commands in Debug Console

The ability to nest RPC commands has been added to the debug console. This allows users to have the output of a command become the input to another command without running the commands separately.

The nested RPC commands use bracket syntax (i.e. getwalletinfo()) and can be nested (i.e. getblock(getblockhash(1))). Simple queries can be done with square brackets where object values are accessed with either an array index or a non-quoted string. Both commas and spaces can be used to separate parameters in both the bracket syntax and normal RPC command syntax.

Network Activity Toggle

A RPC command and GUI toggle have been added to enable or disable all p2p network activity. The network status icon in the bottom right hand corner is now the GUI toggle. Clicking the icon will either enable or disable all p2p network activity. If network activity is disabled, the icon will be grayed out with an X on top of it.

Additionally the setnetworkactive RPC command has been added which does the same thing as the GUI icon. The command takes one boolean parameter, true enables networking and false disables it.

Out-of-sync Modal Info Layer

When Bitcoin Core is out-of-sync on startup, a semi-transparent information layer will be shown over top of the normal display. This layer contains details about the current sync progress and estimates the amount of time remaining to finish syncing. This layer can also be hidden and subsequently unhidden by clicking on the progress bar at the bottom of the window.

Support for JSON-RPC Named Arguments

Commands sent over the JSON-RPC interface and through the bitcoin-cli binary can now use named arguments. This follows the JSON-RPC specification for passing parameters by-name with an object.

bitcoin-cli has been updated to support this by parsing name=value arguments when the -named option is given.

Some examples:

src/bitcoin-cli -named help command="help" src/bitcoin-cli -named getblockhash height=0 src/bitcoin-cli -named getblock blockhash=000000000019d6689c085ae165831e934... src/bitcoin-cli -named sendtoaddress address="(snip)" amount="1.0" subtractfeefromamount=true

The order of arguments doesn’t matter in this case. Named arguments are also useful to leave out arguments that should stay at their default value. The rarely-used arguments comment and comment_to to sendtoaddress, for example, can be left out. However, this is not yet implemented for many RPC calls, this is expected to land in a later release.

The RPC server remains fully backwards compatible with positional arguments.

Opt into RBF When Sending

A new startup option, -walletrbf, has been added to allow users to have all transactions sent opt into RBF support. The default value for this option is currently false, so transactions will not opt into RBF by default. The new bumpfee RPC can be used to replace transactions that opt into RBF.

Sensitive Data Is No Longer Stored In Debug Console History

The debug console maintains a history of previously entered commands that can be accessed by pressing the Up-arrow key so that users can easily reuse previously entered commands. Commands which have sensitive information such as passphrases and private keys will now have a (...) in place of the parameters when accessed through the history.

Retaining the Mempool Across Restarts

The mempool will be saved to the data directory prior to shutdown to a mempool.dat file. This file preserves the mempool so that when the node restarts the mempool can be filled with transactions without waiting for new transactions to be created. This will also preserve any changes made to a transaction through commands such as prioritisetransaction so that those changes will not be lost.

Final Alert

The Alert System was disabled and deprecated in Bitcoin Core 0.12.1 and removed in 0.13.0. The Alert System was retired with a maximum sequence final alert which causes any nodes supporting the Alert System to display a static hard-coded “Alert Key Compromised” message which also prevents any other alerts from overriding it. This final alert is hard-coded into this release so that all old nodes receive the final alert.

GUI Changes
  • After resetting the options by clicking the Reset Options button in the options dialog or with the -resetguioptions startup option, the user will be prompted to choose the data directory again. This is to ensure that custom data directories will be kept after the option reset which clears the custom data directory set via the choose datadir dialog.
  • Multiple peers can now be selected in the list of peers in the debug window. This allows for users to ban or disconnect multiple peers simultaneously instead of banning them one at a time.
  • An indicator has been added to the bottom right hand corner of the main window to indicate whether the wallet being used is a HD wallet. This icon will be grayed out with an X on top of it if the wallet is not a HD wallet.
Low-level RPC changes
  • importprunedfunds only accepts two required arguments. Some versions accept an optional third arg, which was always ignored. Make sure to never pass more than two arguments.
  • The first boolean argument to getaddednodeinfo has been removed. This is an incompatible change.
  • RPC command getmininginfo loses the “testnet” field in favor of the more generic “chain” (which has been present for years).
  • A new RPC command preciousblock has been added which marks a block as precious. A precious block will be treated as if it were received earlier than a competing block.
  • A new RPC command importmulti has been added which receives an array of JSON objects representing the intention of importing a public key, a private key, an address and script/p2sh
  • Use of getrawtransaction for retrieving confirmed transactions with unspent outputs has been deprecated. For now this will still work, but in the future it may change to only be able to retrieve information about transactions in the mempool or if txindex is enabled.
  • A new RPC command getmemoryinfo has been added which will return information about the memory usage of Bitcoin Core. This was added in conjunction with optimizations to memory management. See Pull #8753 for more information.
  • A new RPC command bumpfee has been added which allows replacing an unconfirmed wallet transaction that signaled RBF (see the -walletrbf startup option above) with a new transaction that pays a higher fee, and should be more likely to get confirmed quickly.
HTTP REST Changes
  • UTXO set query responses were changed to return status code HTTP_BAD_REQUEST (400) instead of HTTP_INTERNAL_SERVER_ERROR (500) when requests contain invalid parameters.
Minimum Fee Rate Policies

Since the changes in 0.12 to automatically limit the size of the mempool and improve the performance of block creation in mining code it has not been important for relay nodes or miners to set -minrelaytxfee. With this release the following concepts that were tied to this option have been separated out:

  • incremental relay fee used for calculating BIP 125 replacement and mempool limiting. (1000 satoshis/kB)
  • calculation of threshold for a dust output. (effectively 3 * 1000 satoshis/kB)
  • minimum fee rate of a package of transactions to be included in a block created by the mining code. If miners wish to set this minimum they can use the new -blockmintxfee option. (defaults to 1000 satoshis/kB)

The -minrelaytxfee option continues to exist but is recommended to be left unset.

Fee Estimation Changes
  • Since 0.13.2 fee estimation for a confirmation target of 1 block has been disabled. The fee slider will no longer be able to choose a target of 1 block. This is only a minor behavior change as there was often insufficient data for this target anyway. estimatefee 1 will now always return -1 and estimatesmartfee 1 will start searching at a target of 2.

  • The default target for fee estimation is changed to 6 blocks in both the GUI (previously 25) and for RPC calls (previously 2).

Removal of Priority Estimation
  • Estimation of “priority” needed for a transaction to be included within a target number of blocks has been removed. The RPC calls are deprecated and will either return -1 or 1e24 appropriately. The format for fee_estimates.dat has also changed to no longer save these priority estimates. It will automatically be converted to the new format which is not readable by prior versions of the software.

  • Support for “priority” (coin age) transaction sorting for mining is considered deprecated in Core and will be removed in the next major version. This is not to be confused with the prioritisetransaction RPC which will remain supported by Core for adding fee deltas to transactions.

P2P connection management
  • Peers manually added through the -addnode option or addnode RPC now have their own limit of eight connections which does not compete with other inbound or outbound connection usage and is not subject to the limitation imposed by the -maxconnections option.

  • New connections to manually added peers are performed more quickly.

Introduction of assumed-valid blocks
  • A significant portion of the initial block download time is spent verifying scripts/signatures. Although the verification must pass to ensure the security of the system, no other result from this verification is needed: If the node knew the history of a given block were valid it could skip checking scripts for its ancestors.

  • A new configuration option ‘assumevalid’ is provided to express this knowledge to the software. Unlike the ‘checkpoints’ in the past this setting does not force the use of a particular chain: chains that are consistent with it are processed quicker, but other chains are still accepted if they’d otherwise be chosen as best. Also unlike ‘checkpoints’ the user can configure which block history is assumed true, this means that even outdated software can sync more quickly if the setting is updated by the user.

  • Because the validity of a chain history is a simple objective fact it is much easier to review this setting. As a result the software ships with a default value adjusted to match the current chain shortly before release. The use of this default value can be disabled by setting -assumevalid=0

Fundrawtransaction change address reuse
  • Before 0.14, fundrawtransaction was by default wallet stateless. In almost all cases fundrawtransaction does add a change-output to the outputs of the funded transaction. Before 0.14, the used keypool key was never marked as change-address key and directly returned to the keypool (leading to address reuse). Before 0.14, calling getnewaddress directly after fundrawtransaction did generate the same address as the change-output address.

  • Since 0.14, fundrawtransaction does reserve the change-output-key from the keypool by default (optional by setting reserveChangeKey, default = true)

  • Users should also consider using getrawchangeaddress() in conjunction with fundrawtransaction’s changeAddress option.

Unused mempool memory used by coincache
  • Before 0.14, memory reserved for mempool (using the -maxmempool option) went unused during initial block download, or IBD. In 0.14, the UTXO DB cache (controlled with the -dbcache option) borrows memory from the mempool when there is extra memory available. This may result in an increase in memory usage during IBD for those previously relying on only the -dbcache option to limit memory during that time.
0.14.0 Change log

Detailed release notes follow. This overview includes changes that affect behavior, not code moves, minor refactors and string updates. For convenience in locating the code changes and accompanying discussion, both the pull request and git merge commit are mentioned.

RPC and other APIs
  • #8421 b77bb95 httpserver: drop boost dependency (theuni)
  • #8638 f061415 rest.cpp: change HTTP_INTERNAL_SERVER_ERROR to HTTP_BAD_REQUEST (djpnewton)
  • #8272 91990ee Make the dummy argument to getaddednodeinfo optional (sipa)
  • #8722 bb843ad bitcoin-cli: More detailed error reporting (laanwj)
  • #6996 7f71a3c Add preciousblock RPC (sipa)
  • #8788 97c7f73 Give RPC commands more information about the RPC request (jonasschnelli)
  • #7948 5d2c8e5 Augment getblockchaininfo bip9_softforks data (mruddy)
  • #8980 0e22855 importmulti: Avoid using boost::variant::operator!=, which is only in newer boost versions (luke-jr)
  • #9025 4d8558a Getrawtransaction should take a bool for verbose (jnewbery)
  • #8811 5754e03 Add support for JSON-RPC named arguments (laanwj)
  • #9520 2456a83 Deprecate non-txindex getrawtransaction and better warning (sipa)
  • #9518 a65ced1 Return height of last block pruned by pruneblockchain RPC (ryanofsky)
  • #9222 7cb024e Add ‘subtractFeeFromAmount’ option to ‘fundrawtransaction’ (dooglus)
  • #8456 2ef52d3 Simplified bumpfee command (mrbandrews)
  • #9516 727a798 Bug-fix: listsinceblock: use fork point as reference for blocks in reorg’d chains (kallewoof)
  • #9640 7bfb770 Bumpfee: bugfixes for error handling and feerate calculation (sdaftuar)
  • #9673 8d6447e Set correct metadata on bumpfee wallet transactions (ryanofsky)
  • #9650 40f7e27 Better handle invalid parameters to signrawtransaction (TheBlueMatt)
  • #9682 edc9e63 Require timestamps for importmulti keys (ryanofsky)
  • #9108 d8e8b06 Use importmulti timestamp when importing watch only keys (on top of #9682) (ryanofsky)
  • #9756 7a93af8 Return error when importmulti called with invalid address (ryanofsky)
  • #9778 ad168ef Add two hour buffer to manual pruning (morcos)
  • #9761 9828f9a Use 2 hour grace period for key timestamps in importmulti rescans (ryanofsky)
  • #9474 48d7e0d Mark the minconf parameter to move as ignored (sipa)
  • #9619 861cb0c Bugfix: RPC/Mining: GBT should return 1 MB sizelimit before segwit activates (luke-jr)
  • #9773 9072395 Return errors from importmulti if complete rescans are not successful (ryanofsky)
Block and transaction handling
  • #8391 37d83bb Consensus: Remove ISM (NicolasDorier)
  • #8365 618c9dd Treat high-sigop transactions as larger rather than rejecting them (sipa)
  • #8814 14b7b3f wallet, policy: ParameterInteraction: Don’t allow 0 fee (MarcoFalke)
  • #8515 9bdf526 A few mempool removal optimizations (sipa)
  • #8448 101c642 Store mempool and prioritization data to disk (sipa)
  • #7730 3c03dc2 Remove priority estimation (morcos)
  • #9111 fb15610 Remove unused variable UNLIKELY_PCT from fees.h (fanquake)
  • #9133 434e683 Unset fImporting for loading mempool (morcos)
  • #9179 b9a87b4 Set DEFAULT_LIMITFREERELAY = 0 kB/minute (MarcoFalke)
  • #9239 3fbf079 Disable fee estimates for 1-block target (morcos)
  • #7562 1eef038 Bump transaction version default to 2 (btcdrak)
  • #9313,#9367 If we don’t allow free txs, always send a fee filter (morcos)
  • #9346 b99a093 Batch construct batches (sipa)
  • #9262 5a70572 Prefer coins that have fewer ancestors, sanity check txn before ATMP (instagibbs)
  • #9288 1ce7ede Fix a bug if the min fee is 0 for FeeFilterRounder (morcos)
  • #9395 0fc1c31 Add test for -walletrejectlongchains (morcos)
  • #9107 7dac1e5 Safer modify new coins (morcos)
  • #9312 a72f76c Increase mempool expiry time to 2 weeks (morcos)
  • #8610 c252685 Share unused mempool memory with coincache (sipa)
  • #9138 f646275 Improve fee estimation (morcos)
  • #9408 46b249e Allow shutdown during LoadMempool, dump only when necessary (jonasschnelli)
  • #9310 8c87f17 Assert FRESH validity in CCoinsViewCache::BatchWrite (ryanofsky)
  • #7871 e2e624d Manual block file pruning (mrbandrews)
  • #9507 0595042 Fix use-after-free in CTxMemPool::removeConflicts() (sdaftuar)
  • #9380 dd98f04 Separate different uses of minimum fees (morcos)
  • #9596 71148b8 bugfix save feeDelta instead of priorityDelta in DumpMempool (morcos)
  • #9371 4a1dc35 Notify on removal (morcos)
  • #9519 9b4d267 Exclude RBF replacement txs from fee estimation (morcos)
  • #8606 e2a1a1e Fix some locks (sipa)
  • #8681 6898213 Performance Regression Fix: Pre-Allocate txChanged vector (JeremyRubin)
  • #8223 744d265 c++11: Use std::unique_ptr for block creation (domob1812)
  • #9125 7490ae8 Make CBlock a vector of shared_ptr of CTransactions (sipa)
  • #8930 93566e0 Move orphan processing to ActivateBestChain (TheBlueMatt)
  • #8580 46904ee Make CTransaction actually immutable (sipa)
  • #9240 a1dcf2e Remove txConflicted (morcos)
  • #8589 e8cfe1e Inline CTxInWitness inside CTxIn (sipa)
  • #9349 2db4cbc Make CScript (and prevector) c++11 movable (sipa)
  • #9252 ce5c1f4 Release cs_main before calling ProcessNewBlock, or processing headers (cmpctblock handling) (sdaftuar)
  • #9283 869781c A few more CTransactionRef optimizations (sipa)
  • #9499 9c9af5a Use recent-rejects, orphans, and recently-replaced txn for compact-block-reconstruction (TheBlueMatt)
  • #9813 3972a8e Read/write mempool.dat as a binary (paveljanik)
P2P protocol and network code
  • #8128 1030fa7 Turn net structures into dumb storage classes (theuni)
  • #8282 026c6ed Feeler connections to increase online addrs in the tried table (EthanHeilman)
  • #8462 53f8f22 Move AdvertiseLocal debug output to net category (Mirobit)
  • #8612 84decb5 Check for compatibility with download in FindNextBlocksToDownload (sipa)
  • #8594 5b2ea29 Do not add random inbound peers to addrman (gmaxwell)
  • #8085 6423116 Begin encapsulation (theuni)
  • #8715 881d7ea only delete CConnman if it’s been created (theuni)
  • #8707 f07424a Fix maxuploadtarget setting (theuni)
  • #8661 d2e4655 Do not set an addr time penalty when a peer advertises itself (gmaxwell)
  • #8822 9bc6a6b Consistent checksum handling (laanwj)
  • #8936 1230890 Report NodeId in misbehaving debug (rebroad)
  • #8968 3cf496d Don’t hold cs_main when calling ProcessNewBlock from a cmpctblock (TheBlueMatt)
  • #9002 e1d1f57 Make connect=0 disable automatic outbound connections (gmaxwell)
  • #9050 fcf61b8 Make a few values immutable, and use deterministic randomness for the localnonce (theuni)
  • #8969 3665483 Decouple peer-processing-logic from block-connection-logic (#2) (TheBlueMatt)
  • #8708 c8c572f have CConnman handle message sending (theuni)
  • #8709 1e50d22 Allow filterclear messages for enabling TX relay only (rebroad)
  • #9045 9f554e0 Hash P2P messages as they are received instead of at process-time (TheBlueMatt)
  • #9026 dc6b940 Fix handling of invalid compact blocks (sdaftuar)
  • #8996 ab914a6 Network activity toggle (luke-jr)
  • #9131 62af164 fNetworkActive is not protected by a lock, use an atomic (jonasschnelli)
  • #8872 0c577f2 Remove block-request logic from INV message processing (TheBlueMatt)
  • #8690 791b58d Do not fully sort all nodes for addr relay (sipa)
  • #9128 76fec09 Decouple CConnman and message serialization (theuni)
  • #9226 3bf06e9 Remove fNetworkNode and pnodeLocalHost (gmaxwell)
  • #9352 a7f7651 Attempt reconstruction from all compact block announcements (sdaftuar)
  • #9319 a55716a Break addnode out from the outbound connection limits (gmaxwell)
  • #9261 2742568 Add unstored orphans with rejected parents to recentRejects (morcos)
  • #9441 8b66bf7 Massive speedup. Net locks overhaul (theuni)
  • #9375 3908fc4 Relay compact block messages prior to full block connection (TheBlueMatt)
  • #9400 8a445c5 Set peers as HB peers upon full block validation (instagibbs)
  • #9561 6696b46 Wake message handling thread when we receive a new block (TheBlueMatt)
  • #9535 82274c0 Split CNode::cs_vSend: message processing and message sending (TheBlueMatt)
  • #9606 3f9f962 Consistently use GetTimeMicros() for inactivity checks (sdaftuar)
  • #9594 fd70211 Send final alert message to older peers after..
Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

A directory of Bitcoin Exchanges servicing the world’s 20 largest economies, as well as several international options (serving many countries) are now available on Bitcoin.org.

Helping People Interested in Bitcoin, Get Bitcoin

This new addition to the site:

  • Links to the Find an Exchange button on the Getting Started page and helps many of the new people entering the Bitcoin ecosystem via Bitcoin.org, get bitcoin.
  • Improves SEO for Bitcoin.org, because the site can now potentially rank very well for “Bitcoin Exchange” as well as other key phrases that include country names that are contained on the page (i.e. Bitcoin Exchange China, Bitcoin Exchange India, etc.).
  • Has unique anchor links for each country that people can share on social media that will allow others to find the bitcoin exchanges that are available for their specific country.
  • Allows Bitcoin.org to focus the wallets page on wallets that allow people to maintain full control over their funds (Resolving issue #1109, because custodial wallets that provide exchange services can be moved off of the wallets page to this new page).
  • Is also accessible via the Resources dropdown menu.
Questions, Comments & Feedback

Questions, issues, suggestions or feedback are always welcome on Bitcoin.org. If interested in contributing in this regard, please open an issue or submit a pull request.

Use Discretion when Choosing an Exchange

As noted in the above screen shot, Bitcoin Exchanges provide varying degrees of safety, security, privacy, and control over your funds and information. Perform your own due diligence and choose a wallet where you will keep your bitcoin before selecting an exchange.

=== === ===

Interested in getting involved with Bitcoin.org?

Learn how you can participate.

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Updated instructions for how to run a full node as of version 0.13.1 are now available on Bitcoin.org. These instructions allow one to quickly get set up and running with a full node on the following operating systems:

In addition to the above operating systems, tips on how to configure a full bitcoin node for a local area network and how to tweak the reference client configuration are available.

Why is running a full bitcoin node important?

Full nodes help enforce the consensus rules of the Bitcoin network. When a full node client is running, it downloads every new block and every new transaction and checks them to make sure they are valid. Here are some examples of consensus rules, though there are many more:

  • Blocks may only create a certain number of bitcoins.

  • Transactions must have correct signatures for the bitcoins being spent.

  • Transactions/blocks must be in the correct data format.

  • Within the block chain, a transaction output cannot be double-spent.

Read more about what a full node is, the consensus rules above and other incentives for supporting the network in the Bitcoin Wiki.

Minimum Requirements

Bitcoin Core full nodes have certain requirements. If you try running a node on weak hardware, it may work — but you’ll likely spend more time dealing with issues. If you can meet the following requirements, you’ll have an easy-to-use node.

  • Desktop or laptop hardware running recent versions of Windows, Mac OS X, or Linux.

  • 125GB of free disk space (size of the blockchain plus room to grow)

  • 2GB of memory (RAM)

  • A broadband Internet connection with upload speeds of at least 400 kilobits (50 kilobytes) per second

  • An unmetered connection, a connection with high upload limits, or a connection you regularly monitor to ensure it doesn’t exceed its upload limits. It’s common for full nodes on high-speed connections to use 200GB in uploads or more a month. Download usage is around 20GB/month, plus around an additional 100GB the first time you start your node.

  • 6 hours/day that your full node can be left running. (You can do other things with your computer while running a full node.) More hours would be better, and best of all would be if you can run your node continuously.

Note: many operating systems today (Windows, Mac, and Linux) enter a low-power mode after the screensaver activates, slowing or halting network traffic. This is often the default setting on laptops and on all Mac OS X laptops and desktops. Check your screensaver settings and disable automatic “sleep” or “suspend” options to ensure you support the network whenever your computer is running.

What to do if you need help

Please seek out assistance in the community if you need help setting up your full node correctly to handle high-value and privacy-sensitive tasks. Do your own diligence to ensure who you get help from is ethical, reputable and qualified to assist you.

Acknowledgments

A special thanks goes to the contributors (in no preferential order) who have worked to improve this page over time:

Interested in getting involved?

Learn how you can participate.

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Bitcoin.org is proud to announce the addition of a dozen new pages to the site about Bitcoin Core. Several of the pages describe Bitcoin Core’s powerful features, others provide help for Bitcoin Core users, and several make it easier to start contributing to Bitcoin Core.

Excerpts from Bitcoin.org’s Bitcoin Core pages

Both Bitcoin Core and Bitcoin.org have come a long way since the site began promoting the earliest public versions of the software.

Bitcoin.org homepage, 3 March 2009 (Internet Archive)

These new pages give us a chance to introduce more recent Bitcoin users to the advantages of full nodes like Bitcoin Core, particularly how full validation helps protect Bitcoin’s essential decentralization from takeover by a handful of miners, Bitcoin banks, and service providers.

A Brief Guide to The New Pages
  • Bitcoin Core overview: provides a brief description of Bitcoin Core and links to the other sections of the sub-site.

  • Feature overview: briefly describes some of Bitcoin Core’s leading benefits and links to pages that provide more details.

  • Get help page: resources to help Bitcoin Core users find help. Prior to this PR, we also created and filled a category on the Bitcoin Wiki with all the existing Bitcoin Core help pages.

  • Contribute overview: links to ways you can directly contribute to Bitcoin Core and Bitcoin Core users.

Future Plans

We plan to enhance this new section of the Bitcoin.org website by collecting together some of Bitcoin Core’s disparate documentation and providing instructions for important ways users can enhance their privacy and security while using Bitcoin Core—such as using Tor and an offline wallet.

In addition, we hope to provide more resources that help businesses understand the benefits of validating the transactions they receive with their own full nodes.

If you want to help, please feel free to email the Bitcoin.org documentation maintainer, Dave Harding.

Thank You

Thank you to everyone who made these pages possible, especially the people who reviewed Bitcoin.org pull requests 1044, 1009, 1007, 966, 957, and 869 as well as the Bitcoin Foundation for their funding of the Bitcoin.org server during the time these pages were written.

We hope you enjoy the new pages. If you see any problems, please don’t hesitate to open an issue.

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Bitcoin.org has moved our main git repository to the new bitcoin-dot-org GitHub organization: https://github.com/bitcoin-dot-org/bitcoin.org

We moved to an independent organization to make clear that Bitcoin.org and Bitcoin Core are separate projects, even though we frequently have the pleasure of working together.

Nothing besides the repository URL has changed—Bitcoin.org will continue to provide all of the same information and resources as it did before. The team of contributors is also staying the same.

Existing links to the old repository (including developer git configurations) should continue to work, but we that suggest you upgrade them to point to the new repository at your first convenience. Git users can who have the Bitcoin.org repository as their upstream can run,

cd bitcoin.org
git remote set-url upstream 'https://github.com/bitcoin-dot-org/bitcoin.org'

All current issues and pull requests remain open, and any forks hosted on GitHub shouldn’t need to be updated.

If you have any problems, please open an issue.

Read Full Article
Visit website

Read for later

Articles marked as Favorite are saved for later viewing.
close
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Separate tags by commas
To access this feature, please upgrade your account.
Start your free year
Free Preview