Loading...

Follow Bitcoin.org Blog on Feedspot

Continue with Google
Continue with Facebook
or

Valid
Supporting Sponsorship from Paxful

Paxful, a leading P2P exchange that helps people buy bitcoin, has become a supporting sponsor of Bitcoin.org. Since the Bitcoin Foundation sponsorship ended in 2015, Bitcoin.org has been self-funded by the domain owners and by community donations.

This quarterly supporting sponsorship (which can potentially be renewed) will help bolster and catalyze several efforts:

  • Achieving 100% translation coverage across the site, including the developer documentation
  • Expanding and updating existing developer documentation and other related material
  • Expanding and updating the site in general to be more comprehensive and helpful, based on contributor and community feature requests and feedback
  • New opportunities to compensate active contributors for their time and efforts
  • Increased financial security to cover server, hosting, legal and other administration-related expenses for the foreseeable future

By working together with Paxful, this allows Bitcoin.org to be much more aggressive in getting good quality content produced and translated, and funding efforts to add new functionality and features to the site.

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.

Despite being a privately owned site, its code is open-source and 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.

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

The bitcoin alert keys are disclosed in this blog post, followed by a description of the purpose of this information and its history. The bitcoin alert system has been completely retired. The network is not at risk and this warning may be safely ignored if you do not have an ancient node (running v0.12.x or older) using the deprecated bitcoin alert system or its public keys.

mainnet public key:

04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284

mainnet private key:

30820113020101042053cdc1e0cfac07f7e1c312768886f4635f6bceebec0887f63a9d37a26a92e6b6a081a53081a2020101302c06072a8648ce3d0101022100fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f300604010004010704410479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8022100fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141020101a14403420004fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284

testnet public key:

04302390343f91cc401d56d68b123028bf52e5fca1939df127f63c6467cdf9c8e2c14b61104cf817d0b780da337893ecc4aaff1309e536162dabbdb45200ca2b0a

testnet private key:

308201130201010420474d447aa6f46b4f45f67f21180a5de2722fc807401c4c4d95fdae64b3d6c294a081a53081a2020101302c06072a8648ce3d0101022100fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f300604010004010704410479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8022100fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141020101a14403420004302390343f91cc401d56d68b123028bf52e5fca1939df127f63c6467cdf9c8e2c14b61104cf817d0b780da337893ecc4aaff1309e536162dabbdb45200ca2b0a

These are openssl-serialized private keys.

In 2016, a plan was proposed for the completion of the retirement of the bitcoin alert system which included the idea of revealing the alert system private keys. The proposal still contains good information regarding the purpose and intention of alert system retirement and motivation for the disclosure of the private keys. Additionally, an overview of the alert system retirement and its timeline is available on the web. This disclosure was recently discussed in an IRC meeting logs. A media site also recently discussed this topic.

One of the reasons for disclosure of the keys is to mitigate the effects of unknown dissemination and proliferation of the keys. By broadcasting the values to make them available to everyone, the value of the keys is intended to be to be eliminated, since now everyone could feasibly sign messages, the value of the signed messages becomes zero.

Vulnerabilities in the Bitcoin Alert system

The following text discloses a number of known vulnerabilities in the alert system.

The Alert System previously utilized by Bitcoin has several issues (some of which may be classified as vulnerabilities). These issues no longer exist in Bitcoin as of network protocol version 700013 which was released with Bitcoin Core 0.13.0. Many altcoins and Bitcoin client implementations were notified of the Alert System’s removal and have since removed the alert system themselves or transitioned to using an Alert system that does not share an Alert Key with Bitcoin.

All of the issues described below allow an attacker in possession of the Alert Key to perform a Denial of Service attack on nodes that still support the Alert system. These issues involve the exhaustion of memory which causes node software to crash or be killed due to excessive memory usage.

Many of these issues were not known until the Alert System was removed as developers inspected the code for vulnerabilities prior to releasing the Alert Key. Due to these issues, the publication of the Alert Key was delayed and affected altcoins and software were notified.

As of this writing, less than 4% of Bitcoin nodes are vulnerable. Furthermore, the Bitcoin Core developers have created a “final alert” which is a maximum ID number alert which overrides all previous alerts and displays a fixed “URGENT: Alert key compromised, upgrade required” message on all vulnerable software. The Bitcoin Core developers believe that so few vulnerable nodes are present on the network, and risks to those nodes so minor, that it is safe to publish the Alert Key.

An Alert contains these fields:

int32_t nVersion;
int64_t nRelayUntil;      // when newer nodes stop relaying to newer nodes
int64_t nExpiration;
int32_t nID;
int32_t nCancel;
std::set<int32_t> setCancel;
int32_t nMinVer;            // lowest version inclusive
int32_t nMaxVer;            // highest version inclusive
std::set<std::string> setSubVer;  // empty matches all
int32_t nPriority;

Alerts are also identified by their SHA256 hash. The above fields can be freely modified to generate alerts with differing hashes.

Infinitely Sized Map (CVE-2016-10724)

The Alert System was designed to support multiple Alerts simultaneously. As such, Alerts were stored in memory in a map. However, there is no limit on how large this map can be, thus an attacker with the Alert Key can send a large number of Alerts to a node. Eventually, the map containing all of the Alerts will be so large that the node runs out of memory and crashes, thus causing a Denial of Service attack.

The infinitely sized map is the basis for which the Alert system can be used to cause Denial of Service attacks.

Infinitely Sized Alerts

Although the infinitely sized map is what causes the crash itself, an attacker can also send very large Alerts. Alerts themselves are not limited in size explicitly, they are only limited by the maximum network message size. This maximum network message size has varied between versions. At times in the past, it has been 32 MB. For Bitcoin Core 0.12.0 (the most recent version of Bitcoin Core with the alert system enabled by default), the maximum message size is 2 MB.

Although large Alerts do not directly cause a Denial of Service by themselves, combined with the infinitely sized map, large Alerts can more quickly cause a node to run out of memory.

  • The setCancel field has no length limit (besides the maximum message size) and is a std::set of 32-bit integers. Given that it has no size constraints, an attacker can use this field to create a very large Alert by filling the set with many integers.
  • The setSubVer field, like setCancel, has no length limit and is a std::set. However instead of integers it has std::strings. These strings do not have a length limit themselves and can thus be arbitrarily long to produce an Alert that is arbitrarily large.
  • Bitcoin Core versions prior to 0.10.0 did not have a limit on the length of the strComment, strStatusBar, and strReserved fields. These strings can have an arbitrary length.
The Final Alert

To protect against attackers abusing the Alert key following its publication, the Bitcoin Core developers constructed a “final alert”. This final alert is a maximum ID alert which overrides all previous alerts. All Bitcoin Core versions since and including Bitcoin Core 0.14.0 contain the final alert and will send it to any node which is vulnerable to issues including the following disclosures. However this protection is not enough to protect those nodes as a few issues were found with the final alert implementation itself.

Final alerts are those which meet the following conditions:

nExpiration == maxInt &&
nCancel == (maxInt-1) &&
nMinVer == 0 &&
nMaxVer == maxInt &&
setSubVer.empty() &&
nPriority == maxInt &&
strStatusBar == "URGENT: Alert key compromised, upgrade required"

maxInt is the maximum signed integer as defined by std::numeric_limits<int>::max().

Multiple Final Alerts

The definition for a final alert does not include a few fields. Because alerts are identified by their hashes, changing the ommitted fields allows an Alert to be classified as a final alert but still be an alert that is added to the infinitely sized map.

  • Since setCancel is not required to be empty for an alert to be a final alert, the setCancel field can contain different integers to produce alerts that have different hashes and are thus different alerts. Combined with the infinitely sized map and the infinitely sized setCancel issues, many final alerts can be created which are large, fill the map, and cause a node to run out of memory.
  • The strComment field, while having a maximum length of 65536 bytes, is not required to be a particular string in order for an alert to be a final alert. Thus multiple final alerts can be crafted which have different hashes by using different values for strComment
  • ThestrReserved field, while having a maximum length of 256 bytes, is not required to be a particular string in order for an alert to be a final alert. Thus multiple final alerts can be crafted which have different hashes by using different values for strReserved.
  • The nVersion field is also not required to be a particular value. Thus this can be used to construct final alerts with different hashes by having different values for nVersion.
  • nRelayUntil field is also not required to be a particular value. Thus this can be used to construct final alerts with different hashes by having different values for nRelayUntil.
Final Alert Cancellation (CVE-2016-10725)

Although the final alert is supposed to be uncancellable, it unfortunately is cancellable due to the order of actions when processing an alert. Alerts are first processed by checking whether they cancel any existing alert. Then they are checked whether any of the remaining alerts cancels it. Because of this order, it is possible to create an alert which cancels a final alert before the node checks whether that alert is canceled by the final alert. Thus an attacker can cancel a final alert with another alert allowing a node to be vulnerable to all of the aforementioned attacks.

Protecting Against DoS Attacks from the Alert System

Fixing these issues is relatively easy. The first and most obvious solution is to simply remove the Alert system entirely. As nodes upgrade to versions without the Alert system, fewer nodes will be vulnerable to attack should the Alert keys become public. This is the option that Bitcoin has taken. However, because Bitcoin has retired the Alert system entirely, the Alert key will also be published to reduce the risk that the Alert Key is mistakenly depended upon in the future.

Should altcoins wish to continue using the Alert system but with a different Alert Key, a few very simple fixes will safeguard nodes from the aforementioned issues. Limiting the number of alerts, the size of setCancel and setSubVer, and only allowing one final alert altogether fix the above issues. This patch, on top of Bitcoin Core 0.11 (a vulnerable version), fixes the aforementioned issues. Altcoins that still use the Alert system are recommended to port this patch to their software. Outdated node software is still vulnerable.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
A Redesigned Bitcoin.org

One of our goals in 2018 has been to modernize the look and feel of Bitcoin.org. Each day, tens of thousands of new users come to Bitcoin.org to learn how to get started using the currency and technology. The site has grown exponentially in popularity as Bitcoin adoption has increased. Last year alone, there were over 30 million visitors to Bitcoin.org. These visitors viewed the site’s pages over 200 million times. Many of these pages are often the first results on search engines for bitcoin-related phrases and terms.

As traffic and engagement has increased, however, the design has become very dated. In fact, the current look and feel of the site has pretty much remained the same for ~5 years, going all the way back to 2013. As a result, a large amount of effort and attention has gone into a recent redesign project, that’s getting closer to complete. After holding a community vote on various design options, the community selection has been extended into all of the different subpages.

We’ve reached one of the most critical phases of the project, now, which is getting feedback and lots of help testing from a bunch of different people, before it goes live.

Help test the new design.

If you visited the link above and experienced any issues or have feedback, please send us an email or open an issue on Bitcoin.org’s GitHub repository. Please also make sure to note your device, operating system and browser version(s), when applicable, to give us additional context and clarity - it is super-helpful.

Even the most minor bits of feedback, nits or issues are welcome. The community we are all part of is very diverse, and we want to strive to make Bitcoin.org the best site it can be for as many people as possible.

Acknowledgments

Bitcoin.org is funded exclusively by donations from the community, and a huge debt of gratitude is owed. Without community donations, the current redesign work would not have been possible. More enhancements and special projects are on the horizon, so stay tuned. The support from donations that allow Bitcoin.org to compete with sites that aren’t community supported, are greatly appreciated.

A big thanks is also due specifically to Natalia, Marek and Oleksandr at ETHworks who have spear-headed the redesign efforts, worked tirelessly, and have delivered great results from the very beginning, every step of the way. They are amazingly talented people in the cryptocurrency space.

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.

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

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
  • 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
  • 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
  • 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
  • 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
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

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