Bitcoin Wiki - User contributions [en]

Fallback Nodes

2022-07-25T05:44:59Z

BlueMatt: /* Tor nodes */ Goodbye, old friend.

This is a list of nodes which are considered reliable.

== How to use this list ==

=== Connect to nodes ===

You can connect to these nodes with the ''-addnode=ip'' switch instead of the usual node harvesting process (through IRC or via the embedded nodelist). You can connect to more than one node by using ''-addnode=ip'' more than once. It is usually a good idea to connect to more than one of these nodes.

==== Nodes without a fixed ip ====

If the node IP is not fixed (see "Fixed" column), you will have to resolve the node's name (first column) each time the IP changes. Some nodes may have their ip change once a day, some others once a month, and some others may stay on the same IP for years. Still, as long as the IP is not fixed, there is no guarantee it will stay the same.

In order to enable hostname lookups for the ''-addnode'' and ''-connect'' parameters, you must additionally provide the ''-dns'' parameter. Example:
bitcoind -dns -addnode=bitcoin.es

Versions prior to 0.3.22 do not support hostnames to the ''-addnode'' parameter, so you must do the resolving part for it. For example on linux:
bitcoind -addnode=$(dig +short bitcoin.es)

=== IP Transactions ===

[[Bitcoin Core]] versions prior to 0.8.0 also could send [[IP Transactions]] to these nodes. If you included your bitcoin address in the "message" field, you might have had your coins back.

=== Tor network ===

BitcoinCore will automatically use Tor if it is available at default (''127.0.0.1:9050''), to use Bitcoin-Qt over Tor hidden services '''only''', in a terminal/console enter:
bitcoin-qt -proxy=127.0.0.1:9050 -onlynet=tor

To use Bitcoin with one specific Tor node, run
bitcoin-qt -proxy=127.0.0.1:9050 -connect=abcde.onion
, where abcde.onion needs to be substituted with one of the [[Fallback_Nodes#Tor_nodes|Tor nodes below]]. These parameters can be added to [[Running_Bitcoin#Bitcoin.conf_Configuration_File|bitcoin.conf]] to make them permanent.

More details on how to execute BitcoinCore with Tor see [[Setting_up_a_Tor_hidden_service|Setting up a Tor hidden service]]. You can find detailed information on running clients and hidden services within Tor in the [https://github.com/bitcoin/bitcoin/blob/master/doc/tor.md documentation].

== Nodes list ==

=== IPv4 Nodes ===

This entire list was last checked on 2017-11-15.

{|class="wikitable sortable"
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-

|-
| bitcoin.moneypot.com || [https://www.moneypot.com moneypot] || 212.47.228.216 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || 2015-09-15 || No
|-
| node.bitcoin.xxx || [http://www.bitcoin.xxx Bitcoin.xxx] || 66.228.49.201 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || 2014-08-28 || Yes
|-
| bitcoin.coinprism.com || [[Coinprism]] || 137.116.225.142 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || 2014-04-26 || Yes
|-
| btcnode1.evolyn.net || Evolyn || 85.214.251.25 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || 2014-01-26 || Yes
|-
| InductiveSoul.US || [[User:Inductivesoul|Inductive Soul]] || 67.186.224.85 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || 2013-11-13 || Yes
|-
| archivum.info || Ferraro Ltd.|| 88.198.58.172 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| 62.75.216.13 || exMULTI, Inc. || 62.75.216.13 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No
|-
| 69.64.34.118 || exMULTI, Inc. || 69.64.34.118 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No
|-
| 79.160.221.140 || K-Norway || 79.160.221.140 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| netzbasis.de || unknown3 || 81.169.129.25 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| btc.turboadmin.com || osmosis || 98.143.152.14 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No
|-
| fallback.bitcoin.zhoutong.com || Zhou Tong || 117.121.241.140 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No
|-
| bauhaus.csail.mit.edu || imsaguy || 128.30.96.44 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| jun.dashjr.org || Luke-Jr || 173.242.112.53 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || 2017-11-15 ||
|-
| cheaperinbitcoins.com || Xenland/Shane || 184.154.36.82 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| django.webflows.fr || unknown2 || 188.165.213.169 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| 204.9.55.71 || toasty || 204.9.55.71 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| btcnode.novit.ro || ovidiusoft - novit.ro || 93.187.142.114 || {{Table Value No}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| porgressbar.sk || progressbar hackerspace || 91.210.181.21 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| faucet.bitcoin.st || bitcoin street || 64.27.57.225 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| bitcoin.securepayment.cc || SecurePayment CC || 63.247.147.163 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| www.dcscdn.com || [[User:Danw12|Danw12]] || 199.115.228.181 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || ||
|-
| ns2.dcscdn.com || [[User:Danw12|Danw12]] || 199.115.228.182 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || ||
|-
| coin.soul-dev.com || Soul-Dev || || || {{Fallback Nodes/Node Down}} || ||
|-
| messier.bzfx.net || BZFX/[[User:A Meteorite|A Meteorite]] || 91.121.205.50 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || ||
|-
| btcnode1.bitgroup.cc || BitGroup || 198.211.116.191 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| btcnode2.bitgroup.cc || BitGroup || 162.243.120.138 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| btcnode3.bitgroup.cc || BitGroup || 95.85.8.237 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| btcnode.xiro.co || Xiro Labs || 91.121.108.61 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || 2017-11-15 || No
|-
| stuff.liam-w.io || [[User:liamwli|Liam W]] || 185.122.57.203 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No
|-
| bitcoin.bitdonut.co || James Hartig || || || {{Fallback Nodes/Node Down}} || ||
|-
| coinno.de || jaknam || || || {{Fallback Nodes/Node Down}} || ||
|-
| 82.165.44.44 || anonymous || || || {{Fallback Nodes/Node Down}} || ||
|-
| bitcoin1.dassori.me || gdassori || || || {{Fallback Nodes/Node Down}} || ||
|-
| bitcoin2.dassori.me || gdassori || || || {{Fallback Nodes/Node Down}} || ||
|-
| blockchainnode.meulie.net || [[User:Evert|Evert]] || || || {{Fallback Nodes/Node Up}} || 2017-11-15 ||
|-
| fullnode.fybsg.com || Nagato || || || {{Fallback Nodes/Node Down}} || ||
|-
| n.bitcoin-fr.io || [[User:Arthur|Arthur]] || 62.210.66.227 || || {{Fallback Nodes/Node Up}} || 2017-11-15 ||
|-
| homeplex.tk || [[User:Victorsueca|Victorsueca]] || 90.165.120.190 || || {{Fallback Nodes/Node Down}} || ||
|-
| mars.jordandoyle.uk || [https://doyle.wf Jordan Doyle] || 91.121.83.82 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes

|}

=== IPv6 Nodes ===
{|class="wikitable sortable"
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-

| InductiveSoul.US || [[User:Inductivesoul|Inductive Soul]] || 2601:7:6680:2ac:4d29:40ff:7513:fcc7 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || 11-13-2013 (MDY) || Yes
|-
| caffeinator.net || [[User:Atrophy|Atrophy]] || || || {{Fallback Nodes/Node Up}} || 2013-05-10 ||
|-
| 2001:470:8:2e1::40 || ? || 2001:470:8:2e1::40 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| messier.bzfx.net || BZFX/[[User:A Meteorite|A Meteorite]] || 2001:41d0:1:d632::1 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || ||
|-
| stuff.liam-w.io || [[User:liamwli|Liam W]] || 2a06:8ec0:3::1:2e47 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || No
|-
| bitcoin.bitdonut.co || James Hartig || || || || ||
|-
| n.bitcoin-fr.io || [[User:Arthur|Arthur]] || 2001:bc8:c087:2001::1 || || || ||
|-
| mars.jordandoyle.uk || [https://doyle.wf Jordan Doyle] || || || || ||

|}

=== Tor nodes ===

This entire list was last checked on 2022-07-25.

{|class="wikitable sortable"
! Hostname !! Owner !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-
| pcxlvkgabsowmrx54b5bgqglershgfchr6xavrhbfngridplzhf2pwqd.onion || BlueMatt || Up || 2022-07-25 || No
|}

== Adding a node ==

Before adding yourself as a fallback node, you should be sure your node will stay online for a long time. If a node is offline for more than 24 hours it will be removed from the list.

To add a node in this list, you just need the ip/hostname and your name, the other fields will be filled automatically. Insert the following lines before the <tt>END NODELIST</tt> line:

<nowiki>|-
| ip || your name</nowiki>

==See Also==

* [[Network|Bitcoin Network]]
* [http://nodes.bitcoin.st Fallback Nodes] List of longest running Bitcoin Nodes listed by Country.
* [https://getaddr.bitnodes.io/ Bitnodes project]
* [https://blockchain.info/connected-nodes Recently connected nodes at blockchain.info]

{{Bitcoin Core documentation}}

Segwit support

2017-06-12T17:00:57Z

BlueMatt: Deleted Suhas at his request

<big><big>'''PLEASE NOTE:''' This list is not yet complete, nor completely vetted by the parties listed for accuracy.</big></big>

'''Developers: Please edit your row (add one if you're missing) to reflect your positions. If for some reason you don't already have a wiki account that can edit the page, make an account and ask luke-jr for help if you get caught in the anti-spam.'''

{| class="wikitable"
| {{No}} || doesn't support (but might or might not go along with it with sufficient community support)
|-
| {{Deficient}} || okay with the idea, but considers it to have insufficient community support
|-
| {{Evaluating}} || still evaluating the idea
|-
| {{Wanting}} || positively likes the idea, but considers it to have insufficient community support
|-
| {{Weak}} || better than nothing at all
|-
| {{Acceptable}} || it is a workable solution
|-
| {{Prefer}} || it is what he would choose if it was only up to him and no outside influences
|}



''Note that support for BIP148 does not mean developers support merging it into Core.''

{| class="wikitable sortable"
! rowspan=2 colspan=2 | Developer & affiliation* 
! Segwit itself
! colspan=3 | Deployment methods
! colspan=2 | Hardfork bundles (Silbert agreement)
|-
! [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP 141] !! [https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki BIP 148] !! [https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki BIP 149] !! [https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki BIP 91] || Segwit2x || [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014445.html COOP]
|-
| ฿tcDrak || Core || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}} || {{No}}
|-
| Bryan Bishop || || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}
|-
| Andrew Chow || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}
|-
| Matt Corallo || Core || {{Prefer}} || {{No}} || || {{Acceptable}} || {{No|LOL}} ||
|-
| Johnathan Corgan || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{No}} || {{No}} || {{No}}
|-
| Luke Dashjr || Core || {{Prefer}} || {{Prefer}} || {{No}} || {{Acceptable|Acc. until July}} || {{No}} || {{Deficient}}
|-
| Christian Decker || Core || {{Prefer}} || {{Acceptable}} || || || ||
|-
| Nicolas Dorier || Core || {{Prefer}} || {{Deficient}} || || || ||
|-
| Marco Falke || Core || {{Prefer}} || {{Deficient}} || || || ||
|-
| Michael Ford || Core || {{Prefer}} || || || || ||
|-
| Mark Friedenbach || BIP 68/112 || {{Prefer}} || {{Prefer}} || {{No}} || {{Acceptable|Acc. until July}} || {{No|LOL}} || {{No|Nope}}
|-
| Pavel Janik || Core || {{Prefer}} || {{No}} || {{Acceptable}} || {{No}} || {{No}} || {{No}}
|-
| Thomas Kerin || Core || {{Prefer}} || {{Wanting}} || {{Prefer}} || {{Weak}} || {{No}} || {{No}}
|-
| Johnson Lau || Core || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Acceptable}} || ||
|-
| Eric Lombrozo || || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{Weak}} || {{No}} || {{No}}
|-
| Greg Maxwell || Core || {{Prefer}} || {{Deficient}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}
|-
| Alex Morcos || Core || {{Prefer}} || {{Deficient}} || {{Acceptable}} || {{Weak}} || {{No}} ||
|-
| Pavol "stick" Rusnak || Trezor || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}
|-
| Rusty Russell || c-lightning || {{Prefer}} || {{Prefer}} || || || ||
|-
| Gregory Sanders || Core || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Weak}} || {{No}} ||
|-
| Jonas Schnelli || Core || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}
|-
| Patrick Strateman || Core || {{Prefer}} || || || || ||
|-
| Jorge Timon || Core || {{Prefer}} || {{No}} || {{Prefer}} || {{Deficient}} || {{No}} || {{No}}
|-
| Peter Todd || Core || {{Prefer}} || {{Acceptable}} || || || ||
|-
| Warren Togami || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || || ||
|-
| Wladimir van der Laan || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}
|-
| flix1 || || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{Deficient}} || {{Evaluating}} || {{Evaluating}}
|-
| Leo Wandersleb || Mycelium || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}
|}

* "affiliation" is an optional field for the company or project the individual is associated with, that most qualifies the person to comment on the matter and is not meant as a company or project endorsement of the individual's position.

Contract

2015-10-22T19:47:05Z

BlueMatt: This wiki is about Bitcoin, not Ripple

A '''distributed contract''' is a method of using Bitcoin to form agreements with people via the block chain. Contracts don't make anything possible that was previously impossible, but rather, they allow you to solve common problems in a way that minimizes trust. Minimal trust often makes things more convenient by allowing human judgements to be taken out of the loop, thus allowing complete automation.

By building low trust protocols that interact with Bitcoin, entirely new products can be created:

* [[Smart Property|Smart property]] is property that can be atomically traded and loaned via the block chain.
* [[Transferable virtual property]] are digital items that can be traded but not duplicated.
* [[Agents]] are autonomous programs that maintain their own wallet, which they use to buy server time. Money is obtained by the agent selling services. If demand exceeds supply the agents can spawn children that either survive or die depending on whether they can get enough business.
* [[Distributed markets]] are a way to implement peer to peer bond and stock trading, allowing Bitcoin to be evolve into a full competitor to the international financial system.

This page also lists some smaller examples.

Many of the ideas underlying Bitcoin contracts were first described by Nick Szabó in his seminal paper,
[http://szabo.best.vwh.net/formalize.html Formalizing and Securing Relationships on Public Networks]. These pages were written by [mailto:mike@plan99.net Mike Hearn]. Contact him if you have an idea for a new type of contract. You can watch '''[https://www.youtube.com/watch?feature=player_embedded&v=mD4L7xDNCmA a video of a talk on contracts]''' that was presented at the Bitcoin 2012 conference in London.

==A warning about the mempool transaction replacement mechanism==

In places this page refers to the ability to use the nSequence field for transaction mempool replacement. This mechanism was disabled in [https://github.com/bitcoin/bitcoin/commit/05454818dc7ed92f577a1a1ef6798049f17a52e7#diff-118fcbaaba162ba17933c7893247df3aR522 2010], and more recently the code has been [https://github.com/bitcoin/bitcoin/commit/98c7c8fd1d3712e02be0e9f2eeca7e02aa54d197 removed completely], due to concerns over people using it to perform DoS attacks. Implementors should take this into account and try to create contract mechanisms that do not rely on mempool replacement if they wish to have their implementations work with current implementations. If Bitcoin changes in future to allow mempool replacement once again, this page will be updated.

==Theory==

Every [[transaction]] in Bitcoin has one or more inputs and outputs. Each input/output has a small, pure function associated with it called a [[script]]. Scripts can contain signatures over simplified forms of the transaction itself.

Every transaction can have a lock time associated with it. This allows the transaction to be pending and replaceable until an agreed-upon future time, specified either as a block index or as a timestamp (the same field is used for both, but values less than 500 million are interpreted as a block index). If a transaction's lock time has been reached, we say it is final.

Each transaction input has a sequence number. In a normal transaction that just moves value around, the sequence numbers are all UINT_MAX and the lock time is zero. If the lock time has not yet been reached, but all the sequence numbers are UINT_MAX, the transaction is also considered final. Sequence numbers can be used to issue new versions of a transaction without invalidating other inputs signatures, e.g., in the case where each input on a transaction comes from a different party, each input may start with a sequence number of zero, and those numbers can be incremented independently.

Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:

# SIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, ''are'' signed; it's only the scripts that are not. Intuitively, it means "I agree to put my money in, if everyone puts their money in and the outputs are this".
# SIGHASH_NONE: The outputs are not signed and can be anything. Use this to indicate "I agree to put my money in, as long as everyone puts their money in, but I don't care what's done with the output". This mode allows others to update the transaction by changing their inputs sequence numbers.
# SIGHASH_SINGLE: Like SIGHASH_NONE, the inputs are signed, but the sequence numbers are blanked, so others can create new versions of the transaction. However, the only output that is signed is the one at the same position as the input. Use this to indicate "I agree, as long as my output is what I want; I don't care about the others".

The SIGHASH_ANYONECANPAY modifier can be combined with the above three modes. When set, only that input is signed and the other inputs can be anything.

Scripts can contain the CHECKMULTISIG opcode. This opcode provides n-of-m checking: you provide multiple public keys, and specify the number of valid signatures that must be present. The number of signatures can be less than the number of public keys. An output can require two signatures to be spent by setting it to something like this:

2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY

There are two general patterns for safely creating contracts:

# Transactions are passed around outside of the P2P network, in partially-complete or invalid forms.
# Two transactions are used: one (the contract) is created and signed but not broadcast right away. Instead, the other transaction (the payment) is broadcast after the contract is agreed to lock in the money, and then the contract is broadcast.

This is to ensure that people always know what they are agreeing to.

Together, these features let us build interesting new financial tools on top of the block chain.

==Example 1: Providing a deposit==

Imagine that you open an account on a website (eg, a forum or wiki) and wish to establish your trustworthiness with the operators, but you don't have any pre-existing reputation to leverage. One solution is to buy trust by paying the website some money. But if at some point you close your account, you'd probably like that money back. You may not trust the site enough to give them a deposit that they are tempted to spend. Another risk is that the site might just disappear one day.

The goal is to prove that you made a sacrifice of some kind so the site knows you're not a spambot, but you don't want them to be able to spend the money. And if the operators disappear, you'd eventually like the coins back without needing anything from them.

We can solve this problem with a contract:

# The user and website send each other a newly-generated public key.
# The user creates transaction Tx1 (the payment) putting 10 BTC into an output that requires both user and website to sign, but does not broadcast it. They use the key from the previous step for the site.
# User sends the hash of Tx1 to the website.
# The website creates a transaction Tx2 (the contract). Tx2 spends Tx1 and pays it back to the user via the address he provided in the first step. Note that Tx1 requires two signatures, so this transaction can't be complete. nLockTime is set to some date in the future (eg, six months). The sequence number on the input is set to zero.
# Finally, the incomplete (half-signed) transaction is sent back to the user. The user checks that the contract is as expected - that the coins will eventually come back to him - but, unless things are changed, only after six months. Because the sequence number is zero, the contract can be amended in future if both parties agree. The script in the input isn't finished though; there are only zeros where the user's signature should be. He fixes that by signing the contract and putting the new signature in the appropriate spot.
# The user broadcasts Tx1, then broadcasts Tx2.

At this stage, the 10 BTC are in a state where neither the user nor the website can spend them independently. After six months, the contract will complete and the user will get the coins back, even if the website disappears.

What if the user wishes to close his account early? The website creates a new version of Tx2 with nLockTime set to zero and the input sequence number set to UINT_MAX, then he re-signs it. The site hands the tx back to the user, who signs it as well. The user then broadcasts the transaction, terminating the contract early and releasing the coins.

What if the six months is nearly up and the user wishes to keep his account? The same thing applies: the contract can be resigned with a newer nLockTime, a sequence number 1 higher than the previous and rebroadcast 2^32 times. No matter what happens, both parties must agree for the contract to change.

Obviously, if the user turns out to be abusive (i.e., a spammer), the website will not allow an early close of the contract. If too much abuse is getting through, the size of the deposit can be raised or the length of the contract can be increased.

==Example 2: Escrow and dispute mediation==

A buyer wants to trade with somebody he doesn't know or trust. In the common case where the transaction goes well, the client doesn't want any third parties involved. If something goes wrong though, he'd like a third party to decide who gets the money - perhaps a professional dispute mediation service. Note that this concept can apply to either buyer or seller. The mediator might request proof of postage from the merchant, for example.

In other words, one wants to lock up some coins so a third party has to agree in order for them to be spent:

# Agree with the merchant on a dispute mediator (e.g., ClearCoin).
# Ask the merchant for a public key (K1). Ask the mediator for a public key (K2). Create a new key for yourself (K3).
# Send the merchant K2. The merchant challenges the mediator with a random nonce. The mediator signs the nonce with the private form of K2, thus proving it really belongs to merchant.
# Create a transaction (Tx1) with an output script as follows and broadcast it:

2 <K1> <K2> <K3> 3 CHECKMULTISIGVERIFY

Now the coins are locked in such a way that they can only be spent by the following methods:

# Client and the merchant agree (either a successful trade, or merchant agrees to reimburse client without mediation)
# Client and the mediator agree (failed trade, mediator sides with client, like a charge-back)
# The mediator and the merchant agree (goods delivered, merchant gets client's coins despite the dispute)

When signing an input, the contents are set to the connected output. Thus, to redeem this transaction, the client creates a scriptSig containing zeros where the other signature should be, signs it, and then sets one of the slots to his new signature. The partially-complete transaction can then be sent to the merchant or mediator for the second signature.

==Example 3: Assurance contracts==

An [http://en.wikipedia.org/wiki/Assurance_contract assurance contract] is a way of funding the creation of a [http://www.auburn.edu/~johnspm/gloss/public_goods public good], that is, a good that, once created, anyone can benefit from for free. The standard example is a lighthouse: whilst everyone may agree that one should be built, it’s too expensive for an individual sailor to justify building one, given that it will also benefit all his competitors.

One solution is for everyone to pledge money towards the creation of the public good, such that the pledges are only committed if the total value of all pledges is above the cost of creation. If not enough people contribute, nobody has to pay anything.

Examples where Bitcoin is superior to traditional payment methods for assurance contract fundraising include applications where frequent, small pledges need to be made automatically, for instance internet radio station funding and [https://bitcointalk.org/index.php?topic=67255.msg788110#msg788110 web page translation]. Consider a browser extension that you send a bit of money to. It detects the current language of the page and broadcasts a pledge for a translation into your language to be prepared. If enough users with the extension land on the same page at the same time (eg, it was linked to from somewhere high traffic), then enough pledges are broadcast to trigger a payment to a company who prepares a high quality translation. When complete it automatically loads in your browser.

We can model this in Bitcoin as follows:

# An entrepreneur creates a new address and announces that the good will be created if at least 1000 BTC is raised. Anyone can contribute.
# Each party wishing to pledge creates a new transaction spending some of their coins to the announced address, but they do not broadcast it. The transaction is similar to a regular transaction except for three differences: Firstly, there cannot be any change. If you don’t have any outputs of the right size, you must create one first by spending to one of your own addresses. Secondly, the input script signature is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY. Finally, the output value is set to 1000 BTC. Note that this is not a valid transaction because the output value is larger than the input value.
# The transaction is uploaded to the entrepreneur's server, which saves it to disk and updates its count of how many coins have been pledged.
# Once the server has enough coins, it merges the separate transactions together into a new transaction. The new transaction has a single output that simply spends to the announced address - it is the same as the outputs on each contributed transaction. The inputs to the transaction are collected from the contributed pledges.
# The finished transaction is broadcast, sending the pledged coins to the announced address.

This scheme relies on several aspects of the protocol. The first is the SIGHASH flags used. SIGHASH_ALL is the default and means the entire contents of the transaction are signed, except for the input scripts. SIGHASH_ANYONECANPAY is an additional modifier that means the signature only covers the input it’s found in - the other inputs are not signed and thus can be anything.

By combining these flags together, we are able to create a signature that is valid even when other inputs are added, but breaks if the outputs or other properties of the transaction are changed.

The second aspect we exploit is the fact that a transaction in which the output values are larger than the input values is invalid (for obvious reasons). This means it’s safe to send the entrepreneur a transaction that spends such coins - it’s impossible for him to claim the coins unless he has other inputs that sum to the output value or more.

It's possible to create assurance contracts without using SIGHASH_ANYONECANPAY. Instead, a two step process is used in which pledges are collected without transactions, and once the total value is reached, a transaction with an input for each pledger is created and passed around until all signatures are collected. However, using SIGHASH_ANYONECANPAY and then merging is probably more convenient.

An assurance contract can be prepared for '''[[Funding network security|funding network security]]''' for the next block. In this way, mining can be funded even if block space is not scarce.

An elaboration of this concept is described by Tabarrok in his paper, [http://mason.gmu.edu/~atabarro/PrivateProvision.pdf “The private provision of public goods via dominant assurance contracts”]. In a dominant assurance contract, if a contract fails (not enough pledges within a set time window) the entrepreneur pays a fee to those who pledged so far. This type of contract attempts to arrange incentives such that taking part is always the right strategy. [[Dominant Assurance Contracts|A scheme for dominant assurance contracts]] in Bitcoin has been proposed.

==Example 4: Using external state==

Scripts are, by design, pure functions. They cannot poll external servers or import any state that may change as it would allow an attacker to outrun the block chain. What's more, the scripting language is extremely limited in what it can do. Fortunately, we can make transactions connected to the world in other ways.

Consider the example of an old man who wishes to give an inheritance to his grandson, either on the grandson's 18th birthday or when the man dies, whichever comes first.

To solve this, the man first sends the amount of the inheritance to himself so there is a single output of the right amount. Then he creates a transaction with a lock time of the grandson's 18th birthday that pays the coins to another key owned by the grandson, signs it, and gives it to him - but does not broadcast it. This takes care of the 18th birthday condition. If the date passes, the grandson broadcasts the transaction and claims the coins. He could do it before then, but it doesn't let him get the coins any earlier, and some nodes may choose to drop transactions in the memory pool with lock times far in the future.

The death condition is harder. As Bitcoin nodes cannot measure arbitrary conditions, we must rely on an ''oracle''. An oracle is a server that has a keypair, and signs transactions on request when a user-provided expression evaluates to true.

Here is an example. The man creates a transaction spending his output, and sets the output to:

<hash> OP_DROP 2 <sons pubkey> <oracle pubkey> CHECKMULTISIG

This is the oracle script. It has an unusual form - it pushes data to the stack then immediately deletes it again. The pubkey is published on the oracle's website and is well-known. The hash is set to be the hash of the user-provided expression stating that he has died, written in a form the oracle knows how to evaluate. For example, it could be the hash of the string:

if (has_died('john smith', born_on=1950/01/02)) return (10.0, 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp);

This little language is hypothetical, it'd be defined by the oracle and could be anything. The return value is an output: an amount of value and an address owned by the grandson.

Once more, the man creates this transaction but gives it directly to his grandson instead of broadcasting it. He also provides the expression that is hashed into the transaction and the name of the oracle that can unlock it.

It is used in the following algorithm:

# The oracle accepts a measurement request. The request contains the user-provided expression, a copy of the output script, and a partially complete transaction provided by the user. Everything in this transaction is finished except for the scriptSig, which contains just one signature (the grandson's) - not enough to unlock the output.
# The oracle checks the user-provided expression hashes to the value in the provided output script. If it doesn't, it returns an error.
# The oracle evaluates the expression. If the result is not the destination address of the output, it returns an error.
# Otherwise the oracle signs the transaction and returns the signature to the user. Note that when signing a Bitcoin transaction, the input script is set to the connected output script. The reason is that when OP_CHECKSIG runs, the script containing the opcode is put in the input being evaluated, _not_ the script containing the signature itself. The oracle has never seen the full output it is being asked to sign, but it doesn't have to. It knows the output script, its own public key, and the hash of the user-provided expression, which is everything it needs to check the output script and finish the transaction.
# The user accepts the new signature, inserts it into the scriptSig and broadcasts the transaction.

If, and only if, the oracle agrees that the man is dead, the grandson can broadcast the two transactions (the contract and the claim) and take the coins.

Oracles can potentially evaluate anything, yet the output script form in the block chain can always be the same. Consider the following possibilities:

today() == 2011/09/25 && exchange_rate(mtgoxUSD) >= 12.5 && exchange_rate(mtgoxUSD) <= 13.5
Require exchange rate to be between two values on a given date

google_results_count(site:www.google.com/hostednews 'Mike Hearn' olympic gold medal) > 0
A bet on me doing something that I will never actually do

// Choose between one of two winners of a bet on the outcome of the Eurovision song contest.
if (eurovision_winner() == 'Azerbaijan')
return 1Lj9udBVDwptFffGSJSC2sohCfudQgSTPD;
else
return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;

The conditions that control whether the oracle signs can be arbitrarily complex, but the block chain never needs to contain more than a single hash.

The [http://earlytemple.com/ ''Early Temple'' project] has implemented a prototype of an oracle that looks for a key phrase in a web page.

===Trust minimization: challenges===

There are various ways to reduce the level of required trust in the oracle.

Going back to our first example, the oracle has not seen the transaction the grandson is trying to unlock, as it was never broadcast, thus, it cannot hold the grandson to ransom because it does not know whether the transaction it's signing for even exists. People can, and should, regularly '''challenge''' the oracle in an automated fashion to ensure it always outputs what is expected. The challenges can be done without spending any coins because the tx to be signed can be invalid (ie, connected to transactions that don't exist). The oracle has no way to know whether a request to be signed is random or real. How to challenge the oracle with conditions that are not yet true is however an open research question.

===Trust minimization: multiple independent oracles===

The number of keys in the CHECKMULTISIG can be increased to allow for '''n-of-m''' oracles if need be. Of course, it is vital to check that the oracles really are independent and not in collusion. An implementation of such a system, and explanation was published in the '''[http://github.com/orisi/wiki/wiki/Orisi-White-Paper Orisi whitepaper]'''.

The idea, in short, is that independent oracles could be run by a set of trustworthy independent actors. Contract participants would first settle upon a set of oracles they both are comfortable using - for example by trusting [http://oracles.lo/ a dedicated site] - and then sign a contract requiring most of the oracles signatures to resolve.

One of the interesting properties of such a system is that it can possibly implement very complicated sets of scripts and external inputs, while being based on a set of standard bitcoin scripts. Another property is that the oracles can possibly replace each ones by forwarding the funds to new [https://bitcoinmagazine.com/11108/multisig-future-bitcoin/ multisig addresses] when they discover that one of the oracles is faulty/corrupted. Finally, such oracles could be used to implement sidechains without dedicated blockchain opcodes.

===Trust minimization: trusted hardware===

Using commodity hardware, you can use '''trusted computing''' in the form of Intel TXT or the AMD equivalent (SKINIT) to set up a sealed hardware environment and then use the TPM chip to attest that fact to a third party. That third party can verify the hardware was in the required state. Defeating this requires someone to be able to interfere with the execution of a program that may run entirely on the CPU, even in extreme cases without any data traversing the memory bus (you can run entirely using on-die cache if the program is small enough).

===Trust minimization: Amazon AWS oracles===

Finally, perhaps the most practical approach currently is to use Amazon Web Services. As of November 2013, the closest we have to a working oracle is [https://bitcointalk.org/index.php?topic=301538.0 this recipe for creating a trusted computing environment using AWS], built in support of [https://bitcointalk.org/index.php?topic=173220.0 this project for doing selective SSL logging and decryption]. The idea is that an oracle, which can be proven trustworthy using the Amazon APIs with Amazon as the root of trust, records encrypted SSL sessions to an online banking interface in such a way that later if there is a dispute about a person-to-person exchange, the logs can be decrypted and the dispute settled.

==Example 5: Trading across chains==

The Bitcoin technology can be adapted to create [[Alternative chain|multiple, independent currencies]]. NameCoin is an example of one such currency that operates under a slightly different set of rules, and can also be used to rent names in a namespace. Currencies that implement the same ideas as Bitcoin can be traded freely against each other with limited trust.

For example, imagine a consortium of companies that issue EURcoins, a crypto-currency that is backed 1:1 by deposits in the consortium's bank accounts. Such a currency would have a different set of tradeoffs to Bitcoin: more centralized, but without FX risk. People might wish to trade Bitcoins for EURcoins back and forth, with the companies only getting involved when cashing in/out of the regular banking system.

To implement this, a [https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949 protocol proposed by TierNolan] can be used:

# Party 'A' generates some random data, x (the secret).
# Party 'A' generates Tx1 (the payment) containing an output with the chain-trade script in it. See below for this script and a discussion of it. It allows coin release either by signing with the two keys (key 'A' and key 'B') or with (secret 'x', key 'B'). This transaction is not broadcast. The chain release script contains hashes, not the actual secrets themselves.
# Party 'A' generates Tx2 (the contract), which spends Tx1 and has an output going back to key 'A'. It has a lock time in the future and the input has a sequence number of zero, so it can be replaced. 'A' signs Tx2 and sends it to 'B', who also signs it and sends it back.
# 'A' broadcasts Tx1 and Tx2. Party 'B' can now see the coins but cannot spend them because it does not have an output going to him, and the tx is not finalized anyway.
# 'B' performs the same scheme in reverse on the alternative chain. The lock time for 'B' should be much larger than the lock time for 'A'. Both sides of the trade are now pending but incomplete.
# Since 'A' knows the secret, 'A' can claim his coins immediately. However, 'A', in the process of claiming his coin, reveals the secret 'x' to 'B', who then uses it to finish the other side of the trade with ('x', key 'B').

This protocol makes it feasible to do trades automatically in an entirely peer-to-peer manner, which should ensure good liquidity.

The chain-trade script could look like this:

IF
2 <key A> <key B> 2 CHECKMULTISIGVERIFY
ELSE
<key B> CHECKSIGVERIFY SHA256 <hash of secret x> EQUALVERIFY
ENDIF

The contract input script looks like either:

<sig A> <sig B> 1

or

<secret x> <sig B> 0

i.e., the first data element selects which phase is being used.

See [[Atomic cross-chain trading]] for details.

Note that whilst EURcoins is a natural idea, there are other ways to implement peer-to-peer currency exchange (Bitcoin to fiat and vice versa), see the [[Ripple currency exchange]] article for more information.

Sergio Demian-Lerner proposed [https://bitcointalk.org/index.php?topic=91843.0 P2PTradeX], a solution requiring the validation rules for one blockchain to be effectively encoded into the validation rules for the other.

==Example 6: Pay-for-proof contracts: buying a solution to any pure function==

In example 4, we saw how to make payments conditional on the output of some arbitrary program. Those programs are very powerful and can do anything a regular program can do, like fetching web pages. The downside is that a third party is required (an oracle). Although there are techniques that can help reduce the trust needed in the oracle, none can reduce it to zero.

For a restricted class of programs, pure functions, new cryptographic techniques are starting to become available that can actually reduce the trust needed all the way to zero with no third parties. These programs cannot perform any I/O, but in many cases this restriction turns out to be unimportant or can be worked around in other ways, like by giving the program a signed/timestamped document as an input instead of having the program download it.

Gregory Maxwell has invented a protocol for doing this, which you can read about here: [[Zero Knowledge Contingent Payment]]

==Example 7: Rapidly-adjusted (micro)payments to a pre-determined party==

Bitcoin transactions are very cheap relative to traditional payment systems, but still have a cost due to the need for it to be mined and stored. There are some cases in which you want to rapidly and cheaply adjust the amount of money sent to a particular recipient without incurring the cost of a broadcast transaction.

For example, consider an untrusted internet access point, like a WiFi hotspot in a cafe you never visited before. You'd like to pay 0.001 BTC per 10 kilobytes of usage, without opening an account with the cafe. A zero-trust solution means it could be fully automatic, so you could just pre-allocate a budget on your phone's mobile wallet at the start of the month, and then your device automatically negotiates and pays for internet access on demand. The cafe also wants to allow anyone to pay them without the fear of being ripped off.

To do this, the following protocol can be used. This protocol relies upon a '''different''' behavior of nLockTime to the original design. Starting around 2013 time-locked transactions were made non standard and no longer enter the memory pool, thus cannot be broadcast before the timelock expires. When the behaviour of nLockTime is restored to the original design from Satoshi, a variant of this protocol is required which is discussed below.

We define the client to be the party sending value, and the server to be the party receiving it. This is written from the clients perspective.

# Create a public key (K1). Request a public key from the server (K2).
# Create and sign but do not broadcast a transaction (T1) that sets up a payment of (for example) 10 BTC to an output requiring both the server's private key and one of your own to be used. A good way to do this is use OP_CHECKMULTISIG. The value to be used is chosen as an efficiency tradeoff.
# Create a refund transaction (T2) that is connected to the output of T1 which sends all the money back to yourself. It has a time lock set for some time in the future, for instance a few hours. Don't sign it, and provide the unsigned transaction to the server. By convention, the output script is "2 K1 K2 2 CHECKMULTISIG"
# The server signs T2 using its private key associated with K2 and returns the signature to the client. Note that it has not seen T1 at this point, just the hash (which is in the unsigned T2).
# The client verifies the servers signature is correct and aborts if not.
# The client signs T1 and passes the signature to the server, which now broadcasts the transaction (either party can do this if they both have connectivity). This locks in the money.
# The client then creates a new transaction, T3, which connects to T1 like the refund transaction does and has two outputs. One goes to K1 and the other goes to K2. It starts out with all value allocated to the first output (K1), ie, it does the same thing as the refund transaction but is not time locked. The client signs T3 and provides the transaction and signature to the server.
# The server verifies the output to itself is of the expected size and verifies the client's provided signature is correct.
# When the client wishes to pay the server, it adjusts its copy of T3 to allocate more value to the server's output and less to its own. It then re-signs the new T3 and sends the signature to the server. It does not have to send the whole transaction, just the signature and the amount to increment by is sufficient. The server adjusts its copy of T3 to match the new amounts, verifies the signature and continues.

This continues until the session ends, or the 1-day period is getting close to expiry. The AP then signs and broadcasts the last transaction it saw, allocating the final amount to itself. The refund transaction is needed to handle the case where the server disappears or halts at any point, leaving the allocated value in limbo. If this happens then once the time lock has expired the client can broadcast the refund transaction and get back all the money.

This protocol has [https://code.google.com/p/bitcoinj/wiki/WorkingWithMicropayments been implemented in bitcoinj].

The lock time and sequence numbers avoid an attack in which the AP provides connectivity, and then the user [[double-spending|double-spends]] the output back to themselves using the first version of TX2, thus preventing the cafe from claiming the bill. If the user does try this, the TX won't be included right away, giving the access point a window of time in which it can observe the TX broadcast, and then broadcast the last version it saw, overriding the user's attempted double-spend.

The latter protocol that relies on transaction replacement is more flexible because it allows the value allocated to go down as well as up during the lifetime of the channel as long as the client receives signatures from the server, but for many use cases this functionality is not required. Replacement also allows for more complex configurations of channels that involve more than two parties. Elaboration on such use cases is a left as an exercise for the reader.

==Example 8: Multi-party decentralised lotteries==

Using some of the techniques from example 6 and some very advanced scripting, it becomes possible to build a multi-party lottery with no operator. The exact protocol used is explained in the paper [http://eprint.iacr.org/2013/784 "Secure multiparty computations on Bitcoin"]. A shorter explanation of how it works may be added to this wiki at some point in the future.

==See Also==

* [[Script]]

[[Category:Technical]]

Fallback Nodes

2015-09-03T04:19:30Z

BlueMatt: /* Tor nodes */

This is a list of nodes which are considered reliable.

== How to use this list ==

=== Connect to nodes ===

You can connect to these nodes with the ''-addnode=ip'' switch instead of the usual node harvesting process (through IRC or via the embedded nodelist). You can connect to more than one node by using ''-addnode=ip'' more than once. It is usually a good idea to connect to more than one of these nodes.

==== Nodes without a fixed ip ====

If the node IP is not fixed (see "Fixed" column), you will have to resolve the node's name (first column) each time the IP changes. Some nodes may have their ip change once a day, some others once a month, and some others may stay on the same IP for years. Still, as long as the IP is not fixed, there is no guarantee it will stay the same.

In order to enable hostname lookups for the ''-addnode'' and ''-connect'' parameters, you must additionally provide the ''-dns'' parameter. Example:
bitcoind -dns -addnode=bitcoin.es

Versions prior to 0.3.22 do not support hostnames to the ''-addnode'' parameter, so you must do the resolving part for it. For example on linux:
bitcoind -addnode=$(dig +short bitcoin.es)

=== IP Transactions ===

[[Bitcoin Core]] versions prior to 0.8.0 also could send [[IP Transactions]] to these nodes. If you included your bitcoin address in the "message" field, you might have had your coins back.

=== Tor network ===

To use Bitcoin-Qt over Tor hidden services, in a terminal/console enter:
bitcoin-qt -proxy=127.0.0.1:9050 -onlynet=tor

To use Bitcoin with one specific Tor node, run
bitcoin-qt -proxy=127.0.0.1:9050 -connect=abcde.onion
, where abcde.onion needs to be substituted with one of the [[Fallback_Nodes#Tor_nodes|Tor nodes below]]. These parameters can be added to [[Running_Bitcoin#Bitcoin.conf_Configuration_File|bitcoin.conf]] to make them permanent.

You can find detailed information on running clients and hidden services within Tor in the [https://github.com/bitcoin/bitcoin/blob/master/doc/tor.md documentation].

== Nodes list ==

=== IPv4 Nodes ===
{|class="wikitable sortable"
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-

|-
| node.bitcoin.xxx || www.BitCoin.xxx || 66.228.49.201 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || 2014-08-28 || Yes
|-
| bitcoin.coinprism.com || [[Coinprism]] || 137.116.225.142 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || 2014-04-26 || Yes
|-
|-
| btcnode1.evolyn.net || Evolyn || 85.214.251.25 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || 2014-01-26 || Yes
|-
| InductiveSoul.US || [[User:Inductivesoul|Inductive Soul]] || 67.186.224.85 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || 2013-11-13 || Yes
|-
| archivum.info || Ferraro Ltd.|| 88.198.58.172 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes
|-
| 62.75.216.13 || exMULTI, Inc. || 62.75.216.13 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No
|-
| 69.64.34.118 || exMULTI, Inc. || 69.64.34.118 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No
|-
| 79.160.221.140 || K-Norway || 79.160.221.140 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| netzbasis.de || unknown3 || 81.169.129.25 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| btc.turboadmin.com || osmosis || 98.143.152.14 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No
|-
| fallback.bitcoin.zhoutong.com || Zhou Tong || 117.121.241.140 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No
|-
| bauhaus.csail.mit.edu || imsaguy || 128.30.96.44 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| jun.dashjr.org || Luke-Jr || 173.242.112.53 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || ||
|-
| cheaperinbitcoins.com || Xenland/Shane || 184.154.36.82 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| django.webflows.fr || unknown2 || 188.165.213.169 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| 204.9.55.71 || toasty || 204.9.55.71 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| btcnode.novit.ro || ovidiusoft - novit.ro || 93.187.142.114 || {{Table Value No}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| porgressbar.sk || progressbar hackerspace || 91.210.181.21 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes
|-
| faucet.bitcoin.st || bitcoin street || 64.27.57.225 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes
|-
| bitcoin.securepayment.cc || SecurePayment CC || 63.247.147.163 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes
|-
| x.jine.se || jine || 213.112.48.166 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes
|-
| www.dcscdn.com || [[User:Danw12|Danw12]] || 199.115.228.181 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || ||
|-
| ns2.dcscdn.com || [[User:Danw12|Danw12]] || 199.115.228.182 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || ||
|-
| coin.soul-dev.com || Soul-Dev || || || {{Fallback Nodes/Node Up}} || ||
|-
| messier.bzfx.net || BZFX/[[User:A Meteorite|A Meteorite]] || 91.121.205.50 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || ||
|-
| btcnode1.bitgroup.cc || BitGroup || 198.211.116.191 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes
|-
| btcnode2.bitgroup.cc || BitGroup || 162.243.120.138 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes
|-
| btcnode3.bitgroup.cc || BitGroup || 95.85.8.237 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes
|-
| btcnode.xiro.co || Xiro Labs || 91.121.108.61 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || No
|-
| murder.xf-liam.com || [[User:liamwli|Liam W]] || 162.245.217.119 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || No
|-
| bitcoin.bitdonut.co || James Hartig
|-
| coinno.de || jaknam
|-
| 82.165.44.44 || anonymous
|-
| bitcoin1.dassori.me || gdassori
|-
| bitcoin2.dassori.me || gdassori
|-
| blockchainnode.meulie.net || [[User:Evert|Evert]]
|-
| fullnode.fybsg.com || Nagato
|-
| n.bitcoin-fr.io || [[User:Arthur|Arthur]] || 62.210.66.227

|}

=== IPv6 Nodes ===
{|class="wikitable sortable"
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-

| InductiveSoul.US || [[User:Inductivesoul|Inductive Soul]] || 2601:7:6680:2ac:4d29:40ff:7513:fcc7 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || 11-13-2013 (MDY) || Yes
|-
| caffeinator.net || [[User:Atrophy|Atrophy]] || || || {{Fallback Nodes/Node Up}} || 2013-05-10 ||
|-
| 2001:470:8:2e1::40 || ? || 2001:470:8:2e1::40 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| x.jine.se || jine || 213.112.52.246 || {{Table Value No}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| messier.bzfx.net || BZFX/[[User:A Meteorite|A Meteorite]] || 2001:41d0:1:d632::1 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || ||
|-
| murder.xf-liam.com || [[User:liamwli|Liam W]] || 2602:ffc5::ffc5:56b6 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || No
|-
| bitcoin.bitdonut.co || James Hartig
|-
| n.bitcoin-fr.io || [[User:Arthur|Arthur]] || 2001:bc8:c087:2001::1

|}

=== Tor nodes ===

This entire list was last checked on 2015-02-22.

{|class="wikitable sortable"
! Hostname !! Owner !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-
| nkf5e6b7pl4jfd4a.onion || BlueMatt || Up || 2015-09-02 || No
|-
| hhiv5pnxenvbf4am.onion || ? || Up || 2015-03-17 || No
|-
| bpdlwholl7rnkrkw.onion || kenansulayman || Up || 2015-03-17 || ?
|-
| bk5ejfe56xakvtkk.onion || dserrano5 || Up || 2015-03-17 || No
|-
| wxvp2d4rspn7tqyu.onion || lunokhod || Up || 2015-08-17 || No
|-
| vso3r6cmjoomhhgg.onion || echelon || Down || 2015-03-17 || Yes
|-
| e3tn727fywnioxrc.onion || Zedd || Down || 2015-03-17 || No
|-
| pqosrh6wfaucet32.onion || bitcoin street || Down || 2015-03-17 || No
|-
| r4de4zf4lyniu4mx.onion:8444 || ? || Down || 2015-01-20 || ?
|-
| zy3kdqowmrb7xm7h.onion || Tril || Down || 2015-01-20 || No
|-
| smith4mfhwcq7x3b.onion || Smithtrader || Down || 2014-11-22 || ?
|-
| i2r5tbaizb75h26f.onion || TorDude || Down || 2014-07-24 || No
|-
| btcnet3utgzyz2bf.onion || anonymous || Down || 2014-07-24 || Yes
|-
| kjy2eqzk4zwi5zd3.onion || sipa || Down || 2014-07-24 || No
|-
| tsyvzsqwa2kkf6b2.onion || TorDude || Down || 2014-05-19 || No
|-
| igpdszqrbqjhak5z.onion || anonymous || Down || 2014-05-15 || ?
|-
| evolynhit7shzeet.onion || Evolyn || Down || 2014-05-15 || Yes
|-
| z55v4ostefnwfy32.onion || Tril || Down || 2014-04-09 || No
|-
| bitcoin2u5jnjzzz.onion || anonymous || Down || 2014-01-27 || Yes
|-
| btc4ulpftizx5b72.onion || TorNode || Down || 2013-05-10 || Yes
|-
| yyl3ipdmyjkfypmx.onion || redemerald || Down || 2013-05-10 || Yes
|-
| siqdznszjf4e6v5j.onion || Tuxavant || Down || 2013-05-10 || ?
|-
| 7hxvg2lvr2ashzli.onion || Tuxavant || Down || 2013-05-10 || ?
|-
| x3danbeag2kyx644.onion || redemerald || Down || 2013-01-04 || Yes
|-
| 6hgmaxwellgpv2oe.onion || Gmaxwell || Down || 2012-07-01 || No
|-
| bitcoinprwwpuinm.onion:8333 || ? || Down || 2012-06-26 || ?
|-
| mutqcuh7hwxmhx3k.onion || Xirafe || Down || 2012-06-23 || ?
|-
| sjdntqu5roj4q6lo.onion || torservers || Down || 2012-05-19 || ?
|-
| bitcoin2bkgm3fke.onion || ? || Down || 2012-05-19 || Yes
|-
| ceeji4qpfs3ms3zc.onion || creepa
|}

== Adding a node ==

Before adding yourself as a fallback node, you should be sure your node will stay online for a long time. If a node is offline for more than 24 hours it will be removed from the list.

To add a node in this list, you just need the ip/hostname and your name, the other fields will be filled automatically. Insert the following lines before the <tt>END NODELIST</tt> line:

<nowiki>|-
| ip || your name</nowiki>

==See Also==

* [[Network|Bitcoin Network]]
* [http://nodes.bitcoin.st Fallback Nodes] List of longest running Bitcoin Nodes listed by Country.
* [https://getaddr.bitnodes.io/ Bitnodes project]
* [https://blockchain.info/connected-nodes Recently connected nodes at blockchain.info]

{{Bitcoin Core documentation}}

Protocol documentation

2015-07-09T04:46:49Z

BlueMatt: version is signed

This page ''describes'' the behavior of the [[Original Bitcoin client|reference client]]. The Bitcoin protocol is specified by the behavior of the reference client, not by this page. In particular, while this page is quite complete in describing the network protocol, it does not attempt to list all of the rules for block or transaction validity.

Type names used in this documentation are from the C99 standard.

For protocol used in mining, see [[getblocktemplate]].

==Common standards==

=== Hashes ===

Usually, when a hash is computed within bitcoin, it is computed twice. Most of the time [http://en.wikipedia.org/wiki/SHA-2 SHA-256] hashes are used, however [http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160] is also used when a shorter hash is desirable (for example when creating a bitcoin address).

Example of double-SHA-256 encoding of string "hello":

hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)

For bitcoin addresses (RIPEMD-160) this would give:

hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round is sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (with ripemd-160)

=== Merkle Trees ===

Merkle trees are binary trees of hashes. Merkle trees in bitcoin use a '''double''' SHA-256, the SHA-256 hash of the SHA-256 hash of something.

If, when forming a row in the tree (other than the root of the tree), it would have an odd number of elements, the final double-hash is duplicated to ensure that the row has an even number of hashes.

First form the bottom row of the tree with the ordered double-SHA-256 hashes of the byte streams of the transactions in the block.

Then the row above it consists of half that number of hashes. Each entry is the double-SHA-256 of the 64-byte concatenation of the corresponding two hashes below it in the tree.

This procedure repeats recursively until we reach a row consisting of just a single double-hash. This is the '''Merkle root''' of the tree.

For example, imagine a block with three transactions ''a'', ''b'' and ''c''. The Merkle tree is:

d1 = dhash(a)
d2 = dhash(b)
d3 = dhash(c)
d4 = dhash(c) # a, b, c are 3. that's an odd number, so we take the c twice

d5 = dhash(d1 concat d2)
d6 = dhash(d3 concat d4)

d7 = dhash(d5 concat d6)

where

dhash(a) = sha256(sha256(a))

''d7'' is the Merkle root of the 3 transactions in this block.

Note: Hashes in Merkle Tree displayed in the [[Block Explorer]] are of little-endian notation. For some implementations and [http://www.fileformat.info/tool/hash.htm calculations], the bits need to be reversed before they are hashed, and again after the hashing operation.

=== Signatures ===

Bitcoin uses [http://en.wikipedia.org/wiki/Elliptic_curve_cryptography Elliptic Curve] [http://en.wikipedia.org/wiki/Digital_Signature_Algorithm Digital Signature Algorithm] ([http://en.wikipedia.org/wiki/Elliptic_Curve_DSA ECDSA]) to sign transactions.

For [[ECDSA]] the secp256k1 curve from http://www.secg.org/collateral/sec2_final.pdf is used.

Public keys (in scripts) are given as 04 <x> <y> where ''x'' and ''y'' are 32 byte big-endian integers representing the coordinates of a point on the curve or in compressed form given as <sign> <x> where <sign> is 0x02 if ''y'' is even and 0x03 if ''y'' is odd.

Signatures use [http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER encoding] to pack the ''r'' and ''s'' components into a single byte stream (this is also what OpenSSL produces by default).

=== Transaction Verification ===
Transactions are cryptographically signed records that reassign ownership of Bitcoins to new addresses. Transactions have ''inputs'' - records which reference the funds from other previous transactions - and ''outputs'' - records which determine the new owner of the transferred Bitcoins, and which will be referenced as inputs in future transactions as those funds are respent.

Each ''input'' must have a cryptographic digital signature that unlocks the funds from the prior transaction. Only the person possessing the appropriate [[private key]] is able to create a satisfactory signature; this in effect ensures that funds can only be spent by their owners.

Each ''output'' determines which Bitcoin address (or other criteria, see [[Script]]) is the recipient of the funds.

In a transaction, the sum of all inputs must be equal to or greater than the sum of all outputs. If the inputs exceed the outputs, the difference is considered a [[transaction fee]], and is redeemable by whoever first includes the transaction into the block chain.

A special kind of transaction, called a [[coinbase transaction]], has no inputs. It is created by [[miners]], and there is one coinbase transaction per block. Because each block comes with a reward of newly created Bitcoins (e.g. 50 BTC for the first 210,000 blocks), the first transaction of a block is, with few exceptions, the transaction that grants those coins to their recipient (the miner). In addition to the newly created Bitcoins, the coinbase transaction is also used for assigning the recipient of any transaction fees that were paid within the other transactions being included in the same block. The coinbase transaction can assign the entire reward to a single Bitcoin address, or split it in portions among multiple addresses, just like any other transaction. Coinbase transactions always contain outputs totalling the sum of the block reward plus all transaction fees collected from the other transactions in the same block.

The [[coinbase transaction]] in block zero cannot be spent. This is due to a quirk of the reference client implementation that would open the potential for a block chain fork if some nodes accepted the spend and others did not<ref>[http://bitcointalk.org/index.php?topic=119645.msg1288552#msg1288552 Block 0 Network Fork]</ref>.

Most Bitcoin outputs encumber the newly transferred coins with a single ECDSA private key. The actual record saved with inputs and outputs isn't necessarily a key, but a ''script''. Bitcoin uses an interpreted scripting system to determine whether an output's criteria have been satisfied, with which more complex operations are possible, such as outputs that require two ECDSA signatures, or two-of-three-signature schemes. An output that references a single Bitcoin address is a ''typical'' output; an output actually contains this information in the form of a script that requires a single ECDSA signature (see [[OP_CHECKSIG]]). The output script specifies what must be provided to unlock the funds later, and when the time comes in the future to spend the transaction in another input, that input must provide all of the thing(s) that satisfy the requirements defined by the original output script.

=== Addresses ===

A bitcoin address is in fact the hash of a ECDSA public key, computed this way:

Version = 1 byte of 0 (zero); on the test network, this is 1 byte of 111
Key hash = Version concatenated with RIPEMD-160(SHA-256(public key))
Checksum = 1st 4 bytes of SHA-256(SHA-256(Key hash))
Bitcoin Address = Base58Encode(Key hash concatenated with Checksum)

The Base58 encoding used is home made, and has some differences. Especially, leading zeroes are kept as single zeroes when conversion happens.

== Common structures ==

Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.

=== Message structure ===

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || magic || uint32_t || Magic value indicating message origin network, and used to seek to next message when stream state is unknown
|-
| 12 || command || char[12] || ASCII string identifying the packet content, NULL padded (non-NULL padding results in packet rejected)
|-
| 4 || length || uint32_t || Length of payload in number of bytes
|-
| 4 || checksum || uint32_t || First 4 bytes of sha256(sha256(payload))
|-
| ? || payload || uchar[] || The actual data
|}

Known magic values:

{|class="wikitable"
! Network !! Magic value !! Sent over wire as
|-
| main || 0xD9B4BEF9 || F9 BE B4 D9
|-
| testnet || 0xDAB5BFFA || FA BF B5 DA
|-
| testnet3 || 0x0709110B || 0B 11 09 07
|-
| namecoin || 0xFEB4BEF9 || F9 BE B4 FE
|}

=== Variable length integer ===

Integer can be encoded depending on the represented value to save space.
Variable length integers always precede an array/vector of a type of data that may vary in length.
Longer numbers are encoded in little endian.

{|class="wikitable"
! Value !! Storage length !! Format
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd followed by the length as uint16_t
|-
| <= 0xffffffff || 5 || 0xfe followed by the length as uint32_t
|-
| - || 9 || 0xff followed by the length as uint64_t
|}

If you're reading the Satoshi client code (BitcoinQT) it refers to this as a "CompactSize". Modern BitcoinQT has also CVarInt class which implements even more compact integer for the purpose of local storage (which is incompatible with "CompactSize" described here). CVarInt is not a part of the protocol.

=== Variable length string ===

Variable length string can be stored using a variable length integer followed by the string itself.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || length || [[Protocol_documentation#Variable_length_integer|var_int]] || Length of the string
|-
| ? || string || char[] || The string itself (can be empty)
|}

=== Network address ===

When a network address is needed somewhere, this structure is used. Network addresses are not prefixed with a timestamp in the version message.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || time || uint32 || the Time (version >= 31402). '''Not present in version message.'''
|-
| 8 || services || uint64_t || same service(s) listed in [[#version|version]]
|-
| 16 || IPv6/4 || char[16] || IPv6 address. Network byte order. The original client only supported IPv4 and only read the last 4 bytes to get the IPv4 address. However, the IPv4 address is written into the message as a 16 byte [http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4-mapped IPv6 address]
(12 bytes ''00 00 00 00 00 00 00 00 00 00 FF FF'', followed by the 4 bytes of the IPv4 address).
|-
| 2 || port || uint16_t || port number, network byte order
|}

Hexdump example of Network address structure

<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK: see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:a00:1 or IPv4: 10.0.0.1
20 8D - Port 8333
</pre>

=== Inventory Vectors ===

Inventory vectors are used for notifying other nodes about objects they have or data which is being requested.

Inventory vectors consist of the following data format:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || Identifies the object type linked to this inventory
|-
| 32 || hash || char[32] || Hash of the object
|}

The object type is currently defined as one of the following possibilities:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || ERROR || Any data of with this number may be ignored
|-
| 1 || MSG_TX || Hash is related to a transaction
|-
| 2 || MSG_BLOCK || Hash is related to a data block
|-
| 3 || MSG_FILTERED_BLOCK || Hash of a block header; identical to MSG_BLOCK. When used in a getdata message, this indicates the reply should be a merkleblock message rather than a block message; this only works if a bloom filter has been set.
|}

Other Data Type values are considered reserved for future implementations.

=== Block Headers ===

Block headers are sent in a headers packet in response to a getheaders message.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || int32_t || Block version information (note, this is signed)
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Will overflow in 2106<ref>http://en.wikipedia.org/wiki/Unix_time#Notable.C2.A0events.C2.A0in.C2.A0Unix.C2.A0time</ref>)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| 1 || txn_count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of transaction entries, this value is always 0
|}

== Message types ==

=== version ===

When a node creates an outgoing connection, it will immediately [[Version Handshake|advertise]] its version. The remote node will respond with its version. No further communication is possible until both peers have exchanged their version.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || int32_t || Identifies protocol version being used by the node
|-
| 8 || services || uint64_t || bitfield of features to be enabled for this connection
|-
| 8 || timestamp || int64_t || standard UNIX timestamp in seconds
|-
| 26 || addr_recv || [[#Network address|net_addr]] || The network address of the node receiving this message
|-
|colspan="4"| version >= 106
|-
| 26 || addr_from || [[#Network address|net_addr]] || The network address of the node emitting this message
|-
| 8 || nonce || uint64_t || Node random nonce, randomly generated every time a version packet is sent. This nonce is used to detect connections to self.
|-
| ? || user_agent || [[#Variable length string|var_str]] || [https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki User Agent] (0x00 if string is 0 bytes long)
|-
| 4 || start_height || int32_t || The last block received by the emitting node
|-
| 1 || relay || bool || Whether the remote peer should announce relayed transactions or not, see [https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki BIP 0037], since version >= 70001
|}

A "verack" packet shall be sent if the version packet was accepted.

The following services are currently assigned:

{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers.
|}

Hexdump example of version message (OBSOLETE EXAMPLE: This example lacks a checksum and user-agent):
<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 20 8D 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command
55 00 00 00 - Payload is 85 bytes long
- No checksum in version message until 20 February 2012. See https://bitcointalk.org/index.php?topic=55852.0
Version message:
9C 7C 00 00 - 31900 (version 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 20 8D - Recipient address info - see Network Address
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - Sender address info - see Network Address
DD 9D 20 2C 3A B4 57 13 - Node random unique ID
00 - "" sub-version string (string is 0 bytes long)
55 81 01 00 - Last block sending node has is block #98645
</pre>

And here's a modern (60002) protocol version client advertising itself to a local peer...

Newer protocol includes the checksum now, this is from a mainline (satoshi) client during
an outgoing connection to another local client, notice that it does not fill out the
address information at all when the source or destination is "unroutable".

<pre>

0000 f9 be b4 d9 76 65 72 73 69 6f 6e 00 00 00 00 00 ....version.....
0010 64 00 00 00 35 8d 49 32 62 ea 00 00 01 00 00 00 d...5.I2b.......
0020 00 00 00 00 11 b2 d0 50 00 00 00 00 01 00 00 00 .......P........
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ................
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 00 00 00 00 ff ff 00 00 00 00 00 00 ................
0060 3b 2e b3 5d 8c e6 17 65 0f 2f 53 61 74 6f 73 68 ;..]...e./Satosh
0070 69 3a 30 2e 37 2e 32 2f c0 3e 03 00 i:0.7.2/.>..

Message Header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command
64 00 00 00 - Payload is 100 bytes long
3B 64 8D 5A - payload checksum

Version message:
62 EA 00 00 - 60002 (protocol version 60002)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
11 B2 D0 50 00 00 00 00 - Tue Dec 18 10:12:33 PST 2012
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Recipient address info - see Network Address
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Sender address info - see Network Address
3B 2E B3 5D 8C E6 17 65 - Node ID
0F 2F 53 61 74 6F 73 68 69 3A 30 2E 37 2E 32 2F - "/Satoshi:0.7.2/" sub-version string (string is 15 bytes long)
C0 3E 03 00 - Last block sending node has is block #212672
</pre>

=== verack ===

The ''verack'' message is sent in reply to ''[[#version|version]]''. This message consists of only a [[#Message structure|message header]] with the command string "verack".

Hexdump of the verack message:

<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 5D F6 E0 E2 ........

Message header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 61 63 6B 00 00 00 00 00 00 - "verack" command
00 00 00 00 - Payload is 0 bytes long
5D F6 E0 E2 - Checksum
</pre>

=== addr ===

Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours

Payload:
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of address entries (max: 1000)
|-
| 30x? || addr_list || (uint32_t + [[#Network address|net_addr]])[] || Address of other nodes on the network. version < 209 will only read the first one. The uint32_t is a timestamp (see note below).
|}

'''Note''': Starting version 31402, addresses are prefixed with a timestamp. If no timestamp is present, the addresses should not be relayed to other peers, unless it is indeed confirmed they are up.

Hexdump example of ''addr'' message:
<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 ED 52 39 9B 01 E2 15 10 4D 01 00 00 .....R9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D ..... .

Message Header:
F9 BE B4 D9 - Main network magic bytes
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload is 31 bytes long
ED 52 39 9B - checksum of payload

Payload:
01 - 1 address in this message

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - see version message)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - port 8333
</pre>

=== inv ===

Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to ''getblocks''.

Payload (maximum 50,000 entries, which is just over 1.8 megabytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors
|}

=== getdata ===

getdata is used in response to inv, to retrieve the content of a specific object, and is usually sent after receiving an ''inv'' packet, after filtering known elements. It can be used to retrieve transactions, but only if they are in the memory pool or relay set - arbitrary access to transactions in the chain is not allowed to avoid having clients start to depend on nodes having full transaction indexes (which modern nodes do not).

Payload (maximum 50,000 entries, which is just over 1.8 megabytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors
|}

=== notfound ===

notfound is a response to a getdata, sent if any requested data items could not be relayed, for example, because the requested transaction was not in the memory pool or relay set.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors
|}

=== getblocks ===

Return an ''inv'' packet containing the list of blocks starting right after the last known hash in the block locator object, up to hash_stop or 500 blocks, whichever comes first.

The locator hashes are processed by a node in the order as they appear in the message. If a block hash is found in the node's main chain, the list of its children is returned back via the ''inv'' message and the remaining locators are ignored, no matter if the requested limit was reached, or not.

To receive the next blocks hashes, one needs to issue getblocks again with a new block locator object. Keep in mind that some clients may provide blocks which are invalid if the block locator object contains a hash on the invalid branch.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || the protocol version
|-
| 1+ || hash count || [[Protocol_documentation#Variable_length_integer|var_int]] || number of block locator hash entries
|-
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)
|-
| 32 || hash_stop || char[32] || hash of the last desired block; set to zero to get as many blocks as possible (500)
|}

To create the block locator hashes, keep pushing hashes until you go back to the genesis block. After pushing 10 hashes back, the step backwards doubles every loop:

<pre>
// From libbitcoin which is under AGPL
std::vector<size_t> block_locator_indices(int top_depth)
{
// Start at max_depth
std::vector<size_t> indices;
// Push last 10 indices first
size_t step = 1, start = 0;
for (int i = top_depth; i > 0; i -= step, ++start)
{
if (start >= 10)
step *= 2;
indices.push_back(i);
}
indices.push_back(0);
return indices;
}
</pre>

Note that it is allowed to send in fewer known hashes down to a minimum of just one hash. However, the purpose of the block locator object is to detect a wrong branch in the caller's main chain. If the peer detects that you are off the main chain, it will send in block hashes which are earlier than your last known block. So if you just send in your last known hash and it is off the main chain, the peer starts over at block #1.

=== getheaders ===

Return a ''headers'' packet containing the headers of blocks starting right after the last known hash in the block locator object, up to hash_stop or 2000 blocks, whichever comes first. To receive the next block headers, one needs to issue getheaders again with a new block locator object. The ''getheaders'' command is used by thin clients to quickly download the block chain where the contents of the transactions would be irrelevant (because they are not ours). Keep in mind that some clients may provide headers of blocks which are invalid if the block locator object contains a hash on the invalid branch.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || the protocol version
|-
| 1+ || hash count || [[Protocol_documentation#Variable_length_integer|var_int]] || number of block locator hash entries
|-
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)
|-
| 32 || hash_stop || char[32] || hash of the last desired block header; set to zero to get as many blocks as possible (2000)
|}

For the block locator object in this packet, the same rules apply as for the [[Protocol_documentation#getblocks|getblocks]] packet.

=== tx ===

''tx'' describes a bitcoin transaction, in reply to ''[[#getdata|getdata]]''

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Transaction data format version
|-
| 1+ || tx_in count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of Transaction inputs
|-
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins
|-
| 1+ || tx_out count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of Transaction outputs
|-
| 9+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins
|-
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked:
{|class="wikitable"
! Value !! Description
|-
| 0 || Not locked
|-
| < 500000000 || Block number at which this transaction is locked
|-
| >= 500000000 || UNIX timestamp at which this transaction is locked
|}
If all TxIn inputs have final (0xffffffff) sequence numbers then lock_time is irrelevant. Otherwise, the transaction may not be added to a block until after lock_time (see [[NLockTime]]).

|}

TxIn consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure
|-
| 1+ || script length || [[Protocol_documentation#Variable_length_integer|var_int]] || The length of the signature script
|-
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization
|-
| 4 || [http://bitcoin.stackexchange.com/q/2025/323 sequence] || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.
|}

The OutPoint structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || The hash of the referenced transaction.
|-
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.
|}

The Script structure consists of a series of pieces of information and operations related to the value of the transaction.

(Structure to be expanded in the future… see script.h and script.cpp and [[Script]] for more information)

The TxOut structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || int64_t || Transaction Value
|-
| 1+ || pk_script length || [[Protocol_documentation#Variable_length_integer|var_int]] || Length of the pk_script
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

Example ''tx'' message:
<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - main network magic bytes
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command
02 01 00 00 - payload is 258 bytes long
E2 93 CD BE - checksum of payload

Transaction:
01 00 00 00 - version

Inputs:
01 - number of transaction inputs

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - script is 139 bytes long

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 2 Output Transactions

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script is 25 bytes long

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script is 25 bytes long

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || int32_t || Block version information (note, this is signed)
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A Unix timestamp recording when this block was created (Currently limited to dates before the year 2106!)
|-
| 4 || bits || uint32_t || The calculated [[Difficulty|difficulty target]] being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| ? || txn_count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of transaction entries
|-
| ? || txns || tx[] || Block transactions, in format of "tx" command
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.
See [[Block hashing algorithm]] for details and an example.

=== headers ===

The ''headers'' packet returns block headers in response to a ''getheaders'' packet.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of block headers
|-
| 81x? || headers || [[Protocol_documentation#Block_Headers|block_header]][] || [[Protocol_documentation#Block_Headers|Block headers]]
|}

Note that the block headers in this packet include a transaction count (a var_int, so there can be more than 81 bytes per header) as opposed to the block headers which are sent to miners.

=== getaddr ===

The getaddr message sends a request to a node asking for information about known active peers to help with finding potential nodes in the network. The response to receiving this message is to transmit one or more addr messages with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.

No additional data is transmitted with this message.

=== mempool ===

The mempool message sends a request to a node asking for information about transactions it has verified but which have not yet confirmed. The response to receiving this message is an inv message containing the transaction hashes for all the transactions in the node's mempool.

No additional data is transmitted with this message.

It is specified in [https://github.com/bitcoin/bips/blob/master/bip-0035.mediawiki BIP 35]. Since [https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki BIP 37], if a [[Protocol_documentation#filterload.2C_filteradd.2C_filterclear.2C_merkleblock|bloom filter]] is loaded, only transactions matching the filter are replied.

=== checkorder ===

This message was used for [[IP Transactions]]. As IP transactions have been deprecated, it is no longer used.

=== submitorder ===

This message was used for [[IP Transactions]]. As IP transactions have been deprecated, it is no longer used.

=== reply ===

This message was used for [[IP Transactions]]. As IP transactions have been deprecated, it is no longer used.

=== ping ===

The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || nonce || uint64_t || random nonce
|}

=== pong ===

The ''pong'' message is sent in response to a ''ping'' message. In modern protocol versions, a ''pong'' response is generated using a nonce included in the ping.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || nonce || uint64_t || nonce from ping
|}

=== reject===

The ''reject'' message is sent when messages are rejected.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || message || var_str || type of message rejected
|-
| 1 || ccode || char || code relating to rejected message
|-
| 1+ || reason || var_str || text version of reason for rejection
|-
| 0+ || data || char || Optional extra data provided by some errors. Currently, all errors which provide this field fill it with the TXID or block header hash of the object being rejected, so the field is 32 bytes.
|}

CCodes

{|class="wikitable"
! Value !! Name !! Description
|-
| 0x01 || REJECT_MALFORMED||
|-
| 0x10 || REJECT_INVALID ||
|-
| 0x11 || REJECT_OBSOLETE ||
|-
| 0x12 || REJECT_DUPLICATE ||
|-
| 0x40 || REJECT_NONSTANDARD ||
|-
| 0x41 || REJECT_DUST ||
|-
| 0x42 || REJECT_INSUFFICIENTFEE ||
|-
| 0x43 || REJECT_CHECKPOINT ||
|}

=== filterload, filteradd, filterclear, merkleblock ===

These messages are related to Bloom filtering of connections and are defined in [https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki BIP 0037].

The <code>filterload</code> command is defined as follows:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || filter || uint8_t[] || The filter itself is simply a bit field of arbitrary byte-aligned size. The maximum size is 36,000 bytes.
|-
| 4 || nHashFuncs || uint32_t || The number of hash functions to use in this filter. The maximum value allowed in this field is 50.
|-
| 4 || nTweak || uint32_t || A random value to add to the seed value in the hash function used by the bloom filter.
|-
| 1 || nFlags || uint8_t || A set of flags that control how matched items are added to the filter.
|}

See below for a description of the Bloom filter algorithm and how to select nHashFuncs and filter size for a desired false positive rate.

Upon receiving a <code>filterload</code> command, the remote peer will immediately restrict the broadcast transactions it announces (in inv packets) to transactions matching the filter, where the matching algorithm is specified below. The flags control the update behaviour of the matching algorithm.

The <code>filteradd</code> command is defined as follows:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || data || uint8_t[] || The data element to add to the current filter.
|}

The data field must be smaller than or equal to 520 bytes in size (the maximum size of any potentially matched object).

The given data element will be added to the Bloom filter. A filter must have been previously provided using <code>filterload</code>. This command is useful if a new key or script is added to a clients wallet whilst it has connections to the network open, it avoids the need to re-calculate and send an entirely new filter to every peer (though doing so is usually advisable to maintain anonymity).

The <code>filterclear</code> command has no arguments at all.

After a filter has been set, nodes don't merely stop announcing non-matching transactions, they can also serve filtered blocks. A filtered block is defined by the <code>merkleblock</code> message and is defined like this:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| 4 || total_transactions || uint32_t || Number of transactions in the block (including unmatched ones)
|-
| ? || hashes || uint256[] || hashes in depth-first order (including standard varint size prefix)
|-
| ? || flags || byte[] || flag bits, packed per 8 in a byte, least significant bit first (including standard varint size prefix)
|}

=== alert ===

An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.

Alert format:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || payload || uchar[] || Serialized alert payload
|-
| ? || signature || uchar[] || An ECDSA signature of the message
|}

The developers of Satoshi's client use this public key for signing alerts:
04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

The payload is serialized into a uchar[] to ensure that versions using incompatible alert formats can still relay alerts among one another. The current alert payload format is:
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || Version || int32_t || Alert format version
|-
| 8 || RelayUntil || int64_t || The timestamp beyond which nodes should stop relaying this alert
|-
| 8 || Expiration || int64_t || The timestamp beyond which this alert is no longer in effect and should be ignored
|-
| 4 || ID || int32_t || A unique ID number for this alert
|-
| 4 || Cancel || int32_t || All alerts with an ID number less than or equal to this number should be cancelled: deleted and not accepted in the future
|-
| ? || setCancel || set<int32_t> || All alert IDs contained in this set should be cancelled as above
|-
| 4 || MinVer || int32_t || This alert only applies to versions greater than or equal to this version. Other versions should still relay it.
|-
| 4 || MaxVer || int32_t || This alert only applies to versions less than or equal to this version. Other versions should still relay it.
|-
| ? || setSubVer || set<string> || If this set contains any elements, then only nodes that have their subVer contained in this set are affected by the alert. Other versions should still relay it.
|-
| 4 || Priority || int32_t || Relative priority compared to other alerts
|-
| ? || Comment || string || A comment on the alert that is not displayed
|-
| ? || StatusBar || string || The alert message that is displayed to the user
|-
| ? || Reserved || string || Reserved
|}

Note: '''set<''type''>''' in the table above is a [[#Variable length integer | variable length integer]] followed by the number of fields of the given ''type'' (either int32_t or [[#Variable length string | variable length string]])

Sample alert (no message header):
73010000003766404f00000000b305434f00000000f2030000f1030000001027000048ee0000
0064000000004653656520626974636f696e2e6f72672f666562323020696620796f75206861
76652074726f75626c6520636f6e6e656374696e672061667465722032302046656272756172
79004730450221008389df45f0703f39ec8c1cc42c13810ffcae14995bb648340219e353b63b
53eb022009ec65e1c1aaeec1fd334c6b684bde2b3f573060d5b70c3a46723326e4e8a4f1

Version: 1
RelayUntil: 1329620535
Expiration: 1329792435
ID: 1010
Cancel: 1009
setCancel: <empty>
MinVer: 10000
MaxVer: 61000
setSubVer: <empty>
Priority: 100
Comment: <empty>
StatusBar: "See bitcoin.org/feb20 if you have trouble connecting after 20 February"
Reserved: <empty>

== Scripting ==

See [[script]].

==See Also==

* [[Network]]
* [[Protocol rules]]
* [[Hardfork Wishlist]]
* [https://bitcoin.org/en/developer-documentation Developer Documentation on bitcoin.org]
* Bitcoin dissectors for Wireshark: https://github.com/lbotsch/wireshark-bitcoin https://github.com/op-sig/bitcoin-wireshark-dissector

==References==
<references />

[[zh-cn:协议说明]]
[[Category:Technical]]
[[Category:Developer]]

Fallback Nodes

2012-12-24T21:22:25Z

BlueMatt: /* IPv4 Nodes */

This is a list of nodes which are considered reliable. <del>Nodes from this list which are down for more than 24 hours will be automatically removed and status of each node is displayed and updated every hour by [[User:WikiBot|WikiBot]] </del>.
'''Wikibot is currently malfunctioning and is incorrectly marking nodes running version 0.6 as being down'''.

== How to use this list ==

=== Connect to nodes ===

You can connect to these nodes with the ''-addnode=ip'' switch instead of the usual node harvesting process (through IRC or via the embedded nodelist). You can connect to more than one node by using ''-addnode=ip'' more than once. It is usually a good idea to connect to more than one of these nodes.

==== Nodes without a fixed ip ====

If the node IP is not fixed (see "Fixed" column), you will have to resolve the node's name (first column) each time the IP changes. Some nodes may have their ip change once a day, some others once a month, and some others may stay on the same IP for years. Still, as long as the IP is not fixed, there is no guarantee it will stay the same.

In order to enable hostname lookups for the ''-addnode'' and ''-connect'' parameters, you must additionally provide the ''-dns'' parameter. Example:
bitcoind -dns -addnode=bitcoin.es

Versions prior to 0.3.22 do not support hostnames to the ''-addnode'' parameter, so you must do the resolving part for it. For example on linux:
bitcoind -addnode=$(dig +short bitcoin.es)

=== IP Transactions ===

You can also send [[IP Transactions]] to these nodes. If you include your bitcoin address in the "message" field, you may have your coins back.

=== Tor network ===

To use tor .onion addresses ([[Fallback_Nodes#Tor_nodes|listed below]]), you will need to map virtual ips via the ''torrc'' file:

mapaddress 192.0.2.2 vso3r6cmjoomhhgg.onion
mapaddress 192.0.2.3 sjdntqu5roj4q6lo.onion

And then put these IPs in your bitcoin.conf (or run bitcoin with -connect).

connect=192.0.2.2
connect=192.0.2.3

You can use any arbitrary IP addresses with MapAddress, though some of the common non-routable ranges (10.*, 192.168.*) will not work due to a Bitcoin bug (reference?). 192.0.2.1-192.0.2.255 is the recommended range because it is both non-routable and compatible with Bitcoin.

If you would like to use these nodes in addition to the hard-coded node list in the client, you can substitute "connect" with "addnode". However, if you want to keep all your Bitcoin communication strictly within the Tor network, it is recommended that you use "connect."

Additional suggested settings for hidden node operators:

noirc=1
upnp=0
listen=1

== Nodes list ==

=== IPv6 Nodes ===
{|class="wikitable sortable"
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-

| 2001:470:8:2e1::40 || ? || 2001:470:8:2e1::40 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| x.jine.se || jine || 213.112.48.166 || {{Table Value No}} || {{Fallback Nodes/Node Down}} || || Yes

|}

=== IPv4 Nodes ===
'''Wikibot is currently malfunctioning and is incorrectly marking nodes running 0.6 as being down'''.
{|class="wikitable sortable"
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-

| archivum.info || Ferraro Ltd.|| 88.198.58.172 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes
|-
| 62.75.216.13 || exMULTI, Inc. || 62.75.216.13 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No
|-
| 69.64.34.118 || exMULTI, Inc. || 69.64.34.118 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No
|-
| 79.160.221.140 || K-Norway || 79.160.221.140 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| netzbasis.de || unknown3 || 81.169.129.25 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| btc.turboadmin.com || osmosis || 98.143.152.14 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No
|-
| fallback.bitcoin.zhoutong.com || Zhou Tong || 117.121.241.140 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No
|-
| bauhaus.csail.mit.edu || imsaguy || 128.30.96.44 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| jun.dashjr.org || Luke-Jr || 173.242.112.53 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || ||
|-
| cheaperinbitcoins.com || Xenland/Shane || 184.154.36.82 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| django.webflows.fr || unknown2 || 188.165.213.169 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| 204.9.55.71 || toasty || 204.9.55.71 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| btcnode.novit.ro || ovidiusoft - novit.ro || 93.187.142.114 || {{Table Value No}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| porgressbar.sk || progressbar hackerspace || 91.210.181.21 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes
|-
| faucet.bitcoin.st || bitcoin street || 64.27.57.225 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes
|-
| bitcoin.securepayment.cc || SecurePayment CC || 63.247.147.163 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes
|-
| x.jine.se || jine || 213.112.48.166 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes
|-
| www.dcscdn.com || [[User:Danw12|Danw12]] || 199.115.228.181 || {{Table Value Yes}}
|-
| ns2.dcscdn.com || [[User:Danw12|Danw12]] || 199.115.228.182 || {{Table Value Yes}}

|}

There is a list of nodes which have been seen on the network recently at http://blockchain.info/connected-nodes

=== Tor nodes ===

{|class="wikitable sortable"
! Hostname !! Owner !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-
| 6hgmaxwellgpv2oe.onion|| Gmaxwell || up || 2012-07-01 || No
|-
| pqosrh6wfaucet32.onion|| bitcoin street || up || 2012-08-29 || No
|-
| btc4ulpftizx5b72.onion || TorNode || up || 2012-06-22 || Yes
|-
| 7hxvg2lvr2ashzli.onion || Tuxavant || up || 2012-06-23 || ?
|-
| siqdznszjf4e6v5j.onion || Tuxavant || up || 2012-06-23 || ?
|-
| fpt6orohw2nuf2kn.onion || Tril || up || 2012-06-23 || No
|-
| vso3r6cmjoomhhgg.onion || echelon || up || 2012-09-16 || Yes
|-
| sjdntqu5roj4q6lo.onion || torservers || up || 2012-05-19 || ?
|-
| bitcoin2bkgm3fke.onion || ? || down || 2012-05-19 || Yes
|-
| ijzt2eeizty3p5xe.onion || ? || ? || 2011-02-11 || Yes
|-
| j43z65b6r2usg3vk.onion || Dybbuk || ? || 2011-02-11 || Yes
|-
| pvuif6nonbhj3o3r.onion || ? || ? || 2011-02-11 || Yes
|-
| c5qvugpewwyyy5oz.onion || ? || ? || 2011-02-11 || Yes
|-
| bitcoinbudtoeks7.onion || ? || ? || 2011-02-11 || ?
|-
| iy6ni3wkqazp4ytu.onion || ? || ? || 2011-02-11 || ?
|-
| h4kklwodpcmo6cbq.onion || ? || ? || 2011-02-11 || ?
|-
| vv6kcfscuntybrzm.onion || ? || ? || 2011-02-11 || ?
|-
| nlnsivjku4x4lu5n.onion || ? || ? || 2011-02-11 || ?
|-
| xqzfakpeuvrobvpj.onion || ? || ? || 2010-11-13 || No
|-
| 4lmduyac3svgrrav.onion || ? || ? || 2011-02-11 || No
|-
| usasx4urod3yj4az.onion || ? || ? || 2011-02-11 || No
|-
| e3tn727fywnioxrc.onion || ? || ? || 2011-11-01 || No
|-
| p2hwc26zdsrqxiix.onion || redemerald || down || 2012-05-25 || No
|-
| bxfna6fhddpzduck.onion || ? || ? || ? || ?
|-
| kjy2eqzk4zwi5zd3.onion || sipa || up || 2012-06-23 || No
|-
| mutqcuh7hwxmhx3k.onion || Xirafe || up || 2012-06-23 || ?
|-
| r4de4zf4lyniu4mx.onion:8444 || ? || up || 2012-06-26 || ?
|-
| bitcoinprwwpuinm.onion:8333 || ? || up || 2012-06-26 || ?
|}

== Adding a node ==

Before adding yourself as a fallback node, you should be sure your node will stay online for a long time. If a node is offline for more than 24 hours it will be removed from the list.

To add a node in this list, you just need the ip/hostname and your name, the other fields will be filled automatically. Insert the following lines before the <tt>END NODELIST</tt> line:

<nowiki>|-
| ip || your name</nowiki>

==See Also==

* [[Network|Bitcoin Network]]
* [http://nodes.bitcoin.st Fallback Nodes] List of longest running Bitcoin Nodes listed by Country.

BIP 0037

2012-12-17T21:11:18Z

BlueMatt: Tweak PMT description

{{bip}}

<pre>
BIP: 37
Title: Connection Bloom filtering
Author: Mike Hearn <hearn@google.com>, Matt Corallo <bip@bluematt.me>
Status: Draft
Type: Standards Track
Created: 24-10-2012
</pre>

==Abstract==

This BIP adds new support to the peer-to-peer protocol that allows peers to reduce the amount of transaction data they are sent. Peers have the option of setting ''filters'' on each connection they make after the version handshake has completed. A filter is defined as a [http://en.wikipedia.org/wiki/Bloom_filter Bloom filter] on data derived from transactions. A Bloom filter is a probabilistic data structure which allows for testing set membership - they can have false positives but not false negatives.

This document will not go into the details of how Bloom filters work and the reader is referred to Wikipedia for an introduction to the topic.

==Motivation==

As Bitcoin grows in usage the amount of bandwidth needed to download blocks and transaction broadcasts increases. Clients implementing ''simplified payment verification'' do not attempt to fully verify the block chain, instead just checking that block headers connect together correctly and trusting that the transactions in a chain of high difficulty are in fact valid. See the Bitcoin paper for more detail on this mode.

Today, [[Simplified_Payment_Verification|SPV]] clients have to download the entire contents of blocks and all broadcast transactions, only to throw away the vast majority of the transactions that are not relevant to their wallets. This slows down their synchronization process, wastes users bandwidth (which on phones is often metered) and increases memory usage. All three problems are triggering real user complaints for the Android "Bitcoin Wallet" app which implements SPV mode. In order to make chain synchronization fast, cheap and able to run on older phones with limited memory we want to have remote peers throw away irrelevant transactions before sending them across the network.

==Design rationale==

The most obvious way to implement the stated goal would be for clients to upload lists of their keys to the remote node. We take a more complex approach for the following reasons:

* Privacy: Because Bloom filters are probabilistic, with the false positive rate chosen by the client, nodes can trade off precision vs bandwidth usage. A node with access to lots of bandwidth may choose to have a high FP rate, meaning the remote peer cannot accurately know which transactions belong to the client and which don't. A node with very little bandwidth may choose to use a very accurate filter meaning that they only get sent transactions actually relevant to their wallet, but remote peers may be able to correlate transactions with IP addresses (and each other).
* Bloom filters are compact and testing membership in them is fast. This results in satisfying performance characteristics with minimal risk of opening up potential for DoS attacks.

==Specification==

===New messages===

We start by adding three new messages to the protocol:

* <code>filterload</code>, which sets the current Bloom filter on the connection
* <code>filteradd</code>, which adds the given data element to the connections current filter without requiring a completely new one to be set
* <code>filterclear</code>, which deletes the current filter and goes back to regular pre-BIP37 usage.

Note that there is no filterremove command because by their nature, Bloom filters are append-only data structures. Once an element is added it cannot be removed again without rebuilding the entire structure from scratch.

The <code>filterload</code> command is defined as follows:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || filter || uint8_t[] || The filter itself is simply a bit field of arbitrary byte-aligned size. The maximum size is 36,000 bytes.
|-
| 4 || nHashFuncs || uint32_t || The number of hash functions to use in this filter. The maximum value allowed in this field is 50.
|-
| 4 || nTweak || uint32_t || A random value to add to the seed value in the hash function used by the bloom filter.
|}

See below for a description of the Bloom filter algorithm and how to select nHashFuncs and filter size for a desired false positive rate.

Upon receiving a <code>filterload</code> command, the remote peer will immediately restrict the broadcast transactions it announces (in inv packets) to transactions matching the filter, where the matching algorithm is specified below.

The <code>filteradd</code> command is defined as follows:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || data || uint8_t[] || The data element to add to the current filter.
|}

The data field must be smaller than or equal to 520 bytes in size (the maximum size of any potentially matched object).

The given data element will be added to the Bloom filter. A filter must have been previously provided using <code>filterload</code>. This command is useful if a new key or script is added to a clients wallet whilst it has connections to the network open, it avoids the need to re-calculate and send an entirely new filter to every peer (though doing so is usually advisable to maintain anonymity).

The <code>filterclear</code> command has no arguments at all.

After a filter has been set, nodes don't merely stop announcing non-matching transactions, they can also serve filtered blocks. A filtered block is defined by the <code>merkleblock</code> message and is defined like this:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| 4 || total_transactions || uint32_t || Number of transactions in the block (including unmatched ones)
|-
| ? || hashes || uint256[] || hashes in depth-first order (including standard varint size prefix)
|-
| ? || flags || byte[] || flag bits, packed per 8 in a byte, least significant bit first (including standard varint size prefix)
|}

See below for the format of the partial merkle tree hashes and flags.

Thus, a <code>merkleblock</code> message is a block header, plus a part of a merkle tree which can be used to extract identifying information for transactions that matched the filter and prove that the matching transaction data really did appear in the solved block. Clients can use this data to be sure that the remote node is not feeding them fake transactions that never appeared in a real block, although lying through omission is still possible.

===Extensions to existing messages===

The <code>version</code> command is extended with a new field:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1 byte || fRelay || bool || If false then broadcast transactions will not be announced until a filter{load,add,clear} command is received. If missing or true, no change in protocol behaviour occurs.
|}

SPV clients that wish to use Bloom filtering would normally set fRelay to false in the version message, then set a filter based on their wallet (or a subset of it, if they are overlapping different peers). Being able to opt-out of inv messages until the filter is set prevents a client being flooded with traffic in the brief window of time between finishing version handshaking and setting the filter.

The <code>getdata</code> command is extended to allow a new type in the <code>inv</code> submessage. The type field can now be <code>MSG_FILTERED_BLOCK (== 3)</code> rather than <code>MSG_BLOCK</code>. If no filter has been set on the connection, a request for filtered blocks is ignored. If a filter has been set, a <code>merkleblock</code> message is returned for the requested block hash. In addition, because a <code>merkleblock</code> message contains only a list of transaction hashes, transactions matching the filter should also be sent in separate tx messages. This avoids a slow roundtrip that would otherwise be required (receive hashes, didn't see some of these transactions yet, ask for them). Note that because there is currently no way to request transactions which are already in a block from a node (aside from requesting the full block), the set of matching transactions that the requesting node hasn't either received or announced with an inv must be sent and any additional transactions which match the filter may also be sent. This allows for clients (such as the reference client) to limit the number of invs it must remember a given node to have announced while still providing nodes with, at a minimum, all the transactions it needs.

===Filter matching algorithm===

The filter can be tested against arbitrary pieces of data, to see if that data was inserted by the client. Therefore the question arises of what pieces of data should be inserted/tested.

To determine if a transaction matches the filter, the following algorithm MUST be used. Once a match is found the algorithm aborts.

# Test the hash of the transaction itself.
# For each output, test each data element of the output script. This means each hash and key in the output script is tested independently. '''Important:''' if an output matches whilst testing a transaction, the node MUST update the filter by inserting the serialized COutPoint structure. See below for more details.
# For each input, test the serialized COutPoint structure.
# For each input, test each data element of the input script (note: input scripts only ever contain data elements).
# Otherwise there is no match.

In this way addresses, keys and script hashes (for P2SH outputs) can all be added to the filter. You can also match against classes of transactions that are marked with well known data elements in either inputs or outputs, for example, to implement various forms of [[Smart property]].

The test for outpoints is there to ensure you can find transactions spending outputs in your wallet, even though you don't know anything about their form. As you can see, once set on a connection the filter is '''not static''' and can change throughout the connections lifetime. This is done to avoid the following race condition:

# A client sets a filter matching a key in their wallet. They then start downloading the block chain. The part of the chain that the client is missing is requested using getblocks.
# The first block is read from disk by the serving peer. It contains TX 1 which sends money to the clients key. It matches the filter and is thus sent to the client.
# The second block is read from disk by the serving peer. It contains TX 2 which spends TX 1. However TX 2 does not contain any of the clients keys and is thus not sent. The client does not know the money they received was already spent.

By updating the bloom filter atomically in step 2 with the discovered outpoint, the filter will match against TX 2 in step 3 and the client will learn about all relevant transactions, despite that there is no pause between the node processing the first and second blocks.

===Partial Merkle branch format===

A ''Merkle tree'' is a way of arranging a set of items as leaf nodes of tree in which the interior nodes are hashes of the concatenations of their child hashes. The root node is called the ''Merkle root''. Every Bitcoin block contains a Merkle root of the tree formed from the blocks transactions. By providing some elements of the trees interior nodes (called a ''Merkle branch'') a proof is formed that the given transaction was indeed in the block when it was being mined, but the size of the proof is much smaller than the size of the original block.

The encoding works as follows: we traverse the tree in depth-first order, storing a bit for each traversed node, signifying whether the node is the parent of at least one matched leaf txid (or a matched txid itself). In case we are at the leaf level, or this bit is 0, its merkle node hash is stored, and its children are not explored further. Otherwise, no hash is stored, but we recurse into both (or the only) child branch. During decoding, the same depth-first traversal is performed, consuming bits and hashes as they written during encoding.

===Bloom filter format===

A Bloom filter is a bit-field in which bits are set based on feeding the data element to a set of different hash functions. The number of hash functions used is a parameter of the filter. In Bitcoin we use version 3 of the 32-bit Murmur hash function. To get N "different" hash functions we simply initialize the Murmur algorithm with the following formula:

<code>nHashNum * 0xFBA4C795 + nTweak</code>

i.e. if the filter is initialized with 4 hash functions and a tweak of 0x00000005, when the second function (index 1) is needed h1 would be equal to 4221880218.

When loading a filter with the <code>filterload</code> command, there are two parameters that can be chosen. One is the size of the filter in bytes. The other is the number of hash functions to use. To select the parameters you can use the following formulas:

Let N be the number of elements you wish to insert into the set and P be the probability of a false positive, where 1.0 is "match everything" and zero is unachievable.

The size S of the filter in bytes is given by <code>(-1 / pow(log(2), 2) * N * log(P)) / 8</code>. Of course you must ensure it does not go over the maximum size (36,000: selected as it represents a filter of 20,000 items with false positive rate of < 0.1% or 10,000 items and a false positive rate of < 0.0001%).

The number of hash functions required is given by <code>S * 8 / N * log(2)</code>.

==Copyright==

This document is placed in the public domain.

[[Category:Developer]]
[[Category:Technical]]
[[Category:BIP|D]]

BIP 0037

2012-12-17T21:08:15Z

BlueMatt: Add nTweak

{{bip}}

<pre>
BIP: 37
Title: Connection Bloom filtering
Author: Mike Hearn <hearn@google.com>, Matt Corallo <bip@bluematt.me>
Status: Draft
Type: Standards Track
Created: 24-10-2012
</pre>

==Abstract==

This BIP adds new support to the peer-to-peer protocol that allows peers to reduce the amount of transaction data they are sent. Peers have the option of setting ''filters'' on each connection they make after the version handshake has completed. A filter is defined as a [http://en.wikipedia.org/wiki/Bloom_filter Bloom filter] on data derived from transactions. A Bloom filter is a probabilistic data structure which allows for testing set membership - they can have false positives but not false negatives.

This document will not go into the details of how Bloom filters work and the reader is referred to Wikipedia for an introduction to the topic.

==Motivation==

As Bitcoin grows in usage the amount of bandwidth needed to download blocks and transaction broadcasts increases. Clients implementing ''simplified payment verification'' do not attempt to fully verify the block chain, instead just checking that block headers connect together correctly and trusting that the transactions in a chain of high difficulty are in fact valid. See the Bitcoin paper for more detail on this mode.

Today, [[Simplified_Payment_Verification|SPV]] clients have to download the entire contents of blocks and all broadcast transactions, only to throw away the vast majority of the transactions that are not relevant to their wallets. This slows down their synchronization process, wastes users bandwidth (which on phones is often metered) and increases memory usage. All three problems are triggering real user complaints for the Android "Bitcoin Wallet" app which implements SPV mode. In order to make chain synchronization fast, cheap and able to run on older phones with limited memory we want to have remote peers throw away irrelevant transactions before sending them across the network.

==Design rationale==

The most obvious way to implement the stated goal would be for clients to upload lists of their keys to the remote node. We take a more complex approach for the following reasons:

* Privacy: Because Bloom filters are probabilistic, with the false positive rate chosen by the client, nodes can trade off precision vs bandwidth usage. A node with access to lots of bandwidth may choose to have a high FP rate, meaning the remote peer cannot accurately know which transactions belong to the client and which don't. A node with very little bandwidth may choose to use a very accurate filter meaning that they only get sent transactions actually relevant to their wallet, but remote peers may be able to correlate transactions with IP addresses (and each other).
* Bloom filters are compact and testing membership in them is fast. This results in satisfying performance characteristics with minimal risk of opening up potential for DoS attacks.

==Specification==

===New messages===

We start by adding three new messages to the protocol:

* <code>filterload</code>, which sets the current Bloom filter on the connection
* <code>filteradd</code>, which adds the given data element to the connections current filter without requiring a completely new one to be set
* <code>filterclear</code>, which deletes the current filter and goes back to regular pre-BIP37 usage.

Note that there is no filterremove command because by their nature, Bloom filters are append-only data structures. Once an element is added it cannot be removed again without rebuilding the entire structure from scratch.

The <code>filterload</code> command is defined as follows:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || filter || uint8_t[] || The filter itself is simply a bit field of arbitrary byte-aligned size. The maximum size is 36,000 bytes.
|-
| 4 || nHashFuncs || uint32_t || The number of hash functions to use in this filter. The maximum value allowed in this field is 50.
|-
| 4 || nTweak || uint32_t || A random value to add to the seed value in the hash function used by the bloom filter.
|}

See below for a description of the Bloom filter algorithm and how to select nHashFuncs and filter size for a desired false positive rate.

Upon receiving a <code>filterload</code> command, the remote peer will immediately restrict the broadcast transactions it announces (in inv packets) to transactions matching the filter, where the matching algorithm is specified below.

The <code>filteradd</code> command is defined as follows:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || data || uint8_t[] || The data element to add to the current filter.
|}

The data field must be smaller than or equal to 520 bytes in size (the maximum size of any potentially matched object).

The given data element will be added to the Bloom filter. A filter must have been previously provided using <code>filterload</code>. This command is useful if a new key or script is added to a clients wallet whilst it has connections to the network open, it avoids the need to re-calculate and send an entirely new filter to every peer (though doing so is usually advisable to maintain anonymity).

The <code>filterclear</code> command has no arguments at all.

After a filter has been set, nodes don't merely stop announcing non-matching transactions, they can also serve filtered blocks. A filtered block is defined by the <code>merkleblock</code> message and is defined like this:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| 4 || total_transactions || uint32_t || Number of transactions in the block (including unmatched ones)
|-
| ? || number_of_hashes || varint || Number of hashes
|-
| ? || hashes || uint256[] || hashes in depth-first order (<= 32*N bytes)
|-
| ? || bytes_of_flags || varint || number of bytes of flag bits (1-3 bytes)
|-
| ? || flags || byte[] || flag bits, packed per 8 in a byte, least significant bit first (<= 2*N-1 bits)
|}

See below for the format of the partial merkle tree hashes and flags.

Thus, a <code>merkleblock</code> message is a block header, plus a part of a merkle tree which can be used to extract identifying information for transactions that matched the filter and prove that the matching transaction data really did appear in the solved block. Clients can use this data to be sure that the remote node is not feeding them fake transactions that never appeared in a real block, although lying through omission is still possible.

===Extensions to existing messages===

The <code>version</code> command is extended with a new field:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1 byte || fRelay || bool || If false then broadcast transactions will not be announced until a filter{load,add,clear} command is received. If missing or true, no change in protocol behaviour occurs.
|}

SPV clients that wish to use Bloom filtering would normally set fRelay to false in the version message, then set a filter based on their wallet (or a subset of it, if they are overlapping different peers). Being able to opt-out of inv messages until the filter is set prevents a client being flooded with traffic in the brief window of time between finishing version handshaking and setting the filter.

The <code>getdata</code> command is extended to allow a new type in the <code>inv</code> submessage. The type field can now be <code>MSG_FILTERED_BLOCK (== 3)</code> rather than <code>MSG_BLOCK</code>. If no filter has been set on the connection, a request for filtered blocks is ignored. If a filter has been set, a <code>merkleblock</code> message is returned for the requested block hash. In addition, because a <code>merkleblock</code> message contains only a list of transaction hashes, transactions matching the filter should also be sent in separate tx messages. This avoids a slow roundtrip that would otherwise be required (receive hashes, didn't see some of these transactions yet, ask for them). Note that because there is currently no way to request transactions which are already in a block from a node (aside from requesting the full block), the set of matching transactions that the requesting node hasn't either received or announced with an inv must be sent and any additional transactions which match the filter may also be sent. This allows for clients (such as the reference client) to limit the number of invs it must remember a given node to have announced while still providing nodes with, at a minimum, all the transactions it needs.

===Filter matching algorithm===

The filter can be tested against arbitrary pieces of data, to see if that data was inserted by the client. Therefore the question arises of what pieces of data should be inserted/tested.

To determine if a transaction matches the filter, the following algorithm MUST be used. Once a match is found the algorithm aborts.

# Test the hash of the transaction itself.
# For each output, test each data element of the output script. This means each hash and key in the output script is tested independently. '''Important:''' if an output matches whilst testing a transaction, the node MUST update the filter by inserting the serialized COutPoint structure. See below for more details.
# For each input, test the serialized COutPoint structure.
# For each input, test each data element of the input script (note: input scripts only ever contain data elements).
# Otherwise there is no match.

In this way addresses, keys and script hashes (for P2SH outputs) can all be added to the filter. You can also match against classes of transactions that are marked with well known data elements in either inputs or outputs, for example, to implement various forms of [[Smart property]].

The test for outpoints is there to ensure you can find transactions spending outputs in your wallet, even though you don't know anything about their form. As you can see, once set on a connection the filter is '''not static''' and can change throughout the connections lifetime. This is done to avoid the following race condition:

# A client sets a filter matching a key in their wallet. They then start downloading the block chain. The part of the chain that the client is missing is requested using getblocks.
# The first block is read from disk by the serving peer. It contains TX 1 which sends money to the clients key. It matches the filter and is thus sent to the client.
# The second block is read from disk by the serving peer. It contains TX 2 which spends TX 1. However TX 2 does not contain any of the clients keys and is thus not sent. The client does not know the money they received was already spent.

By updating the bloom filter atomically in step 2 with the discovered outpoint, the filter will match against TX 2 in step 3 and the client will learn about all relevant transactions, despite that there is no pause between the node processing the first and second blocks.

===Partial Merkle branch format===

A ''Merkle tree'' is a way of arranging a set of items as leaf nodes of tree in which the interior nodes are hashes of the concatenations of their child hashes. The root node is called the ''Merkle root''. Every Bitcoin block contains a Merkle root of the tree formed from the blocks transactions. By providing some elements of the trees interior nodes (called a ''Merkle branch'') a proof is formed that the given transaction was indeed in the block when it was being mined, but the size of the proof is much smaller than the size of the original block.

The encoding works as follows: we traverse the tree in depth-first order, storing a bit for each traversed node, signifying whether the node is the parent of at least one matched leaf txid (or a matched txid itself). In case we are at the leaf level, or this bit is 0, its merkle node hash is stored, and its children are not explored further. Otherwise, no hash is stored, but we recurse into both (or the only) child branch. During decoding, the same depth-first traversal is performed, consuming bits and hashes as they written during encoding.

===Bloom filter format===

A Bloom filter is a bit-field in which bits are set based on feeding the data element to a set of different hash functions. The number of hash functions used is a parameter of the filter. In Bitcoin we use version 3 of the 32-bit Murmur hash function. To get N "different" hash functions we simply initialize the Murmur algorithm with the following formula:

<code>nHashNum * 0xFBA4C795 + nTweak</code>

i.e. if the filter is initialized with 4 hash functions and a tweak of 0x00000005, when the second function (index 1) is needed h1 would be equal to 4221880218.

When loading a filter with the <code>filterload</code> command, there are two parameters that can be chosen. One is the size of the filter in bytes. The other is the number of hash functions to use. To select the parameters you can use the following formulas:

Let N be the number of elements you wish to insert into the set and P be the probability of a false positive, where 1.0 is "match everything" and zero is unachievable.

The size S of the filter in bytes is given by <code>(-1 / pow(log(2), 2) * N * log(P)) / 8</code>. Of course you must ensure it does not go over the maximum size (36,000: selected as it represents a filter of 20,000 items with false positive rate of < 0.1% or 10,000 items and a false positive rate of < 0.0001%).

The number of hash functions required is given by <code>S * 8 / N * log(2)</code>.

==Copyright==

This document is placed in the public domain.

[[Category:Developer]]
[[Category:Technical]]
[[Category:BIP|D]]

BIP 0037

2012-12-17T20:59:39Z

BlueMatt: re add <code>

{{bip}}

<pre>
BIP: 37
Title: Connection Bloom filtering
Author: Mike Hearn <hearn@google.com>, Matt Corallo <bip@bluematt.me>
Status: Draft
Type: Standards Track
Created: 24-10-2012
</pre>

==Abstract==

This BIP adds new support to the peer-to-peer protocol that allows peers to reduce the amount of transaction data they are sent. Peers have the option of setting ''filters'' on each connection they make after the version handshake has completed. A filter is defined as a [http://en.wikipedia.org/wiki/Bloom_filter Bloom filter] on data derived from transactions. A Bloom filter is a probabilistic data structure which allows for testing set membership - they can have false positives but not false negatives.

This document will not go into the details of how Bloom filters work and the reader is referred to Wikipedia for an introduction to the topic.

==Motivation==

As Bitcoin grows in usage the amount of bandwidth needed to download blocks and transaction broadcasts increases. Clients implementing ''simplified payment verification'' do not attempt to fully verify the block chain, instead just checking that block headers connect together correctly and trusting that the transactions in a chain of high difficulty are in fact valid. See the Bitcoin paper for more detail on this mode.

Today, [[Simplified_Payment_Verification|SPV]] clients have to download the entire contents of blocks and all broadcast transactions, only to throw away the vast majority of the transactions that are not relevant to their wallets. This slows down their synchronization process, wastes users bandwidth (which on phones is often metered) and increases memory usage. All three problems are triggering real user complaints for the Android "Bitcoin Wallet" app which implements SPV mode. In order to make chain synchronization fast, cheap and able to run on older phones with limited memory we want to have remote peers throw away irrelevant transactions before sending them across the network.

==Design rationale==

The most obvious way to implement the stated goal would be for clients to upload lists of their keys to the remote node. We take a more complex approach for the following reasons:

* Privacy: Because Bloom filters are probabilistic, with the false positive rate chosen by the client, nodes can trade off precision vs bandwidth usage. A node with access to lots of bandwidth may choose to have a high FP rate, meaning the remote peer cannot accurately know which transactions belong to the client and which don't. A node with very little bandwidth may choose to use a very accurate filter meaning that they only get sent transactions actually relevant to their wallet, but remote peers may be able to correlate transactions with IP addresses (and each other).
* Bloom filters are compact and testing membership in them is fast. This results in satisfying performance characteristics with minimal risk of opening up potential for DoS attacks.

==Specification==

===New messages===

We start by adding three new messages to the protocol:

* <code>filterload</code>, which sets the current Bloom filter on the connection
* <code>filteradd</code>, which adds the given data element to the connections current filter without requiring a completely new one to be set
* <code>filterclear</code>, which deletes the current filter and goes back to regular pre-BIP37 usage.

Note that there is no filterremove command because by their nature, Bloom filters are append-only data structures. Once an element is added it cannot be removed again without rebuilding the entire structure from scratch.

The <code>filterload</code> command is defined as follows:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || filter || uint8_t[] || The filter itself is simply a bit field of arbitrary byte-aligned size. The maximum size is 36,000 bytes.
|-
| 4 || nHashFuncs || uint32_t || The number of hash functions to use in this filter. The maximum value allowed in this field is 50.
|}

See below for a description of the Bloom filter algorithm and how to select nHashFuncs and filter size for a desired false positive rate.

Upon receiving a <code>filterload</code> command, the remote peer will immediately restrict the broadcast transactions it announces (in inv packets) to transactions matching the filter, where the matching algorithm is specified below.

The <code>filteradd</code> command is defined as follows:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || data || uint8_t[] || The data element to add to the current filter.
|}

The data field must be smaller than or equal to 520 bytes in size (the maximum size of any potentially matched object).

The given data element will be added to the Bloom filter. A filter must have been previously provided using <code>filterload</code>. This command is useful if a new key or script is added to a clients wallet whilst it has connections to the network open, it avoids the need to re-calculate and send an entirely new filter to every peer (though doing so is usually advisable to maintain anonymity).

The <code>filterclear</code> command has no arguments at all.

After a filter has been set, nodes don't merely stop announcing non-matching transactions, they can also serve filtered blocks. A filtered block is defined by the <code>merkleblock</code> message and is defined like this:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| 4 || total_transactions || uint32_t || Number of transactions in the block (including unmatched ones)
|-
| ? || number_of_hashes || varint || Number of hashes
|-
| ? || hashes || uint256[] || hashes in depth-first order (<= 32*N bytes)
|-
| ? || bytes_of_flags || varint || number of bytes of flag bits (1-3 bytes)
|-
| ? || flags || byte[] || flag bits, packed per 8 in a byte, least significant bit first (<= 2*N-1 bits)
|}

See below for the format of the partial merkle tree hashes and flags.

Thus, a <code>merkleblock</code> message is a block header, plus a part of a merkle tree which can be used to extract identifying information for transactions that matched the filter and prove that the matching transaction data really did appear in the solved block. Clients can use this data to be sure that the remote node is not feeding them fake transactions that never appeared in a real block, although lying through omission is still possible.

===Extensions to existing messages===

The <code>version</code> command is extended with a new field:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1 byte || fRelay || bool || If false then broadcast transactions will not be announced until a filter{load,add,clear} command is received. If missing or true, no change in protocol behaviour occurs.
|}

SPV clients that wish to use Bloom filtering would normally set fRelay to false in the version message, then set a filter based on their wallet (or a subset of it, if they are overlapping different peers). Being able to opt-out of inv messages until the filter is set prevents a client being flooded with traffic in the brief window of time between finishing version handshaking and setting the filter.

The <code>getdata</code> command is extended to allow a new type in the <code>inv</code> submessage. The type field can now be <code>MSG_FILTERED_BLOCK (== 3)</code> rather than <code>MSG_BLOCK</code>. If no filter has been set on the connection, a request for filtered blocks is ignored. If a filter has been set, a <code>merkleblock</code> message is returned for the requested block hash. In addition, because a <code>merkleblock</code> message contains only a list of transaction hashes, transactions matching the filter should also be sent in separate tx messages. This avoids a slow roundtrip that would otherwise be required (receive hashes, didn't see some of these transactions yet, ask for them). Note that because there is currently no way to request transactions which are already in a block from a node (aside from requesting the full block), the set of matching transactions that the requesting node hasn't either received or announced with an inv must be sent and any additional transactions which match the filter may also be sent. This allows for clients (such as the reference client) to limit the number of invs it must remember a given node to have announced while still providing nodes with, at a minimum, all the transactions it needs.

===Filter matching algorithm===

The filter can be tested against arbitrary pieces of data, to see if that data was inserted by the client. Therefore the question arises of what pieces of data should be inserted/tested.

To determine if a transaction matches the filter, the following algorithm MUST be used. Once a match is found the algorithm aborts.

# Test the hash of the transaction itself.
# For each output, test each data element of the output script. This means each hash and key in the output script is tested independently. '''Important:''' if an output matches whilst testing a transaction, the node MUST update the filter by inserting the serialized COutPoint structure. See below for more details.
# For each input, test the serialized COutPoint structure.
# For each input, test each data element of the input script (note: input scripts only ever contain data elements).
# Otherwise there is no match.

In this way addresses, keys and script hashes (for P2SH outputs) can all be added to the filter. You can also match against classes of transactions that are marked with well known data elements in either inputs or outputs, for example, to implement various forms of [[Smart property]].

The test for outpoints is there to ensure you can find transactions spending outputs in your wallet, even though you don't know anything about their form. As you can see, once set on a connection the filter is '''not static''' and can change throughout the connections lifetime. This is done to avoid the following race condition:

# A client sets a filter matching a key in their wallet. They then start downloading the block chain. The part of the chain that the client is missing is requested using getblocks.
# The first block is read from disk by the serving peer. It contains TX 1 which sends money to the clients key. It matches the filter and is thus sent to the client.
# The second block is read from disk by the serving peer. It contains TX 2 which spends TX 1. However TX 2 does not contain any of the clients keys and is thus not sent. The client does not know the money they received was already spent.

By updating the bloom filter atomically in step 2 with the discovered outpoint, the filter will match against TX 2 in step 3 and the client will learn about all relevant transactions, despite that there is no pause between the node processing the first and second blocks.

===Partial Merkle branch format===

A ''Merkle tree'' is a way of arranging a set of items as leaf nodes of tree in which the interior nodes are hashes of the concatenations of their child hashes. The root node is called the ''Merkle root''. Every Bitcoin block contains a Merkle root of the tree formed from the blocks transactions. By providing some elements of the trees interior nodes (called a ''Merkle branch'') a proof is formed that the given transaction was indeed in the block when it was being mined, but the size of the proof is much smaller than the size of the original block.

The encoding works as follows: we traverse the tree in depth-first order, storing a bit for each traversed node, signifying whether the node is the parent of at least one matched leaf txid (or a matched txid itself). In case we are at the leaf level, or this bit is 0, its merkle node hash is stored, and its children are not explored further. Otherwise, no hash is stored, but we recurse into both (or the only) child branch. During decoding, the same depth-first traversal is performed, consuming bits and hashes as they written during encoding.

===Bloom filter format===

A Bloom filter is a bit-field in which bits are set based on feeding the data element to a set of different hash functions. The number of hash functions used is a parameter of the filter. In Bitcoin we use version 3 of the 32-bit Murmur hash function. To get N "different" hash functions we simply initialize the Murmur algorithm with the following formula:

<code>nHashNum * (MAX_UINT32 / (nHashFuncs - 1))</code>

i.e. if the filter is initialized with 4 hash functions, when the second function is needed h1 would be equal to 1431655765.

When loading a filter with the <code>filterload</code> command, there are two parameters that can be chosen. One is the size of the filter in bytes. The other is the number of hash functions to use. To select the parameters you can use the following formulas:

Let N be the number of elements you wish to insert into the set and P be the probability of a false positive, where 1.0 is "match everything" and zero is unachievable.

The size S of the filter in bytes is given by <code>(-1 / pow(log(2), 2) * N * log(P)) / 8</code>. Of course you must ensure it does not go over the maximum size (36,000).

The number of hash functions required is given by <code>S * 8 / N * log(2)</code>.

==Copyright==

This document is placed in the public domain.

[[Category:Developer]]
[[Category:Technical]]
[[Category:BIP|D]]

BIP 0037

2012-12-17T20:56:22Z

BlueMatt: Require a previous filter before filteradd

{{bip}}

<pre>
BIP: 37
Title: Connection Bloom filtering
Author: Mike Hearn <hearn@google.com>, Matt Corallo <bip@bluematt.me>
Status: Draft
Type: Standards Track
Created: 24-10-2012
</pre>

==Abstract==

This BIP adds new support to the peer-to-peer protocol that allows peers to reduce the amount of transaction data they are sent. Peers have the option of setting ''filters'' on each connection they make after the version handshake has completed. A filter is defined as a [http://en.wikipedia.org/wiki/Bloom_filter Bloom filter] on data derived from transactions. A Bloom filter is a probabilistic data structure which allows for testing set membership - they can have false positives but not false negatives.

This document will not go into the details of how Bloom filters work and the reader is referred to Wikipedia for an introduction to the topic.

==Motivation==

As Bitcoin grows in usage the amount of bandwidth needed to download blocks and transaction broadcasts increases. Clients implementing ''simplified payment verification'' do not attempt to fully verify the block chain, instead just checking that block headers connect together correctly and trusting that the transactions in a chain of high difficulty are in fact valid. See the Bitcoin paper for more detail on this mode.

Today, [[Simplified_Payment_Verification|SPV]] clients have to download the entire contents of blocks and all broadcast transactions, only to throw away the vast majority of the transactions that are not relevant to their wallets. This slows down their synchronization process, wastes users bandwidth (which on phones is often metered) and increases memory usage. All three problems are triggering real user complaints for the Android "Bitcoin Wallet" app which implements SPV mode. In order to make chain synchronization fast, cheap and able to run on older phones with limited memory we want to have remote peers throw away irrelevant transactions before sending them across the network.

==Design rationale==

The most obvious way to implement the stated goal would be for clients to upload lists of their keys to the remote node. We take a more complex approach for the following reasons:

* Privacy: Because Bloom filters are probabilistic, with the false positive rate chosen by the client, nodes can trade off precision vs bandwidth usage. A node with access to lots of bandwidth may choose to have a high FP rate, meaning the remote peer cannot accurately know which transactions belong to the client and which don't. A node with very little bandwidth may choose to use a very accurate filter meaning that they only get sent transactions actually relevant to their wallet, but remote peers may be able to correlate transactions with IP addresses (and each other).
* Bloom filters are compact and testing membership in them is fast. This results in satisfying performance characteristics with minimal risk of opening up potential for DoS attacks.

==Specification==

===New messages===

We start by adding three new messages to the protocol:

* <code>filterload</code>, which sets the current Bloom filter on the connection
* <code>filteradd</code>, which adds the given data element to the connections current filter without requiring a completely new one to be set
* <code>filterclear</code>, which deletes the current filter and goes back to regular pre-BIP37 usage.

Note that there is no filterremove command because by their nature, Bloom filters are append-only data structures. Once an element is added it cannot be removed again without rebuilding the entire structure from scratch.

The <code>filterload</code> command is defined as follows:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || filter || uint8_t[] || The filter itself is simply a bit field of arbitrary byte-aligned size. The maximum size is 36,000 bytes.
|-
| 4 || nHashFuncs || uint32_t || The number of hash functions to use in this filter. The maximum value allowed in this field is 50.
|}

See below for a description of the Bloom filter algorithm and how to select nHashFuncs and filter size for a desired false positive rate.

Upon receiving a <code>filterload</code> command, the remote peer will immediately restrict the broadcast transactions it announces (in inv packets) to transactions matching the filter, where the matching algorithm is specified below.

The <code>filteradd</code> command is defined as follows:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || data || uint8_t[] || The data element to add to the current filter.
|}

The data field must be smaller than or equal to 520 bytes in size (the maximum size of any potentially matched object).

The given data element will be added to the Bloom filter. A filter must have been previously provided using filterload. This command is useful if a new key or script is added to a clients wallet whilst it has connections to the network open, it avoids the need to re-calculate and send an entirely new filter to every peer (though doing so is usually advisable to maintain anonymity).

The <code>filterclear</code> command has no arguments at all.

After a filter has been set, nodes don't merely stop announcing non-matching transactions, they can also serve filtered blocks. A filtered block is defined by the <code>merkleblock</code> message and is defined like this:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| 4 || total_transactions || uint32_t || Number of transactions in the block (including unmatched ones)
|-
| ? || number_of_hashes || varint || Number of hashes
|-
| ? || hashes || uint256[] || hashes in depth-first order (<= 32*N bytes)
|-
| ? || bytes_of_flags || varint || number of bytes of flag bits (1-3 bytes)
|-
| ? || flags || byte[] || flag bits, packed per 8 in a byte, least significant bit first (<= 2*N-1 bits)
|}

See below for the format of the partial merkle tree hashes and flags.

Thus, a <code>merkleblock</code> message is a block header, plus a part of a merkle tree which can be used to extract identifying information for transactions that matched the filter and prove that the matching transaction data really did appear in the solved block. Clients can use this data to be sure that the remote node is not feeding them fake transactions that never appeared in a real block, although lying through omission is still possible.

===Extensions to existing messages===

The <code>version</code> command is extended with a new field:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1 byte || fRelay || bool || If false then broadcast transactions will not be announced until a filter{load,add,clear} command is received. If missing or true, no change in protocol behaviour occurs.
|}

SPV clients that wish to use Bloom filtering would normally set fRelay to false in the version message, then set a filter based on their wallet (or a subset of it, if they are overlapping different peers). Being able to opt-out of inv messages until the filter is set prevents a client being flooded with traffic in the brief window of time between finishing version handshaking and setting the filter.

The <code>getdata</code> command is extended to allow a new type in the <code>inv</code> submessage. The type field can now be <code>MSG_FILTERED_BLOCK (== 3)</code> rather than <code>MSG_BLOCK</code>. If no filter has been set on the connection, a request for filtered blocks is ignored. If a filter has been set, a <code>merkleblock</code> message is returned for the requested block hash. In addition, because a <code>merkleblock</code> message contains only a list of transaction hashes, transactions matching the filter should also be sent in separate tx messages. This avoids a slow roundtrip that would otherwise be required (receive hashes, didn't see some of these transactions yet, ask for them). Note that because there is currently no way to request transactions which are already in a block from a node (aside from requesting the full block), the set of matching transactions that the requesting node hasn't either received or announced with an inv must be sent and any additional transactions which match the filter may also be sent. This allows for clients (such as the reference client) to limit the number of invs it must remember a given node to have announced while still providing nodes with, at a minimum, all the transactions it needs.

===Filter matching algorithm===

The filter can be tested against arbitrary pieces of data, to see if that data was inserted by the client. Therefore the question arises of what pieces of data should be inserted/tested.

To determine if a transaction matches the filter, the following algorithm MUST be used. Once a match is found the algorithm aborts.

# Test the hash of the transaction itself.
# For each output, test each data element of the output script. This means each hash and key in the output script is tested independently. '''Important:''' if an output matches whilst testing a transaction, the node MUST update the filter by inserting the serialized COutPoint structure. See below for more details.
# For each input, test the serialized COutPoint structure.
# For each input, test each data element of the input script (note: input scripts only ever contain data elements).
# Otherwise there is no match.

In this way addresses, keys and script hashes (for P2SH outputs) can all be added to the filter. You can also match against classes of transactions that are marked with well known data elements in either inputs or outputs, for example, to implement various forms of [[Smart property]].

The test for outpoints is there to ensure you can find transactions spending outputs in your wallet, even though you don't know anything about their form. As you can see, once set on a connection the filter is '''not static''' and can change throughout the connections lifetime. This is done to avoid the following race condition:

# A client sets a filter matching a key in their wallet. They then start downloading the block chain. The part of the chain that the client is missing is requested using getblocks.
# The first block is read from disk by the serving peer. It contains TX 1 which sends money to the clients key. It matches the filter and is thus sent to the client.
# The second block is read from disk by the serving peer. It contains TX 2 which spends TX 1. However TX 2 does not contain any of the clients keys and is thus not sent. The client does not know the money they received was already spent.

By updating the bloom filter atomically in step 2 with the discovered outpoint, the filter will match against TX 2 in step 3 and the client will learn about all relevant transactions, despite that there is no pause between the node processing the first and second blocks.

===Partial Merkle branch format===

A ''Merkle tree'' is a way of arranging a set of items as leaf nodes of tree in which the interior nodes are hashes of the concatenations of their child hashes. The root node is called the ''Merkle root''. Every Bitcoin block contains a Merkle root of the tree formed from the blocks transactions. By providing some elements of the trees interior nodes (called a ''Merkle branch'') a proof is formed that the given transaction was indeed in the block when it was being mined, but the size of the proof is much smaller than the size of the original block.

The encoding works as follows: we traverse the tree in depth-first order, storing a bit for each traversed node, signifying whether the node is the parent of at least one matched leaf txid (or a matched txid itself). In case we are at the leaf level, or this bit is 0, its merkle node hash is stored, and its children are not explored further. Otherwise, no hash is stored, but we recurse into both (or the only) child branch. During decoding, the same depth-first traversal is performed, consuming bits and hashes as they written during encoding.

===Bloom filter format===

A Bloom filter is a bit-field in which bits are set based on feeding the data element to a set of different hash functions. The number of hash functions used is a parameter of the filter. In Bitcoin we use version 3 of the 32-bit Murmur hash function. To get N "different" hash functions we simply initialize the Murmur algorithm with the following formula:

<code>nHashNum * (MAX_UINT32 / (nHashFuncs - 1))</code>

i.e. if the filter is initialized with 4 hash functions, when the second function is needed h1 would be equal to 1431655765.

When loading a filter with the <code>filterload</code> command, there are two parameters that can be chosen. One is the size of the filter in bytes. The other is the number of hash functions to use. To select the parameters you can use the following formulas:

Let N be the number of elements you wish to insert into the set and P be the probability of a false positive, where 1.0 is "match everything" and zero is unachievable.

The size S of the filter in bytes is given by <code>(-1 / pow(log(2), 2) * N * log(P)) / 8</code>. Of course you must ensure it does not go over the maximum size (36,000).

The number of hash functions required is given by <code>S * 8 / N * log(2)</code>.

==Copyright==

This document is placed in the public domain.

[[Category:Developer]]
[[Category:Technical]]
[[Category:BIP|D]]

BIP 0037

2012-12-15T00:23:30Z

BlueMatt: Update for PMT

{{bip}}

<pre>
BIP: 37
Title: Connection Bloom filtering
Author: Mike Hearn <hearn@google.com>, Matt Corallo <bip@bluematt.me>
Status: Draft
Type: Standards Track
Created: 24-10-2012
</pre>

==Abstract==

This BIP adds new support to the peer-to-peer protocol that allows peers to reduce the amount of transaction data they are sent. Peers have the option of setting ''filters'' on each connection they make after the version handshake has completed. A filter is defined as a [http://en.wikipedia.org/wiki/Bloom_filter Bloom filter] on data derived from transactions. A Bloom filter is a probabilistic data structure which allows for testing set membership - they can have false positives but not false negatives.

This document will not go into the details of how Bloom filters work and the reader is referred to Wikipedia for an introduction to the topic.

==Motivation==

As Bitcoin grows in usage the amount of bandwidth needed to download blocks and transaction broadcasts increases. Clients implementing ''simplified payment verification'' do not attempt to fully verify the block chain, instead just checking that block headers connect together correctly and trusting that the transactions in a chain of high difficulty are in fact valid. See the Bitcoin paper for more detail on this mode.

Today, [[Simplified_Payment_Verification|SPV]] clients have to download the entire contents of blocks and all broadcast transactions, only to throw away the vast majority of the transactions that are not relevant to their wallets. This slows down their synchronization process, wastes users bandwidth (which on phones is often metered) and increases memory usage. All three problems are triggering real user complaints for the Android "Bitcoin Wallet" app which implements SPV mode. In order to make chain synchronization fast, cheap and able to run on older phones with limited memory we want to have remote peers throw away irrelevant transactions before sending them across the network.

==Design rationale==

The most obvious way to implement the stated goal would be for clients to upload lists of their keys to the remote node. We take a more complex approach for the following reasons:

* Privacy: Because Bloom filters are probabilistic, with the false positive rate chosen by the client, nodes can trade off precision vs bandwidth usage. A node with access to lots of bandwidth may choose to have a high FP rate, meaning the remote peer cannot accurately know which transactions belong to the client and which don't. A node with very little bandwidth may choose to use a very accurate filter meaning that they only get sent transactions actually relevant to their wallet, but remote peers may be able to correlate transactions with IP addresses (and each other).
* Bloom filters are compact and testing membership in them is fast. This results in satisfying performance characteristics with minimal risk of opening up potential for DoS attacks.

==Specification==

===New messages===

We start by adding three new messages to the protocol:

* <code>filterload</code>, which sets the current Bloom filter on the connection
* <code>filteradd</code>, which adds the given data element to the connections current filter without requiring a completely new one to be set
* <code>filterclear</code>, which deletes the current filter and goes back to regular pre-BIP37 usage.

Note that there is no filterremove command because by their nature, Bloom filters are append-only data structures. Once an element is added it cannot be removed again without rebuilding the entire structure from scratch.

The <code>filterload</code> command is defined as follows:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || filter || uint8_t[] || The filter itself is simply a bit field of arbitrary byte-aligned size. The maximum size is 36,000 bytes.
|-
| 4 || nHashFuncs || uint32_t || The number of hash functions to use in this filter. The maximum value allowed in this field is 50.
|}

See below for a description of the Bloom filter algorithm and how to select nHashFuncs and filter size for a desired false positive rate.

Upon receiving a <code>filterload</code> command, the remote peer will immediately restrict the broadcast transactions it announces (in inv packets) to transactions matching the filter, where the matching algorithm is specified below.

The <code>filteradd</code> command is defined as follows:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || data || uint8_t[] || The data element to add to the current filter.
|}

The data field must be smaller than or equal to 520 bytes in size (the maximum size of any potentially matched object).

The given data element will be added to the Bloom filter. If no filter has been previously provided using <code>filterload</code>, a new one will be initialized that would have a false positive rate of, at a minimum, 0.1% with 1000 inserted elements. This command is useful if a new key or script is added to a clients wallet whilst it has connections to the network open, it avoids the need to re-calculate and send an entirely new filter to every peer.

The <code>filterclear</code> command has no arguments at all.

After a filter has been set, nodes don't merely stop announcing non-matching transactions, they can also serve filtered blocks. A filtered block is defined by the <code>merkleblock</code> message and is defined like this:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| 4 || total_transactions || uint32_t || Number of transactions in the block (including unmatched ones)
|-
| ? || number_of_hashes || varint || Number of hashes
|-
| ? || hashes || uint256[] || hashes in depth-first order (<= 32*N bytes)
|-
| ? || bytes_of_flags || varint || number of bytes of flag bits (1-3 bytes)
|-
| ? || flags || byte[] || flag bits, packed per 8 in a byte, least significant bit first (<= 2*N-1 bits)
|}

See below for the format of the partial merkle tree hashes and flags.

Thus, a <code>merkleblock</code> message is a block header, plus a part of a merkle tree which can be used to extract identifying information for transactions that matched the filter and prove that the matching transaction data really did appear in the solved block. Clients can use this data to be sure that the remote node is not feeding them fake transactions that never appeared in a real block, although lying through omission is still possible.

===Extensions to existing messages===

The <code>version</code> command is extended with a new field:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1 byte || fRelay || bool || If false then broadcast transactions will not be announced until a filter{load,add,clear} command is received. If missing or true, no change in protocol behaviour occurs.
|}

SPV clients that wish to use Bloom filtering would normally set fRelay to false in the version message, then set a filter based on their wallet (or a subset of it, if they are overlapping different peers). Being able to opt-out of inv messages until the filter is set prevents a client being flooded with traffic in the brief window of time between finishing version handshaking and setting the filter.

The <code>getdata</code> command is extended to allow a new type in the <code>inv</code> submessage. The type field can now be <code>MSG_FILTERED_BLOCK (== 3)</code> rather than <code>MSG_BLOCK</code>. If no filter has been set on the connection, a request for filtered blocks is ignored. If a filter has been set, a <code>merkleblock</code> message is returned for the requested block hash. In addition, because a <code>merkleblock</code> message contains only a list of transaction hashes, transactions matching the filter should also be sent in separate tx messages. This avoids a slow roundtrip that would otherwise be required (receive hashes, didn't see some of these transactions yet, ask for them). Note that because there is currently no way to request transactions which are already in a block from a node (aside from requesting the full block), the set of matching transactions that the requesting node hasn't either received or announced with an inv must be sent and any additional transactions which match the filter may also be sent. This allows for clients (such as the reference client) to limit the number of invs it must remember a given node to have announced while still providing nodes with, at a minimum, all the transactions it needs.

===Filter matching algorithm===

The filter can be tested against arbitrary pieces of data, to see if that data was inserted by the client. Therefore the question arises of what pieces of data should be inserted/tested.

To determine if a transaction matches the filter, the following algorithm MUST be used. Once a match is found the algorithm aborts.

# Test the hash of the transaction itself.
# For each output, test each data element of the output script. This means each hash and key in the output script is tested independently. '''Important:''' if an output matches whilst testing a transaction, the node MUST update the filter by inserting the serialized COutPoint structure. See below for more details.
# For each input, test the serialized COutPoint structure.
# For each input, test each data element of the input script (note: input scripts only ever contain data elements).
# Otherwise there is no match.

In this way addresses, keys and script hashes (for P2SH outputs) can all be added to the filter. You can also match against classes of transactions that are marked with well known data elements in either inputs or outputs, for example, to implement various forms of [[Smart property]].

The test for outpoints is there to ensure you can find transactions spending outputs in your wallet, even though you don't know anything about their form. As you can see, once set on a connection the filter is '''not static''' and can change throughout the connections lifetime. This is done to avoid the following race condition:

# A client sets a filter matching a key in their wallet. They then start downloading the block chain. The part of the chain that the client is missing is requested using getblocks.
# The first block is read from disk by the serving peer. It contains TX 1 which sends money to the clients key. It matches the filter and is thus sent to the client.
# The second block is read from disk by the serving peer. It contains TX 2 which spends TX 1. However TX 2 does not contain any of the clients keys and is thus not sent. The client does not know the money they received was already spent.

By updating the bloom filter atomically in step 2 with the discovered outpoint, the filter will match against TX 2 in step 3 and the client will learn about all relevant transactions, despite that there is no pause between the node processing the first and second blocks.

===Partial Merkle branch format===

A ''Merkle tree'' is a way of arranging a set of items as leaf nodes of tree in which the interior nodes are hashes of the concatenations of their child hashes. The root node is called the ''Merkle root''. Every Bitcoin block contains a Merkle root of the tree formed from the blocks transactions. By providing some elements of the trees interior nodes (called a ''Merkle branch'') a proof is formed that the given transaction was indeed in the block when it was being mined, but the size of the proof is much smaller than the size of the original block.

The encoding works as follows: we traverse the tree in depth-first order, storing a bit for each traversed node, signifying whether the node is the parent of at least one matched leaf txid (or a matched txid itself). In case we are at the leaf level, or this bit is 0, its merkle node hash is stored, and its children are not explored further. Otherwise, no hash is stored, but we recurse into both (or the only) child branch. During decoding, the same depth-first traversal is performed, consuming bits and hashes as they written during encoding.

===Bloom filter format===

A Bloom filter is a bit-field in which bits are set based on feeding the data element to a set of different hash functions. The number of hash functions used is a parameter of the filter. In Bitcoin we use version 3 of the 32-bit Murmur hash function. To get N "different" hash functions we simply initialize the Murmur algorithm with the following formula:

<code>nHashNum * (MAX_UINT32 / (nHashFuncs - 1))</code>

i.e. if the filter is initialized with 4 hash functions, when the second function is needed h1 would be equal to 1431655765.

When loading a filter with the <code>filterload</code> command, there are two parameters that can be chosen. One is the size of the filter in bytes. The other is the number of hash functions to use. To select the parameters you can use the following formulas:

Let N be the number of elements you wish to insert into the set and P be the probability of a false positive, where 1.0 is "match everything" and zero is unachievable.

The size S of the filter in bytes is given by <code>(-1 / pow(log(2), 2) * N * log(P)) / 8</code>. Of course you must ensure it does not go over the maximum size (36,000).

The number of hash functions required is given by <code>S * 8 / N * log(2)</code>.

==Copyright==

This document is placed in the public domain.

[[Category:Developer]]
[[Category:Technical]]
[[Category:BIP|D]]

Developers

2012-12-11T04:07:26Z

BlueMatt:

* '''This list is not complete.''' Please make updates/corrections as needed.
* Attempt to sort by contribution
* Legend:
** "Author" = original author; "Lead" = current project lead
{|
| style="background:#90ff90" | active maintainer
| style="background:#ffffaa" | has made contributions
| style="background:#ff9090" | no involvement
|}

{|
! Name !! Reference !! BitcoinJ !! BFGMiner !! Tools !! Spesmilo !! Gentoo !! Supybot !! Other
|-
| Satoshi Nakamoto
|style="background:#90ff90"|Author/Retired
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| Bitcoin original designer
|-
| [[Gavin Andresen]]
|style="background:#90ff90"|Lead
| {{Table Value No}}
| {{Table Value No}}
|style="background:#90ff90"|Author
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| sirius-m
|style="background:#90ff90"|Retired
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| tcatm
| {{Table Value Yes}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
|-
| Jeff Garzik
| {{Table Value Yes}}
| {{Table Value No}}
|style="background:#90ff90"|Retired
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|style="background:#90ff90"|pushpool
|-
| TD
| {{Table Value No}}
|style="background:#90ff90"|Author
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Daniel Folkinshteyn
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
|-
| Luke Dashjr
| {{Table Value Yes}}
| {{Table Value No}}
|style="background:#90ff90"|Maintainer
| {{Table Value No}}
| {{Table Value Yes}}
| {{Table Value Yes}}
| {{Table Value Yes}}
|style="background:#90ff90"|URI, Wallet protocols, Eloipool
|-
| genjix
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|style="background:#90ff90"|Author
| {{Table Value No}}
| {{Table Value No}}
| https://bitcoinconsultancy.com/wiki/index.php/Libbitcoin
|-
| Matt Giuca
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Con Kolivas
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Mizery De Aria
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|style="background:#90ff90"|Author
| {{Table Value No}}
|-
| Laurent Bachelier
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
| {{Table Value No}}
|-
| Florian Schmaus
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
| {{Table Value No}}
|-
| BioMike
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
| {{Table Value No}}
|-
| Chris Moore
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Matt Corallo
| {{Table Value Yes}}
| {{Table Value Yes}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Pieter Wuille
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Marius Hanne
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| David FRANCOIS
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Nils Schneider
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Giel van Schijndel
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Fabian H jr.
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| ovdeathiam
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Dev Random
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Michal Zima
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Venkatesh Srinivas
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Vegard Nossum
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| JoelKatz
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Joerie de Gram
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Johannes Henninger
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Jeroenz0r
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Han Lin Yap
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Wladimir J. van der Laan
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Abraham Jewowich
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Michael Bemmerl
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Eric Hosmer
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Dawid Spiechowicz
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Stéphane Gimenez
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Patrick Varilly
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Jay Weisskopf
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Dylan Noblesmith
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| James Burkle
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Jordan Lewis
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Dean Lee
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| xHire
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| HostFat
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Jakob Kramer
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| ariel
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| dabaopku
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Federico Faggiano
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| m0ray
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Danube
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Carlos Pizarro
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Blitzboom
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Daniel Holbert
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Jaromil
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Carlo Alberto Ferraris
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Forrest Voight
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Amir Yalon
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| John Maguire
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Ricardo M. Correia
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Dan Helfman
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| gjs278
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Dan Loewenherz
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Eric Swanson
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Santiago M. Mola
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Shane Wegner
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Sven Slootweg
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| ojab
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| sandos
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Witchspace
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| laszloh
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|}

==See Also==

* [[Original client developers]]
* [[People]]

[[Category:Developer]]

Developers

2012-12-11T04:06:13Z

BlueMatt:

* '''This list is not complete.''' Please make updates/corrections as needed.
* Attempt to sort by contribution
* Legend:
** "Author" = original author; "Lead" = current project lead
{|
| style="background:#90ff90" | active maintainer
| style="background:#ffffaa" | has made contributions
| style="background:#ff9090" | no involvement
|}

{|
! Name !! Reference !! BitcoinJ !! BFGMiner !! Tools !! Spesmilo !! Gentoo !! Supybot !! Other
|-
| Satoshi Nakamoto
|style="background:#90ff90"|Author/Retired
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| Bitcoin original designer
|-
| [[Gavin Andresen]]
|style="background:#90ff90"|Lead
| {{Table Value No}}
| {{Table Value No}}
|style="background:#90ff90"|Author
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| sirius-m
|style="background:#90ff90"|Retired
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| tcatm
| {{Table Value Yes}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
|-
| Jeff Garzik
| {{Table Value Yes}}
| {{Table Value No}}
|style="background:#90ff90"|Retired
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|style="background:#90ff90"|pushpool
|-
| TD
| {{Table Value No}}
|style="background:#90ff90"|Author
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Daniel Folkinshteyn
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
|-
| Luke Dashjr
| {{Table Value Yes}}
| {{Table Value No}}
|style="background:#90ff90"|Maintainer
| {{Table Value No}}
| {{Table Value Yes}}
| {{Table Value Yes}}
| {{Table Value Yes}}
|style="background:#90ff90"|URI, Wallet protocols, Eloipool
|-
| genjix
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|style="background:#90ff90"|Author
| {{Table Value No}}
| {{Table Value No}}
| https://bitcoinconsultancy.com/wiki/index.php/Libbitcoin
|-
| Matt Giuca
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Con Kolivas
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Mizery De Aria
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|style="background:#90ff90"|Author
| {{Table Value No}}
|-
| Laurent Bachelier
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
| {{Table Value No}}
|-
| Florian Schmaus
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
| {{Table Value No}}
|-
| BioMike
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
| {{Table Value No}}
|-
| Chris Moore
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Matt Corallo
| {{Table value Yes}}
| {{Table Value Yes}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Pieter Wuille
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Marius Hanne
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| David FRANCOIS
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Nils Schneider
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Giel van Schijndel
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Fabian H jr.
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| ovdeathiam
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Dev Random
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Michal Zima
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Venkatesh Srinivas
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Vegard Nossum
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| JoelKatz
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Joerie de Gram
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Johannes Henninger
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Jeroenz0r
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Han Lin Yap
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Wladimir J. van der Laan
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Abraham Jewowich
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Michael Bemmerl
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Eric Hosmer
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Dawid Spiechowicz
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Stéphane Gimenez
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Patrick Varilly
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Jay Weisskopf
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Dylan Noblesmith
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| James Burkle
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Jordan Lewis
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Dean Lee
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| xHire
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| HostFat
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Jakob Kramer
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| ariel
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| dabaopku
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Federico Faggiano
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| m0ray
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Danube
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Carlos Pizarro
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Blitzboom
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Daniel Holbert
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Jaromil
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Carlo Alberto Ferraris
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Forrest Voight
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Amir Yalon
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| John Maguire
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Ricardo M. Correia
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Dan Helfman
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| gjs278
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Dan Loewenherz
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Eric Swanson
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Santiago M. Mola
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Shane Wegner
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Sven Slootweg
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| ojab
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| sandos
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Witchspace
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| laszloh
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|}

==See Also==

* [[Original client developers]]
* [[People]]

[[Category:Developer]]

Developers

2012-12-11T04:05:24Z

BlueMatt:

* '''This list is not complete.''' Please make updates/corrections as needed.
* Attempt to sort by contribution
* Legend:
** "Author" = original author; "Lead" = current project lead
{|
| style="background:#90ff90" | active maintainer
| style="background:#ffffaa" | has made contributions
| style="background:#ff9090" | no involvement
|}

{|
! Name !! Reference !! BitcoinJ !! BFGMiner !! Tools !! Spesmilo !! Gentoo !! Supybot !! Other
|-
| Satoshi Nakamoto
|style="background:#90ff90"|Author/Retired
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| Bitcoin original designer
|-
| [[Gavin Andresen]]
|style="background:#90ff90"|Lead
| {{Table Value No}}
| {{Table Value No}}
|style="background:#90ff90"|Author
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| sirius-m
|style="background:#90ff90"|Retired
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| tcatm
| {{Table Value Yes}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
|-
| Jeff Garzik
| {{Table Value Yes}}
| {{Table Value No}}
|style="background:#90ff90"|Retired
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|style="background:#90ff90"|pushpool
|-
| TD
| {{Table Value No}}
|style="background:#90ff90"|Author
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Daniel Folkinshteyn
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
|-
| Luke Dashjr
| {{Table Value Yes}}
| {{Table Value No}}
|style="background:#90ff90"|Maintainer
| {{Table Value No}}
| {{Table Value Yes}}
| {{Table Value Yes}}
| {{Table Value Yes}}
|style="background:#90ff90"|URI, Wallet protocols, Eloipool
|-
| genjix
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|style="background:#90ff90"|Author
| {{Table Value No}}
| {{Table Value No}}
| https://bitcoinconsultancy.com/wiki/index.php/Libbitcoin
|-
| Matt Giuca
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Con Kolivas
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Mizery De Aria
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|style="background:#90ff90"|Author
| {{Table Value No}}
|-
| Laurent Bachelier
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
| {{Table Value No}}
|-
| Florian Schmaus
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
| {{Table Value No}}
|-
| BioMike
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
| {{Table Value No}}
|-
| Chris Moore
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Matt Corallo
|style="background:#ffffaa"|
| {{Table Value Yes}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Pieter Wuille
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Marius Hanne
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| David FRANCOIS
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Nils Schneider
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Giel van Schijndel
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Fabian H jr.
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| ovdeathiam
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Dev Random
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Michal Zima
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Venkatesh Srinivas
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Vegard Nossum
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| JoelKatz
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Joerie de Gram
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Johannes Henninger
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Jeroenz0r
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Han Lin Yap
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Wladimir J. van der Laan
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Abraham Jewowich
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Michael Bemmerl
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Eric Hosmer
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Dawid Spiechowicz
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Stéphane Gimenez
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Patrick Varilly
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Jay Weisskopf
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Dylan Noblesmith
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| James Burkle
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Jordan Lewis
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Dean Lee
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| xHire
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| HostFat
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Jakob Kramer
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| ariel
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| dabaopku
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Federico Faggiano
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| m0ray
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Danube
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Carlos Pizarro
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Blitzboom
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Daniel Holbert
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Jaromil
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Carlo Alberto Ferraris
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Forrest Voight
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Amir Yalon
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| John Maguire
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Ricardo M. Correia
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Dan Helfman
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| gjs278
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Dan Loewenherz
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Eric Swanson
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Santiago M. Mola
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Shane Wegner
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Sven Slootweg
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| ojab
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| sandos
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Witchspace
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| laszloh
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|}

==See Also==

* [[Original client developers]]
* [[People]]

[[Category:Developer]]

Developers

2012-12-11T04:05:08Z

BlueMatt:

* '''This list is not complete.''' Please make updates/corrections as needed.
* Attempt to sort by contribution
* Legend:
** "Author" = original author; "Lead" = current project lead
{|
| style="background:#90ff90" | active maintainer
| style="background:#ffffaa" | has made contributions
| style="background:#ff9090" | no involvement
|}

{|
! Name !! Reference !! BitcoinJ !! BFGMiner !! Tools !! Spesmilo !! Gentoo !! Supybot !! Other
|-
| Satoshi Nakamoto
|style="background:#90ff90"|Author/Retired
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| Bitcoin original designer
|-
| [[Gavin Andresen]]
|style="background:#90ff90"|Lead
| {{Table Value No}}
| {{Table Value No}}
|style="background:#90ff90"|Author
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| sirius-m
|style="background:#90ff90"|Retired
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| tcatm
| {{Table Value Yes}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
|-
| Jeff Garzik
| {{Table Value Yes}}
| {{Table Value No}}
|style="background:#90ff90"|Retired
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|style="background:#90ff90"|pushpool
|-
| TD
| {{Table Value No}}
|style="background:#90ff90"|Author
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Daniel Folkinshteyn
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
|-
| Luke Dashjr
| {{Table Value Yes}}
| {{Table Value No}}
|style="background:#90ff90"|Maintainer
| {{Table Value No}}
| {{Table Value Yes}}
| {{Table Value Yes}}
| {{Table Value Yes}}
|style="background:#90ff90"|URI, Wallet protocols, Eloipool
|-
| genjix
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|style="background:#90ff90"|Author
| {{Table Value No}}
| {{Table Value No}}
| https://bitcoinconsultancy.com/wiki/index.php/Libbitcoin
|-
| Matt Giuca
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Con Kolivas
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Mizery De Aria
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|style="background:#90ff90"|Author
| {{Table Value No}}
|-
| Laurent Bachelier
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
| {{Table Value No}}
|-
| Florian Schmaus
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
| {{Table Value No}}
|-
| BioMike
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
| {{Table Value No}}
|-
| Chris Moore
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Matt Corallo
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value Yes}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Pieter Wuille
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Marius Hanne
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| David FRANCOIS
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Nils Schneider
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Giel van Schijndel
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Fabian H jr.
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| ovdeathiam
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Dev Random
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Michal Zima
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Venkatesh Srinivas
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Vegard Nossum
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| JoelKatz
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Joerie de Gram
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Johannes Henninger
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Jeroenz0r
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Han Lin Yap
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Wladimir J. van der Laan
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Abraham Jewowich
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Michael Bemmerl
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Eric Hosmer
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Dawid Spiechowicz
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Stéphane Gimenez
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Patrick Varilly
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Jay Weisskopf
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Dylan Noblesmith
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| James Burkle
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Jordan Lewis
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Dean Lee
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| xHire
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| HostFat
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Jakob Kramer
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| ariel
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| dabaopku
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Federico Faggiano
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| m0ray
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Danube
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Carlos Pizarro
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Blitzboom
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Daniel Holbert
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Jaromil
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Carlo Alberto Ferraris
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Forrest Voight
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Amir Yalon
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| John Maguire
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Ricardo M. Correia
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Dan Helfman
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| gjs278
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Dan Loewenherz
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Eric Swanson
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Santiago M. Mola
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Shane Wegner
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Sven Slootweg
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| ojab
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| sandos
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Witchspace
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| laszloh
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|}

==See Also==

* [[Original client developers]]
* [[People]]

[[Category:Developer]]

BIP 0037

2012-11-16T20:11:07Z

BlueMatt: /* New messages */

{{bip}}

<pre>
BIP: 37
Title: Connection Bloom filtering
Author: Mike Hearn <hearn@google.com>, Matt Corallo <bip@bluematt.me>
Status: Draft
Type: Standards Track
Created: 24-10-2012
</pre>

==Abstract==

This BIP adds new support to the peer-to-peer protocol that allows peers to reduce the amount of transaction data they are sent. Peers have the option of setting ''filters'' on each connection they make after the version handshake has completed. A filter is defined as a [http://en.wikipedia.org/wiki/Bloom_filter Bloom filter] on data derived from transactions. A Bloom filter is a probabilistic data structure which allows for testing set membership - they can have false positives but not false negatives.

This document will not go into the details of how Bloom filters work and the reader is referred to Wikipedia for an introduction to the topic.

==Motivation==

As Bitcoin grows in usage the amount of bandwidth needed to download blocks and transaction broadcasts increases. Clients implementing ''simplified payment verification'' do not attempt to fully verify the block chain, instead just checking that block headers connect together correctly and trusting that the transactions in a chain of high difficulty are in fact valid. See the Bitcoin paper for more detail on this mode.

Today, SPV clients have to download the entire contents of blocks and all broadcast transactions, only to throw away the vast majority of the transactions that are not relevant to their wallets. This slows down their synchronization process, wastes users bandwidth (which on phones is often metered) and increases memory usage. All three problems are triggering real user complaints for the Android "Bitcoin Wallet" app which implements SPV mode. In order to make chain synchronization fast, cheap and able to run on older phones with limited memory we want to have remote peers throw away irrelevant transactions before sending them across the network.

==Design rationale==

The most obvious way to implement the stated goal would be for clients to upload lists of their keys to the remote node. We take a more complex approach for the following reasons:

* Privacy: Because Bloom filters are probabilistic, with the false positive rate chosen by the client, nodes can trade off precision vs bandwidth usage. A node with access to lots of bandwidth may choose to have a high FP rate, meaning the remote peer cannot accurately know which transactions belong to the client and which don't. A node with very little bandwidth may choose to use a very accurate filter meaning that they only get sent transactions actually relevant to their wallet, but remote peers may be able to correlate transactions with IP addresses (and each other).
* Bloom filters are compact and testing membership in them is fast. This results in satisfying performance characteristics with minimal risk of opening up potential for DoS attacks.

==Specification==

===New messages===

We start by adding three new messages to the protocol:

* <code>filterload</code>, which sets the current Bloom filter on the connection
* <code>filteradd</code>, which adds the given data element to the connections current filter without requiring a completely new one to be set
* <code>filterclear</code>, which deletes the current filter and goes back to regular pre-BIP37 usage.

Note that there is no filterremove command because by their nature, Bloom filters are append-only data structures. Once an element is added it cannot be removed again without rebuilding the entire structure from scratch.

The <code>filterload</code> command is defined as follows:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || filter || uint8_t[] || The filter itself is simply a bit field of arbitrary byte-aligned size. The maximum size is 36,000 bytes.
|-
| 4 || nHashFuncs || uint32_t || The number of hash functions to use in this filter. The maximum value allowed in this field is 50.
|}

See below for a description of the Bloom filter algorithm and how to select nHashFuncs and filter size for a desired false positive rate.

Upon receiving a <code>filterload</code> command, the remote peer will immediately restrict the broadcast transactions it announces (in inv packets) to transactions matching the filter, where the matching algorithm is specified below.

The <code>filteradd</code> command is defined as follows:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || data || uint8_t[] || The data element to add to the current filter.
|}

The data field must be smaller than or equal to 520 bytes in size (the maximum size of any potentially matched object).

The given data element will be added to the Bloom filter. If no filter has been previously provided using <code>filterload</code>, a new one will be initialized that would have a false positive rate of, at a minimum, 0.1% with 1000 inserted elements. This command is useful if a new key or script is added to a clients wallet whilst it has connections to the network open, it avoids the need to re-calculate and send an entirely new filter to every peer.

The <code>filterclear</code> command has no arguments at all.

After a filter has been set, nodes don't merely stop announcing non-matching transactions, they can also serve filtered blocks. A filtered block is defined by the <code>merkleblock</code> message and is defined like this:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| 1 || txn_count || uint32_t || Number of transactions that matched the filter
|-
| ? || transactions || merkle_tx[] || A series of merkle_tx messages, defined below, for each transaction in the block that matched the filter.
|}

The <code>merkle_tx</code> message is defined below:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || index || uint32_t || The index in the original block that the transaction appeared at.
|-
| 32 || hash || uint256_t || The hash of the matching transaction.
|-
| ? || merkle_branch || uint256_t[] || A vector of hashes defining the Merkle branch linking this transaction to the merkle root in the block header
|}

See below for the format of the merkle branch.

As you can see a <code>merkleblock</code> message is a block header, plus identifying information for transactions that matched the filter, plus the Merkle branch which can be used to prove that the matching transaction data really did appear in the solved block. Clients can use this data to be sure that the remote node is not feeding them fake transactions that never appeared in a real block, although lying through omission is still possible.

===Extensions to existing messages===

The <code>version</code> command is extended with a new field:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1 byte || fRelay || bool || If false then broadcast transactions will not be announced until a filter{load,add,clear} command is received. If missing or true, no change in protocol behaviour occurs.
|}

SPV clients that wish to use Bloom filtering would normally set fRelay to false in the version message, then set a filter based on their wallet (or a subset of it, if they are overlapping different peers). Being able to opt-out of inv messages until the filter is set prevents a client being flooded with traffic in the brief window of time between finishing version handshaking and setting the filter.

The <code>getdata</code> command is extended to allow a new type in the <code>inv</code> submessage. The type field can now be <code>MSG_FILTERED_BLOCK (== 3)</code> rather than <code>MSG_BLOCK</code>. If no filter has been set on the connection, a request for filtered blocks is ignored. If a filter has been set, a <code>merkleblock</code> message is returned for the requested block hash. In addition, because a <code>merkleblock</code> message contains only a list of transaction hashes, transactions matching the filter should also be sent in separate tx messages. This avoids a slow roundtrip that would otherwise be required (receive hashes, didn't see some of these transactions yet, ask for them). Note that because there is currently no way to request transactions which are already in a block from a node (aside from requesting the full block), the set of matching transactions that the requesting node hasn't either received or announced with an inv must be sent and any additional transactions which match the filter may also be sent. This allows for clients (such as the reference client) to limit the number of invs it must remember a given node to have announced while still providing nodes with, at a minimum, all the transactions it needs.

===Filter matching algorithm===

The filter can be tested against arbitrary pieces of data, to see if that data was inserted by the client. Therefore the question arises of what pieces of data should be inserted/tested.

To determine if a transaction matches the filter, the following algorithm MUST be used. Once a match is found the algorithm aborts.

# Test the hash of the transaction itself.
# For each output, test each data element of the output script. This means each hash and key in the output script is tested independently. '''Important:''' if an output matches whilst testing a transaction, the node MUST update the filter by inserting the serialized COutPoint structure. See below for more details.
# For each input, test the serialized COutPoint structure.
# For each input, test each data element of the input script (note: input scripts only ever contain data elements).
# Otherwise there is no match.

In this way addresses, keys and script hashes (for P2SH outputs) can all be added to the filter. You can also match against classes of transactions that are marked with well known data elements in either inputs or outputs, for example, to implement various forms of [[Smart property]].

The test for outpoints is there to ensure you can find transactions spending outputs in your wallet, even though you don't know anything about their form. As you can see, once set on a connection the filter is '''not static''' and can change throughout the connections lifetime. This is done to avoid the following race condition:

# A client sets a filter matching a key in their wallet. They then start downloading the block chain. The part of the chain that the client is missing is requested using getblocks.
# The first block is read from disk by the serving peer. It contains TX 1 which sends money to the clients key. It matches the filter and is thus sent to the client.
# The second block is read from disk by the serving peer. It contains TX 2 which spends TX 1. However TX 2 does not contain any of the clients keys and is thus not sent. The client does not know the money they received was already spent.

By updating the bloom filter atomically in step 2 with the discovered outpoint, the filter will match against TX 2 in step 3 and the client will learn about all relevant transactions, despite that there is no pause between the node processing the first and second blocks.

===Merkle branch format===

A ''Merkle tree'' is a way of arranging a set of items as leaf nodes of tree in which the interior nodes are hashes of the concatenations of their child hashes. The root node is called the ''Merkle root''. Every Bitcoin block contains a Merkle root of the tree formed from the blocks transactions. By providing some elements of the trees interior nodes (called a ''Merkle branch'') a proof is formed that the given transaction was indeed in the block when it was being mined, but the size of the proof is much smaller than the size of the original block.

The branch is a list of hashes that can be used with the following algorithm.

# Let H = the hash of the transaction being checked for block inclusion.
# Let I = the index in the original block of the transaction being checked.
# For each element E in the branch:
## If I is even, H = SHA256(SHA256(concatenation of E and H))
## If I is odd, H = SHA256(SHA256(concatenation of H and E))
## Divide I by 2 (right-shift)
# If H is equal to the merkle root in the block header, the transaction was included

===Bloom filter format===

A Bloom filter is a bit-field in which bits are set based on feeding the data element to a set of different hash functions. The number of hash functions used is a parameter of the filter. In Bitcoin we use version 3 of the 32-bit Murmur hash function. To get N "different" hash functions we simply initialize the Murmur algorithm with the following formula:

<code>nHashNum * (MAX_UINT32 / (nHashFuncs - 1))</code>

i.e. if the filter is initialized with 4 hash functions, when the second function is needed h1 would be equal to 1431655765.

When loading a filter with the <code>filterload</code> command, there are two parameters that can be chosen. One is the size of the filter in bytes. The other is the number of hash functions to use. To select the parameters you can use the following formulas:

Let N be the number of elements you wish to insert into the set and P be the probability of a false positive, where 1.0 is "match everything" and zero is unachievable.

The size S of the filter in bytes is given by <code>(-1 / pow(log(2), 2) * N * log(P)) / 8</code>. Of course you must ensure it does not go over the maximum size (36,000).

The number of hash functions required is given by <code>S * 8 / N * log(2)</code>.

==Copyright==

This document is placed in the public domain.

[[Category:Developer]]
[[Category:Technical]]
[[Category:BIP|D]]

BIP 0037

2012-11-16T20:02:27Z

BlueMatt: 520 byte max for filteradd

{{bip}}

<pre>
BIP: 37
Title: Connection Bloom filtering
Author: Mike Hearn <hearn@google.com>, Matt Corallo <bip@bluematt.me>
Status: Draft
Type: Standards Track
Created: 24-10-2012
</pre>

==Abstract==

This BIP adds new support to the peer-to-peer protocol that allows peers to reduce the amount of transaction data they are sent. Peers have the option of setting ''filters'' on each connection they make after the version handshake has completed. A filter is defined as a [http://en.wikipedia.org/wiki/Bloom_filter Bloom filter] on data derived from transactions. A Bloom filter is a probabilistic data structure which allows for testing set membership - they can have false positives but not false negatives.

This document will not go into the details of how Bloom filters work and the reader is referred to Wikipedia for an introduction to the topic.

==Motivation==

As Bitcoin grows in usage the amount of bandwidth needed to download blocks and transaction broadcasts increases. Clients implementing ''simplified payment verification'' do not attempt to fully verify the block chain, instead just checking that block headers connect together correctly and trusting that the transactions in a chain of high difficulty are in fact valid. See the Bitcoin paper for more detail on this mode.

Today, SPV clients have to download the entire contents of blocks and all broadcast transactions, only to throw away the vast majority of the transactions that are not relevant to their wallets. This slows down their synchronization process, wastes users bandwidth (which on phones is often metered) and increases memory usage. All three problems are triggering real user complaints for the Android "Bitcoin Wallet" app which implements SPV mode. In order to make chain synchronization fast, cheap and able to run on older phones with limited memory we want to have remote peers throw away irrelevant transactions before sending them across the network.

==Design rationale==

The most obvious way to implement the stated goal would be for clients to upload lists of their keys to the remote node. We take a more complex approach for the following reasons:

* Privacy: Because Bloom filters are probabilistic, with the false positive rate chosen by the client, nodes can trade off precision vs bandwidth usage. A node with access to lots of bandwidth may choose to have a high FP rate, meaning the remote peer cannot accurately know which transactions belong to the client and which don't. A node with very little bandwidth may choose to use a very accurate filter meaning that they only get sent transactions actually relevant to their wallet, but remote peers may be able to correlate transactions with IP addresses (and each other).
* Bloom filters are compact and testing membership in them is fast. This results in satisfying performance characteristics with minimal risk of opening up potential for DoS attacks.

==Specification==

===New messages===

We start by adding three new messages to the protocol:

* <code>filterload</code>, which sets the current Bloom filter on the connection
* <code>filteradd</code>, which adds the given data element to the connections current filter without requiring a completely new one to be set
* <code>filterclear</code>, which deletes the current filter and goes back to regular pre-BIP37 usage.

Note that there is no filterremove command because by their nature, Bloom filters are append-only data structures. Once an element is added it cannot be removed again without rebuilding the entire structure from scratch.

The <code>filterload</code> command is defined as follows:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || filter || uint8_t[] || The filter itself is simply a bit field of arbitrary byte-aligned size. The maximum size is 36,000 bytes.
|-
| 4 || nHashFuncs || uint32_t || The number of hash functions to use in this filter. The maximum value allowed in this field is 50.
|}

See below for a description of the Bloom filter algorithm and how to select nHashFuncs and filter size for a desired false positive rate.

Upon receiving a <code>filterload</code> command, the remote peer will immediately restrict the broadcast transactions it announces (in inv packets) to transactions matching the filter, where the matching algorithm is specified below.

The <code>filteradd</code> command is defined as follows:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || data || uint8_t[] || The data element to add to the current filter.
|}

The data field must be smaller than or equal to 520 bytes in size (the maximum size of any potentially matched object).

The given data element will be added to the Bloom filter. If no filter has been previously provided using <code>filterload</code>, a new one will be initialized that would have a false positive rate of 0.1% with 1000 inserted elements. This command is useful if a new key or script is added to a clients wallet whilst it has connections to the network open, it avoids the need to re-calculate and send an entirely new filter to every peer.

The <code>filterclear</code> command has no arguments at all.

After a filter has been set, nodes don't merely stop announcing non-matching transactions, they can also serve filtered blocks. A filtered block is defined by the <code>merkleblock</code> message and is defined like this:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| 1 || txn_count || uint32_t || Number of transactions that matched the filter
|-
| ? || transactions || merkle_tx[] || A series of merkle_tx messages, defined below, for each transaction in the block that matched the filter.
|}

The <code>merkle_tx</code> message is defined below:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || index || uint32_t || The index in the original block that the transaction appeared at.
|-
| 32 || hash || uint256_t || The hash of the matching transaction.
|-
| ? || merkle_branch || uint256_t[] || A vector of hashes defining the Merkle branch linking this transaction to the merkle root in the block header
|}

See below for the format of the merkle branch.

As you can see a <code>merkleblock</code> message is a block header, plus identifying information for transactions that matched the filter, plus the Merkle branch which can be used to prove that the matching transaction data really did appear in the solved block. Clients can use this data to be sure that the remote node is not feeding them fake transactions that never appeared in a real block, although lying through omission is still possible.

===Extensions to existing messages===

The <code>version</code> command is extended with a new field:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1 byte || fRelay || bool || If false then broadcast transactions will not be announced until a filter{load,add,clear} command is received. If missing or true, no change in protocol behaviour occurs.
|}

SPV clients that wish to use Bloom filtering would normally set fRelay to false in the version message, then set a filter based on their wallet (or a subset of it, if they are overlapping different peers). Being able to opt-out of inv messages until the filter is set prevents a client being flooded with traffic in the brief window of time between finishing version handshaking and setting the filter.

The <code>getdata</code> command is extended to allow a new type in the <code>inv</code> submessage. The type field can now be <code>MSG_FILTERED_BLOCK (== 3)</code> rather than <code>MSG_BLOCK</code>. If no filter has been set on the connection, a request for filtered blocks is ignored. If a filter has been set, a <code>merkleblock</code> message is returned for the requested block hash. In addition, because a <code>merkleblock</code> message contains only a list of transaction hashes, transactions matching the filter should also be sent in separate tx messages. This avoids a slow roundtrip that would otherwise be required (receive hashes, didn't see some of these transactions yet, ask for them). Note that because there is currently no way to request transactions which are already in a block from a node (aside from requesting the full block), the set of matching transactions that the requesting node hasn't either received or announced with an inv must be sent and any additional transactions which match the filter may also be sent. This allows for clients (such as the reference client) to limit the number of invs it must remember a given node to have announced while still providing nodes with, at a minimum, all the transactions it needs.

===Filter matching algorithm===

The filter can be tested against arbitrary pieces of data, to see if that data was inserted by the client. Therefore the question arises of what pieces of data should be inserted/tested.

To determine if a transaction matches the filter, the following algorithm MUST be used. Once a match is found the algorithm aborts.

# Test the hash of the transaction itself.
# For each output, test each data element of the output script. This means each hash and key in the output script is tested independently. '''Important:''' if an output matches whilst testing a transaction, the node MUST update the filter by inserting the serialized COutPoint structure. See below for more details.
# For each input, test the serialized COutPoint structure.
# For each input, test each data element of the input script (note: input scripts only ever contain data elements).
# Otherwise there is no match.

In this way addresses, keys and script hashes (for P2SH outputs) can all be added to the filter. You can also match against classes of transactions that are marked with well known data elements in either inputs or outputs, for example, to implement various forms of [[Smart property]].

The test for outpoints is there to ensure you can find transactions spending outputs in your wallet, even though you don't know anything about their form. As you can see, once set on a connection the filter is '''not static''' and can change throughout the connections lifetime. This is done to avoid the following race condition:

# A client sets a filter matching a key in their wallet. They then start downloading the block chain. The part of the chain that the client is missing is requested using getblocks.
# The first block is read from disk by the serving peer. It contains TX 1 which sends money to the clients key. It matches the filter and is thus sent to the client.
# The second block is read from disk by the serving peer. It contains TX 2 which spends TX 1. However TX 2 does not contain any of the clients keys and is thus not sent. The client does not know the money they received was already spent.

By updating the bloom filter atomically in step 2 with the discovered outpoint, the filter will match against TX 2 in step 3 and the client will learn about all relevant transactions, despite that there is no pause between the node processing the first and second blocks.

===Merkle branch format===

A ''Merkle tree'' is a way of arranging a set of items as leaf nodes of tree in which the interior nodes are hashes of the concatenations of their child hashes. The root node is called the ''Merkle root''. Every Bitcoin block contains a Merkle root of the tree formed from the blocks transactions. By providing some elements of the trees interior nodes (called a ''Merkle branch'') a proof is formed that the given transaction was indeed in the block when it was being mined, but the size of the proof is much smaller than the size of the original block.

The branch is a list of hashes that can be used with the following algorithm.

# Let H = the hash of the transaction being checked for block inclusion.
# Let I = the index in the original block of the transaction being checked.
# For each element E in the branch:
## If I is even, H = SHA256(SHA256(concatenation of E and H))
## If I is odd, H = SHA256(SHA256(concatenation of H and E))
## Divide I by 2 (right-shift)
# If H is equal to the merkle root in the block header, the transaction was included

===Bloom filter format===

A Bloom filter is a bit-field in which bits are set based on feeding the data element to a set of different hash functions. The number of hash functions used is a parameter of the filter. In Bitcoin we use version 3 of the 32-bit Murmur hash function. To get N "different" hash functions we simply initialize the Murmur algorithm with the following formula:

<code>nHashNum * (MAX_UINT32 / (nHashFuncs - 1))</code>

i.e. if the filter is initialized with 4 hash functions, when the second function is needed h1 would be equal to 1431655765.

When loading a filter with the <code>filterload</code> command, there are two parameters that can be chosen. One is the size of the filter in bytes. The other is the number of hash functions to use. To select the parameters you can use the following formulas:

Let N be the number of elements you wish to insert into the set and P be the probability of a false positive, where 1.0 is "match everything" and zero is unachievable.

The size S of the filter in bytes is given by <code>(-1 / pow(log(2), 2) * N * log(P)) / 8</code>. Of course you must ensure it does not go over the maximum size (36,000).

The number of hash functions required is given by <code>S * 8 / N * log(2)</code>.

==Copyright==

This document is placed in the public domain.

[[Category:Developer]]
[[Category:Technical]]
[[Category:BIP|D]]

BIP 0037

2012-11-02T21:06:11Z

BlueMatt: /* Extensions to existing messages */

{{bip}}

<pre>
BIP: 37
Title: Connection Bloom filtering
Author: Mike Hearn <hearn@google.com>, Matt Corallo <bip@bluematt.me>
Status: Draft
Type: Standards Track
Created: 24-10-2012
</pre>

==Abstract==

This BIP adds new support to the peer-to-peer protocol that allows peers to reduce the amount of transaction data they are sent. Peers have the option of setting ''filters'' on each connection they make after the version handshake has completed. A filter is defined as a [http://en.wikipedia.org/wiki/Bloom_filter Bloom filter] on data derived from transactions. A Bloom filter is a probabilistic data structure which allows for testing set membership - they can have false positives but not false negatives.

This document will not go into the details of how Bloom filters work and the reader is referred to Wikipedia for an introduction to the topic.

==Motivation==

As Bitcoin grows in usage the amount of bandwidth needed to download blocks and transaction broadcasts increases. Clients implementing ''simplified payment verification'' do not attempt to fully verify the block chain, instead just checking that block headers connect together correctly and trusting that the transactions in a chain of high difficulty are in fact valid. See the Bitcoin paper for more detail on this mode.

Today, SPV clients have to download the entire contents of blocks and all broadcast transactions, only to throw away the vast majority of the transactions that are not relevant to their wallets. This slows down their synchronization process, wastes users bandwidth (which on phones is often metered) and increases memory usage. All three problems are triggering real user complaints for the Android "Bitcoin Wallet" app which implements SPV mode. In order to make chain synchronization fast, cheap and able to run on older phones with limited memory we want to have remote peers throw away irrelevant transactions before sending them across the network.

==Design rationale==

The most obvious way to implement the stated goal would be for clients to upload lists of their keys to the remote node. We take a more complex approach for the following reasons:

* Privacy: Because Bloom filters are probabilistic, with the false positive rate chosen by the client, nodes can trade off precision vs bandwidth usage. A node with access to lots of bandwidth may choose to have a high FP rate, meaning the remote peer cannot accurately know which transactions belong to the client and which don't. A node with very little bandwidth may choose to use a very accurate filter meaning that they only get sent transactions actually relevant to their wallet, but remote peers may be able to correlate transactions with IP addresses (and each other).
* Bloom filters are compact and testing membership in them is fast. This results in satisfying performance characteristics with minimal risk of opening up potential for DoS attacks.

==Specification==

===New messages===

We start by adding three new messages to the protocol:

* <code>filterload</code>, which sets the current Bloom filter on the connection
* <code>filteradd</code>, which adds the given data element to the connections current filter without requiring a completely new one to be set
* <code>filterclear</code>, which deletes the current filter and goes back to regular pre-BIP37 usage.

Note that there is no filterremove command because by their nature, Bloom filters are append-only data structures. Once an element is added it cannot be removed again without rebuilding the entire structure from scratch.

The <code>filterload</code> command is defined as follows:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || filter || uint8_t[] || The filter itself is simply a bit field of arbitrary byte-aligned size. The maximum size is 36,000 bytes.
|-
| 4 || nHashFuncs || uint32_t || The number of hash functions to use in this filter. The maximum value allowed in this field is 50.
|}

See below for a description of the Bloom filter algorithm and how to select nHashFuncs and filter size for a desired false positive rate.

Upon receiving a <code>filterload</code> command, the remote peer will immediately restrict the broadcast transactions it announces (in inv packets) to transactions matching the filter, where the matching algorithm is specified below.

The <code>filteradd</code> command is defined as follows:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || data || uint8_t[] || The data element to add to the current filter.
|}

The data field can be of any size up to the maximum message size limit.

The given data element will be added to the Bloom filter. If no filter has been previously provided using <code>filterload</code>, a new one will be initialized that would have a false positive rate of 0.1% with 1000 inserted elements. This command is useful if a new key or script is added to a clients wallet whilst it has connections to the network open, it avoids the need to re-calculate and send an entirely new filter to every peer.

The <code>filterclear</code> command has no arguments at all.

After a filter has been set, nodes don't merely stop announcing non-matching transactions, they can also serve filtered blocks. A filtered block is defined by the <code>merkleblock</code> message and is defined like this:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| 1 || txn_count || uint32_t || Number of transactions that matched the filter
|-
| ? || transactions || merkle_tx[] || A series of merkle_tx messages, defined below, for each transaction in the block that matched the filter.
|}

The <code>merkle_tx</code> message is defined below:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || index || uint32_t || The index in the original block that the transaction appeared at.
|-
| 32 || hash || uint256_t || The hash of the matching transaction.
|-
| ? || merkle_branch || uint256_t[] || A vector of hashes defining the Merkle branch linking this transaction to the merkle root in the block header
|}

See below for the format of the merkle branch.

As you can see a <code>merkleblock</code> message is a block header, plus identifying information for transactions that matched the filter, plus the Merkle branch which can be used to prove that the matching transaction data really did appear in the solved block. Clients can use this data to be sure that the remote node is not feeding them fake transactions that never appeared in a real block, although lying through omission is still possible.

===Extensions to existing messages===

The <code>version</code> command is extended with a new field:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1 byte || fRelay || bool || If false then broadcast transactions will not be announced until a filter{load,add,clear} command is received. If missing or true, no change in protocol behaviour occurs.
|}

SPV clients that wish to use Bloom filtering would normally set fRelay to false in the version message, then set a filter based on their wallet (or a subset of it, if they are overlapping different peers). Being able to opt-out of inv messages until the filter is set prevents a client being flooded with traffic in the brief window of time between finishing version handshaking and setting the filter.

The <code>getdata</code> command is extended to allow a new type in the <code>inv</code> submessage. The type field can now be <code>MSG_FILTERED_BLOCK (== 3)</code> rather than <code>MSG_BLOCK</code>. If no filter has been set on the connection, a request for filtered blocks is ignored. If a filter has been set, a <code>merkleblock</code> message is returned for the requested block hash. In addition, because a <code>merkleblock</code> message contains only a list of transaction hashes, transactions matching the filter should also be sent in separate tx messages. This avoids a slow roundtrip that would otherwise be required (receive hashes, didn't see some of these transactions yet, ask for them). Note that because there is currently no way to request transactions which are already in a block from a node (aside from requesting the full block), the set of matching transactions that the requesting node hasn't either received or announced with an inv must be sent and any additional transactions which match the filter may also be sent. This allows for clients (such as the reference client) to limit the number of invs it must remember a given node to have announced while still providing nodes with, at a minimum, all the transactions it needs.

===Filter matching algorithm===

The filter can be tested against arbitrary pieces of data, to see if that data was inserted by the client. Therefore the question arises of what pieces of data should be inserted/tested.

To determine if a transaction matches the filter, the following algorithm MUST be used. Once a match is found the algorithm aborts.

# Test the hash of the transaction itself.
# For each output, test each data element of the output script. This means each hash and key in the output script is tested independently. '''Important:''' if an output matches whilst testing a transaction, the node MUST update the filter by inserting the serialized COutPoint structure. See below for more details.
# For each input, test the serialized COutPoint structure.
# For each input, test each data element of the input script (note: input scripts only ever contain data elements).
# Otherwise there is no match.

In this way addresses, keys and script hashes (for P2SH outputs) can all be added to the filter. You can also match against classes of transactions that are marked with well known data elements in either inputs or outputs, for example, to implement various forms of [[Smart property]].

The test for outpoints is there to ensure you can find transactions spending outputs in your wallet, even though you don't know anything about their form. As you can see, once set on a connection the filter is '''not static''' and can change throughout the connections lifetime. This is done to avoid the following race condition:

# A client sets a filter matching a key in their wallet. They then start downloading the block chain. The part of the chain that the client is missing is requested using getblocks.
# The first block is read from disk by the serving peer. It contains TX 1 which sends money to the clients key. It matches the filter and is thus sent to the client.
# The second block is read from disk by the serving peer. It contains TX 2 which spends TX 1. However TX 2 does not contain any of the clients keys and is thus not sent. The client does not know the money they received was already spent.

By updating the bloom filter atomically in step 2 with the discovered outpoint, the filter will match against TX 2 in step 3 and the client will learn about all relevant transactions, despite that there is no pause between the node processing the first and second blocks.

===Merkle branch format===

A ''Merkle tree'' is a way of arranging a set of items as leaf nodes of tree in which the interior nodes are hashes of the concatenations of their child hashes. The root node is called the ''Merkle root''. Every Bitcoin block contains a Merkle root of the tree formed from the blocks transactions. By providing some elements of the trees interior nodes (called a ''Merkle branch'') a proof is formed that the given transaction was indeed in the block when it was being mined, but the size of the proof is much smaller than the size of the original block.

The branch is a list of hashes that can be used with the following algorithm.

# Let H = the hash of the transaction being checked for block inclusion.
# Let I = the index in the original block of the transaction being checked.
# For each element E in the branch:
## If I is even, H = SHA256(SHA256(concatenation of E and H))
## If I is odd, H = SHA256(SHA256(concatenation of H and E))
## Divide I by 2 (right-shift)
# If H is equal to the merkle root in the block header, the transaction was included

===Bloom filter format===

A Bloom filter is a bit-field in which bits are set based on feeding the data element to a set of different hash functions. The number of hash functions used is a parameter of the filter. In Bitcoin we use version 3 of the 32-bit Murmur hash function. To get N "different" hash functions we simply initialize the Murmur algorithm with the following formula:

<code>nHashNum * (MAX_UINT32 / (nHashFuncs - 1))</code>

i.e. if the filter is initialized with 4 hash functions, when the second function is needed h1 would be equal to 1431655765.

When loading a filter with the <code>filterload</code> command, there are two parameters that can be chosen. One is the size of the filter in bytes. The other is the number of hash functions to use. To select the parameters you can use the following formulas:

Let N be the number of elements you wish to insert into the set and P be the probability of a false positive, where 1.0 is "match everything" and zero is unachievable.

The size S of the filter in bytes is given by <code>(-1 / pow(log(2), 2) * N * log(P)) / 8</code>. Of course you must ensure it does not go over the maximum size (36,000).

The number of hash functions required is given by <code>S * 8 / N * log(2)</code>.

==Copyright==

This document is placed in the public domain.

[[Category:Developer]]
[[Category:Technical]]
[[Category:BIP|D]]

Fallback Nodes

2012-10-12T03:33:42Z

BlueMatt: /* IPv4 Nodes */

This is a list of nodes which are considered reliable. <del>Nodes from this list which are down for more than 24 hours will be automatically removed and status of each node is displayed and updated every hour by [[User:WikiBot|WikiBot]] </del>.
'''Wikibot is currently malfunctioning and is incorrectly marking nodes running version 0.6 as being down'''.

== How to use this list ==

=== Connect to nodes ===

You can connect to these nodes with the ''-addnode=ip'' switch instead of the usual node harvesting process (through IRC or via the embedded nodelist). You can connect to more than one node by using ''-addnode=ip'' more than once. It is usually a good idea to connect to more than one of these nodes.

==== Nodes without a fixed ip ====

If the node IP is not fixed (see "Fixed" column), you will have to resolve the node's name (first column) each time the IP changes. Some nodes may have their ip change once a day, some others once a month, and some others may stay on the same IP for years. Still, as long as the IP is not fixed, there is no guarantee it will stay the same.

In order to enable hostname lookups for the ''-addnode'' and ''-connect'' parameters, you must additionally provide the ''-dns'' parameter. Example:
bitcoind -dns -addnode=bitcoin.es

Versions prior to 0.3.22 do not support hostnames to the ''-addnode'' parameter, so you must do the resolving part for it. For example on linux:
bitcoind -addnode=$(dig +short bitcoin.es)

=== IP Transactions ===

You can also send [[IP Transactions]] to these nodes. If you include your bitcoin address in the "message" field, you may have your coins back.

=== Tor network ===

To use tor .onion addresses ([[Fallback_Nodes#Tor_nodes|listed below]]), you will need to map virtual ips via the ''torrc'' file:

mapaddress 192.0.2.2 vso3r6cmjoomhhgg.onion
mapaddress 192.0.2.3 sjdntqu5roj4q6lo.onion

And then put these IPs in your bitcoin.conf (or run bitcoin with -connect).

connect=192.0.2.2
connect=192.0.2.3

You can use any arbitrary IP addresses with MapAddress, though some of the common non-routable ranges (10.*, 192.168.*) will not work due to a Bitcoin bug (reference?). 192.0.2.1-192.0.2.255 is the recommended range because it is both non-routable and compatible with Bitcoin.

If you would like to use these nodes in addition to the hard-coded node list in the client, you can substitute "connect" with "addnode". However, if you want to keep all your Bitcoin communication strictly within the Tor network, it is recommended that you use "connect."

Additional suggested settings for hidden node operators:

noirc=1
upnp=0
listen=1

== Nodes list ==

=== IPv6 Nodes ===
{|class="wikitable sortable"
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-

| 2001:470:8:2e1::40 || ? || 2001:470:8:2e1::40 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes
|-


|}

=== IPv4 Nodes ===
'''Wikibot is currently malfunctioning and is incorrectly marking nodes running 0.6 as being down'''.
{|class="wikitable sortable"
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-

| dorm.bluematt.me || Matt Corallo || 152.23.202.249 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || No
|-
| 62.75.216.13 || exMULTI, Inc. || 62.75.216.13 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No
|-
| 69.64.34.118 || exMULTI, Inc. || 69.64.34.118 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No
|-
| 79.160.221.140 || K-Norway || 79.160.221.140 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| netzbasis.de || unknown3 || 81.169.129.25 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| btc.turboadmin.com || osmosis || 98.143.152.14 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No
|-
| fallback.bitcoin.zhoutong.com || Zhou Tong || 117.121.241.140 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No
|-
| bauhaus.csail.mit.edu || imsaguy || 128.30.96.44 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| jun.dashjr.org || Luke-Jr || 173.242.112.53 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || ||
|-
| cheaperinbitcoins.com || Xenland/Shane || 184.154.36.82 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| django.webflows.fr || unknown2 || 188.165.213.169 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| 204.9.55.71 || toasty || 204.9.55.71 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| btcnode.novit.ro || ovidiusoft - novit.ro || 93.187.142.114 || {{Table Value No}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| porgressbar.sk || progressbar hackerspace || 91.210.181.21 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes
|-
| faucet.bitcoin.st || bitcoin street || 64.27.57.225 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes
|-
| bitcoin.securepayment.cc || SecurePayment CC || 63.247.147.163 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes

|}

There is a list of nodes which have been seen on the network recently at http://blockchain.info/connected-nodes

=== Tor nodes ===

{|class="wikitable sortable"
! Hostname !! Owner !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-
| 6hgmaxwellgpv2oe.onion|| Gmaxwell || up || 2012-07-01 || No
|-
| pqosrh6wfaucet32.onion|| bitcoin street || up || 2012-08-29 || No
|-
| btc4ulpftizx5b72.onion || TorNode || up || 2012-06-22 || Yes
|-
| 7hxvg2lvr2ashzli.onion || Tuxavant || up || 2012-06-23 || ?
|-
| siqdznszjf4e6v5j.onion || Tuxavant || up || 2012-06-23 || ?
|-
| fpt6orohw2nuf2kn.onion || Tril || up || 2012-06-23 || No
|-
| vso3r6cmjoomhhgg.onion || echelon || up || 2012-09-16 || Yes
|-
| sjdntqu5roj4q6lo.onion || torservers || up || 2012-05-19 || ?
|-
| bitcoin2bkgm3fke.onion || ? || down || 2012-05-19 || Yes
|-
| ijzt2eeizty3p5xe.onion || ? || ? || 2011-02-11 || Yes
|-
| j43z65b6r2usg3vk.onion || Dybbuk || ? || 2011-02-11 || Yes
|-
| pvuif6nonbhj3o3r.onion || ? || ? || 2011-02-11 || Yes
|-
| c5qvugpewwyyy5oz.onion || ? || ? || 2011-02-11 || Yes
|-
| bitcoinbudtoeks7.onion || ? || ? || 2011-02-11 || ?
|-
| iy6ni3wkqazp4ytu.onion || ? || ? || 2011-02-11 || ?
|-
| h4kklwodpcmo6cbq.onion || ? || ? || 2011-02-11 || ?
|-
| vv6kcfscuntybrzm.onion || ? || ? || 2011-02-11 || ?
|-
| nlnsivjku4x4lu5n.onion || ? || ? || 2011-02-11 || ?
|-
| xqzfakpeuvrobvpj.onion || ? || ? || 2010-11-13 || No
|-
| 4lmduyac3svgrrav.onion || ? || ? || 2011-02-11 || No
|-
| usasx4urod3yj4az.onion || ? || ? || 2011-02-11 || No
|-
| e3tn727fywnioxrc.onion || ? || ? || 2011-11-01 || No
|-
| p2hwc26zdsrqxiix.onion || redemerald || down || 2012-05-25 || No
|-
| bxfna6fhddpzduck.onion || ? || ? || ? || ?
|-
| kjy2eqzk4zwi5zd3.onion || sipa || up || 2012-06-23 || No
|-
| mutqcuh7hwxmhx3k.onion || Xirafe || up || 2012-06-23 || ?
|-
| r4de4zf4lyniu4mx.onion:8444 || ? || up || 2012-06-26 || ?
|-
| bitcoinprwwpuinm.onion:8333 || ? || up || 2012-06-26 || ?
|}

== Adding a node ==

Before adding yourself as a fallback node, you should be sure your node will stay online for a long time. If a node is offline for more than 24 hours it will be removed from the list.

To add a node in this list, you just need the ip/hostname and your name, the other fields will be filled automatically. Insert the following lines before the <tt>END NODELIST</tt> line:

<nowiki>|-
| ip || your name</nowiki>

==See Also==

* [[Network|Bitcoin Network]]
* [http://nodes.bitcoin.st Fallback Nodes] List of longest running Bitcoin Nodes listed by Country.

Protocol documentation

2012-08-13T16:06:23Z

BlueMatt:

Sources:
* [[Original Bitcoin client]] source

Type names used in this documentation are from the C99 standard.

For protocol used in mining, see [[Getwork]].

==Common standards==

=== Hashes ===

Usually, when a hash is computed within bitcoin, it is computed twice. Most of the time [http://en.wikipedia.org/wiki/SHA-2 SHA-256] hashes are used, however [http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160] is also used when a shorter hash is desirable (for example when creating a bitcoin address).

Example of double-SHA-256 encoding of string "hello":

hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)

For bitcoin addresses (RIPEMD-160) this would give:

hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round is sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (with ripemd-160)

=== Merkle Trees ===

Merkle trees are binary trees of hashes. Merkle trees in bitcoin use '''Double''' SHA-256, and are built up as so:

hash(a) = sha256(sha256(a))

hash(a) hash(b) hash(c)
hash(hash(a)+hash(b)) hash(hash(c)+hash(c))
hash(hash(hash(a)+hash(b))+hash(hash(c)+hash(c)))

They are paired up, with the last element being _duplicated_.

Note: Hashes in Merkle Tree displayed in the [[Block Explorer]] are of little-endian notation. For some implementations and [http://www.fileformat.info/tool/hash.htm calculations], the bits need to be reversed before they are hashed, and again after the hashing operation.

=== Signatures ===

Bitcoin uses [http://en.wikipedia.org/wiki/Elliptic_curve_cryptography Elliptic Curve] [http://en.wikipedia.org/wiki/Digital_Signature_Algorithm Digital Signature Algorithm] ([http://en.wikipedia.org/wiki/Elliptic_Curve_DSA ECDSA]) to sign transactions.

For ECDSA the secp256k1 curve from http://www.secg.org/collateral/sec2_final.pdf is used.

Public keys (in scripts) are given as 04 <x> <y> where ''x'' and ''y'' are 32 byte big-endian integers representing the coordinates of a point on the curve or in compressed form given as <sign> <x> where <sign> is 0x02 if ''y'' is even and 0x03 if ''y'' is odd. Signatures use [http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER encoding] to pack the ''r'' and ''s'' components into a single byte stream (this is also what OpenSSL produces by default).

=== Transaction Verification ===
Transactions are cryptographically signed records that reassign ownership of Bitcoins to new addresses. Transactions have ''inputs'' - records which reference the funds from other previous transactions - and ''outputs'' - records which determine the new owner of the transferred Bitcoins, and which will be referenced as inputs in future transactions as those funds are respent.

Each ''input'' must have a cryptographic digital signature that unlocks the funds from the prior transaction. Only the person possessing the appropriate [[private key]] is able to create a satisfactory signature; this in effect ensures that funds can only be spent by their owners.

Each ''output'' determines which Bitcoin address (or other criteria, see [[Scripting]]) is the recipient of the funds.

In a transaction, the sum of all inputs must be equal to or greater than the sum of all outputs. If the inputs exceed the outputs, the difference is considered a [[transaction fee]], and is redeemable by whoever first includes the transaction into the block chain.

A special kind of transaction, called a [[coinbase transaction]], has no inputs. It is created by [[miners]], and there is one coinbase transaction per block. Because each block comes with a reward of newly created Bitcoins (e.g. 50 BTC for the first 210,000 blocks), the first transaction of a block is, with few exceptions, the transaction that grants those coins to their recipient (the miner). In addition to the newly created Bitcoins, the coinbase transaction is also used for assigning the recipient of any transaction fees that were paid within the other transactions being included in the same block. The coinbase transaction can assign the entire reward to a single Bitcoin address, or split it in portions among multiple addresses, just like any other transaction. Coinbase transactions always contain outputs totaling the sum of the block reward plus all transaction fees collected from the other transactions in the same block.

Most Bitcoin outputs encumber the newly transferred coins with a single ECDSA private key. The actual record saved with inputs and outputs isn't necessarily a key, but a ''script''. Bitcoin uses an interpreted scripting system to determine whether an output's criteria have been satisfied, with which more complex operations are possible, such as outputs that require two ECDSA signatures, or two-of-three-signature schemes. An output that references a single Bitcoin address is a ''typical'' output; an output actually contains this information in the form of a script that requires a single ECDSA signature (see [[OP_CHECKSIG]]). The output script specifies what must be provided to unlock the funds later, and when the time comes in the future to spend the transaction in another input, that input must provide all of the thing(s) that satisfy the requirements defined by the original output script.

=== Addresses ===

A bitcoin address is in fact the hash of a ECDSA public key, computed this way:

Version = 1 byte of 0 (zero); on the test network, this is 1 byte of 111
Key hash = Version concatenated with RIPEMD-160(SHA-256(public key))
Checksum = 1st 4 bytes of SHA-256(SHA-256(Key hash))
Bitcoin Address = Base58Encode(Key hash concatenated with Checksum)

The Base58 encoding used is home made, and has some differences. Especially, leading zeroes are kept as single zeroes when conversion happens.

== Common structures ==

Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.

=== Message structure ===

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || magic || uint32_t || Magic value indicating message origin network, and used to seek to next message when stream state is unknown
|-
| 12 || command || char[12] || ASCII string identifying the packet content, NULL padded (non-NULL padding results in packet rejected)
|-
| 4 || length || uint32_t || Length of payload in number of bytes
|-
| 4 || checksum || uint32_t || First 4 bytes of sha256(sha256(payload))
|-
| ? || payload || uchar[] || The actual data
|}

Known magic values:

{|class="wikitable"
! Network !! Magic value !! Sent over wire as
|-
| main || 0xD9B4BEF9 || F9 BE B4 D9
|-
| testnet || 0xDAB5BFFA || FA BF B5 DA
|}

=== Variable length integer ===

Integer can be encoded depending on the represented value to save space. Variable length integers always precede an array/vector of a type of data that may vary in length.

{|class="wikitable"
! Value !! Storage length !! Format
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd followed by the length as uint16_t
|-
| <= 0xffffffff || 5 || 0xfe followed by the length as uint32_t
|-
| - || 9 || 0xff followed by the length as uint64_t
|}

=== Variable length string ===

Variable length string can be stored using a variable length integer followed by the string itself.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the string
|-
| ? || string || char[] || The string itself (can be empty)
|}

=== Network address ===

When a network address is needed somewhere, this structure is used. This protocol and structure supports IPv6, '''but note that the original client currently only supports IPv4 networking'''. Network addresses are not prefixed with a timestamp in the version message.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || time || uint32 || the Time (version >= 31402)
|-
| 8 || services || uint64_t || same service(s) listed in [[#version|version]]
|-
| 16 || IPv6/4 || char[16] || IPv6 address. Network byte order. The original client only supports IPv4 and only reads the last 4 bytes to get the IPv4 address. However, the IPv4 address is written into the message as a 16 byte [http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4-mapped IPv6 address]
(12 bytes ''00 00 00 00 00 00 00 00 00 00 FF FF'', followed by the 4 bytes of the IPv4 address).
|-
| 2 || port || uint16_t || port number, network byte order
|}

Hexdump example of Network address structure

<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK: see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - Port 8333
</pre>

=== Inventory Vectors ===

Inventory vectors are used for notifying other nodes about objects they have or data which is being requested.

Inventory vectors consist of the following data format:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || Identifies the object type linked to this inventory
|-
| 32 || hash || char[32] || Hash of the object
|}

The object type is currently defined as one of the following possibilities:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || ERROR || Any data of with this number may be ignored
|-
| 1 || MSG_TX || Hash is related to a transaction
|-
| 2 || MSG_BLOCK || Hash is related to a data block
|}

Other Data Type values are considered reserved for future implementations.

=== Block Headers ===

Block headers are sent in a headers packet in response to a getheaders message.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| 1 || txn_count || uint8_t || Number of transaction entries, this value is always 0
|}

== Message types ==

=== version ===

When a node creates an outgoing connection, it will immediately advertise its version. The remote node will respond with its version. No futher communication is possible until both peers have exchanged their version.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || int32_t || Identifies protocol version being used by the node
|-
| 8 || services || uint64_t || bitfield of features to be enabled for this connection
|-
| 8 || timestamp || int64_t || standard UNIX timestamp in seconds
|-
| 26 || addr_recv || net_addr || The network address of the node receiving this message
|-
|colspan="4"| version >= 106
|-
| 26 || addr_from || net_addr || The network address of the node emitting this message
|-
| 8 || nonce || uint64_t || Node random nonce, randomly generated every time a version packet is sent. This nonce is used to detect connections to self.
|-
| ? || user_agent || [[#Variable length string|var_str]] || [[BIP_0014|User Agent]] (0x00 if string is 0 bytes long)
|-
| 4 || start_height || int32_t || The last block received by the emitting node
|}

A "verack" packet shall be sent if the version packet was accepted.

The following services are currently assigned:

{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers.
|}

Hexdump example of version message (OBSOLETE EXAMPLE. This example lacks a checksum and user-agent):
<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 20 8D 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command
55 00 00 00 - Payload is 85 bytes long
- No checksum in version message until 20 February 2012. See https://bitcointalk.org/index.php?topic=55852.0
Version message:
9C 7C 00 00 - 31900 (version 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 20 8D - Recipient address info - see Network Address
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - Sender address info - see Network Address
DD 9D 20 2C 3A B4 57 13 - Node random unique ID
00 - "" sub-version string (string is 0 bytes long)
55 81 01 00 - Last block sending node has is block #98645
</pre>

=== verack ===

The ''verack'' message is sent in reply to ''version''. This message consists of only a [[#Message structure|message header]] with the command string "verack".

Hexdump of the verack message:

<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 5D F6 E0 E2 ........

Message header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 61 63 6B 00 00 00 00 00 00 - "verack" command
00 00 00 00 - Payload is 0 bytes long
5D F6 E0 E2 - Checksum
</pre>

=== addr ===

Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours

Payload:
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of address entries (max: 1000)
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || Address of other nodes on the network. version < 209 will only read the first one. The uint32_t is a timestamp (see note below).
|}

'''Note''': Starting version 31402, addresses are prefixed with a timestamp. If no timestamp is present, the addresses should not be relayed to other peers, unless it is indeed confirmed they are up.

Hexdump example of ''addr'' message:
<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 ED 52 39 9B 01 E2 15 10 4D 01 00 00 .....R9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D ..... .

Message Header:
F9 BE B4 D9 - Main network magic bytes
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload is 31 bytes long
ED 52 39 9B - checksum of payload

Payload:
01 - 1 address in this message

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - see version message)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - port 8333
</pre>

=== inv ===

Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to ''getblocks''.

Payload (maximum payload length: 50000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors
|}

=== getdata ===

getdata is used in response to inv, to retrieve the content of a specific object, and is usually sent after receiving an ''inv'' packet, after filtering known elements.

Payload (maximum payload length: 50000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors
|}

=== getblocks ===

Return an ''inv'' packet containing the list of blocks starting right after the last known hash in the block locator object, up to hash_stop or 500 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getblocks again with a new block locator object. Keep in mind that some clients (specifically the Satoshi client) will gladly provide blocks which are invalid if the block locator object contains a hash on the invalid branch.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || the protocol version
|-
| 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries
|-
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)
|-
| 32 || hash_stop || char[32] || hash of the last desired block; set to zero to get as many blocks as possible (500)
|}

To create the block locator hashes, keep pushing hashes until you go back to the genesis block. After pushing 10 hashes back, the step backwards doubles every loop:

<pre>
// From libbitcoin which is under AGPL
std::vector<size_t> block_locator_indices(int top_depth)
{
// Start at max_depth
std::vector<size_t> indices;
// Push last 10 indices first
size_t step = 1, start = 0;
for (int i = top_depth; i > 0; i -= step, ++start)
{
if (start >= 10)
step *= 2;
indices.push_back(i);
}
indices.push_back(0);
return indices;
}
</pre>

Note that it is allowed to send in fewer known hashes down to a minimum of just one hash. However, the purpose of the block locator object is to detect a wrong branch in the caller's main chain. If the peer detects that you are off the main chain, it will send in block hashes which are earlier than your last known block. So if you just send in your last known hash and it is off the main chain, the peer starts over at block #1.

=== getheaders ===

Return a ''headers'' packet containing the headers of blocks starting right after the last known hash in the block locator object, up to hash_stop or 2000 blocks, whichever comes first. To receive the next block headers, one needs to issue getheaders again with a new block locator object. The ''getheaders'' command is used by thin clients to quickly download the blockchain where the contents of the transactions would be irrelevant (because they are not ours). Keep in mind that some clients (specifically the Satoshi client) will gladly provide headers of blocks which are invalid if the block locator object contains a hash on the invalid branch.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || the protocol version
|-
| 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries
|-
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)
|-
| 32 || hash_stop || char[32] || hash of the last desired block header; set to zero to get as many blocks as possible (2000)
|}

For the block locator object in this packet, the same rules apply as for the [[Protocol_specification#Variable_length_integer|getblocks]] packet.

=== tx ===

''tx'' describes a bitcoin transaction, in reply to ''getdata''

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Transaction data format version
|-
| 1+ || tx_in count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction inputs
|-
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins
|-
| 1+ || tx_out count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction outputs
|-
| 8+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins
|-
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked:
{|class="wikitable"
! Value !! Description
|-
| 0 || Always locked
|-
| < 500000000 || Block number at which this transaction is locked
|-
| >= 500000000 || UNIX timestamp at which this transaction is locked
|}
A non-locked transaction must not be included in blocks, and it can be modified by broadcasting a new version before the time has expired (replacement is currently disabled in Bitcoin, however, so this is useless).

|}

TxIn consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure
|-
| 1+ || script length || [[Protocol_specification#Variable_length_integer|var_int]] || The length of the signature script
|-
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization
|-
| 4 || [http://bitcoin.stackexchange.com/q/2025/323 sequence] || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.
|}

The OutPoint structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || The hash of the referenced transaction.
|-
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.
|}

The Script structure consists of a series of pieces of information and operations related to the value of the transaction.

(Structure to be expanded in the future… see script.h and script.cpp and [[Script]] for more information)

The TxOut structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || int64_t || Transaction Value
|-
| 1+ || pk_script length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the pk_script
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

Example ''tx'' message:
<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - main network magic bytes
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command
02 01 00 00 - payload is 258 bytes long
E2 93 CD BE - checksum of payload

Transaction:
01 00 00 00 - version

Inputs:
01 - number of transaction inputs

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - script is 139 bytes long

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 2 Output Transactions

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script is 25 bytes long

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script is 25 bytes long

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A unix timestamp recording when this block was created (Currently limited to dates before the year 2106!)
|-
| 4 || bits || uint32_t || The calculated [[Difficulty|difficulty target]] being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| ? || txn_count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of transaction entries
|-
| ? || txns || tx[] || Block transactions, in format of "tx" command
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.
See [[Block hashing algorithm]] for details and an example.

=== headers ===

The ''headers'' packet returns block headers in response to a ''getheaders'' packet.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of block headers
|-
| 81x? || headers || [[Protocol_specification#Block_Headers|block_header]][] || [[Protocol_specification#Block_Headers|Block headers]]
|}

Note that the block headers in this packet include a transaction count (a var_int, so there can be more than 81 bytes per header) as opposed to the block headers which are sent to miners.

=== getaddr ===

The getaddr message sends a request to a node asking for information about known active peers to help with identifying potential nodes in the network. The response to receiving this message is to transmit an addr message with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.

No additional data is transmitted with this message.

=== checkorder ===

This message is used for [[IP Transactions]], to ask the peer if it accepts such transactions and allow it to look at the content of the order.

It contains a CWalletTx object

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock
|-
| ? || vMerkleBranch
|-
| ? || nIndex
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev
|-
| ? || mapValue
|-
| ? || vOrderForm
|-
| ? || fTimeReceivedIsTxTime
|-
| ? || nTimeReceived
|-
| ? || fFromMe
|-
| ? || fSpent
|}

=== submitorder ===

Confirms an order has been submitted.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || Hash of the transaction
|-
| ? || wallet_entry || CWalletTx || Same payload as checkorder
|}

=== reply ===

Generic reply for [[IP Transactions]]

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || reply code
|}

Possible values:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed
|-
| 2 || DENIED || IP Transactions are not accepted by this node
|}

=== ping ===

The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. No reply is expected as a result of this message being sent nor any sort of action expected on the part of a client when it is used.

=== alert ===

An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.

Alert format:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || payload || var_str || Serialized alert payload
|-
| ? || signature || var_str || An ECDSA signature of the message
|}

The developers of Satoshi's client use this public key for signing alerts:
04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

The payload is serialized into a var_str to ensure that versions using incompatible alert formats can still relay alerts among one another. The current alert payload format is:
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || Version || int32_t || Alert format version
|-
| 8 || RelayUntil || int64_t || The timestamp beyond which nodes should stop relaying this alert
|-
| 8 || Expiration || int64_t || The timestamp beyond which this alert is no longer in effect and should be ignored
|-
| 4 || ID || int32_t || A unique ID number for this alert
|-
| 4 || Cancel || int32_t || All alerts with an ID number less than or equal to this number should be canceled: deleted and not accepted in the future
|-
| ? || setCancel || set<int> || All alert IDs contained in this set should be canceled as above
|-
| 4 || MinVer || int32_t || This alert only applies to versions greater than or equal to this version. Other versions should still relay it.
|-
| 4 || MaxVer || int32_t || This alert only applies to versions less than or equal to this version. Other versions should still relay it.
|-
| ? || setSubVer || set<string> || If this set contains any elements, then only nodes that have their subVer contained in this set are affected by the alert. Other versions should still relay it.
|-
| 4 || Priority || int32_t || Relative priority compared to other alerts
|-
| ? || Comment || string || A comment on the alert that is not displayed
|-
| ? || StatusBar || string || The alert message that is displayed to the user
|-
| ? || Reserved || string || Reserved
|}

Sample alert (no message header):
73010000003766404f00000000b305434f00000000f2030000f1030000001027000048ee0000
0064000000004653656520626974636f696e2e6f72672f666562323020696620796f75206861
76652074726f75626c6520636f6e6e656374696e672061667465722032302046656272756172
79004730450221008389df45f0703f39ec8c1cc42c13810ffcae14995bb648340219e353b63b
53eb022009ec65e1c1aaeec1fd334c6b684bde2b3f573060d5b70c3a46723326e4e8a4f1

Version: 1
RelayUntil: 1329620535
Expiration: 1329792435
ID: 1010
Cancel: 1009
setCancel: <empty>
MinVer: 10000
MaxVer: 61000
setSubVer: <empty>
Priority: 100
Comment: <empty>
StatusBar: "See bitcoin.org/feb20 if you have trouble connecting after 20 February"
Reserved: <empty>

== Scripting ==

See [[script]].

== Wireshark dissector ==
A dissector for wireshark is being developed at https://github.com/blueCommand/bitcoin-dissector

==See Also==

* [[Network]]
* [[Protocol rules]]
[[zh-cn:协议说明]]
[[Category:Technical]]
[[Category:Developer]]

Script

2012-07-28T00:48:57Z

BlueMatt: /* Transaction with a message */ Line is if (opcode > OP_16 && ++nOpCount > 201)

Bitcoin uses a scripting system for [[transactions]]. [[Wikipedia:FORTH|Forth]]-like, Script is simple, stack-based, and processed from left to right. It is purposefully not Turing-complete, with no loops.

A script is essentially a list of instructions recorded with each transaction that describe how the next person wanting to spend the Bitcoins being transferred can gain access to them. The script for a typical Bitcoin transfer to destination Bitcoin address D simply encumbers future spending of the bitcoins with two things: the spender must provide
# a public key that, when hashed, yields destination address D embedded in the script, and
# a signature to show evidence of the private key corresponding to the public key just provided.

Scripting provides the flexibility to change the parameters of what's needed to spend transferred Bitcoins. For example, the scripting system could be used to require two private keys, or a combination of several, or even no keys at all.

A transaction is valid if nothing in the combined script triggers failure and the top stack item is true (non-zero). The party who originally ''sent'' the Bitcoins now being spent, dictates the script operations that will occur ''last'' in order to release them for use in another transaction. The party wanting to spend them must provide the input(s) to the previously recorded script that results in those operations occurring last leaving behind true (non-zero).

Scripts are big-endian.

The stacks hold byte vectors. Byte vectors are interpreted as little-endian variable-length integers with the most significant bit determining the sign of the integer. Thus 0x81 represents -1. 0x80 is another representation of zero (so called negative 0). Byte vectors are interpreted as Booleans where False is represented by any representation of zero, and True is represented by any representation of non-zero.

== Words ==
This is a list of all Script words (commands/functions). Some of the more complicated opcodes are disabled out of concern that the client might have a bug in their implementation; if a transaction using such an opcode were to be included in the chain any fix would risk forking the chain.

True=1 and False=0.

=== Constants ===
When talking about scripts, these value-pushing words are usually omitted.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_0, OP_FALSE
|0
|0x00
|Nothing.
|(empty value)
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)
|-
|N/A
|1-75
|0x01-0x4b
|(special)
|data
|The next ''opcode'' bytes is data to be pushed onto the stack
|-
|OP_PUSHDATA1
|76
|0x4c
|(special)
|data
|The next byte contains the number of bytes to be pushed onto the stack.
|-
|OP_PUSHDATA2
|77
|0x4d
|(special)
|data
|The next two bytes contain the number of bytes to be pushed onto the stack.
|-
|OP_PUSHDATA4
|78
|0x4e
|(special)
|data
|The next four bytes contain the number of bytes to be pushed onto the stack.
|-
|OP_1NEGATE
|79
|0x4f
|Nothing.
| -1
|The number -1 is pushed onto the stack.
|-
|OP_1, OP_TRUE
|81
|0x51
|Nothing.
|1
|The number 1 is pushed onto the stack.
|-
|OP_2-OP_16
|82-96
|0x52-0x60
|Nothing.
|2-16
|The number in the word name (2-16) is pushed onto the stack.
|}

=== Flow control ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_NOP
|97
|0x61
|Nothing
|Nothing
|Does nothing.
|-
|OP_IF
|99
|0x63
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|If the top stack value is not 0, the statements are executed. The top stack value is removed.
|-
|OP_NOTIF
|100
|0x64
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|If the top stack value is 0, the statements are executed. The top stack value is removed.
|-
|OP_ELSE
|103
|0x67
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|If the preceding OP_IF or OP_NOTIF or OP_ELSE was not executed then these statements are and if the preceding OP_IF or OP_NOTIF or OP_ELSE was executed then these statements are not.
|-
|OP_ENDIF
|104
|0x68
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|Ends an if/else block.
|-
|OP_VERIFY
|105
|0x69
|True / false
|Nothing / False
|'''Marks transaction as invalid''' if top stack value is not true. True is removed, but false is not.
|-
|OP_RETURN
|106
|0x6a
|Nothing
|Nothing
|'''Marks transaction as invalid'''.
|}

=== Stack ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_TOALTSTACK
|107
|0x6b
|x1
|(alt)x1
|Puts the input onto the top of the alt stack. Removes it from the main stack.
|-
|OP_FROMALTSTACK
|108
|0x6c
|(alt)x1
|x1
|Puts the input onto the top of the main stack. Removes it from the alt stack.
|-
|OP_IFDUP
|115
|0x73
|x
|x / x x
|If the top stack value is not 0, duplicate it.
|-
|OP_DEPTH
|116
|0x74
|Nothing
|<Stack size>
|Puts the number of stack items onto the stack.
|-
|OP_DROP
|117
|0x75
|x
|Nothing
|Removes the top stack item.
|-
|OP_DUP
|118
|0x76
|x
|x x
|Duplicates the top stack item.
|-
|OP_NIP
|119
|0x77
|x1 x2
|x2
|Removes the second-to-top stack item.
|-
|OP_OVER
|120
|0x78
|x1 x2
|x1 x2 x1
|Copies the second-to-top stack item to the top.
|-
|OP_PICK
|121
|0x79
|xn ... x2 x1 x0 <n>
|xn ... x2 x1 x0 xn
|The item ''n'' back in the stack is copied to the top.
|-
|OP_ROLL
|122
|0x7a
|xn ... x2 x1 x0 <n>
|... x2 x1 x0 xn
|The item ''n'' back in the stack is moved to the top.
|-
|OP_ROT
|123
|0x7b
|x1 x2 x3
|x2 x3 x1
|The top three items on the stack are rotated to the left.
|-
|OP_SWAP
|124
|0x7c
|x1 x2
|x2 x1
|The top two items on the stack are swapped.
|-
|OP_TUCK
|125
|0x7d
|x1 x2
|x2 x1 x2
|The item at the top of the stack is copied and inserted before the second-to-top item.
|-
|OP_2DROP
|109
|0x6d
|x1 x2
|Nothing
|Removes the top two stack items.
|-
|OP_2DUP
|110
|0x6e
|x1 x2
|x1 x2 x1 x2
|Duplicates the top two stack items.
|-
|OP_3DUP
|111
|0x6f
|x1 x2 x3
|x1 x2 x3 x1 x2 x3
|Duplicates the top three stack items.
|-
|OP_2OVER
|112
|0x70
|x1 x2 x3 x4
|x1 x2 x3 x4 x1 x2
|Copies the pair of items two spaces back in the stack to the front.
|-
|OP_2ROT
|113
|0x71
|x1 x2 x3 x4 x5 x6
|x3 x4 x5 x6 x1 x2
|The fifth and sixth items back are moved to the top of the stack.
|-
|OP_2SWAP
|114
|0x72
|x1 x2 x3 x4
|x3 x4 x1 x2
|Swaps the top two pairs of items.
|}

=== Splice ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_CAT
|126
|0x7e
|x1 x2
|out
|Concatenates two strings. ''Currently disabled.''
|-
|OP_SUBSTR
|127
|0x7f
|in begin size
|out
|Returns a section of a string. ''Currently disabled.''
|-
|OP_LEFT
|128
|0x80
|in size
|out
|Keeps only characters left of the specified point in a string. ''Currently disabled.''
|-
|OP_RIGHT
|129
|0x81
|in size
|out
|Keeps only characters right of the specified point in a string. ''Currently disabled.''
|-
|OP_SIZE
|130
|0x82
|in
|in size
|Returns the length of the input string.
|}

=== Bitwise logic ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_INVERT
|131
|0x83
|in
|out
|Flips all of the bits in the input. ''Currently disabled.''
|-
|OP_AND
|132
|0x84
|x1 x2
|out
|Boolean ''and'' between each bit in the inputs. ''Currently disabled.''
|-
|OP_OR
|133
|0x85
|x1 x2
|out
|Boolean ''or'' between each bit in the inputs. ''Currently disabled.''
|-
|OP_XOR
|134
|0x86
|x1 x2
|out
|Boolean ''exclusive or'' between each bit in the inputs. ''Currently disabled.''
|-
|OP_EQUAL
|135
|0x87
|x1 x2
|True / false
|Returns 1 if the inputs are exactly equal, 0 otherwise.
|-
|OP_EQUALVERIFY
|136
|0x88
|x1 x2
|True / false
|Same as OP_EQUAL, but runs OP_VERIFY afterward.
|}

=== Arithmetic ===

Arithmetic is limited to max 4 byte integers

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_1ADD
|139
|0x8b
|in
|out
|1 is added to the input.
|-
|OP_1SUB
|140
|0x8c
|in
|out
|1 is subtracted from the input.
|-
|OP_2MUL
|141
|0x8d
|in
|out
|The input is multiplied by 2. ''Currently disabled.''
|-
|OP_2DIV
|142
|0x8e
|in
|out
|The input is divided by 2. ''Currently disabled.''
|-
|OP_NEGATE
|143
|0x8f
|in
|out
|The sign of the input is flipped.
|-
|OP_ABS
|144
|0x90
|in
|out
|The input is made positive.
|-
|OP_NOT
|145
|0x91
|in
|out
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.
|-
|OP_0NOTEQUAL
|146
|0x92
|in
|out
|Returns 0 if the input is 0. 1 otherwise.
|-
|OP_ADD
|147
|0x93
|a b
|out
|a is added to b.
|-
|OP_SUB
|148
|0x94
|a b
|out
|b is subtracted from a.
|-
|OP_MUL
|149
|0x95
|a b
|out
|a is multiplied by b. ''Currently disabled.''
|-
|OP_DIV
|150
|0x96
|a b
|out
|a is divided by b. ''Currently disabled.''
|-
|OP_MOD
|151
|0x97
|a b
|out
|Returns the remainder after dividing a by b. ''Currently disabled.''
|-
|OP_LSHIFT
|152
|0x98
|a b
|out
|Shifts a left b bits, preserving sign. ''Currently disabled.''
|-
|OP_RSHIFT
|153
|0x99
|a b
|out
|Shifts a right b bits, preserving sign. ''Currently disabled.''
|-
|OP_BOOLAND
|154
|0x9a
|a b
|out
|If both a and b are not 0, the output is 1. Otherwise 0.
|-
|OP_BOOLOR
|155
|0x9b
|a b
|out
|If a or b is not 0, the output is 1. Otherwise 0.
|-
|OP_NUMEQUAL
|156
|0x9c
|a b
|out
|Returns 1 if the numbers are equal, 0 otherwise.
|-
|OP_NUMEQUALVERIFY
|157
|0x9d
|a b
|out
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.
|-
|OP_NUMNOTEQUAL
|158
|0x9e
|a b
|out
|Returns 1 if the numbers are not equal, 0 otherwise.
|-
|OP_LESSTHAN
|159
|0x9f
|a b
|out
|Returns 1 if a is less than b, 0 otherwise.
|-
|OP_GREATERTHAN
|160
|0xa0
|a b
|out
|Returns 1 if a is greater than b, 0 otherwise.
|-
|OP_LESSTHANOREQUAL
|161
|0xa1
|a b
|out
|Returns 1 if a is less than or equal to b, 0 otherwise.
|-
|OP_GREATERTHANOREQUAL
|162
|0xa2
|a b
|out
|Returns 1 if a is greater than or equal to b, 0 otherwise.
|-
|OP_MIN
|163
|0xa3
|a b
|out
|Returns the smaller of a and b.
|-
|OP_MAX
|164
|0xa4
|a b
|out
|Returns the larger of a and b.
|-
|OP_WITHIN
|165
|0xa5
|x min max
|out
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.
|}

=== Crypto ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_RIPEMD160
|166
|0xa6
|in
|hash
|The input is hashed using RIPEMD-160.
|-
|OP_SHA1
|167
|0xa7
|in
|hash
|The input is hashed using SHA-1.
|-
|OP_SHA256
|168
|0xa8
|in
|hash
|The input is hashed using SHA-256.
|-
|OP_HASH160
|169
|0xa9
|in
|hash
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.
|-
|OP_HASH256
|170
|0xaa
|in
|hash
|The input is hashed two times with SHA-256.
|-
|OP_CODESEPARATOR
|171
|0xab
|Nothing
|Nothing
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.
|-
|[[OP_CHECKSIG]]
|172
|0xac
|sig pubkey
|True / false
|The entire transaction's outputs, inputs, and script (from the most recently-executed OP_CODESEPARATOR to the end) are hashed. The signature used by OP_CHECKSIG must be a valid signature for this hash and public key. If it is, 1 is returned, 0 otherwise.
|-
|OP_CHECKSIGVERIFY
|173
|0xad
|sig pubkey
|True / false
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.
|-
|OP_CHECKMULTISIG
|174
|0xae
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys>
|True / False
|For each signature and public key pair, OP_CHECKSIG is executed. If more public keys than signatures are listed, some key/sig pairs can fail. All signatures need to match a public key. If all signatures are valid, 1 is returned, 0 otherwise. Due to a bug, one extra unused value is removed from the stack.
|-
|OP_CHECKMULTISIGVERIFY
|175
|0xaf
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys>
|True / False
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.
|}

===Pseudo-words===
These words are used internally for assisting with transaction matching. They are invalid if used in actual scripts.
{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Description
|-
|OP_PUBKEYHASH
|253
|0xfd
|Represents a public key hashed with OP_HASH160.
|-
|OP_PUBKEY
|254
|0xfe
|Represents a public key compatible with OP_CHECKSIG.
|-
|OP_INVALIDOPCODE
|255
|0xff
|Matches any opcode that is not yet assigned.
|}

=== Reserved words ===
Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction invalid.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!When used...
|-
|OP_RESERVED
|80
|0x50
|Transaction is invalid unless occuring in an unexecuted OP_IF branch
|-
|OP_VER
|98
|0x62
|Transaction is invalid unless occuring in an unexecuted OP_IF branch
|-
|OP_VERIF
|101
|0x65
|Transaction is invalid even when occuring in an unexecuted OP_IF branch
|-
|OP_VERNOTIF
|102
|0x66
|Transaction is invalid even when occuring in an unexecuted OP_IF branch
|-
|OP_RESERVED1
|137
|0x89
|Transaction is invalid unless occuring in an unexecuted OP_IF branch
|-
|OP_RESERVED2
|138
|0x8a
|Transaction is invalid unless occuring in an unexecuted OP_IF branch
|-
|OP_NOP1-OP_NOP10
|176-185
|0xb0-0xb9
|The word is ignored.
|}

== Scripts ==
This is a list of interesting scripts. Keep in mind that all constants actually use the data-pushing commands above.

=== Standard Transaction to Bitcoin address ===

scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

To demonstrate how scripts look on the wire, here is a raw scriptPubKey:
<pre> 76 A9 14
OP_DUP OP_HASH160 Bytes to push

89 AB CD EF AB BA AB BA AB BA AB BA AB BA AB BA AB BA AB BA 88 AC
Data to push OP_EQUALVERIFY OP_CHECKSIG</pre>

Note: scriptSig is in the input of the spending transaction and scriptPubKey is in the output of the previously unspent i.e. "available" transaction.

Here is how each word is processed:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey>
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Constants are added to the stack.
|-
|<sig> <pubKey> <pubKey>
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is duplicated.
|-
|<sig> <pubKey> <pubHashA>
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is hashed.
|-
|<sig> <pubKey> <pubHashA> <pubKeyHash>
|OP_EQUALVERIFY OP_CHECKSIG
| Constant added.
|-
|<sig> <pubKey>
|OP_CHECKSIG
| Equality is checked between the top two stack items.
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

=== Standard Generation / transaction to IP address ===

scriptPubKey: <pubKey> OP_CHECKSIG
scriptSig: <sig>

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
|<sig> <pubKey> OP_CHECKSIG
|scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey>
| OP_CHECKSIG
|Constants are added to the stack.
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

=== Transaction with a message ===

It's possible to add arbitrary data to any transaction by just adding some data along with OP_DROP. Scripts are limited to 10,000 bytes and 201 instructions, and each individual instruction/value is limited to 520 bytes.

scriptPubKey: <message> OP_DROP <pubKey> OP_CHECKSIG
scriptSig: <sig>

{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
|<sig> <message> OP_DROP <pubKey> OP_CHECKSIG
|
|-
|<sig>
|<message> OP_DROP <pubKey> OP_CHECKSIG
|scriptSig added to the stack.
|-
|<sig> <message>
|OP_DROP <pubKey> OP_CHECKSIG
|The message has been put.
|-
|<sig>
|<pubKey> OP_CHECKSIG
|Top stack item has been removed.
|-
|<sig> <pubKey>
|OP_CHECKSIG
|Checking signature against the public key.
|-
|true
|Empty.
|Stack holds the value of signature check now.
|}

=== Example non standard transaction on Testnet ===

These 2 links below show a non standard transaction. It just prepends the hex of "bob" and the operation OP_DROP
which just removes it. As you can see they can be spent as normal.

Input non-std transaction:
http://blockexplorer.com/testnet/t/6ttfeb55B1

Spent by:
http://blockexplorer.com/testnet/t/AFdRB1CHS3

==See Also==

* [[Transactions]]
* [[Contracts]]

[[Category:Technical]]
[[Category:Vocabulary]]

Changelog

2012-06-12T23:03:12Z

BlueMatt: Not a stub

This page aggregates the changelogs that have been posted on the forum for the Bitcoin releases.
Note that some download links are not longer valid as highly insecure versions may have been deleted, or links may have changed.

=Changelogs=

==0.6.X==
===0.6.2<ref>[https://bitcointalk.org/index.php?topic=80187.0 0.6.2 release announcement]</ref>===
Bitcoin version 0.6.2 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.2/

This is a bug-fix and code-cleanup release, with no major new features.

Please report bugs using the github issue tracker at:
https://github.com/bitcoin/bitcoin/issues

NOTABLE CHANGES

Much faster shutdowns. However, the blkindex.dat file is no longer
portable to different data directories by default. If you need a
portable blkindex.dat file then run with the new -detachdb=1 option
or the "Detach databases at shutdown" GUI preference.

Fixed https://github.com/bitcoin/bitcoin/issues/1065, a bug that
could cause long-running nodes to crash.

Mac and Windows binaries are compiled against OpenSSL 1.0.1b (Linux
binaries are dynamically linked to the version of OpenSSL on the system).

CHANGE SUMMARY

Use 'git shortlog --no-merges v0.6.0..' for a summary of this release.

Source codebase changes:
- Many source code cleanups and warnings fixes. Close to building with -Wall
- Locking overhaul, and several minor locking fixes
- Several source code portability fixes, e.g. FreeBSD

JSON-RPC interface changes:
- addmultisigaddress enabled for mainnet (previously only enabled for testnet)

Network protocol changes:
- protocol version 60001
- added nonce value to "ping" message (BIP 31)
- added new "pong" message (BIP 31)

Backend storage changes:
- Less redundant database flushing, especially during initial block download
- Shutdown improvements (see above)

Qt user interface:
- minor URI handling improvements
- progressbar improvements
- error handling improvements (show message box rather than console exception,
etc.)
- by popular request, make 4th bar of connection icon green

===0.6.1===
Never released

===0.6.0<ref>[https://bitcointalk.org/index.php?topic=74737.0 0.6.0 release announcement]</ref>===
Bitcoin version 0.6.0 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/

This release includes more than 20 language localizations.
More translations are welcome; join the
project at Transifex to help:
https://www.transifex.net/projects/p/bitcoin/

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Project source code is hosted at github; we are no longer
distributing .tar.gz files here, you can get them
directly from github:
https://github.com/bitcoin/bitcoin/tarball/v0.6.0 # .tar.gz
https://github.com/bitcoin/bitcoin/zipball/v0.6.0 # .zip

For Ubuntu users, there is a ppa maintained by Matt Corallo which
you can add to your system so that it will automatically keep
bitcoin up-to-date. Just type
sudo apt-add-repository ppa:bitcoin/bitcoin
in your terminal, then install the bitcoin-qt package.

KNOWN ISSUES

Shutting down while synchronizing with the network
(downloading the blockchain) can take more than a minute,
because database writes are queued to speed up download
time.

NEW FEATURES SINCE BITCOIN VERSION 0.5

Initial network synchronization should be much faster
(one or two hours on a typical machine instead of ten or more
hours).

Backup Wallet menu option.

Bitcoin-Qt can display and save QR codes for sending
and receiving addresses.

New context menu on addresses to copy/edit/delete them.

New Sign Message dialog that allows you to prove that you
own a bitcoin address by creating a digital
signature.

New wallets created with this version will
use 33-byte 'compressed' public keys instead of
65-byte public keys, resulting in smaller
transactions and less traffic on the bitcoin
network. The shorter keys are already supported
by the network but wallet.dat files containing
short keys are not compatible with earlier
versions of Bitcoin-Qt/bitcoind.

New command-line argument -blocknotify=<command>
that will spawn a shell process to run <command>
when a new block is accepted.

New command-line argument -splash=0 to disable
Bitcoin-Qt's initial splash screen

validateaddress JSON-RPC api command output includes
two new fields for addresses in the wallet:
pubkey : hexadecimal public key
iscompressed : true if pubkey is a short 33-byte key

New JSON-RPC api commands for dumping/importing
private keys from the wallet (dumprivkey, importprivkey).

New JSON-RPC api command for getting information about
blocks (getblock, getblockhash).

New JSON-RPC api command (getmininginfo) for getting
extra information related to mining. The getinfo
JSON-RPC command no longer includes mining-related
information (generate/genproclimit/hashespersec).

NOTABLE CHANGES

BIP30 implemented (security fix for an attack involving
duplicate "coinbase transactions").

The -nolisten, -noupnp and -nodnsseed command-line
options were renamed to -listen, -upnp and -dnsseed,
with a default value of 1. The old names are still
supported for compatibility (so specifying -nolisten
is automatically interpreted as -listen=0; every
boolean argument can now be specified as either
-foo or -nofoo).

The -noirc command-line options was renamed to
-irc, with a default value of 0. Run -irc=1 to
get the old behavior.

Three fill-up-available-memory denial-of-service
attacks were fixed.

NOT YET IMPLEMENTED FEATURES

Support for clicking on bitcoin: URIs and
opening/launching Bitcoin-Qt is available only on Linux,
and only if you configure your desktop to launch
Bitcoin-Qt. All platforms support dragging and dropping
bitcoin: URIs onto the Bitcoin-Qt window to start
payment.

PRELIMINARY SUPPORT FOR MULTISIGNATURE TRANSACTIONS

This release has preliminary support for multisignature
transactions-- transactions that require authorization
from more than one person or device before they
will be accepted by the bitcoin network.

Prior to this release, multisignature transactions
were considered 'non-standard' and were ignored;
with this release multisignature transactions are
considered standard and will start to be relayed
and accepted into blocks.

It is expected that future releases of Bitcoin-Qt
will support the creation of multisignature transactions,
once enough of the network has upgraded so relaying
and validating them is robust.

For this release, creation and testing of multisignature
transactions is limited to the bitcoin test network using
the "addmultisigaddress" JSON-RPC api call.

Short multisignature address support is included in this
release, as specified in BIP 13 and BIP 16.

==0.5.X==
After 0.5.1, all subsequent releases are stable maintenance releases, 0.6.0 is based on 0.5.1.

===0.5.5<ref>[https://bitcointalk.org/index.php?topic=79651 0.4.6/0.5.5 release announcement]</ref>===
bitcoind and Bitcoin-Qt version 0.5.5 are now available for download at:
Windows: installer | zip (sig)
Source: tar.gz
bitcoind and Bitcoin-Qt version 0.6.0.7 are also tagged in git, but it is recommended to upgrade to 0.6.1.

These are bugfix-only releases.

Please report bugs by replying to this forum thread. Note that the 0.4.x wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr.

BUG FIXES

Version 0.6.0 allowed importing invalid "private keys", which would be unspendable; 0.6.0.7 will now verify the private key is valid, and refuse to import an invalid one
Verify status of encrypt/decrypt calls to detect failed padding
Check blocks for duplicate transactions earlier. Fixes #1167
Upgrade Windows builds to OpenSSL 1.0.1b
Set label when selecting an address that already has a label. Fixes #1080 (Bitcoin-Qt)
JSON-RPC listtransactions's from/count handling is now fixed
Optimize and fix multithreaded access, when checking whether we already know about transactions
Fix potential networking deadlock
Proper support for Growl 1.3 notifications
Display an error, rather than crashing, if encoding a QR Code failed (0.6.0.7)
Don't erroneously set "Display addresses" for users who haven't explicitly enabled it (Bitcoin-Qt)
Some non-ASCII input in JSON-RPC expecting hexadecimal may have been misinterpreted rather than rejected
Missing error condition checking added
Do not show green tick unless all known blocks are downloaded. Fixes #921 (Bitcoin-Qt)
Increase time ago of last block for "up to date" status from 30 to 90 minutes
Show a message box when runaway exception happens (Bitcoin-Qt)
Use a messagebox to display the error when -server is provided without providing a rpc password
Show error message instead of exception crash when unable to bind RPC port (Bitcoin-Qt)
Correct sign message bitcoin address tooltip. Fixes #1050 (Bitcoin-Qt)
Removed "(no label)" from QR Code dialog titlebar if we have no label (0.6.0.7)
Removed an ugly line break in tooltip for mature transactions (0.6.0.7)
Add missing tooltip and key shortcut in settings dialog (part of #1088) (Bitcoin-Qt)
Work around issue in boost::program_options that prevents from compiling in clang
Fixed bugs occurring only on platforms with unsigned characters (such as ARM).
Rename make_windows_icon.py to .sh as it is a shell script. Fixes #1099 (Bitcoin-Qt)
Various trivial internal corrections to types used for counting/size loops and warnings

===0.5.4<ref>[https://bitcointalk.org/index.php?topic=76808.0 0.5.4 release announcement]</ref>===
Bitcoin version 0.5.4 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.4/
NOTE: 0.5.4rc3 is being renamed to 0.5.4 final with no changes.

This is a bugfix-only release in the 0.5.x series, plus a few protocol updates.

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.4#.tar.gz

PROTOCOL UPDATES

BIP 16: Special-case "pay to script hash" logic to enable minimal validation of new transactions.
Support for validating message signatures produced with compressed public keys.

BUG FIXES

Build with thread-safe MingW libraries for Windows, fixing a dangerous memory corruption scenario when exceptions are thrown.
Fix broken testnet mining.
Stop excess inventory relay during initial block download.
When disconnecting a node, clear the received buffer so that we do not process any already received messages.
Yet another attempt at implementing "minimize to tray" that works on all operating systems.
Fix Bitcoin-Qt notifications under Growl 1.3.
Increase required age of Bitcoin-Qt's "not up to date" status from 30 to 90 minutes.
Implemented missing verifications that led to crash on entering some wrong passphrases for encrypted wallets.
Fix default filename suffixes in GNOME save dialog.
Make the "Send coins" tab use the configured unit type, even on the first attempt.
Print detailed wallet loading errors to debug.log when it is corrupt.
Allocate exactly the amount of space needed for signing transactions, instead of a fixed 10k buffer.
Workaround for improbable memory access violation.
Check wallet's minimum version before trying to load it.
Remove wxBitcoin properly when installing Bitcoin-Qt over it. (Windows)
Detail reorganization information better in debug log.
Use a messagebox to display the error when -server is provided without configuring a RPC password.
Testing suite build now honours provided CXXFLAGS.
Removed an extraneous line-break in mature transaction tooltips.
Fix some grammatical errors in translation process documentation.

===0.5.3<ref>[https://bitcointalk.org/index.php?topic=68895.0 0.5.3 release announcement]</ref>===
Bitcoin version 0.5.3 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.3/

This is a bugfix-only release based on 0.5.1.
It also includes a few protocol updates.

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.3#.tar.gz

PROTOCOL UPDATES

BIP 30: Introduce a new network rule: "a block is not valid if it contains a transaction whose hash already exists in the block chain, unless all that transaction's outputs were already spent before said block" beginning on March 15, 2012, 00:00 UTC.
On testnet, allow mining of min-difficulty blocks if 20 minutes have gone by without mining a regular-difficulty block. This is to make testing Bitcoin easier, and will not affect normal mode.

BUG FIXES

Limit the number of orphan transactions stored in memory, to prevent a potential denial-of-service attack by flooding orphan transactions. Also never store invalid transactions at all.
Fix possible buffer overflow on systems with very long application data paths. This is not exploitable.
Resolved multiple bugs preventing long-term unlocking of encrypted wallets
(issue #922).
Only send local IP in "version" messages if it is globally routable (ie, not private), and try to get such an IP from UPnP if applicable.
Reannounce UPnP port forwards every 20 minutes, to workaround routers expiring old entries, and allow the -upnp option to override any stored setting.
Skip splash screen when -min is used, and fix Minimize to Tray function.
Do not blank "label" in Bitcoin-Qt "Send" tab, if the user has already entered something.
Correct various labels and messages.
Various memory leaks and potential null pointer deferences have been fixed.
Handle invalid Bitcoin URIs using "bitcoin://" instead of "bitcoin:".
Several shutdown issues have been fixed.
Revert to "global progress indication", as starting from zero every time was considered too confusing for many users.
Check that keys stored in the wallet are valid at startup, and if not, report corruption.
Enable accessible widgets on Windows, so that people with screen readers such as NVDA can make sense of it.
Various build fixes.
If no password is specified to bitcoind, recommend a secure password.
Automatically focus and scroll to new "Send coins" entries in Bitcoin-Qt.
Show a message box for --help on Windows, for Bitcoin-Qt.
Add missing "About Qt" menu option to show built-in Qt About dialog.
Don't show "-daemon" as an option for Bitcoin-Qt, since it isn't available.
Update hard-coded fallback seed nodes, choosing recent ones with long uptime and versions at least 0.4.0.
Add checkpoint at block 168,000.

===0.5.2<ref>[https://bitcointalk.org/index.php?topic=60146.0 0.5.2 release announcement]</ref>===
Bitcoin version 0.5.2 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.2/

This is a bugfix-only release based on 0.5.1.

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.2#.tar.gz

BUG FIXES

Check all transactions in blocks after the last checkpoint (0.5.0 and 0.5.1 skipped checking ECDSA signatures during initial blockchain download).
Cease locking memory used by non-sensitive information (this caused a huge performance hit on some platforms, especially noticable during initial blockchain download; this was
not a security vulnerability).
Fixed some address-handling deadlocks (client freezes).
No longer accept inbound connections over the internet when Bitcoin is being used with Tor (identity leak).
Re-enable SSL support for the JSON-RPC interface (it was unintentionally disabled for the 0.5.0 and 0.5.1 release Linux binaries).
Use the correct base transaction fee of 0.0005 BTC for accepting transactions into mined blocks (since 0.4.0, it was incorrectly accepting 0.0001 BTC which was only meant to be relayed).
Don't show "IP" for transactions which are not necessarily IP transactions.
Add new DNS seeds (maintained by Pieter Wuille and Luke Dashjr).

===0.5.1<ref>[https://bitcointalk.org/index.php?topic=54717.0 0.5.1 release announcement]</ref>===
Bitcoin version 0.5.1 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.1/

This is a bugfix-only release.

This release includes 13 translations, including 5 new translations:
Italian, Hungarian, Ukranian, Portuguese (Brazilian) and Simplified Chinese.
More translations are welcome; join the project at Transifex if you can help:
https://www.transifex.net/projects/p/bitcoin/

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Project source code is hosted at github; we are no longer
distributing .tar.gz files here, you can get them
directly from github:
https://github.com/bitcoin/bitcoin/tarball/v0.5.1 # .tar.gz
https://github.com/bitcoin/bitcoin/zipball/v0.5.1 # .zip

For Ubuntu users, there is a new ppa maintained by Matt Corallo which
you can add to your system so that it will automatically keep
bitcoin up-to-date. Just type
sudo apt-add-repository ppa:bitcoin/bitcoin
in your terminal, then install the bitcoin-qt package.

BUG FIXES

Re-enable SSL support for the JSON-RPC interface (it was unintentionally
disabled for the 0.5.0 release binaries).

The code that finds peers via "dns seeds" no longer stops bitcoin startup
if one of the dns seed machines is down.

Tooltips on the transaction list view were rendering incorrectly (as black boxes
or with a transparent background).

Prevent a denial-of-service attack involving flooding a bitcoin node with
orphan blocks.

The wallet passphrase dialog now warns you if the caps lock key was pressed.

Improved searching in addresses and labels in bitcoin-qt.

===0.5.0<ref>[https://bitcointalk.org/index.php?topic=52480.0 0.5.0 release announcement]</ref>===
Bitcoin version 0.5.0 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.0/

The major change for this release is a completely new graphical interface that uses the Qt user interface toolkit.

This release include German, Spanish, Spanish-Castilian, Norwegian and Dutch translations. More translations are welcome; join the project at Transifex if you can help:
https://www.transifex.net/projects/p/bitcoin/

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

For Ubuntu users, there is a new ppa maintained by Matt Corallo which you can add to your system so that it will automatically keep bitcoin up-to-date. Just type "sudo apt-add-repository ppa:bitcoin/bitcoin" in your terminal, then install the bitcoin-qt package.

MAJOR BUG FIX (CVE-2011-4447)

The wallet encryption feature introduced in Bitcoin version 0.4.0 did not sufficiently secure the private keys. An attacker who
managed to get a copy of your encrypted wallet.dat file might be able to recover some or all of the unencrypted keys and steal the
associated coins.

If you have a previously encrypted wallet.dat, the first time you run bitcoin-qt or bitcoind the wallet will be rewritten, Bitcoin will
shut down, and you will be prompted to restart it to run with the new, properly encrypted file.

If you had a previously encrypted wallet.dat that might have been copied or stolen (for example, you backed it up to a public
location) you should send all of your bitcoins to yourself using a new bitcoin address and stop using any previously generated addresses.

Wallets encrypted with this version of Bitcoin are written properly.

Technical note: the encrypted wallet's 'keypool' will be regenerated the first time you request a new bitcoin address; to be certain that the
new private keys are properly backed up you should:

1. Run Bitcoin and let it rewrite the wallet.dat file

2. Run it again, then ask it for a new bitcoin address.
Bitcoin-Qt: Address Book, then New Address...
bitcoind: run the 'walletpassphrase' RPC command to unlock the wallet, then run the 'getnewaddress' RPC command.

3. If your encrypted wallet.dat may have been copied or stolen, send all of your bitcoins to the new bitcoin address.

4. Shut down Bitcoin, then backup the wallet.dat file.
IMPORTANT: be sure to request a new bitcoin address before backing up, so that the 'keypool' is regenerated and backed up.

"Security in depth" is always a good idea, so choosing a secure location for the backup and/or encrypting the backup before uploading it is recommended. And as in previous releases, if your machine is infected by malware there are several ways an attacker might steal your bitcoins.

Thanks to Alan Reiner (etotheipi) for finding and reporting this bug.

MAJOR GUI CHANGES

"Splash" graphics at startup that show address/wallet/blockchain loading progress.

"Synchronizing with network" progress bar to show block-chain download progress.

Icons at the bottom of the window that show how well connected you are to the network, with tooltips to display details.

Drag and drop support for bitcoin: URIs on web pages.

Export transactions as a .csv file.

Many other GUI improvements, large and small.

RPC CHANGES

getmemorypool : new RPC command, provides everything needed to construct a block with a custom generation transaction and submit a solution

listsinceblock : new RPC command, list transactions since given block

signmessage/verifymessage : new RPC commands to sign a message with one of your private keys or verify that a message signed by the private key associated with a bitcoin address.

GENERAL CHANGES

Faster initial block download.

==0.4.X==
After 0.4.0, all subsequent releases are stable maintenance releases, 0.5.0 is based on 0.4.0.

===0.4.6<ref>[https://bitcointalk.org/index.php?topic=79651 0.4.6/0.5.5 release announcement]</ref>===
bitcoind version 0.4.6 is now available for download at:
Windows: installer | zip (sig)
Source: tar.gz
bitcoind and Bitcoin-Qt version 0.6.0.7 are also tagged in git, but it is recommended to upgrade to 0.6.1.

These are bugfix-only releases.

Please report bugs by replying to this forum thread. Note that the 0.4.x wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr.

BUG FIXES

Version 0.6.0 allowed importing invalid "private keys", which would be unspendable; 0.6.0.7 will now verify the private key is valid, and refuse to import an invalid one
Verify status of encrypt/decrypt calls to detect failed padding
Check blocks for duplicate transactions earlier. Fixes #1167
Upgrade Windows builds to OpenSSL 1.0.1b
Set label when selecting an address that already has a label. Fixes #1080 (Bitcoin-Qt)
JSON-RPC listtransactions's from/count handling is now fixed
Optimize and fix multithreaded access, when checking whether we already know about transactions
Fix potential networking deadlock
Proper support for Growl 1.3 notifications
Display an error, rather than crashing, if encoding a QR Code failed (0.6.0.7)
Don't erroneously set "Display addresses" for users who haven't explicitly enabled it (Bitcoin-Qt)
Some non-ASCII input in JSON-RPC expecting hexadecimal may have been misinterpreted rather than rejected
Missing error condition checking added
Do not show green tick unless all known blocks are downloaded. Fixes #921 (Bitcoin-Qt)
Increase time ago of last block for "up to date" status from 30 to 90 minutes
Show a message box when runaway exception happens (Bitcoin-Qt)
Use a messagebox to display the error when -server is provided without providing a rpc password
Show error message instead of exception crash when unable to bind RPC port (Bitcoin-Qt)
Correct sign message bitcoin address tooltip. Fixes #1050 (Bitcoin-Qt)
Removed "(no label)" from QR Code dialog titlebar if we have no label (0.6.0.7)
Removed an ugly line break in tooltip for mature transactions (0.6.0.7)
Add missing tooltip and key shortcut in settings dialog (part of #1088) (Bitcoin-Qt)
Work around issue in boost::program_options that prevents from compiling in clang
Fixed bugs occurring only on platforms with unsigned characters (such as ARM).
Rename make_windows_icon.py to .sh as it is a shell script. Fixes #1099 (Bitcoin-Qt)
Various trivial internal corrections to types used for counting/size loops and warnings

===0.4.5===
(No known forum post.)

===0.4.4<ref>[https://bitcointalk.org/index.php?topic=70566.0 0.4.4 release announcement]</ref>===
Bitcoin version 0.4.4 is now available for download at:
http://luke.dashjr.org/programs/bitcoin/files/bitcoind-0.4.4/

This is a bugfix-only release based on 0.4.0.

Please note that the wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr.

Please report bugs for the daemon only using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.4.4#.tar.gz

BUG FIXES

Limit the number of orphan transactions stored in memory, to prevent a potential denial-of-service attack by flooding orphan transactions. Also never store invalid transactions at all.
Fix possible buffer overflow on systems with very long application data paths. This is not exploitable.
Resolved multiple bugs preventing long-term unlocking of encrypted wallets (issue #922).
Only send local IP in "version" messages if it is globally routable (ie, not private), and try to get such an IP from UPnP if applicable.
Reannounce UPnP port forwards every 20 minutes, to workaround routers expiring old entries, and allow the -upnp option to override any stored setting.
Various memory leaks and potential null pointer deferences have been
fixed.
Several shutdown issues have been fixed.
Check that keys stored in the wallet are valid at startup, and if not,
report corruption.
Various build fixes.
If no password is specified to bitcoind, recommend a secure password.
Update hard-coded fallback seed nodes, choosing recent ones with long uptime and versions at least 0.4.0.
Add checkpoint at block 168,000.

===0.4.3<ref>[https://bitcointalk.org/index.php?topic=57734.0 0.4.3 release announcement]</ref>===
bitcoind version 0.4.3 is now available for download at:
http://luke.dashjr.org/programs/bitcoin/files/bitcoind-0.4.3/ (until Gavin uploads to SourceForge)

This is a bugfix-only release based on 0.4.0.

Please note that the wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr.

Please report bugs for the daemon only using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.4.3#.tar.gz

BUG FIXES

Cease locking memory used by non-sensitive information (this caused a huge performance hit on some platforms, especially noticable during initial blockchain download).
Fixed some address-handling deadlocks (client freezes).
No longer accept inbound connections over the internet when Bitcoin is being used with Tor (identity leak).
Use the correct base transaction fee of 0.0005 BTC for accepting transactions into mined blocks (since 0.4.0, it was incorrectly accepting 0.0001 BTC which was only meant to be relayed).
Add new DNS seeds (maintained by Pieter Wuille and Luke Dashjr).

===0.4.2===
(No known forum post.)

===0.4.1<ref>[https://bitcointalk.org/index.php?topic=52503.0 0.4.1 release announcement]</ref>===
Bitcoin version 0.4.1 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.4.1/

This is a bugfix only release based on 0.4.0.

Please report bugs by replying to this forum thread.

MAJOR BUG FIX (CVE-2011-4447)

The wallet encryption feature introduced in Bitcoin version 0.4.0 did not sufficiently secure the private keys. An attacker who
managed to get a copy of your encrypted wallet.dat file might be able to recover some or all of the unencrypted keys and steal the
associated coins.

If you have a previously encrypted wallet.dat, the first time you run wxbitcoin or bitcoind the wallet will be rewritten, Bitcoin will
shut down, and you will be prompted to restart it to run with the new, properly encrypted file.

If you had a previously encrypted wallet.dat that might have been copied or stolen (for example, you backed it up to a public
location) you should send all of your bitcoins to yourself using a new bitcoin address and stop using any previously generated addresses.

Wallets encrypted with this version of Bitcoin are written properly.

Technical note: the encrypted wallet's 'keypool' will be regenerated the first time you request a new bitcoin address; to be certain that the
new private keys are properly backed up you should:

1. Run Bitcoin and let it rewrite the wallet.dat file

2. Run it again, then ask it for a new bitcoin address.
wxBitcoin: new address visible on main window
bitcoind: run the 'walletpassphrase' RPC command to unlock the wallet, then run the 'getnewaddress' RPC command.

3. If your encrypted wallet.dat may have been copied or stolen, send all of your bitcoins to the new bitcoin address.

4. Shut down Bitcoin, then backup the wallet.dat file.
IMPORTANT: be sure to request a new bitcoin address before backing up, so that the 'keypool' is regenerated and backed up.

"Security in depth" is always a good idea, so choosing a secure location for the backup and/or encrypting the backup before uploading it is recommended. And as in previous releases, if your machine is infected by malware there are several ways an attacker might steal your bitcoins.

Thanks to Alan Reiner (etotheipi) for finding and reporting this bug.

===0.4.0<ref>[https://bitcointalk.org/index.php?topic=45410.0 0.4 release announcement]</ref>===
Bitcoin version 0.4.0 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.4.0/

The main feature in this release is wallet private key encryption;
you can set a passphrase that must be entered before sending coins.
See below for more information; if you decide to encrypt your wallet,
WRITE DOWN YOUR PASSPHRASE AND PUT IT IN A SECURE LOCATION. If you
forget or lose your wallet passphrase, you lose your bitcoins.
Previous versions of bitcoin are unable to read encrypted wallets,
and will crash on startup if the wallet is encrypted.

Also note: bitcoin version 0.4 uses a newer version of Berkeley DB
(bdb version 4.8) than previous versions (bdb 4.7). If you upgrade
to version 0.4 and then revert back to an earlier version of bitcoin
the it may be unable to start because bdb 4.7 cannot read bdb 4.8
"log" files.

Notable bug fixes from version 0.3.24:

Fix several bitcoin-becomes-unresponsive bugs due to multithreading
deadlocks.

Optimize database writes for large (lots of inputs) transactions
(fixes a potential denial-of-service attack)

Wallet Encryption

Bitcoin supports native wallet encryption so that people who steal your
wallet file don't automatically get access to all of your Bitcoins.
In order to enable this feature, choose "Encrypt Wallet" from the
Options menu. You will be prompted to enter a passphrase, which
will be used as the key to encrypt your wallet and will be needed
every time you wish to send Bitcoins. If you lose this passphrase,
you will lose access to spend all of the bitcoins in your wallet,
no one, not even the Bitcoin developers can recover your Bitcoins.
This means you are responsible for your own security, store your
passphrase in a secure location and do not forget it.

Remember that the encryption built into bitcoin only encrypts the
actual keys which are required to send your bitcoins, not the full
wallet. This means that someone who steals your wallet file will
be able to see all the addresses which belong to you, as well as the
relevant transactions, you are only protected from someone spending
your coins.

It is recommended that you backup your wallet file before you
encrypt your wallet. To do this, close the Bitcoin client and
copy the wallet.dat file from ~/.bitcoin/ on Linux, /Users/(user
name)/Application Support/Bitcoin/ on Mac OSX, and %APPDATA%/Bitcoin/
on Windows (that is /Users/(user name)/AppData/Roaming/Bitcoin on
Windows Vista and 7 and /Documents and Settings/(user name)/Application
Data/Bitcoin on Windows XP). Once you have copied that file to a
safe location, reopen the Bitcoin client and Encrypt your wallet.
If everything goes fine, delete the backup and enjoy your encrypted
wallet. Note that once you encrypt your wallet, you will never be
able to go back to a version of the Bitcoin client older than 0.4.

Keep in mind that you are always responsible for your own security.
All it takes is a slightly more advanced wallet-stealing trojan which
installs a keylogger to steal your wallet passphrase as you enter it
in addition to your wallet file and you have lost all your Bitcoins.
Wallet encryption cannot keep you safe if you do not practice
good security, such as running up-to-date antivirus software, only
entering your wallet passphrase in the Bitcoin client and using the
same passphrase only as your wallet passphrase.

See the doc/README file in the bitcoin source for technical details
of wallet encryption.

==0.3.X==

===0.3.24<ref>[https://bitcointalk.org/index.php?topic=27187.0 0.3.24 release announcement]</ref>===
Bitcoin v0.3.24 is now available for download at
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.24/

This is another bug fix release. We had hoped to have wallet encryption ready for release, but more urgent fixes for existing clients were needed -- most notably block download problems were getting severe. Wallet encryption is ready for testing at https://github.com/bitcoin/bitcoin/pull/352 for the git-savvy, and hopefully will follow shortly in the next release, v0.4.

Notable fixes in v0.3.24, and the main reasons for this release:

F1) Block downloads were failing or taking unreasonable amounts of time to complete, because the increased size of the block chain was bumping up against some earlier buffer-size DoS limits.

F2) Fix crash caused by loss/lack of network connection.

Notable changes in v0.3.24:

C1) DNS seeding enabled by default.

C2) UPNP enabled by default in the GUI client. The percentage of bitcoin clients that accept incoming connections is quite small, and that is a problem. This should help. bitcoind, and unofficial builds, are unchanged (though we encourage use of "-upnp" to help the network!)

C3) Initial unit testing framework. Bitcoin sorely needs automated tests, and this is a beginning. Contributions welcome.

C4) Internal wallet code cleanup. While invisible to an end user, this change provides the basis for v0.4's wallet encryption.

===0.3.23<ref>[https://bitcointalk.org/index.php?topic=16553.0 0.3.23 release announcement]</ref>===
Win32, Linux, MacOSX and source releases for bitcoin v0.3.23 have been uploaded to
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.23/

This is another quick bugfix release, trying to deal with the influx of new bitcoin users.

Main items of note:

* P2P connect-to-node logic changed to reduce timeout a bit. The network saw a huge influx of new users, who do not permit incoming connections. This change is a short-term hack, to more quickly hunt for useful P2P connections. Better "leaf node" logic is in the works, but this should let us limp along until then. One may use -upnp to properly forward ports, and help the network.
* Transaction fee reduced to 0.0005 for new transactions
* Client will relay transactions with fees as low as 0.0001 BTC

===0.3.22<ref>[https://bitcointalk.org/index.php?topic=12269.0 0.3.22 release announcement]</ref>===
Download URL: https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.22/

This is largely a bugfix and TX fee schedule release. We also hope to make 0.3.23 a quick release, to fix problems that the network has seen due to explosive growth in the past week.

Notable changes:
* Client will accept and relay TX's with 0.0005 BTC fee schedule (users still pay 0.01 BTC per kb, until next version)
* Non-standard transactions accepted on testnet
* Source code tree reorganized (prep for autotools build)
* Remove "Generate Coins" option from GUI, and remove 4way SSE miner. Internal reference CPU miner remains available, but users are directed to external miners for best hash production.
* IRC is overflowing. Client now bootstraps to channels #bitcoin00 - #bitcoin99
* DNS names now may be used with -addnode, -connect (requires -dns to enable)

RPC changes:
* 'listtransactions' adds 'from' param, for range queries
* 'move' may take account balances negative
* 'settxfee' added, to manually set TX fee

===0.3.21<ref>[https://bitcointalk.org/index.php?topic=6642.0 0.3.21 release announcement]</ref>===
Binaries for Bitcoin version 0.3.21 are available at:
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.21/

Changes and new features from the 0.3.20 release include:

* Universal Plug and Play support. Enable automatic opening of a port for incoming connections by running bitcoin or bitcoind with the - -upnp=1 command line switch or using the Options dialog box.

* Support for full-precision bitcoin amounts. You can now send, and bitcoin will display, bitcoin amounts smaller than 0.01. However, sending fewer than 0.01 bitcoins still requires a 0.01 bitcoin fee (so you can send 1.0001 bitcoins without a fee, but you will be asked to pay a fee if you try to send 0.0001).

* A new method of finding bitcoin nodes to connect with, via DNS A records. Use the -dnsseed option to enable.

For developers, changes to bitcoin's remote-procedure-call API:

* New rpc command "sendmany" to send bitcoins to more than one address in a single transaction.

* Several bug fixes, including a serious intermittent bug that would sometimes cause bitcoind to stop accepting rpc requests.

* -logtimestamps option, to add a timestamp to each line in debug.log.

* Immature blocks (newly generated, under 120 confirmations) are now shown in listtransactions.

===0.3.20.2<ref>[https://bitcointalk.org/index.php?topic=4167.0 0.3.20.2 release announcement]</ref>===
The maxsendbuffer bug (0.3.20.1 clients not being able to download the block chain from other 0.3.20.1 clients) was only going to get
worse as people upgraded, so I cherry-picked the bug fix and created a minor release yesterday.

The Amazon Machine Images I used to do the builds are available:

ami-38a05251 Bitcoin-v0.3.20.2 Mingw (Windows; Administrator password 'bitcoin development')
ami-30a05259 Bitcoin_0.3.20.2 Linux32
ami-8abc4ee3 Bitcoin_0.3.20.2 Linux64

(mac build will be done soon)

If you have already downloaded version 0.3.20.1, please either add this to your bitcoin.conf file:

maxsendbuffer=10000
maxreceivebuffer=10000

... or download the new version.

===0.3.20.1===
(No known forum post.)

===0.3.20<ref>[https://bitcointalk.org/index.php?topic=2953.0 0.3.20 release announcement]</ref>===
Please checkout the git integration branch from:

https://github.com/bitcoin/bitcoin

... and help test. The new features that need testing are:

* -nolisten : https://github.com/bitcoin/bitcoin/pull/11
* -rescan : scan block chain for missing wallet transactions
* -printtoconsole : https://github.com/bitcoin/bitcoin/pull/37
* RPC gettransaction details : https://github.com/bitcoin/bitcoin/pull/24
* listtransactions new features : https://github.com/bitcoin/bitcoin/pull/10

Bug fixes that also need testing:

* -maxconnections= : https://github.com/bitcoin/bitcoin/pull/42
* RPC listaccounts minconf : https://github.com/bitcoin/bitcoin/pull/27
* RPC move, add time to output : https://github.com/bitcoin/bitcoin/pull/21
* ...and several improvements to --help output.

This needs more testing on Windows! Please drop me a quick private message, email, or IRC message if you are able to do some testing. If you find bugs, please open an issue at:

https://github.com/bitcoin/bitcoin/issues

===0.3.19<ref>[https://bitcointalk.org/index.php?topic=2228.0 0.3.19 release announcement]</ref>===
There's more work to do on DoS, but I'm doing a quick build of what I have so far in case it's needed, before venturing into more complex ideas. The build for this is version 0.3.19.

- Added some DoS controls
As Gavin and I have said clearly before, the software is not at all resistant to DoS attack. This is one improvement, but there are still more ways to attack than I can count.

I'm leaving the -limitfreerelay part as a switch for now and it's there if you need it.

- Removed "safe mode" alerts
"safe mode" alerts was a temporary measure after the 0.3.9 overflow bug. We can say all we want that users can just run with "-disablesafemode", but it's better just not to have it for the sake of appearances. It was never intended as a long term feature. Safe mode can still be triggered by seeing a longer (greater total PoW) invalid block chain.

===0.3.18<ref>[https://bitcointalk.org/index.php?topic=2162.0 0.3.18 release announcement]</ref>===

Changes:
* Fixed a wallet.dat compatibility problem if you downgraded from 0.3.17 and then upgraded again
* IsStandard() check to only include known transaction types in blocks
* Jgarzik's optimisation to speed up the initial block download a little

The main addition in this release is the Accounts-Based JSON-RPC commands that Gavin's been working on (more details at http://www.bitcoin.org/smf/index.php?topic=1886.0).
* getaccountaddress
* sendfrom
* move
* getbalance
* listtransactions

===0.3.17<ref>[https://bitcointalk.org/index.php?topic=1946.0 0.3.17 release announcement]</ref>===

Version 0.3.17 is now available.

Changes:
* new getwork, thanks m0mchil
* added transaction fee setting in UI options menu
* free transaction limits
* sendtoaddress returns transaction id instead of "sent"
* getaccountaddress <account>

The UI transaction fee setting was easy since it was still there from 0.1.5 and all I had to do was re-enable it.

The accounts-based commands: move, sendfrom and getbalance <account> will be in the next release. We still have some more changes to make first.

===0.3.16===

Never released.

===0.3.15<ref>[https://bitcointalk.org/index.php?topic=1780.0 0.3.15 release announcement]</ref>===

* paytxfee switch is now per KB, so it adds the correct fee for large transactions
* sending avoids using coins with less than 6 confirmations if it can
* BitcoinMiner processes transactions in priority order based on age of dependencies
* make sure generation doesn't start before block 74000 downloaded
* bugfixes by Dean Gores
* testnet, keypoololdest and paytxfee added to getinfo

===0.3.14<ref>[https://bitcointalk.org/index.php?topic=1528.0 0.3.14 release announcement]</ref>===

Version 0.3.14 is now available
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.14/

Changes:
* Key pool feature for safer wallet backup
Gavin Andresen:
* TEST network mode with switch -testnet
* Option to use SSL for JSON-RPC connections on unix/osx
* validateaddress RPC command
eurekafag:
* Russian translation

===0.3.13<ref>[https://bitcointalk.org/index.php?topic=1327.0 0.3.13 release announcement]</ref>===

Version 0.3.13 is now available. You should upgrade to prevent potential problems with 0/unconfirmed transactions. Note: 0.3.13 prevents problems if you haven't already spent a 0/unconfirmed transaction, but if that already happened, you need 0.3.13.2.

Changes:
* Don't count or spend payments until they have 1 confirmation.
* Internal version number from 312 to 31300.
* Only accept transactions sent by IP address if -allowreceivebyip is specified.
* Dropped DB_PRIVATE Berkeley DB flag.
* Fix problem sending the last cent with sub-cent fractional change.
* Auto-detect whether to use 128-bit 4-way SSE2 on Linux.
Gavin Andresen:
* Option -rpcallowip= to accept json-rpc connections from another machine.
* Clean shutdown on SIGTERM on Linux.

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.13/

(Thanks Laszlo for the Mac OSX build!)

Note:
The SSE2 auto-detect in the Linux 64-bit version doesn't work with AMD in 64-bit mode. Please try this instead and let me know if it gets it right:
http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gz

You can still control the SSE2 use manually with -4way and -4way=0.

Version 0.3.13.2 (SVN rev 161) has improvements for the case where you already had 0/unconfirmed transactions that you might have already spent. Here's a Windows build of it:
http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe

===0.3.12<ref>[https://bitcointalk.org/index.php?topic=999.0 0.3.12 release announcement]</ref>===

Version 0.3.12 is now available.

Features:
* json-rpc errors return a more standard error object. (thanks to Gavin Andresen)
* json-rpc command line returns exit codes.
* json-rpc "backupwallet" command.
* Recovers and continues if an exception is caused by a message you received. Other nodes shouldn't be able to cause an exception, and it hasn't happened before, but if a way is found to cause an exception, this would keep it from being used to stop network nodes.

If you have json-rpc code that checks the contents of the error string, you need to change it to expect error objects of the form {"code":<number>,"message":<string>}, which is the standard. See this thread:
http://www.bitcoin.org/smf/index.php?topic=969.0

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.12/

=References=
<references/>

Changelog

2012-06-12T23:03:01Z

BlueMatt: /* 0.6.00.6.0 release announcement */ Remove Box

{{stub}}

This page aggregates the changelogs that have been posted on the forum for the Bitcoin releases.
Note that some download links are not longer valid as highly insecure versions may have been deleted, or links may have changed.

=Changelogs=

==0.6.X==
===0.6.2<ref>[https://bitcointalk.org/index.php?topic=80187.0 0.6.2 release announcement]</ref>===
Bitcoin version 0.6.2 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.2/

This is a bug-fix and code-cleanup release, with no major new features.

Please report bugs using the github issue tracker at:
https://github.com/bitcoin/bitcoin/issues

NOTABLE CHANGES

Much faster shutdowns. However, the blkindex.dat file is no longer
portable to different data directories by default. If you need a
portable blkindex.dat file then run with the new -detachdb=1 option
or the "Detach databases at shutdown" GUI preference.

Fixed https://github.com/bitcoin/bitcoin/issues/1065, a bug that
could cause long-running nodes to crash.

Mac and Windows binaries are compiled against OpenSSL 1.0.1b (Linux
binaries are dynamically linked to the version of OpenSSL on the system).

CHANGE SUMMARY

Use 'git shortlog --no-merges v0.6.0..' for a summary of this release.

Source codebase changes:
- Many source code cleanups and warnings fixes. Close to building with -Wall
- Locking overhaul, and several minor locking fixes
- Several source code portability fixes, e.g. FreeBSD

JSON-RPC interface changes:
- addmultisigaddress enabled for mainnet (previously only enabled for testnet)

Network protocol changes:
- protocol version 60001
- added nonce value to "ping" message (BIP 31)
- added new "pong" message (BIP 31)

Backend storage changes:
- Less redundant database flushing, especially during initial block download
- Shutdown improvements (see above)

Qt user interface:
- minor URI handling improvements
- progressbar improvements
- error handling improvements (show message box rather than console exception,
etc.)
- by popular request, make 4th bar of connection icon green

===0.6.1===
Never released

===0.6.0<ref>[https://bitcointalk.org/index.php?topic=74737.0 0.6.0 release announcement]</ref>===
Bitcoin version 0.6.0 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/

This release includes more than 20 language localizations.
More translations are welcome; join the
project at Transifex to help:
https://www.transifex.net/projects/p/bitcoin/

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Project source code is hosted at github; we are no longer
distributing .tar.gz files here, you can get them
directly from github:
https://github.com/bitcoin/bitcoin/tarball/v0.6.0 # .tar.gz
https://github.com/bitcoin/bitcoin/zipball/v0.6.0 # .zip

For Ubuntu users, there is a ppa maintained by Matt Corallo which
you can add to your system so that it will automatically keep
bitcoin up-to-date. Just type
sudo apt-add-repository ppa:bitcoin/bitcoin
in your terminal, then install the bitcoin-qt package.

KNOWN ISSUES

Shutting down while synchronizing with the network
(downloading the blockchain) can take more than a minute,
because database writes are queued to speed up download
time.

NEW FEATURES SINCE BITCOIN VERSION 0.5

Initial network synchronization should be much faster
(one or two hours on a typical machine instead of ten or more
hours).

Backup Wallet menu option.

Bitcoin-Qt can display and save QR codes for sending
and receiving addresses.

New context menu on addresses to copy/edit/delete them.

New Sign Message dialog that allows you to prove that you
own a bitcoin address by creating a digital
signature.

New wallets created with this version will
use 33-byte 'compressed' public keys instead of
65-byte public keys, resulting in smaller
transactions and less traffic on the bitcoin
network. The shorter keys are already supported
by the network but wallet.dat files containing
short keys are not compatible with earlier
versions of Bitcoin-Qt/bitcoind.

New command-line argument -blocknotify=<command>
that will spawn a shell process to run <command>
when a new block is accepted.

New command-line argument -splash=0 to disable
Bitcoin-Qt's initial splash screen

validateaddress JSON-RPC api command output includes
two new fields for addresses in the wallet:
pubkey : hexadecimal public key
iscompressed : true if pubkey is a short 33-byte key

New JSON-RPC api commands for dumping/importing
private keys from the wallet (dumprivkey, importprivkey).

New JSON-RPC api command for getting information about
blocks (getblock, getblockhash).

New JSON-RPC api command (getmininginfo) for getting
extra information related to mining. The getinfo
JSON-RPC command no longer includes mining-related
information (generate/genproclimit/hashespersec).

NOTABLE CHANGES

BIP30 implemented (security fix for an attack involving
duplicate "coinbase transactions").

The -nolisten, -noupnp and -nodnsseed command-line
options were renamed to -listen, -upnp and -dnsseed,
with a default value of 1. The old names are still
supported for compatibility (so specifying -nolisten
is automatically interpreted as -listen=0; every
boolean argument can now be specified as either
-foo or -nofoo).

The -noirc command-line options was renamed to
-irc, with a default value of 0. Run -irc=1 to
get the old behavior.

Three fill-up-available-memory denial-of-service
attacks were fixed.

NOT YET IMPLEMENTED FEATURES

Support for clicking on bitcoin: URIs and
opening/launching Bitcoin-Qt is available only on Linux,
and only if you configure your desktop to launch
Bitcoin-Qt. All platforms support dragging and dropping
bitcoin: URIs onto the Bitcoin-Qt window to start
payment.

PRELIMINARY SUPPORT FOR MULTISIGNATURE TRANSACTIONS

This release has preliminary support for multisignature
transactions-- transactions that require authorization
from more than one person or device before they
will be accepted by the bitcoin network.

Prior to this release, multisignature transactions
were considered 'non-standard' and were ignored;
with this release multisignature transactions are
considered standard and will start to be relayed
and accepted into blocks.

It is expected that future releases of Bitcoin-Qt
will support the creation of multisignature transactions,
once enough of the network has upgraded so relaying
and validating them is robust.

For this release, creation and testing of multisignature
transactions is limited to the bitcoin test network using
the "addmultisigaddress" JSON-RPC api call.

Short multisignature address support is included in this
release, as specified in BIP 13 and BIP 16.

==0.5.X==
After 0.5.1, all subsequent releases are stable maintenance releases, 0.6.0 is based on 0.5.1.

===0.5.5<ref>[https://bitcointalk.org/index.php?topic=79651 0.4.6/0.5.5 release announcement]</ref>===
bitcoind and Bitcoin-Qt version 0.5.5 are now available for download at:
Windows: installer | zip (sig)
Source: tar.gz
bitcoind and Bitcoin-Qt version 0.6.0.7 are also tagged in git, but it is recommended to upgrade to 0.6.1.

These are bugfix-only releases.

Please report bugs by replying to this forum thread. Note that the 0.4.x wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr.

BUG FIXES

Version 0.6.0 allowed importing invalid "private keys", which would be unspendable; 0.6.0.7 will now verify the private key is valid, and refuse to import an invalid one
Verify status of encrypt/decrypt calls to detect failed padding
Check blocks for duplicate transactions earlier. Fixes #1167
Upgrade Windows builds to OpenSSL 1.0.1b
Set label when selecting an address that already has a label. Fixes #1080 (Bitcoin-Qt)
JSON-RPC listtransactions's from/count handling is now fixed
Optimize and fix multithreaded access, when checking whether we already know about transactions
Fix potential networking deadlock
Proper support for Growl 1.3 notifications
Display an error, rather than crashing, if encoding a QR Code failed (0.6.0.7)
Don't erroneously set "Display addresses" for users who haven't explicitly enabled it (Bitcoin-Qt)
Some non-ASCII input in JSON-RPC expecting hexadecimal may have been misinterpreted rather than rejected
Missing error condition checking added
Do not show green tick unless all known blocks are downloaded. Fixes #921 (Bitcoin-Qt)
Increase time ago of last block for "up to date" status from 30 to 90 minutes
Show a message box when runaway exception happens (Bitcoin-Qt)
Use a messagebox to display the error when -server is provided without providing a rpc password
Show error message instead of exception crash when unable to bind RPC port (Bitcoin-Qt)
Correct sign message bitcoin address tooltip. Fixes #1050 (Bitcoin-Qt)
Removed "(no label)" from QR Code dialog titlebar if we have no label (0.6.0.7)
Removed an ugly line break in tooltip for mature transactions (0.6.0.7)
Add missing tooltip and key shortcut in settings dialog (part of #1088) (Bitcoin-Qt)
Work around issue in boost::program_options that prevents from compiling in clang
Fixed bugs occurring only on platforms with unsigned characters (such as ARM).
Rename make_windows_icon.py to .sh as it is a shell script. Fixes #1099 (Bitcoin-Qt)
Various trivial internal corrections to types used for counting/size loops and warnings

===0.5.4<ref>[https://bitcointalk.org/index.php?topic=76808.0 0.5.4 release announcement]</ref>===
Bitcoin version 0.5.4 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.4/
NOTE: 0.5.4rc3 is being renamed to 0.5.4 final with no changes.

This is a bugfix-only release in the 0.5.x series, plus a few protocol updates.

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.4#.tar.gz

PROTOCOL UPDATES

BIP 16: Special-case "pay to script hash" logic to enable minimal validation of new transactions.
Support for validating message signatures produced with compressed public keys.

BUG FIXES

Build with thread-safe MingW libraries for Windows, fixing a dangerous memory corruption scenario when exceptions are thrown.
Fix broken testnet mining.
Stop excess inventory relay during initial block download.
When disconnecting a node, clear the received buffer so that we do not process any already received messages.
Yet another attempt at implementing "minimize to tray" that works on all operating systems.
Fix Bitcoin-Qt notifications under Growl 1.3.
Increase required age of Bitcoin-Qt's "not up to date" status from 30 to 90 minutes.
Implemented missing verifications that led to crash on entering some wrong passphrases for encrypted wallets.
Fix default filename suffixes in GNOME save dialog.
Make the "Send coins" tab use the configured unit type, even on the first attempt.
Print detailed wallet loading errors to debug.log when it is corrupt.
Allocate exactly the amount of space needed for signing transactions, instead of a fixed 10k buffer.
Workaround for improbable memory access violation.
Check wallet's minimum version before trying to load it.
Remove wxBitcoin properly when installing Bitcoin-Qt over it. (Windows)
Detail reorganization information better in debug log.
Use a messagebox to display the error when -server is provided without configuring a RPC password.
Testing suite build now honours provided CXXFLAGS.
Removed an extraneous line-break in mature transaction tooltips.
Fix some grammatical errors in translation process documentation.

===0.5.3<ref>[https://bitcointalk.org/index.php?topic=68895.0 0.5.3 release announcement]</ref>===
Bitcoin version 0.5.3 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.3/

This is a bugfix-only release based on 0.5.1.
It also includes a few protocol updates.

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.3#.tar.gz

PROTOCOL UPDATES

BIP 30: Introduce a new network rule: "a block is not valid if it contains a transaction whose hash already exists in the block chain, unless all that transaction's outputs were already spent before said block" beginning on March 15, 2012, 00:00 UTC.
On testnet, allow mining of min-difficulty blocks if 20 minutes have gone by without mining a regular-difficulty block. This is to make testing Bitcoin easier, and will not affect normal mode.

BUG FIXES

Limit the number of orphan transactions stored in memory, to prevent a potential denial-of-service attack by flooding orphan transactions. Also never store invalid transactions at all.
Fix possible buffer overflow on systems with very long application data paths. This is not exploitable.
Resolved multiple bugs preventing long-term unlocking of encrypted wallets
(issue #922).
Only send local IP in "version" messages if it is globally routable (ie, not private), and try to get such an IP from UPnP if applicable.
Reannounce UPnP port forwards every 20 minutes, to workaround routers expiring old entries, and allow the -upnp option to override any stored setting.
Skip splash screen when -min is used, and fix Minimize to Tray function.
Do not blank "label" in Bitcoin-Qt "Send" tab, if the user has already entered something.
Correct various labels and messages.
Various memory leaks and potential null pointer deferences have been fixed.
Handle invalid Bitcoin URIs using "bitcoin://" instead of "bitcoin:".
Several shutdown issues have been fixed.
Revert to "global progress indication", as starting from zero every time was considered too confusing for many users.
Check that keys stored in the wallet are valid at startup, and if not, report corruption.
Enable accessible widgets on Windows, so that people with screen readers such as NVDA can make sense of it.
Various build fixes.
If no password is specified to bitcoind, recommend a secure password.
Automatically focus and scroll to new "Send coins" entries in Bitcoin-Qt.
Show a message box for --help on Windows, for Bitcoin-Qt.
Add missing "About Qt" menu option to show built-in Qt About dialog.
Don't show "-daemon" as an option for Bitcoin-Qt, since it isn't available.
Update hard-coded fallback seed nodes, choosing recent ones with long uptime and versions at least 0.4.0.
Add checkpoint at block 168,000.

===0.5.2<ref>[https://bitcointalk.org/index.php?topic=60146.0 0.5.2 release announcement]</ref>===
Bitcoin version 0.5.2 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.2/

This is a bugfix-only release based on 0.5.1.

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.2#.tar.gz

BUG FIXES

Check all transactions in blocks after the last checkpoint (0.5.0 and 0.5.1 skipped checking ECDSA signatures during initial blockchain download).
Cease locking memory used by non-sensitive information (this caused a huge performance hit on some platforms, especially noticable during initial blockchain download; this was
not a security vulnerability).
Fixed some address-handling deadlocks (client freezes).
No longer accept inbound connections over the internet when Bitcoin is being used with Tor (identity leak).
Re-enable SSL support for the JSON-RPC interface (it was unintentionally disabled for the 0.5.0 and 0.5.1 release Linux binaries).
Use the correct base transaction fee of 0.0005 BTC for accepting transactions into mined blocks (since 0.4.0, it was incorrectly accepting 0.0001 BTC which was only meant to be relayed).
Don't show "IP" for transactions which are not necessarily IP transactions.
Add new DNS seeds (maintained by Pieter Wuille and Luke Dashjr).

===0.5.1<ref>[https://bitcointalk.org/index.php?topic=54717.0 0.5.1 release announcement]</ref>===
Bitcoin version 0.5.1 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.1/

This is a bugfix-only release.

This release includes 13 translations, including 5 new translations:
Italian, Hungarian, Ukranian, Portuguese (Brazilian) and Simplified Chinese.
More translations are welcome; join the project at Transifex if you can help:
https://www.transifex.net/projects/p/bitcoin/

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Project source code is hosted at github; we are no longer
distributing .tar.gz files here, you can get them
directly from github:
https://github.com/bitcoin/bitcoin/tarball/v0.5.1 # .tar.gz
https://github.com/bitcoin/bitcoin/zipball/v0.5.1 # .zip

For Ubuntu users, there is a new ppa maintained by Matt Corallo which
you can add to your system so that it will automatically keep
bitcoin up-to-date. Just type
sudo apt-add-repository ppa:bitcoin/bitcoin
in your terminal, then install the bitcoin-qt package.

BUG FIXES

Re-enable SSL support for the JSON-RPC interface (it was unintentionally
disabled for the 0.5.0 release binaries).

The code that finds peers via "dns seeds" no longer stops bitcoin startup
if one of the dns seed machines is down.

Tooltips on the transaction list view were rendering incorrectly (as black boxes
or with a transparent background).

Prevent a denial-of-service attack involving flooding a bitcoin node with
orphan blocks.

The wallet passphrase dialog now warns you if the caps lock key was pressed.

Improved searching in addresses and labels in bitcoin-qt.

===0.5.0<ref>[https://bitcointalk.org/index.php?topic=52480.0 0.5.0 release announcement]</ref>===
Bitcoin version 0.5.0 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.0/

The major change for this release is a completely new graphical interface that uses the Qt user interface toolkit.

This release include German, Spanish, Spanish-Castilian, Norwegian and Dutch translations. More translations are welcome; join the project at Transifex if you can help:
https://www.transifex.net/projects/p/bitcoin/

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

For Ubuntu users, there is a new ppa maintained by Matt Corallo which you can add to your system so that it will automatically keep bitcoin up-to-date. Just type "sudo apt-add-repository ppa:bitcoin/bitcoin" in your terminal, then install the bitcoin-qt package.

MAJOR BUG FIX (CVE-2011-4447)

The wallet encryption feature introduced in Bitcoin version 0.4.0 did not sufficiently secure the private keys. An attacker who
managed to get a copy of your encrypted wallet.dat file might be able to recover some or all of the unencrypted keys and steal the
associated coins.

If you have a previously encrypted wallet.dat, the first time you run bitcoin-qt or bitcoind the wallet will be rewritten, Bitcoin will
shut down, and you will be prompted to restart it to run with the new, properly encrypted file.

If you had a previously encrypted wallet.dat that might have been copied or stolen (for example, you backed it up to a public
location) you should send all of your bitcoins to yourself using a new bitcoin address and stop using any previously generated addresses.

Wallets encrypted with this version of Bitcoin are written properly.

Technical note: the encrypted wallet's 'keypool' will be regenerated the first time you request a new bitcoin address; to be certain that the
new private keys are properly backed up you should:

1. Run Bitcoin and let it rewrite the wallet.dat file

2. Run it again, then ask it for a new bitcoin address.
Bitcoin-Qt: Address Book, then New Address...
bitcoind: run the 'walletpassphrase' RPC command to unlock the wallet, then run the 'getnewaddress' RPC command.

3. If your encrypted wallet.dat may have been copied or stolen, send all of your bitcoins to the new bitcoin address.

4. Shut down Bitcoin, then backup the wallet.dat file.
IMPORTANT: be sure to request a new bitcoin address before backing up, so that the 'keypool' is regenerated and backed up.

"Security in depth" is always a good idea, so choosing a secure location for the backup and/or encrypting the backup before uploading it is recommended. And as in previous releases, if your machine is infected by malware there are several ways an attacker might steal your bitcoins.

Thanks to Alan Reiner (etotheipi) for finding and reporting this bug.

MAJOR GUI CHANGES

"Splash" graphics at startup that show address/wallet/blockchain loading progress.

"Synchronizing with network" progress bar to show block-chain download progress.

Icons at the bottom of the window that show how well connected you are to the network, with tooltips to display details.

Drag and drop support for bitcoin: URIs on web pages.

Export transactions as a .csv file.

Many other GUI improvements, large and small.

RPC CHANGES

getmemorypool : new RPC command, provides everything needed to construct a block with a custom generation transaction and submit a solution

listsinceblock : new RPC command, list transactions since given block

signmessage/verifymessage : new RPC commands to sign a message with one of your private keys or verify that a message signed by the private key associated with a bitcoin address.

GENERAL CHANGES

Faster initial block download.

==0.4.X==
After 0.4.0, all subsequent releases are stable maintenance releases, 0.5.0 is based on 0.4.0.

===0.4.6<ref>[https://bitcointalk.org/index.php?topic=79651 0.4.6/0.5.5 release announcement]</ref>===
bitcoind version 0.4.6 is now available for download at:
Windows: installer | zip (sig)
Source: tar.gz
bitcoind and Bitcoin-Qt version 0.6.0.7 are also tagged in git, but it is recommended to upgrade to 0.6.1.

These are bugfix-only releases.

Please report bugs by replying to this forum thread. Note that the 0.4.x wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr.

BUG FIXES

Version 0.6.0 allowed importing invalid "private keys", which would be unspendable; 0.6.0.7 will now verify the private key is valid, and refuse to import an invalid one
Verify status of encrypt/decrypt calls to detect failed padding
Check blocks for duplicate transactions earlier. Fixes #1167
Upgrade Windows builds to OpenSSL 1.0.1b
Set label when selecting an address that already has a label. Fixes #1080 (Bitcoin-Qt)
JSON-RPC listtransactions's from/count handling is now fixed
Optimize and fix multithreaded access, when checking whether we already know about transactions
Fix potential networking deadlock
Proper support for Growl 1.3 notifications
Display an error, rather than crashing, if encoding a QR Code failed (0.6.0.7)
Don't erroneously set "Display addresses" for users who haven't explicitly enabled it (Bitcoin-Qt)
Some non-ASCII input in JSON-RPC expecting hexadecimal may have been misinterpreted rather than rejected
Missing error condition checking added
Do not show green tick unless all known blocks are downloaded. Fixes #921 (Bitcoin-Qt)
Increase time ago of last block for "up to date" status from 30 to 90 minutes
Show a message box when runaway exception happens (Bitcoin-Qt)
Use a messagebox to display the error when -server is provided without providing a rpc password
Show error message instead of exception crash when unable to bind RPC port (Bitcoin-Qt)
Correct sign message bitcoin address tooltip. Fixes #1050 (Bitcoin-Qt)
Removed "(no label)" from QR Code dialog titlebar if we have no label (0.6.0.7)
Removed an ugly line break in tooltip for mature transactions (0.6.0.7)
Add missing tooltip and key shortcut in settings dialog (part of #1088) (Bitcoin-Qt)
Work around issue in boost::program_options that prevents from compiling in clang
Fixed bugs occurring only on platforms with unsigned characters (such as ARM).
Rename make_windows_icon.py to .sh as it is a shell script. Fixes #1099 (Bitcoin-Qt)
Various trivial internal corrections to types used for counting/size loops and warnings

===0.4.5===
(No known forum post.)

===0.4.4<ref>[https://bitcointalk.org/index.php?topic=70566.0 0.4.4 release announcement]</ref>===
Bitcoin version 0.4.4 is now available for download at:
http://luke.dashjr.org/programs/bitcoin/files/bitcoind-0.4.4/

This is a bugfix-only release based on 0.4.0.

Please note that the wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr.

Please report bugs for the daemon only using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.4.4#.tar.gz

BUG FIXES

Limit the number of orphan transactions stored in memory, to prevent a potential denial-of-service attack by flooding orphan transactions. Also never store invalid transactions at all.
Fix possible buffer overflow on systems with very long application data paths. This is not exploitable.
Resolved multiple bugs preventing long-term unlocking of encrypted wallets (issue #922).
Only send local IP in "version" messages if it is globally routable (ie, not private), and try to get such an IP from UPnP if applicable.
Reannounce UPnP port forwards every 20 minutes, to workaround routers expiring old entries, and allow the -upnp option to override any stored setting.
Various memory leaks and potential null pointer deferences have been
fixed.
Several shutdown issues have been fixed.
Check that keys stored in the wallet are valid at startup, and if not,
report corruption.
Various build fixes.
If no password is specified to bitcoind, recommend a secure password.
Update hard-coded fallback seed nodes, choosing recent ones with long uptime and versions at least 0.4.0.
Add checkpoint at block 168,000.

===0.4.3<ref>[https://bitcointalk.org/index.php?topic=57734.0 0.4.3 release announcement]</ref>===
bitcoind version 0.4.3 is now available for download at:
http://luke.dashjr.org/programs/bitcoin/files/bitcoind-0.4.3/ (until Gavin uploads to SourceForge)

This is a bugfix-only release based on 0.4.0.

Please note that the wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr.

Please report bugs for the daemon only using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.4.3#.tar.gz

BUG FIXES

Cease locking memory used by non-sensitive information (this caused a huge performance hit on some platforms, especially noticable during initial blockchain download).
Fixed some address-handling deadlocks (client freezes).
No longer accept inbound connections over the internet when Bitcoin is being used with Tor (identity leak).
Use the correct base transaction fee of 0.0005 BTC for accepting transactions into mined blocks (since 0.4.0, it was incorrectly accepting 0.0001 BTC which was only meant to be relayed).
Add new DNS seeds (maintained by Pieter Wuille and Luke Dashjr).

===0.4.2===
(No known forum post.)

===0.4.1<ref>[https://bitcointalk.org/index.php?topic=52503.0 0.4.1 release announcement]</ref>===
Bitcoin version 0.4.1 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.4.1/

This is a bugfix only release based on 0.4.0.

Please report bugs by replying to this forum thread.

MAJOR BUG FIX (CVE-2011-4447)

The wallet encryption feature introduced in Bitcoin version 0.4.0 did not sufficiently secure the private keys. An attacker who
managed to get a copy of your encrypted wallet.dat file might be able to recover some or all of the unencrypted keys and steal the
associated coins.

If you have a previously encrypted wallet.dat, the first time you run wxbitcoin or bitcoind the wallet will be rewritten, Bitcoin will
shut down, and you will be prompted to restart it to run with the new, properly encrypted file.

If you had a previously encrypted wallet.dat that might have been copied or stolen (for example, you backed it up to a public
location) you should send all of your bitcoins to yourself using a new bitcoin address and stop using any previously generated addresses.

Wallets encrypted with this version of Bitcoin are written properly.

Technical note: the encrypted wallet's 'keypool' will be regenerated the first time you request a new bitcoin address; to be certain that the
new private keys are properly backed up you should:

1. Run Bitcoin and let it rewrite the wallet.dat file

2. Run it again, then ask it for a new bitcoin address.
wxBitcoin: new address visible on main window
bitcoind: run the 'walletpassphrase' RPC command to unlock the wallet, then run the 'getnewaddress' RPC command.

3. If your encrypted wallet.dat may have been copied or stolen, send all of your bitcoins to the new bitcoin address.

4. Shut down Bitcoin, then backup the wallet.dat file.
IMPORTANT: be sure to request a new bitcoin address before backing up, so that the 'keypool' is regenerated and backed up.

"Security in depth" is always a good idea, so choosing a secure location for the backup and/or encrypting the backup before uploading it is recommended. And as in previous releases, if your machine is infected by malware there are several ways an attacker might steal your bitcoins.

Thanks to Alan Reiner (etotheipi) for finding and reporting this bug.

===0.4.0<ref>[https://bitcointalk.org/index.php?topic=45410.0 0.4 release announcement]</ref>===
Bitcoin version 0.4.0 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.4.0/

The main feature in this release is wallet private key encryption;
you can set a passphrase that must be entered before sending coins.
See below for more information; if you decide to encrypt your wallet,
WRITE DOWN YOUR PASSPHRASE AND PUT IT IN A SECURE LOCATION. If you
forget or lose your wallet passphrase, you lose your bitcoins.
Previous versions of bitcoin are unable to read encrypted wallets,
and will crash on startup if the wallet is encrypted.

Also note: bitcoin version 0.4 uses a newer version of Berkeley DB
(bdb version 4.8) than previous versions (bdb 4.7). If you upgrade
to version 0.4 and then revert back to an earlier version of bitcoin
the it may be unable to start because bdb 4.7 cannot read bdb 4.8
"log" files.

Notable bug fixes from version 0.3.24:

Fix several bitcoin-becomes-unresponsive bugs due to multithreading
deadlocks.

Optimize database writes for large (lots of inputs) transactions
(fixes a potential denial-of-service attack)

Wallet Encryption

Bitcoin supports native wallet encryption so that people who steal your
wallet file don't automatically get access to all of your Bitcoins.
In order to enable this feature, choose "Encrypt Wallet" from the
Options menu. You will be prompted to enter a passphrase, which
will be used as the key to encrypt your wallet and will be needed
every time you wish to send Bitcoins. If you lose this passphrase,
you will lose access to spend all of the bitcoins in your wallet,
no one, not even the Bitcoin developers can recover your Bitcoins.
This means you are responsible for your own security, store your
passphrase in a secure location and do not forget it.

Remember that the encryption built into bitcoin only encrypts the
actual keys which are required to send your bitcoins, not the full
wallet. This means that someone who steals your wallet file will
be able to see all the addresses which belong to you, as well as the
relevant transactions, you are only protected from someone spending
your coins.

It is recommended that you backup your wallet file before you
encrypt your wallet. To do this, close the Bitcoin client and
copy the wallet.dat file from ~/.bitcoin/ on Linux, /Users/(user
name)/Application Support/Bitcoin/ on Mac OSX, and %APPDATA%/Bitcoin/
on Windows (that is /Users/(user name)/AppData/Roaming/Bitcoin on
Windows Vista and 7 and /Documents and Settings/(user name)/Application
Data/Bitcoin on Windows XP). Once you have copied that file to a
safe location, reopen the Bitcoin client and Encrypt your wallet.
If everything goes fine, delete the backup and enjoy your encrypted
wallet. Note that once you encrypt your wallet, you will never be
able to go back to a version of the Bitcoin client older than 0.4.

Keep in mind that you are always responsible for your own security.
All it takes is a slightly more advanced wallet-stealing trojan which
installs a keylogger to steal your wallet passphrase as you enter it
in addition to your wallet file and you have lost all your Bitcoins.
Wallet encryption cannot keep you safe if you do not practice
good security, such as running up-to-date antivirus software, only
entering your wallet passphrase in the Bitcoin client and using the
same passphrase only as your wallet passphrase.

See the doc/README file in the bitcoin source for technical details
of wallet encryption.

==0.3.X==

===0.3.24<ref>[https://bitcointalk.org/index.php?topic=27187.0 0.3.24 release announcement]</ref>===
Bitcoin v0.3.24 is now available for download at
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.24/

This is another bug fix release. We had hoped to have wallet encryption ready for release, but more urgent fixes for existing clients were needed -- most notably block download problems were getting severe. Wallet encryption is ready for testing at https://github.com/bitcoin/bitcoin/pull/352 for the git-savvy, and hopefully will follow shortly in the next release, v0.4.

Notable fixes in v0.3.24, and the main reasons for this release:

F1) Block downloads were failing or taking unreasonable amounts of time to complete, because the increased size of the block chain was bumping up against some earlier buffer-size DoS limits.

F2) Fix crash caused by loss/lack of network connection.

Notable changes in v0.3.24:

C1) DNS seeding enabled by default.

C2) UPNP enabled by default in the GUI client. The percentage of bitcoin clients that accept incoming connections is quite small, and that is a problem. This should help. bitcoind, and unofficial builds, are unchanged (though we encourage use of "-upnp" to help the network!)

C3) Initial unit testing framework. Bitcoin sorely needs automated tests, and this is a beginning. Contributions welcome.

C4) Internal wallet code cleanup. While invisible to an end user, this change provides the basis for v0.4's wallet encryption.

===0.3.23<ref>[https://bitcointalk.org/index.php?topic=16553.0 0.3.23 release announcement]</ref>===
Win32, Linux, MacOSX and source releases for bitcoin v0.3.23 have been uploaded to
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.23/

This is another quick bugfix release, trying to deal with the influx of new bitcoin users.

Main items of note:

* P2P connect-to-node logic changed to reduce timeout a bit. The network saw a huge influx of new users, who do not permit incoming connections. This change is a short-term hack, to more quickly hunt for useful P2P connections. Better "leaf node" logic is in the works, but this should let us limp along until then. One may use -upnp to properly forward ports, and help the network.
* Transaction fee reduced to 0.0005 for new transactions
* Client will relay transactions with fees as low as 0.0001 BTC

===0.3.22<ref>[https://bitcointalk.org/index.php?topic=12269.0 0.3.22 release announcement]</ref>===
Download URL: https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.22/

This is largely a bugfix and TX fee schedule release. We also hope to make 0.3.23 a quick release, to fix problems that the network has seen due to explosive growth in the past week.

Notable changes:
* Client will accept and relay TX's with 0.0005 BTC fee schedule (users still pay 0.01 BTC per kb, until next version)
* Non-standard transactions accepted on testnet
* Source code tree reorganized (prep for autotools build)
* Remove "Generate Coins" option from GUI, and remove 4way SSE miner. Internal reference CPU miner remains available, but users are directed to external miners for best hash production.
* IRC is overflowing. Client now bootstraps to channels #bitcoin00 - #bitcoin99
* DNS names now may be used with -addnode, -connect (requires -dns to enable)

RPC changes:
* 'listtransactions' adds 'from' param, for range queries
* 'move' may take account balances negative
* 'settxfee' added, to manually set TX fee

===0.3.21<ref>[https://bitcointalk.org/index.php?topic=6642.0 0.3.21 release announcement]</ref>===
Binaries for Bitcoin version 0.3.21 are available at:
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.21/

Changes and new features from the 0.3.20 release include:

* Universal Plug and Play support. Enable automatic opening of a port for incoming connections by running bitcoin or bitcoind with the - -upnp=1 command line switch or using the Options dialog box.

* Support for full-precision bitcoin amounts. You can now send, and bitcoin will display, bitcoin amounts smaller than 0.01. However, sending fewer than 0.01 bitcoins still requires a 0.01 bitcoin fee (so you can send 1.0001 bitcoins without a fee, but you will be asked to pay a fee if you try to send 0.0001).

* A new method of finding bitcoin nodes to connect with, via DNS A records. Use the -dnsseed option to enable.

For developers, changes to bitcoin's remote-procedure-call API:

* New rpc command "sendmany" to send bitcoins to more than one address in a single transaction.

* Several bug fixes, including a serious intermittent bug that would sometimes cause bitcoind to stop accepting rpc requests.

* -logtimestamps option, to add a timestamp to each line in debug.log.

* Immature blocks (newly generated, under 120 confirmations) are now shown in listtransactions.

===0.3.20.2<ref>[https://bitcointalk.org/index.php?topic=4167.0 0.3.20.2 release announcement]</ref>===
The maxsendbuffer bug (0.3.20.1 clients not being able to download the block chain from other 0.3.20.1 clients) was only going to get
worse as people upgraded, so I cherry-picked the bug fix and created a minor release yesterday.

The Amazon Machine Images I used to do the builds are available:

ami-38a05251 Bitcoin-v0.3.20.2 Mingw (Windows; Administrator password 'bitcoin development')
ami-30a05259 Bitcoin_0.3.20.2 Linux32
ami-8abc4ee3 Bitcoin_0.3.20.2 Linux64

(mac build will be done soon)

If you have already downloaded version 0.3.20.1, please either add this to your bitcoin.conf file:

maxsendbuffer=10000
maxreceivebuffer=10000

... or download the new version.

===0.3.20.1===
(No known forum post.)

===0.3.20<ref>[https://bitcointalk.org/index.php?topic=2953.0 0.3.20 release announcement]</ref>===
Please checkout the git integration branch from:

https://github.com/bitcoin/bitcoin

... and help test. The new features that need testing are:

* -nolisten : https://github.com/bitcoin/bitcoin/pull/11
* -rescan : scan block chain for missing wallet transactions
* -printtoconsole : https://github.com/bitcoin/bitcoin/pull/37
* RPC gettransaction details : https://github.com/bitcoin/bitcoin/pull/24
* listtransactions new features : https://github.com/bitcoin/bitcoin/pull/10

Bug fixes that also need testing:

* -maxconnections= : https://github.com/bitcoin/bitcoin/pull/42
* RPC listaccounts minconf : https://github.com/bitcoin/bitcoin/pull/27
* RPC move, add time to output : https://github.com/bitcoin/bitcoin/pull/21
* ...and several improvements to --help output.

This needs more testing on Windows! Please drop me a quick private message, email, or IRC message if you are able to do some testing. If you find bugs, please open an issue at:

https://github.com/bitcoin/bitcoin/issues

===0.3.19<ref>[https://bitcointalk.org/index.php?topic=2228.0 0.3.19 release announcement]</ref>===
There's more work to do on DoS, but I'm doing a quick build of what I have so far in case it's needed, before venturing into more complex ideas. The build for this is version 0.3.19.

- Added some DoS controls
As Gavin and I have said clearly before, the software is not at all resistant to DoS attack. This is one improvement, but there are still more ways to attack than I can count.

I'm leaving the -limitfreerelay part as a switch for now and it's there if you need it.

- Removed "safe mode" alerts
"safe mode" alerts was a temporary measure after the 0.3.9 overflow bug. We can say all we want that users can just run with "-disablesafemode", but it's better just not to have it for the sake of appearances. It was never intended as a long term feature. Safe mode can still be triggered by seeing a longer (greater total PoW) invalid block chain.

===0.3.18<ref>[https://bitcointalk.org/index.php?topic=2162.0 0.3.18 release announcement]</ref>===

Changes:
* Fixed a wallet.dat compatibility problem if you downgraded from 0.3.17 and then upgraded again
* IsStandard() check to only include known transaction types in blocks
* Jgarzik's optimisation to speed up the initial block download a little

The main addition in this release is the Accounts-Based JSON-RPC commands that Gavin's been working on (more details at http://www.bitcoin.org/smf/index.php?topic=1886.0).
* getaccountaddress
* sendfrom
* move
* getbalance
* listtransactions

===0.3.17<ref>[https://bitcointalk.org/index.php?topic=1946.0 0.3.17 release announcement]</ref>===

Version 0.3.17 is now available.

Changes:
* new getwork, thanks m0mchil
* added transaction fee setting in UI options menu
* free transaction limits
* sendtoaddress returns transaction id instead of "sent"
* getaccountaddress <account>

The UI transaction fee setting was easy since it was still there from 0.1.5 and all I had to do was re-enable it.

The accounts-based commands: move, sendfrom and getbalance <account> will be in the next release. We still have some more changes to make first.

===0.3.16===

Never released.

===0.3.15<ref>[https://bitcointalk.org/index.php?topic=1780.0 0.3.15 release announcement]</ref>===

* paytxfee switch is now per KB, so it adds the correct fee for large transactions
* sending avoids using coins with less than 6 confirmations if it can
* BitcoinMiner processes transactions in priority order based on age of dependencies
* make sure generation doesn't start before block 74000 downloaded
* bugfixes by Dean Gores
* testnet, keypoololdest and paytxfee added to getinfo

===0.3.14<ref>[https://bitcointalk.org/index.php?topic=1528.0 0.3.14 release announcement]</ref>===

Version 0.3.14 is now available
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.14/

Changes:
* Key pool feature for safer wallet backup
Gavin Andresen:
* TEST network mode with switch -testnet
* Option to use SSL for JSON-RPC connections on unix/osx
* validateaddress RPC command
eurekafag:
* Russian translation

===0.3.13<ref>[https://bitcointalk.org/index.php?topic=1327.0 0.3.13 release announcement]</ref>===

Version 0.3.13 is now available. You should upgrade to prevent potential problems with 0/unconfirmed transactions. Note: 0.3.13 prevents problems if you haven't already spent a 0/unconfirmed transaction, but if that already happened, you need 0.3.13.2.

Changes:
* Don't count or spend payments until they have 1 confirmation.
* Internal version number from 312 to 31300.
* Only accept transactions sent by IP address if -allowreceivebyip is specified.
* Dropped DB_PRIVATE Berkeley DB flag.
* Fix problem sending the last cent with sub-cent fractional change.
* Auto-detect whether to use 128-bit 4-way SSE2 on Linux.
Gavin Andresen:
* Option -rpcallowip= to accept json-rpc connections from another machine.
* Clean shutdown on SIGTERM on Linux.

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.13/

(Thanks Laszlo for the Mac OSX build!)

Note:
The SSE2 auto-detect in the Linux 64-bit version doesn't work with AMD in 64-bit mode. Please try this instead and let me know if it gets it right:
http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gz

You can still control the SSE2 use manually with -4way and -4way=0.

Version 0.3.13.2 (SVN rev 161) has improvements for the case where you already had 0/unconfirmed transactions that you might have already spent. Here's a Windows build of it:
http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe

===0.3.12<ref>[https://bitcointalk.org/index.php?topic=999.0 0.3.12 release announcement]</ref>===

Version 0.3.12 is now available.

Features:
* json-rpc errors return a more standard error object. (thanks to Gavin Andresen)
* json-rpc command line returns exit codes.
* json-rpc "backupwallet" command.
* Recovers and continues if an exception is caused by a message you received. Other nodes shouldn't be able to cause an exception, and it hasn't happened before, but if a way is found to cause an exception, this would keep it from being used to stop network nodes.

If you have json-rpc code that checks the contents of the error string, you need to change it to expect error objects of the form {"code":<number>,"message":<string>}, which is the standard. See this thread:
http://www.bitcoin.org/smf/index.php?topic=969.0

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.12/

=References=
<references/>

Changelog

2012-06-12T23:02:32Z

BlueMatt: 0.6.X

Changelog

2012-06-12T22:50:31Z

BlueMatt: /* 0.5.00.5.0 release announcement */ Remove Boxes

{{stub}}

This page aggregates the changelogs that have been posted on the forum for the Bitcoin releases.
Note that some download links are not longer valid as highly insecure versions may have been deleted, or links may have changed.

=Changelogs=

==0.5.X==
After 0.5.1, all subsequent releases are stable maintenance releases, 0.6.0 is based on 0.5.1.

===0.5.5<ref>[https://bitcointalk.org/index.php?topic=79651 0.4.6/0.5.5 release announcement]</ref>===
bitcoind and Bitcoin-Qt version 0.5.5 are now available for download at:
Windows: installer | zip (sig)
Source: tar.gz
bitcoind and Bitcoin-Qt version 0.6.0.7 are also tagged in git, but it is recommended to upgrade to 0.6.1.

These are bugfix-only releases.

Please report bugs by replying to this forum thread. Note that the 0.4.x wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr.

BUG FIXES

Version 0.6.0 allowed importing invalid "private keys", which would be unspendable; 0.6.0.7 will now verify the private key is valid, and refuse to import an invalid one
Verify status of encrypt/decrypt calls to detect failed padding
Check blocks for duplicate transactions earlier. Fixes #1167
Upgrade Windows builds to OpenSSL 1.0.1b
Set label when selecting an address that already has a label. Fixes #1080 (Bitcoin-Qt)
JSON-RPC listtransactions's from/count handling is now fixed
Optimize and fix multithreaded access, when checking whether we already know about transactions
Fix potential networking deadlock
Proper support for Growl 1.3 notifications
Display an error, rather than crashing, if encoding a QR Code failed (0.6.0.7)
Don't erroneously set "Display addresses" for users who haven't explicitly enabled it (Bitcoin-Qt)
Some non-ASCII input in JSON-RPC expecting hexadecimal may have been misinterpreted rather than rejected
Missing error condition checking added
Do not show green tick unless all known blocks are downloaded. Fixes #921 (Bitcoin-Qt)
Increase time ago of last block for "up to date" status from 30 to 90 minutes
Show a message box when runaway exception happens (Bitcoin-Qt)
Use a messagebox to display the error when -server is provided without providing a rpc password
Show error message instead of exception crash when unable to bind RPC port (Bitcoin-Qt)
Correct sign message bitcoin address tooltip. Fixes #1050 (Bitcoin-Qt)
Removed "(no label)" from QR Code dialog titlebar if we have no label (0.6.0.7)
Removed an ugly line break in tooltip for mature transactions (0.6.0.7)
Add missing tooltip and key shortcut in settings dialog (part of #1088) (Bitcoin-Qt)
Work around issue in boost::program_options that prevents from compiling in clang
Fixed bugs occurring only on platforms with unsigned characters (such as ARM).
Rename make_windows_icon.py to .sh as it is a shell script. Fixes #1099 (Bitcoin-Qt)
Various trivial internal corrections to types used for counting/size loops and warnings

===0.5.4<ref>[https://bitcointalk.org/index.php?topic=76808.0 0.5.4 release announcement]</ref>===
Bitcoin version 0.5.4 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.4/
NOTE: 0.5.4rc3 is being renamed to 0.5.4 final with no changes.

This is a bugfix-only release in the 0.5.x series, plus a few protocol updates.

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.4#.tar.gz

PROTOCOL UPDATES

BIP 16: Special-case "pay to script hash" logic to enable minimal validation of new transactions.
Support for validating message signatures produced with compressed public keys.

BUG FIXES

Build with thread-safe MingW libraries for Windows, fixing a dangerous memory corruption scenario when exceptions are thrown.
Fix broken testnet mining.
Stop excess inventory relay during initial block download.
When disconnecting a node, clear the received buffer so that we do not process any already received messages.
Yet another attempt at implementing "minimize to tray" that works on all operating systems.
Fix Bitcoin-Qt notifications under Growl 1.3.
Increase required age of Bitcoin-Qt's "not up to date" status from 30 to 90 minutes.
Implemented missing verifications that led to crash on entering some wrong passphrases for encrypted wallets.
Fix default filename suffixes in GNOME save dialog.
Make the "Send coins" tab use the configured unit type, even on the first attempt.
Print detailed wallet loading errors to debug.log when it is corrupt.
Allocate exactly the amount of space needed for signing transactions, instead of a fixed 10k buffer.
Workaround for improbable memory access violation.
Check wallet's minimum version before trying to load it.
Remove wxBitcoin properly when installing Bitcoin-Qt over it. (Windows)
Detail reorganization information better in debug log.
Use a messagebox to display the error when -server is provided without configuring a RPC password.
Testing suite build now honours provided CXXFLAGS.
Removed an extraneous line-break in mature transaction tooltips.
Fix some grammatical errors in translation process documentation.

===0.5.3<ref>[https://bitcointalk.org/index.php?topic=68895.0 0.5.3 release announcement]</ref>===
Bitcoin version 0.5.3 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.3/

This is a bugfix-only release based on 0.5.1.
It also includes a few protocol updates.

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.3#.tar.gz

PROTOCOL UPDATES

BIP 30: Introduce a new network rule: "a block is not valid if it contains a transaction whose hash already exists in the block chain, unless all that transaction's outputs were already spent before said block" beginning on March 15, 2012, 00:00 UTC.
On testnet, allow mining of min-difficulty blocks if 20 minutes have gone by without mining a regular-difficulty block. This is to make testing Bitcoin easier, and will not affect normal mode.

BUG FIXES

Limit the number of orphan transactions stored in memory, to prevent a potential denial-of-service attack by flooding orphan transactions. Also never store invalid transactions at all.
Fix possible buffer overflow on systems with very long application data paths. This is not exploitable.
Resolved multiple bugs preventing long-term unlocking of encrypted wallets
(issue #922).
Only send local IP in "version" messages if it is globally routable (ie, not private), and try to get such an IP from UPnP if applicable.
Reannounce UPnP port forwards every 20 minutes, to workaround routers expiring old entries, and allow the -upnp option to override any stored setting.
Skip splash screen when -min is used, and fix Minimize to Tray function.
Do not blank "label" in Bitcoin-Qt "Send" tab, if the user has already entered something.
Correct various labels and messages.
Various memory leaks and potential null pointer deferences have been fixed.
Handle invalid Bitcoin URIs using "bitcoin://" instead of "bitcoin:".
Several shutdown issues have been fixed.
Revert to "global progress indication", as starting from zero every time was considered too confusing for many users.
Check that keys stored in the wallet are valid at startup, and if not, report corruption.
Enable accessible widgets on Windows, so that people with screen readers such as NVDA can make sense of it.
Various build fixes.
If no password is specified to bitcoind, recommend a secure password.
Automatically focus and scroll to new "Send coins" entries in Bitcoin-Qt.
Show a message box for --help on Windows, for Bitcoin-Qt.
Add missing "About Qt" menu option to show built-in Qt About dialog.
Don't show "-daemon" as an option for Bitcoin-Qt, since it isn't available.
Update hard-coded fallback seed nodes, choosing recent ones with long uptime and versions at least 0.4.0.
Add checkpoint at block 168,000.

===0.5.2<ref>[https://bitcointalk.org/index.php?topic=60146.0 0.5.2 release announcement]</ref>===
Bitcoin version 0.5.2 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.2/

This is a bugfix-only release based on 0.5.1.

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.2#.tar.gz

BUG FIXES

Check all transactions in blocks after the last checkpoint (0.5.0 and 0.5.1 skipped checking ECDSA signatures during initial blockchain download).
Cease locking memory used by non-sensitive information (this caused a huge performance hit on some platforms, especially noticable during initial blockchain download; this was
not a security vulnerability).
Fixed some address-handling deadlocks (client freezes).
No longer accept inbound connections over the internet when Bitcoin is being used with Tor (identity leak).
Re-enable SSL support for the JSON-RPC interface (it was unintentionally disabled for the 0.5.0 and 0.5.1 release Linux binaries).
Use the correct base transaction fee of 0.0005 BTC for accepting transactions into mined blocks (since 0.4.0, it was incorrectly accepting 0.0001 BTC which was only meant to be relayed).
Don't show "IP" for transactions which are not necessarily IP transactions.
Add new DNS seeds (maintained by Pieter Wuille and Luke Dashjr).

===0.5.1<ref>[https://bitcointalk.org/index.php?topic=54717.0 0.5.1 release announcement]</ref>===
Bitcoin version 0.5.1 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.1/

This is a bugfix-only release.

This release includes 13 translations, including 5 new translations:
Italian, Hungarian, Ukranian, Portuguese (Brazilian) and Simplified Chinese.
More translations are welcome; join the project at Transifex if you can help:
https://www.transifex.net/projects/p/bitcoin/

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Project source code is hosted at github; we are no longer
distributing .tar.gz files here, you can get them
directly from github:
https://github.com/bitcoin/bitcoin/tarball/v0.5.1 # .tar.gz
https://github.com/bitcoin/bitcoin/zipball/v0.5.1 # .zip

For Ubuntu users, there is a new ppa maintained by Matt Corallo which
you can add to your system so that it will automatically keep
bitcoin up-to-date. Just type
sudo apt-add-repository ppa:bitcoin/bitcoin
in your terminal, then install the bitcoin-qt package.

BUG FIXES

Re-enable SSL support for the JSON-RPC interface (it was unintentionally
disabled for the 0.5.0 release binaries).

The code that finds peers via "dns seeds" no longer stops bitcoin startup
if one of the dns seed machines is down.

Tooltips on the transaction list view were rendering incorrectly (as black boxes
or with a transparent background).

Prevent a denial-of-service attack involving flooding a bitcoin node with
orphan blocks.

The wallet passphrase dialog now warns you if the caps lock key was pressed.

Improved searching in addresses and labels in bitcoin-qt.

===0.5.0<ref>[https://bitcointalk.org/index.php?topic=52480.0 0.5.0 release announcement]</ref>===
Bitcoin version 0.5.0 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.0/

The major change for this release is a completely new graphical interface that uses the Qt user interface toolkit.

This release include German, Spanish, Spanish-Castilian, Norwegian and Dutch translations. More translations are welcome; join the project at Transifex if you can help:
https://www.transifex.net/projects/p/bitcoin/

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

For Ubuntu users, there is a new ppa maintained by Matt Corallo which you can add to your system so that it will automatically keep bitcoin up-to-date. Just type "sudo apt-add-repository ppa:bitcoin/bitcoin" in your terminal, then install the bitcoin-qt package.

MAJOR BUG FIX (CVE-2011-4447)

The wallet encryption feature introduced in Bitcoin version 0.4.0 did not sufficiently secure the private keys. An attacker who
managed to get a copy of your encrypted wallet.dat file might be able to recover some or all of the unencrypted keys and steal the
associated coins.

If you have a previously encrypted wallet.dat, the first time you run bitcoin-qt or bitcoind the wallet will be rewritten, Bitcoin will
shut down, and you will be prompted to restart it to run with the new, properly encrypted file.

If you had a previously encrypted wallet.dat that might have been copied or stolen (for example, you backed it up to a public
location) you should send all of your bitcoins to yourself using a new bitcoin address and stop using any previously generated addresses.

Wallets encrypted with this version of Bitcoin are written properly.

Technical note: the encrypted wallet's 'keypool' will be regenerated the first time you request a new bitcoin address; to be certain that the
new private keys are properly backed up you should:

1. Run Bitcoin and let it rewrite the wallet.dat file

2. Run it again, then ask it for a new bitcoin address.
Bitcoin-Qt: Address Book, then New Address...
bitcoind: run the 'walletpassphrase' RPC command to unlock the wallet, then run the 'getnewaddress' RPC command.

3. If your encrypted wallet.dat may have been copied or stolen, send all of your bitcoins to the new bitcoin address.

4. Shut down Bitcoin, then backup the wallet.dat file.
IMPORTANT: be sure to request a new bitcoin address before backing up, so that the 'keypool' is regenerated and backed up.

"Security in depth" is always a good idea, so choosing a secure location for the backup and/or encrypting the backup before uploading it is recommended. And as in previous releases, if your machine is infected by malware there are several ways an attacker might steal your bitcoins.

Thanks to Alan Reiner (etotheipi) for finding and reporting this bug.

MAJOR GUI CHANGES

"Splash" graphics at startup that show address/wallet/blockchain loading progress.

"Synchronizing with network" progress bar to show block-chain download progress.

Icons at the bottom of the window that show how well connected you are to the network, with tooltips to display details.

Drag and drop support for bitcoin: URIs on web pages.

Export transactions as a .csv file.

Many other GUI improvements, large and small.

RPC CHANGES

getmemorypool : new RPC command, provides everything needed to construct a block with a custom generation transaction and submit a solution

listsinceblock : new RPC command, list transactions since given block

signmessage/verifymessage : new RPC commands to sign a message with one of your private keys or verify that a message signed by the private key associated with a bitcoin address.

GENERAL CHANGES

Faster initial block download.

==0.4.X==
After 0.4.0, all subsequent releases are stable maintenance releases, 0.5.0 is based on 0.4.0.

===0.4.6<ref>[https://bitcointalk.org/index.php?topic=79651 0.4.6/0.5.5 release announcement]</ref>===
bitcoind version 0.4.6 is now available for download at:
Windows: installer | zip (sig)
Source: tar.gz
bitcoind and Bitcoin-Qt version 0.6.0.7 are also tagged in git, but it is recommended to upgrade to 0.6.1.

These are bugfix-only releases.

Please report bugs by replying to this forum thread. Note that the 0.4.x wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr.

BUG FIXES

Version 0.6.0 allowed importing invalid "private keys", which would be unspendable; 0.6.0.7 will now verify the private key is valid, and refuse to import an invalid one
Verify status of encrypt/decrypt calls to detect failed padding
Check blocks for duplicate transactions earlier. Fixes #1167
Upgrade Windows builds to OpenSSL 1.0.1b
Set label when selecting an address that already has a label. Fixes #1080 (Bitcoin-Qt)
JSON-RPC listtransactions's from/count handling is now fixed
Optimize and fix multithreaded access, when checking whether we already know about transactions
Fix potential networking deadlock
Proper support for Growl 1.3 notifications
Display an error, rather than crashing, if encoding a QR Code failed (0.6.0.7)
Don't erroneously set "Display addresses" for users who haven't explicitly enabled it (Bitcoin-Qt)
Some non-ASCII input in JSON-RPC expecting hexadecimal may have been misinterpreted rather than rejected
Missing error condition checking added
Do not show green tick unless all known blocks are downloaded. Fixes #921 (Bitcoin-Qt)
Increase time ago of last block for "up to date" status from 30 to 90 minutes
Show a message box when runaway exception happens (Bitcoin-Qt)
Use a messagebox to display the error when -server is provided without providing a rpc password
Show error message instead of exception crash when unable to bind RPC port (Bitcoin-Qt)
Correct sign message bitcoin address tooltip. Fixes #1050 (Bitcoin-Qt)
Removed "(no label)" from QR Code dialog titlebar if we have no label (0.6.0.7)
Removed an ugly line break in tooltip for mature transactions (0.6.0.7)
Add missing tooltip and key shortcut in settings dialog (part of #1088) (Bitcoin-Qt)
Work around issue in boost::program_options that prevents from compiling in clang
Fixed bugs occurring only on platforms with unsigned characters (such as ARM).
Rename make_windows_icon.py to .sh as it is a shell script. Fixes #1099 (Bitcoin-Qt)
Various trivial internal corrections to types used for counting/size loops and warnings

===0.4.5===
(No known forum post.)

===0.4.4<ref>[https://bitcointalk.org/index.php?topic=70566.0 0.4.4 release announcement]</ref>===
Bitcoin version 0.4.4 is now available for download at:
http://luke.dashjr.org/programs/bitcoin/files/bitcoind-0.4.4/

This is a bugfix-only release based on 0.4.0.

Please note that the wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr.

Please report bugs for the daemon only using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.4.4#.tar.gz

BUG FIXES

Limit the number of orphan transactions stored in memory, to prevent a potential denial-of-service attack by flooding orphan transactions. Also never store invalid transactions at all.
Fix possible buffer overflow on systems with very long application data paths. This is not exploitable.
Resolved multiple bugs preventing long-term unlocking of encrypted wallets (issue #922).
Only send local IP in "version" messages if it is globally routable (ie, not private), and try to get such an IP from UPnP if applicable.
Reannounce UPnP port forwards every 20 minutes, to workaround routers expiring old entries, and allow the -upnp option to override any stored setting.
Various memory leaks and potential null pointer deferences have been
fixed.
Several shutdown issues have been fixed.
Check that keys stored in the wallet are valid at startup, and if not,
report corruption.
Various build fixes.
If no password is specified to bitcoind, recommend a secure password.
Update hard-coded fallback seed nodes, choosing recent ones with long uptime and versions at least 0.4.0.
Add checkpoint at block 168,000.

===0.4.3<ref>[https://bitcointalk.org/index.php?topic=57734.0 0.4.3 release announcement]</ref>===
bitcoind version 0.4.3 is now available for download at:
http://luke.dashjr.org/programs/bitcoin/files/bitcoind-0.4.3/ (until Gavin uploads to SourceForge)

This is a bugfix-only release based on 0.4.0.

Please note that the wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr.

Please report bugs for the daemon only using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.4.3#.tar.gz

BUG FIXES

Cease locking memory used by non-sensitive information (this caused a huge performance hit on some platforms, especially noticable during initial blockchain download).
Fixed some address-handling deadlocks (client freezes).
No longer accept inbound connections over the internet when Bitcoin is being used with Tor (identity leak).
Use the correct base transaction fee of 0.0005 BTC for accepting transactions into mined blocks (since 0.4.0, it was incorrectly accepting 0.0001 BTC which was only meant to be relayed).
Add new DNS seeds (maintained by Pieter Wuille and Luke Dashjr).

===0.4.2===
(No known forum post.)

===0.4.1<ref>[https://bitcointalk.org/index.php?topic=52503.0 0.4.1 release announcement]</ref>===
Bitcoin version 0.4.1 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.4.1/

This is a bugfix only release based on 0.4.0.

Please report bugs by replying to this forum thread.

MAJOR BUG FIX (CVE-2011-4447)

The wallet encryption feature introduced in Bitcoin version 0.4.0 did not sufficiently secure the private keys. An attacker who
managed to get a copy of your encrypted wallet.dat file might be able to recover some or all of the unencrypted keys and steal the
associated coins.

If you have a previously encrypted wallet.dat, the first time you run wxbitcoin or bitcoind the wallet will be rewritten, Bitcoin will
shut down, and you will be prompted to restart it to run with the new, properly encrypted file.

If you had a previously encrypted wallet.dat that might have been copied or stolen (for example, you backed it up to a public
location) you should send all of your bitcoins to yourself using a new bitcoin address and stop using any previously generated addresses.

Wallets encrypted with this version of Bitcoin are written properly.

Technical note: the encrypted wallet's 'keypool' will be regenerated the first time you request a new bitcoin address; to be certain that the
new private keys are properly backed up you should:

1. Run Bitcoin and let it rewrite the wallet.dat file

2. Run it again, then ask it for a new bitcoin address.
wxBitcoin: new address visible on main window
bitcoind: run the 'walletpassphrase' RPC command to unlock the wallet, then run the 'getnewaddress' RPC command.

3. If your encrypted wallet.dat may have been copied or stolen, send all of your bitcoins to the new bitcoin address.

4. Shut down Bitcoin, then backup the wallet.dat file.
IMPORTANT: be sure to request a new bitcoin address before backing up, so that the 'keypool' is regenerated and backed up.

"Security in depth" is always a good idea, so choosing a secure location for the backup and/or encrypting the backup before uploading it is recommended. And as in previous releases, if your machine is infected by malware there are several ways an attacker might steal your bitcoins.

Thanks to Alan Reiner (etotheipi) for finding and reporting this bug.

===0.4.0<ref>[https://bitcointalk.org/index.php?topic=45410.0 0.4 release announcement]</ref>===
Bitcoin version 0.4.0 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.4.0/

The main feature in this release is wallet private key encryption;
you can set a passphrase that must be entered before sending coins.
See below for more information; if you decide to encrypt your wallet,
WRITE DOWN YOUR PASSPHRASE AND PUT IT IN A SECURE LOCATION. If you
forget or lose your wallet passphrase, you lose your bitcoins.
Previous versions of bitcoin are unable to read encrypted wallets,
and will crash on startup if the wallet is encrypted.

Also note: bitcoin version 0.4 uses a newer version of Berkeley DB
(bdb version 4.8) than previous versions (bdb 4.7). If you upgrade
to version 0.4 and then revert back to an earlier version of bitcoin
the it may be unable to start because bdb 4.7 cannot read bdb 4.8
"log" files.

Notable bug fixes from version 0.3.24:

Fix several bitcoin-becomes-unresponsive bugs due to multithreading
deadlocks.

Optimize database writes for large (lots of inputs) transactions
(fixes a potential denial-of-service attack)

Wallet Encryption

Bitcoin supports native wallet encryption so that people who steal your
wallet file don't automatically get access to all of your Bitcoins.
In order to enable this feature, choose "Encrypt Wallet" from the
Options menu. You will be prompted to enter a passphrase, which
will be used as the key to encrypt your wallet and will be needed
every time you wish to send Bitcoins. If you lose this passphrase,
you will lose access to spend all of the bitcoins in your wallet,
no one, not even the Bitcoin developers can recover your Bitcoins.
This means you are responsible for your own security, store your
passphrase in a secure location and do not forget it.

Remember that the encryption built into bitcoin only encrypts the
actual keys which are required to send your bitcoins, not the full
wallet. This means that someone who steals your wallet file will
be able to see all the addresses which belong to you, as well as the
relevant transactions, you are only protected from someone spending
your coins.

It is recommended that you backup your wallet file before you
encrypt your wallet. To do this, close the Bitcoin client and
copy the wallet.dat file from ~/.bitcoin/ on Linux, /Users/(user
name)/Application Support/Bitcoin/ on Mac OSX, and %APPDATA%/Bitcoin/
on Windows (that is /Users/(user name)/AppData/Roaming/Bitcoin on
Windows Vista and 7 and /Documents and Settings/(user name)/Application
Data/Bitcoin on Windows XP). Once you have copied that file to a
safe location, reopen the Bitcoin client and Encrypt your wallet.
If everything goes fine, delete the backup and enjoy your encrypted
wallet. Note that once you encrypt your wallet, you will never be
able to go back to a version of the Bitcoin client older than 0.4.

Keep in mind that you are always responsible for your own security.
All it takes is a slightly more advanced wallet-stealing trojan which
installs a keylogger to steal your wallet passphrase as you enter it
in addition to your wallet file and you have lost all your Bitcoins.
Wallet encryption cannot keep you safe if you do not practice
good security, such as running up-to-date antivirus software, only
entering your wallet passphrase in the Bitcoin client and using the
same passphrase only as your wallet passphrase.

See the doc/README file in the bitcoin source for technical details
of wallet encryption.

==0.3.X==

===0.3.24<ref>[https://bitcointalk.org/index.php?topic=27187.0 0.3.24 release announcement]</ref>===
Bitcoin v0.3.24 is now available for download at
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.24/

This is another bug fix release. We had hoped to have wallet encryption ready for release, but more urgent fixes for existing clients were needed -- most notably block download problems were getting severe. Wallet encryption is ready for testing at https://github.com/bitcoin/bitcoin/pull/352 for the git-savvy, and hopefully will follow shortly in the next release, v0.4.

Notable fixes in v0.3.24, and the main reasons for this release:

F1) Block downloads were failing or taking unreasonable amounts of time to complete, because the increased size of the block chain was bumping up against some earlier buffer-size DoS limits.

F2) Fix crash caused by loss/lack of network connection.

Notable changes in v0.3.24:

C1) DNS seeding enabled by default.

C2) UPNP enabled by default in the GUI client. The percentage of bitcoin clients that accept incoming connections is quite small, and that is a problem. This should help. bitcoind, and unofficial builds, are unchanged (though we encourage use of "-upnp" to help the network!)

C3) Initial unit testing framework. Bitcoin sorely needs automated tests, and this is a beginning. Contributions welcome.

C4) Internal wallet code cleanup. While invisible to an end user, this change provides the basis for v0.4's wallet encryption.

===0.3.23<ref>[https://bitcointalk.org/index.php?topic=16553.0 0.3.23 release announcement]</ref>===
Win32, Linux, MacOSX and source releases for bitcoin v0.3.23 have been uploaded to
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.23/

This is another quick bugfix release, trying to deal with the influx of new bitcoin users.

Main items of note:

* P2P connect-to-node logic changed to reduce timeout a bit. The network saw a huge influx of new users, who do not permit incoming connections. This change is a short-term hack, to more quickly hunt for useful P2P connections. Better "leaf node" logic is in the works, but this should let us limp along until then. One may use -upnp to properly forward ports, and help the network.
* Transaction fee reduced to 0.0005 for new transactions
* Client will relay transactions with fees as low as 0.0001 BTC

===0.3.22<ref>[https://bitcointalk.org/index.php?topic=12269.0 0.3.22 release announcement]</ref>===
Download URL: https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.22/

This is largely a bugfix and TX fee schedule release. We also hope to make 0.3.23 a quick release, to fix problems that the network has seen due to explosive growth in the past week.

Notable changes:
* Client will accept and relay TX's with 0.0005 BTC fee schedule (users still pay 0.01 BTC per kb, until next version)
* Non-standard transactions accepted on testnet
* Source code tree reorganized (prep for autotools build)
* Remove "Generate Coins" option from GUI, and remove 4way SSE miner. Internal reference CPU miner remains available, but users are directed to external miners for best hash production.
* IRC is overflowing. Client now bootstraps to channels #bitcoin00 - #bitcoin99
* DNS names now may be used with -addnode, -connect (requires -dns to enable)

RPC changes:
* 'listtransactions' adds 'from' param, for range queries
* 'move' may take account balances negative
* 'settxfee' added, to manually set TX fee

===0.3.21<ref>[https://bitcointalk.org/index.php?topic=6642.0 0.3.21 release announcement]</ref>===
Binaries for Bitcoin version 0.3.21 are available at:
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.21/

Changes and new features from the 0.3.20 release include:

* Universal Plug and Play support. Enable automatic opening of a port for incoming connections by running bitcoin or bitcoind with the - -upnp=1 command line switch or using the Options dialog box.

* Support for full-precision bitcoin amounts. You can now send, and bitcoin will display, bitcoin amounts smaller than 0.01. However, sending fewer than 0.01 bitcoins still requires a 0.01 bitcoin fee (so you can send 1.0001 bitcoins without a fee, but you will be asked to pay a fee if you try to send 0.0001).

* A new method of finding bitcoin nodes to connect with, via DNS A records. Use the -dnsseed option to enable.

For developers, changes to bitcoin's remote-procedure-call API:

* New rpc command "sendmany" to send bitcoins to more than one address in a single transaction.

* Several bug fixes, including a serious intermittent bug that would sometimes cause bitcoind to stop accepting rpc requests.

* -logtimestamps option, to add a timestamp to each line in debug.log.

* Immature blocks (newly generated, under 120 confirmations) are now shown in listtransactions.

===0.3.20.2<ref>[https://bitcointalk.org/index.php?topic=4167.0 0.3.20.2 release announcement]</ref>===
The maxsendbuffer bug (0.3.20.1 clients not being able to download the block chain from other 0.3.20.1 clients) was only going to get
worse as people upgraded, so I cherry-picked the bug fix and created a minor release yesterday.

The Amazon Machine Images I used to do the builds are available:

ami-38a05251 Bitcoin-v0.3.20.2 Mingw (Windows; Administrator password 'bitcoin development')
ami-30a05259 Bitcoin_0.3.20.2 Linux32
ami-8abc4ee3 Bitcoin_0.3.20.2 Linux64

(mac build will be done soon)

If you have already downloaded version 0.3.20.1, please either add this to your bitcoin.conf file:

maxsendbuffer=10000
maxreceivebuffer=10000

... or download the new version.

===0.3.20.1===
(No known forum post.)

===0.3.20<ref>[https://bitcointalk.org/index.php?topic=2953.0 0.3.20 release announcement]</ref>===
Please checkout the git integration branch from:

https://github.com/bitcoin/bitcoin

... and help test. The new features that need testing are:

* -nolisten : https://github.com/bitcoin/bitcoin/pull/11
* -rescan : scan block chain for missing wallet transactions
* -printtoconsole : https://github.com/bitcoin/bitcoin/pull/37
* RPC gettransaction details : https://github.com/bitcoin/bitcoin/pull/24
* listtransactions new features : https://github.com/bitcoin/bitcoin/pull/10

Bug fixes that also need testing:

* -maxconnections= : https://github.com/bitcoin/bitcoin/pull/42
* RPC listaccounts minconf : https://github.com/bitcoin/bitcoin/pull/27
* RPC move, add time to output : https://github.com/bitcoin/bitcoin/pull/21
* ...and several improvements to --help output.

This needs more testing on Windows! Please drop me a quick private message, email, or IRC message if you are able to do some testing. If you find bugs, please open an issue at:

https://github.com/bitcoin/bitcoin/issues

===0.3.19<ref>[https://bitcointalk.org/index.php?topic=2228.0 0.3.19 release announcement]</ref>===
There's more work to do on DoS, but I'm doing a quick build of what I have so far in case it's needed, before venturing into more complex ideas. The build for this is version 0.3.19.

- Added some DoS controls
As Gavin and I have said clearly before, the software is not at all resistant to DoS attack. This is one improvement, but there are still more ways to attack than I can count.

I'm leaving the -limitfreerelay part as a switch for now and it's there if you need it.

- Removed "safe mode" alerts
"safe mode" alerts was a temporary measure after the 0.3.9 overflow bug. We can say all we want that users can just run with "-disablesafemode", but it's better just not to have it for the sake of appearances. It was never intended as a long term feature. Safe mode can still be triggered by seeing a longer (greater total PoW) invalid block chain.

===0.3.18<ref>[https://bitcointalk.org/index.php?topic=2162.0 0.3.18 release announcement]</ref>===

Changes:
* Fixed a wallet.dat compatibility problem if you downgraded from 0.3.17 and then upgraded again
* IsStandard() check to only include known transaction types in blocks
* Jgarzik's optimisation to speed up the initial block download a little

The main addition in this release is the Accounts-Based JSON-RPC commands that Gavin's been working on (more details at http://www.bitcoin.org/smf/index.php?topic=1886.0).
* getaccountaddress
* sendfrom
* move
* getbalance
* listtransactions

===0.3.17<ref>[https://bitcointalk.org/index.php?topic=1946.0 0.3.17 release announcement]</ref>===

Version 0.3.17 is now available.

Changes:
* new getwork, thanks m0mchil
* added transaction fee setting in UI options menu
* free transaction limits
* sendtoaddress returns transaction id instead of "sent"
* getaccountaddress <account>

The UI transaction fee setting was easy since it was still there from 0.1.5 and all I had to do was re-enable it.

The accounts-based commands: move, sendfrom and getbalance <account> will be in the next release. We still have some more changes to make first.

===0.3.16===

Never released.

===0.3.15<ref>[https://bitcointalk.org/index.php?topic=1780.0 0.3.15 release announcement]</ref>===

* paytxfee switch is now per KB, so it adds the correct fee for large transactions
* sending avoids using coins with less than 6 confirmations if it can
* BitcoinMiner processes transactions in priority order based on age of dependencies
* make sure generation doesn't start before block 74000 downloaded
* bugfixes by Dean Gores
* testnet, keypoololdest and paytxfee added to getinfo

===0.3.14<ref>[https://bitcointalk.org/index.php?topic=1528.0 0.3.14 release announcement]</ref>===

Version 0.3.14 is now available
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.14/

Changes:
* Key pool feature for safer wallet backup
Gavin Andresen:
* TEST network mode with switch -testnet
* Option to use SSL for JSON-RPC connections on unix/osx
* validateaddress RPC command
eurekafag:
* Russian translation

===0.3.13<ref>[https://bitcointalk.org/index.php?topic=1327.0 0.3.13 release announcement]</ref>===

Version 0.3.13 is now available. You should upgrade to prevent potential problems with 0/unconfirmed transactions. Note: 0.3.13 prevents problems if you haven't already spent a 0/unconfirmed transaction, but if that already happened, you need 0.3.13.2.

Changes:
* Don't count or spend payments until they have 1 confirmation.
* Internal version number from 312 to 31300.
* Only accept transactions sent by IP address if -allowreceivebyip is specified.
* Dropped DB_PRIVATE Berkeley DB flag.
* Fix problem sending the last cent with sub-cent fractional change.
* Auto-detect whether to use 128-bit 4-way SSE2 on Linux.
Gavin Andresen:
* Option -rpcallowip= to accept json-rpc connections from another machine.
* Clean shutdown on SIGTERM on Linux.

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.13/

(Thanks Laszlo for the Mac OSX build!)

Note:
The SSE2 auto-detect in the Linux 64-bit version doesn't work with AMD in 64-bit mode. Please try this instead and let me know if it gets it right:
http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gz

You can still control the SSE2 use manually with -4way and -4way=0.

Version 0.3.13.2 (SVN rev 161) has improvements for the case where you already had 0/unconfirmed transactions that you might have already spent. Here's a Windows build of it:
http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe

===0.3.12<ref>[https://bitcointalk.org/index.php?topic=999.0 0.3.12 release announcement]</ref>===

Version 0.3.12 is now available.

Features:
* json-rpc errors return a more standard error object. (thanks to Gavin Andresen)
* json-rpc command line returns exit codes.
* json-rpc "backupwallet" command.
* Recovers and continues if an exception is caused by a message you received. Other nodes shouldn't be able to cause an exception, and it hasn't happened before, but if a way is found to cause an exception, this would keep it from being used to stop network nodes.

If you have json-rpc code that checks the contents of the error string, you need to change it to expect error objects of the form {"code":<number>,"message":<string>}, which is the standard. See this thread:
http://www.bitcoin.org/smf/index.php?topic=969.0

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.12/

=References=
<references/>

Changelog

2012-06-12T22:50:14Z

BlueMatt: /* Changelogs */ Remove Boxes

{{stub}}

This page aggregates the changelogs that have been posted on the forum for the Bitcoin releases.
Note that some download links are not longer valid as highly insecure versions may have been deleted, or links may have changed.

=Changelogs=

==0.5.X==
After 0.5.1, all subsequent releases are stable maintenance releases, 0.6.0 is based on 0.5.1.

===0.5.5<ref>[https://bitcointalk.org/index.php?topic=79651 0.4.6/0.5.5 release announcement]</ref>===
bitcoind and Bitcoin-Qt version 0.5.5 are now available for download at:
Windows: installer | zip (sig)
Source: tar.gz
bitcoind and Bitcoin-Qt version 0.6.0.7 are also tagged in git, but it is recommended to upgrade to 0.6.1.

These are bugfix-only releases.

Please report bugs by replying to this forum thread. Note that the 0.4.x wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr.

BUG FIXES

Version 0.6.0 allowed importing invalid "private keys", which would be unspendable; 0.6.0.7 will now verify the private key is valid, and refuse to import an invalid one
Verify status of encrypt/decrypt calls to detect failed padding
Check blocks for duplicate transactions earlier. Fixes #1167
Upgrade Windows builds to OpenSSL 1.0.1b
Set label when selecting an address that already has a label. Fixes #1080 (Bitcoin-Qt)
JSON-RPC listtransactions's from/count handling is now fixed
Optimize and fix multithreaded access, when checking whether we already know about transactions
Fix potential networking deadlock
Proper support for Growl 1.3 notifications
Display an error, rather than crashing, if encoding a QR Code failed (0.6.0.7)
Don't erroneously set "Display addresses" for users who haven't explicitly enabled it (Bitcoin-Qt)
Some non-ASCII input in JSON-RPC expecting hexadecimal may have been misinterpreted rather than rejected
Missing error condition checking added
Do not show green tick unless all known blocks are downloaded. Fixes #921 (Bitcoin-Qt)
Increase time ago of last block for "up to date" status from 30 to 90 minutes
Show a message box when runaway exception happens (Bitcoin-Qt)
Use a messagebox to display the error when -server is provided without providing a rpc password
Show error message instead of exception crash when unable to bind RPC port (Bitcoin-Qt)
Correct sign message bitcoin address tooltip. Fixes #1050 (Bitcoin-Qt)
Removed "(no label)" from QR Code dialog titlebar if we have no label (0.6.0.7)
Removed an ugly line break in tooltip for mature transactions (0.6.0.7)
Add missing tooltip and key shortcut in settings dialog (part of #1088) (Bitcoin-Qt)
Work around issue in boost::program_options that prevents from compiling in clang
Fixed bugs occurring only on platforms with unsigned characters (such as ARM).
Rename make_windows_icon.py to .sh as it is a shell script. Fixes #1099 (Bitcoin-Qt)
Various trivial internal corrections to types used for counting/size loops and warnings

===0.5.4<ref>[https://bitcointalk.org/index.php?topic=76808.0 0.5.4 release announcement]</ref>===
Bitcoin version 0.5.4 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.4/
NOTE: 0.5.4rc3 is being renamed to 0.5.4 final with no changes.

This is a bugfix-only release in the 0.5.x series, plus a few protocol updates.

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.4#.tar.gz

PROTOCOL UPDATES

BIP 16: Special-case "pay to script hash" logic to enable minimal validation of new transactions.
Support for validating message signatures produced with compressed public keys.

BUG FIXES

Build with thread-safe MingW libraries for Windows, fixing a dangerous memory corruption scenario when exceptions are thrown.
Fix broken testnet mining.
Stop excess inventory relay during initial block download.
When disconnecting a node, clear the received buffer so that we do not process any already received messages.
Yet another attempt at implementing "minimize to tray" that works on all operating systems.
Fix Bitcoin-Qt notifications under Growl 1.3.
Increase required age of Bitcoin-Qt's "not up to date" status from 30 to 90 minutes.
Implemented missing verifications that led to crash on entering some wrong passphrases for encrypted wallets.
Fix default filename suffixes in GNOME save dialog.
Make the "Send coins" tab use the configured unit type, even on the first attempt.
Print detailed wallet loading errors to debug.log when it is corrupt.
Allocate exactly the amount of space needed for signing transactions, instead of a fixed 10k buffer.
Workaround for improbable memory access violation.
Check wallet's minimum version before trying to load it.
Remove wxBitcoin properly when installing Bitcoin-Qt over it. (Windows)
Detail reorganization information better in debug log.
Use a messagebox to display the error when -server is provided without configuring a RPC password.
Testing suite build now honours provided CXXFLAGS.
Removed an extraneous line-break in mature transaction tooltips.
Fix some grammatical errors in translation process documentation.

===0.5.3<ref>[https://bitcointalk.org/index.php?topic=68895.0 0.5.3 release announcement]</ref>===
Bitcoin version 0.5.3 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.3/

This is a bugfix-only release based on 0.5.1.
It also includes a few protocol updates.

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.3#.tar.gz

PROTOCOL UPDATES

BIP 30: Introduce a new network rule: "a block is not valid if it contains a transaction whose hash already exists in the block chain, unless all that transaction's outputs were already spent before said block" beginning on March 15, 2012, 00:00 UTC.
On testnet, allow mining of min-difficulty blocks if 20 minutes have gone by without mining a regular-difficulty block. This is to make testing Bitcoin easier, and will not affect normal mode.

BUG FIXES

Limit the number of orphan transactions stored in memory, to prevent a potential denial-of-service attack by flooding orphan transactions. Also never store invalid transactions at all.
Fix possible buffer overflow on systems with very long application data paths. This is not exploitable.
Resolved multiple bugs preventing long-term unlocking of encrypted wallets
(issue #922).
Only send local IP in "version" messages if it is globally routable (ie, not private), and try to get such an IP from UPnP if applicable.
Reannounce UPnP port forwards every 20 minutes, to workaround routers expiring old entries, and allow the -upnp option to override any stored setting.
Skip splash screen when -min is used, and fix Minimize to Tray function.
Do not blank "label" in Bitcoin-Qt "Send" tab, if the user has already entered something.
Correct various labels and messages.
Various memory leaks and potential null pointer deferences have been fixed.
Handle invalid Bitcoin URIs using "bitcoin://" instead of "bitcoin:".
Several shutdown issues have been fixed.
Revert to "global progress indication", as starting from zero every time was considered too confusing for many users.
Check that keys stored in the wallet are valid at startup, and if not, report corruption.
Enable accessible widgets on Windows, so that people with screen readers such as NVDA can make sense of it.
Various build fixes.
If no password is specified to bitcoind, recommend a secure password.
Automatically focus and scroll to new "Send coins" entries in Bitcoin-Qt.
Show a message box for --help on Windows, for Bitcoin-Qt.
Add missing "About Qt" menu option to show built-in Qt About dialog.
Don't show "-daemon" as an option for Bitcoin-Qt, since it isn't available.
Update hard-coded fallback seed nodes, choosing recent ones with long uptime and versions at least 0.4.0.
Add checkpoint at block 168,000.

===0.5.2<ref>[https://bitcointalk.org/index.php?topic=60146.0 0.5.2 release announcement]</ref>===
Bitcoin version 0.5.2 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.2/

This is a bugfix-only release based on 0.5.1.

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.2#.tar.gz

BUG FIXES

Check all transactions in blocks after the last checkpoint (0.5.0 and 0.5.1 skipped checking ECDSA signatures during initial blockchain download).
Cease locking memory used by non-sensitive information (this caused a huge performance hit on some platforms, especially noticable during initial blockchain download; this was
not a security vulnerability).
Fixed some address-handling deadlocks (client freezes).
No longer accept inbound connections over the internet when Bitcoin is being used with Tor (identity leak).
Re-enable SSL support for the JSON-RPC interface (it was unintentionally disabled for the 0.5.0 and 0.5.1 release Linux binaries).
Use the correct base transaction fee of 0.0005 BTC for accepting transactions into mined blocks (since 0.4.0, it was incorrectly accepting 0.0001 BTC which was only meant to be relayed).
Don't show "IP" for transactions which are not necessarily IP transactions.
Add new DNS seeds (maintained by Pieter Wuille and Luke Dashjr).

===0.5.1<ref>[https://bitcointalk.org/index.php?topic=54717.0 0.5.1 release announcement]</ref>===
Bitcoin version 0.5.1 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.1/

This is a bugfix-only release.

This release includes 13 translations, including 5 new translations:
Italian, Hungarian, Ukranian, Portuguese (Brazilian) and Simplified Chinese.
More translations are welcome; join the project at Transifex if you can help:
https://www.transifex.net/projects/p/bitcoin/

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Project source code is hosted at github; we are no longer
distributing .tar.gz files here, you can get them
directly from github:
https://github.com/bitcoin/bitcoin/tarball/v0.5.1 # .tar.gz
https://github.com/bitcoin/bitcoin/zipball/v0.5.1 # .zip

For Ubuntu users, there is a new ppa maintained by Matt Corallo which
you can add to your system so that it will automatically keep
bitcoin up-to-date. Just type
sudo apt-add-repository ppa:bitcoin/bitcoin
in your terminal, then install the bitcoin-qt package.

BUG FIXES

Re-enable SSL support for the JSON-RPC interface (it was unintentionally
disabled for the 0.5.0 release binaries).

The code that finds peers via "dns seeds" no longer stops bitcoin startup
if one of the dns seed machines is down.

Tooltips on the transaction list view were rendering incorrectly (as black boxes
or with a transparent background).

Prevent a denial-of-service attack involving flooding a bitcoin node with
orphan blocks.

The wallet passphrase dialog now warns you if the caps lock key was pressed.

Improved searching in addresses and labels in bitcoin-qt.

===0.5.0<ref>[https://bitcointalk.org/index.php?topic=52480.0 0.5.0 release announcement]</ref>===
Bitcoin version 0.5.0 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.0/

The major change for this release is a completely new graphical interface that uses the Qt user interface toolkit.

This release include German, Spanish, Spanish-Castilian, Norwegian and Dutch translations. More translations are welcome; join the project at Transifex if you can help:
https://www.transifex.net/projects/p/bitcoin/

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

For Ubuntu users, there is a new ppa maintained by Matt Corallo which you can add to your system so that it will automatically keep bitcoin up-to-date. Just type "sudo apt-add-repository ppa:bitcoin/bitcoin" in your terminal, then install the bitcoin-qt package.

MAJOR BUG FIX (CVE-2011-4447)

The wallet encryption feature introduced in Bitcoin version 0.4.0 did not sufficiently secure the private keys. An attacker who
managed to get a copy of your encrypted wallet.dat file might be able to recover some or all of the unencrypted keys and steal the
associated coins.

If you have a previously encrypted wallet.dat, the first time you run bitcoin-qt or bitcoind the wallet will be rewritten, Bitcoin will
shut down, and you will be prompted to restart it to run with the new, properly encrypted file.

If you had a previously encrypted wallet.dat that might have been copied or stolen (for example, you backed it up to a public
location) you should send all of your bitcoins to yourself using a new bitcoin address and stop using any previously generated addresses.

Wallets encrypted with this version of Bitcoin are written properly.

Technical note: the encrypted wallet's 'keypool' will be regenerated the first time you request a new bitcoin address; to be certain that the
new private keys are properly backed up you should:

1. Run Bitcoin and let it rewrite the wallet.dat file

2. Run it again, then ask it for a new bitcoin address.
Bitcoin-Qt: Address Book, then New Address...
bitcoind: run the 'walletpassphrase' RPC command to unlock the wallet, then run the 'getnewaddress' RPC command.

3. If your encrypted wallet.dat may have been copied or stolen, send all of your bitcoins to the new bitcoin address.

4. Shut down Bitcoin, then backup the wallet.dat file.
IMPORTANT: be sure to request a new bitcoin address before backing up, so that the 'keypool' is regenerated and backed up.

"Security in depth" is always a good idea, so choosing a secure location for the backup and/or encrypting the backup before uploading it is recommended. And as in previous releases, if your machine is infected by malware there are several ways an attacker might steal your bitcoins.

Thanks to Alan Reiner (etotheipi) for finding and reporting this bug.

MAJOR GUI CHANGES

"Splash" graphics at startup that show address/wallet/blockchain loading progress.

"Synchronizing with network" progress bar to show block-chain download progress.

Icons at the bottom of the window that show how well connected you are to the network, with tooltips to display details.

Drag and drop support for bitcoin: URIs on web pages.

Export transactions as a .csv file.

Many other GUI improvements, large and small.

RPC CHANGES

getmemorypool : new RPC command, provides everything needed to construct a block with a custom generation transaction and submit a solution

listsinceblock : new RPC command, list transactions since given block

signmessage/verifymessage : new RPC commands to sign a message with one of your private keys or verify that a message signed by the private key associated with a bitcoin address.

GENERAL CHANGES

Faster initial block download.

==0.4.X==
After 0.4.0, all subsequent releases are stable maintenance releases, 0.5.0 is based on 0.4.0.

===0.4.6<ref>[https://bitcointalk.org/index.php?topic=79651 0.4.6/0.5.5 release announcement]</ref>===
bitcoind version 0.4.6 is now available for download at:
Windows: installer | zip (sig)
Source: tar.gz
bitcoind and Bitcoin-Qt version 0.6.0.7 are also tagged in git, but it is recommended to upgrade to 0.6.1.

These are bugfix-only releases.

Please report bugs by replying to this forum thread. Note that the 0.4.x wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr.

BUG FIXES

Version 0.6.0 allowed importing invalid "private keys", which would be unspendable; 0.6.0.7 will now verify the private key is valid, and refuse to import an invalid one
Verify status of encrypt/decrypt calls to detect failed padding
Check blocks for duplicate transactions earlier. Fixes #1167
Upgrade Windows builds to OpenSSL 1.0.1b
Set label when selecting an address that already has a label. Fixes #1080 (Bitcoin-Qt)
JSON-RPC listtransactions's from/count handling is now fixed
Optimize and fix multithreaded access, when checking whether we already know about transactions
Fix potential networking deadlock
Proper support for Growl 1.3 notifications
Display an error, rather than crashing, if encoding a QR Code failed (0.6.0.7)
Don't erroneously set "Display addresses" for users who haven't explicitly enabled it (Bitcoin-Qt)
Some non-ASCII input in JSON-RPC expecting hexadecimal may have been misinterpreted rather than rejected
Missing error condition checking added
Do not show green tick unless all known blocks are downloaded. Fixes #921 (Bitcoin-Qt)
Increase time ago of last block for "up to date" status from 30 to 90 minutes
Show a message box when runaway exception happens (Bitcoin-Qt)
Use a messagebox to display the error when -server is provided without providing a rpc password
Show error message instead of exception crash when unable to bind RPC port (Bitcoin-Qt)
Correct sign message bitcoin address tooltip. Fixes #1050 (Bitcoin-Qt)
Removed "(no label)" from QR Code dialog titlebar if we have no label (0.6.0.7)
Removed an ugly line break in tooltip for mature transactions (0.6.0.7)
Add missing tooltip and key shortcut in settings dialog (part of #1088) (Bitcoin-Qt)
Work around issue in boost::program_options that prevents from compiling in clang
Fixed bugs occurring only on platforms with unsigned characters (such as ARM).
Rename make_windows_icon.py to .sh as it is a shell script. Fixes #1099 (Bitcoin-Qt)
Various trivial internal corrections to types used for counting/size loops and warnings

===0.4.5===
(No known forum post.)

===0.4.4<ref>[https://bitcointalk.org/index.php?topic=70566.0 0.4.4 release announcement]</ref>===
Bitcoin version 0.4.4 is now available for download at:
http://luke.dashjr.org/programs/bitcoin/files/bitcoind-0.4.4/

This is a bugfix-only release based on 0.4.0.

Please note that the wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr.

Please report bugs for the daemon only using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.4.4#.tar.gz

BUG FIXES

Limit the number of orphan transactions stored in memory, to prevent a potential denial-of-service attack by flooding orphan transactions. Also never store invalid transactions at all.
Fix possible buffer overflow on systems with very long application data paths. This is not exploitable.
Resolved multiple bugs preventing long-term unlocking of encrypted wallets (issue #922).
Only send local IP in "version" messages if it is globally routable (ie, not private), and try to get such an IP from UPnP if applicable.
Reannounce UPnP port forwards every 20 minutes, to workaround routers expiring old entries, and allow the -upnp option to override any stored setting.
Various memory leaks and potential null pointer deferences have been
fixed.
Several shutdown issues have been fixed.
Check that keys stored in the wallet are valid at startup, and if not,
report corruption.
Various build fixes.
If no password is specified to bitcoind, recommend a secure password.
Update hard-coded fallback seed nodes, choosing recent ones with long uptime and versions at least 0.4.0.
Add checkpoint at block 168,000.

===0.4.3<ref>[https://bitcointalk.org/index.php?topic=57734.0 0.4.3 release announcement]</ref>===
bitcoind version 0.4.3 is now available for download at:
http://luke.dashjr.org/programs/bitcoin/files/bitcoind-0.4.3/ (until Gavin uploads to SourceForge)

This is a bugfix-only release based on 0.4.0.

Please note that the wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr.

Please report bugs for the daemon only using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.4.3#.tar.gz

BUG FIXES

Cease locking memory used by non-sensitive information (this caused a huge performance hit on some platforms, especially noticable during initial blockchain download).
Fixed some address-handling deadlocks (client freezes).
No longer accept inbound connections over the internet when Bitcoin is being used with Tor (identity leak).
Use the correct base transaction fee of 0.0005 BTC for accepting transactions into mined blocks (since 0.4.0, it was incorrectly accepting 0.0001 BTC which was only meant to be relayed).
Add new DNS seeds (maintained by Pieter Wuille and Luke Dashjr).

===0.4.2===
(No known forum post.)

===0.4.1<ref>[https://bitcointalk.org/index.php?topic=52503.0 0.4.1 release announcement]</ref>===
Bitcoin version 0.4.1 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.4.1/

This is a bugfix only release based on 0.4.0.

Please report bugs by replying to this forum thread.

MAJOR BUG FIX (CVE-2011-4447)

The wallet encryption feature introduced in Bitcoin version 0.4.0 did not sufficiently secure the private keys. An attacker who
managed to get a copy of your encrypted wallet.dat file might be able to recover some or all of the unencrypted keys and steal the
associated coins.

If you have a previously encrypted wallet.dat, the first time you run wxbitcoin or bitcoind the wallet will be rewritten, Bitcoin will
shut down, and you will be prompted to restart it to run with the new, properly encrypted file.

If you had a previously encrypted wallet.dat that might have been copied or stolen (for example, you backed it up to a public
location) you should send all of your bitcoins to yourself using a new bitcoin address and stop using any previously generated addresses.

Wallets encrypted with this version of Bitcoin are written properly.

Technical note: the encrypted wallet's 'keypool' will be regenerated the first time you request a new bitcoin address; to be certain that the
new private keys are properly backed up you should:

1. Run Bitcoin and let it rewrite the wallet.dat file

2. Run it again, then ask it for a new bitcoin address.
wxBitcoin: new address visible on main window
bitcoind: run the 'walletpassphrase' RPC command to unlock the wallet, then run the 'getnewaddress' RPC command.

3. If your encrypted wallet.dat may have been copied or stolen, send all of your bitcoins to the new bitcoin address.

4. Shut down Bitcoin, then backup the wallet.dat file.
IMPORTANT: be sure to request a new bitcoin address before backing up, so that the 'keypool' is regenerated and backed up.

"Security in depth" is always a good idea, so choosing a secure location for the backup and/or encrypting the backup before uploading it is recommended. And as in previous releases, if your machine is infected by malware there are several ways an attacker might steal your bitcoins.

Thanks to Alan Reiner (etotheipi) for finding and reporting this bug.

===0.4.0<ref>[https://bitcointalk.org/index.php?topic=45410.0 0.4 release announcement]</ref>===
Bitcoin version 0.4.0 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.4.0/

The main feature in this release is wallet private key encryption;
you can set a passphrase that must be entered before sending coins.
See below for more information; if you decide to encrypt your wallet,
WRITE DOWN YOUR PASSPHRASE AND PUT IT IN A SECURE LOCATION. If you
forget or lose your wallet passphrase, you lose your bitcoins.
Previous versions of bitcoin are unable to read encrypted wallets,
and will crash on startup if the wallet is encrypted.

Also note: bitcoin version 0.4 uses a newer version of Berkeley DB
(bdb version 4.8) than previous versions (bdb 4.7). If you upgrade
to version 0.4 and then revert back to an earlier version of bitcoin
the it may be unable to start because bdb 4.7 cannot read bdb 4.8
"log" files.

Notable bug fixes from version 0.3.24:

Fix several bitcoin-becomes-unresponsive bugs due to multithreading
deadlocks.

Optimize database writes for large (lots of inputs) transactions
(fixes a potential denial-of-service attack)

Wallet Encryption

Bitcoin supports native wallet encryption so that people who steal your
wallet file don't automatically get access to all of your Bitcoins.
In order to enable this feature, choose "Encrypt Wallet" from the
Options menu. You will be prompted to enter a passphrase, which
will be used as the key to encrypt your wallet and will be needed
every time you wish to send Bitcoins. If you lose this passphrase,
you will lose access to spend all of the bitcoins in your wallet,
no one, not even the Bitcoin developers can recover your Bitcoins.
This means you are responsible for your own security, store your
passphrase in a secure location and do not forget it.

Remember that the encryption built into bitcoin only encrypts the
actual keys which are required to send your bitcoins, not the full
wallet. This means that someone who steals your wallet file will
be able to see all the addresses which belong to you, as well as the
relevant transactions, you are only protected from someone spending
your coins.

It is recommended that you backup your wallet file before you
encrypt your wallet. To do this, close the Bitcoin client and
copy the wallet.dat file from ~/.bitcoin/ on Linux, /Users/(user
name)/Application Support/Bitcoin/ on Mac OSX, and %APPDATA%/Bitcoin/
on Windows (that is /Users/(user name)/AppData/Roaming/Bitcoin on
Windows Vista and 7 and /Documents and Settings/(user name)/Application
Data/Bitcoin on Windows XP). Once you have copied that file to a
safe location, reopen the Bitcoin client and Encrypt your wallet.
If everything goes fine, delete the backup and enjoy your encrypted
wallet. Note that once you encrypt your wallet, you will never be
able to go back to a version of the Bitcoin client older than 0.4.

Keep in mind that you are always responsible for your own security.
All it takes is a slightly more advanced wallet-stealing trojan which
installs a keylogger to steal your wallet passphrase as you enter it
in addition to your wallet file and you have lost all your Bitcoins.
Wallet encryption cannot keep you safe if you do not practice
good security, such as running up-to-date antivirus software, only
entering your wallet passphrase in the Bitcoin client and using the
same passphrase only as your wallet passphrase.

See the doc/README file in the bitcoin source for technical details
of wallet encryption.

==0.3.X==

===0.3.24<ref>[https://bitcointalk.org/index.php?topic=27187.0 0.3.24 release announcement]</ref>===
Bitcoin v0.3.24 is now available for download at
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.24/

This is another bug fix release. We had hoped to have wallet encryption ready for release, but more urgent fixes for existing clients were needed -- most notably block download problems were getting severe. Wallet encryption is ready for testing at https://github.com/bitcoin/bitcoin/pull/352 for the git-savvy, and hopefully will follow shortly in the next release, v0.4.

Notable fixes in v0.3.24, and the main reasons for this release:

F1) Block downloads were failing or taking unreasonable amounts of time to complete, because the increased size of the block chain was bumping up against some earlier buffer-size DoS limits.

F2) Fix crash caused by loss/lack of network connection.

Notable changes in v0.3.24:

C1) DNS seeding enabled by default.

C2) UPNP enabled by default in the GUI client. The percentage of bitcoin clients that accept incoming connections is quite small, and that is a problem. This should help. bitcoind, and unofficial builds, are unchanged (though we encourage use of "-upnp" to help the network!)

C3) Initial unit testing framework. Bitcoin sorely needs automated tests, and this is a beginning. Contributions welcome.

C4) Internal wallet code cleanup. While invisible to an end user, this change provides the basis for v0.4's wallet encryption.

===0.3.23<ref>[https://bitcointalk.org/index.php?topic=16553.0 0.3.23 release announcement]</ref>===
Win32, Linux, MacOSX and source releases for bitcoin v0.3.23 have been uploaded to
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.23/

This is another quick bugfix release, trying to deal with the influx of new bitcoin users.

Main items of note:

* P2P connect-to-node logic changed to reduce timeout a bit. The network saw a huge influx of new users, who do not permit incoming connections. This change is a short-term hack, to more quickly hunt for useful P2P connections. Better "leaf node" logic is in the works, but this should let us limp along until then. One may use -upnp to properly forward ports, and help the network.
* Transaction fee reduced to 0.0005 for new transactions
* Client will relay transactions with fees as low as 0.0001 BTC

===0.3.22<ref>[https://bitcointalk.org/index.php?topic=12269.0 0.3.22 release announcement]</ref>===
Download URL: https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.22/

This is largely a bugfix and TX fee schedule release. We also hope to make 0.3.23 a quick release, to fix problems that the network has seen due to explosive growth in the past week.

Notable changes:
* Client will accept and relay TX's with 0.0005 BTC fee schedule (users still pay 0.01 BTC per kb, until next version)
* Non-standard transactions accepted on testnet
* Source code tree reorganized (prep for autotools build)
* Remove "Generate Coins" option from GUI, and remove 4way SSE miner. Internal reference CPU miner remains available, but users are directed to external miners for best hash production.
* IRC is overflowing. Client now bootstraps to channels #bitcoin00 - #bitcoin99
* DNS names now may be used with -addnode, -connect (requires -dns to enable)

RPC changes:
* 'listtransactions' adds 'from' param, for range queries
* 'move' may take account balances negative
* 'settxfee' added, to manually set TX fee

===0.3.21<ref>[https://bitcointalk.org/index.php?topic=6642.0 0.3.21 release announcement]</ref>===
Binaries for Bitcoin version 0.3.21 are available at:
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.21/

Changes and new features from the 0.3.20 release include:

* Universal Plug and Play support. Enable automatic opening of a port for incoming connections by running bitcoin or bitcoind with the - -upnp=1 command line switch or using the Options dialog box.

* Support for full-precision bitcoin amounts. You can now send, and bitcoin will display, bitcoin amounts smaller than 0.01. However, sending fewer than 0.01 bitcoins still requires a 0.01 bitcoin fee (so you can send 1.0001 bitcoins without a fee, but you will be asked to pay a fee if you try to send 0.0001).

* A new method of finding bitcoin nodes to connect with, via DNS A records. Use the -dnsseed option to enable.

For developers, changes to bitcoin's remote-procedure-call API:

* New rpc command "sendmany" to send bitcoins to more than one address in a single transaction.

* Several bug fixes, including a serious intermittent bug that would sometimes cause bitcoind to stop accepting rpc requests.

* -logtimestamps option, to add a timestamp to each line in debug.log.

* Immature blocks (newly generated, under 120 confirmations) are now shown in listtransactions.

===0.3.20.2<ref>[https://bitcointalk.org/index.php?topic=4167.0 0.3.20.2 release announcement]</ref>===
The maxsendbuffer bug (0.3.20.1 clients not being able to download the block chain from other 0.3.20.1 clients) was only going to get
worse as people upgraded, so I cherry-picked the bug fix and created a minor release yesterday.

The Amazon Machine Images I used to do the builds are available:

ami-38a05251 Bitcoin-v0.3.20.2 Mingw (Windows; Administrator password 'bitcoin development')
ami-30a05259 Bitcoin_0.3.20.2 Linux32
ami-8abc4ee3 Bitcoin_0.3.20.2 Linux64

(mac build will be done soon)

If you have already downloaded version 0.3.20.1, please either add this to your bitcoin.conf file:

maxsendbuffer=10000
maxreceivebuffer=10000

... or download the new version.

===0.3.20.1===
(No known forum post.)

===0.3.20<ref>[https://bitcointalk.org/index.php?topic=2953.0 0.3.20 release announcement]</ref>===
Please checkout the git integration branch from:

https://github.com/bitcoin/bitcoin

... and help test. The new features that need testing are:

* -nolisten : https://github.com/bitcoin/bitcoin/pull/11
* -rescan : scan block chain for missing wallet transactions
* -printtoconsole : https://github.com/bitcoin/bitcoin/pull/37
* RPC gettransaction details : https://github.com/bitcoin/bitcoin/pull/24
* listtransactions new features : https://github.com/bitcoin/bitcoin/pull/10

Bug fixes that also need testing:

* -maxconnections= : https://github.com/bitcoin/bitcoin/pull/42
* RPC listaccounts minconf : https://github.com/bitcoin/bitcoin/pull/27
* RPC move, add time to output : https://github.com/bitcoin/bitcoin/pull/21
* ...and several improvements to --help output.

This needs more testing on Windows! Please drop me a quick private message, email, or IRC message if you are able to do some testing. If you find bugs, please open an issue at:

https://github.com/bitcoin/bitcoin/issues

===0.3.19<ref>[https://bitcointalk.org/index.php?topic=2228.0 0.3.19 release announcement]</ref>===
There's more work to do on DoS, but I'm doing a quick build of what I have so far in case it's needed, before venturing into more complex ideas. The build for this is version 0.3.19.

- Added some DoS controls
As Gavin and I have said clearly before, the software is not at all resistant to DoS attack. This is one improvement, but there are still more ways to attack than I can count.

I'm leaving the -limitfreerelay part as a switch for now and it's there if you need it.

- Removed "safe mode" alerts
"safe mode" alerts was a temporary measure after the 0.3.9 overflow bug. We can say all we want that users can just run with "-disablesafemode", but it's better just not to have it for the sake of appearances. It was never intended as a long term feature. Safe mode can still be triggered by seeing a longer (greater total PoW) invalid block chain.

===0.3.18<ref>[https://bitcointalk.org/index.php?topic=2162.0 0.3.18 release announcement]</ref>===

Changes:
* Fixed a wallet.dat compatibility problem if you downgraded from 0.3.17 and then upgraded again
* IsStandard() check to only include known transaction types in blocks
* Jgarzik's optimisation to speed up the initial block download a little

The main addition in this release is the Accounts-Based JSON-RPC commands that Gavin's been working on (more details at http://www.bitcoin.org/smf/index.php?topic=1886.0).
* getaccountaddress
* sendfrom
* move
* getbalance
* listtransactions

===0.3.17<ref>[https://bitcointalk.org/index.php?topic=1946.0 0.3.17 release announcement]</ref>===

Version 0.3.17 is now available.

Changes:
* new getwork, thanks m0mchil
* added transaction fee setting in UI options menu
* free transaction limits
* sendtoaddress returns transaction id instead of "sent"
* getaccountaddress <account>

The UI transaction fee setting was easy since it was still there from 0.1.5 and all I had to do was re-enable it.

The accounts-based commands: move, sendfrom and getbalance <account> will be in the next release. We still have some more changes to make first.

===0.3.16===

Never released.

===0.3.15<ref>[https://bitcointalk.org/index.php?topic=1780.0 0.3.15 release announcement]</ref>===

* paytxfee switch is now per KB, so it adds the correct fee for large transactions
* sending avoids using coins with less than 6 confirmations if it can
* BitcoinMiner processes transactions in priority order based on age of dependencies
* make sure generation doesn't start before block 74000 downloaded
* bugfixes by Dean Gores
* testnet, keypoololdest and paytxfee added to getinfo

===0.3.14<ref>[https://bitcointalk.org/index.php?topic=1528.0 0.3.14 release announcement]</ref>===

Version 0.3.14 is now available
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.14/

Changes:
* Key pool feature for safer wallet backup
Gavin Andresen:
* TEST network mode with switch -testnet
* Option to use SSL for JSON-RPC connections on unix/osx
* validateaddress RPC command
eurekafag:
* Russian translation

===0.3.13<ref>[https://bitcointalk.org/index.php?topic=1327.0 0.3.13 release announcement]</ref>===

Version 0.3.13 is now available. You should upgrade to prevent potential problems with 0/unconfirmed transactions. Note: 0.3.13 prevents problems if you haven't already spent a 0/unconfirmed transaction, but if that already happened, you need 0.3.13.2.

Changes:
* Don't count or spend payments until they have 1 confirmation.
* Internal version number from 312 to 31300.
* Only accept transactions sent by IP address if -allowreceivebyip is specified.
* Dropped DB_PRIVATE Berkeley DB flag.
* Fix problem sending the last cent with sub-cent fractional change.
* Auto-detect whether to use 128-bit 4-way SSE2 on Linux.
Gavin Andresen:
* Option -rpcallowip= to accept json-rpc connections from another machine.
* Clean shutdown on SIGTERM on Linux.

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.13/

(Thanks Laszlo for the Mac OSX build!)

Note:
The SSE2 auto-detect in the Linux 64-bit version doesn't work with AMD in 64-bit mode. Please try this instead and let me know if it gets it right:
http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gz

You can still control the SSE2 use manually with -4way and -4way=0.

Version 0.3.13.2 (SVN rev 161) has improvements for the case where you already had 0/unconfirmed transactions that you might have already spent. Here's a Windows build of it:
http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe

===0.3.12<ref>[https://bitcointalk.org/index.php?topic=999.0 0.3.12 release announcement]</ref>===

Version 0.3.12 is now available.

Features:
* json-rpc errors return a more standard error object. (thanks to Gavin Andresen)
* json-rpc command line returns exit codes.
* json-rpc "backupwallet" command.
* Recovers and continues if an exception is caused by a message you received. Other nodes shouldn't be able to cause an exception, and it hasn't happened before, but if a way is found to cause an exception, this would keep it from being used to stop network nodes.

If you have json-rpc code that checks the contents of the error string, you need to change it to expect error objects of the form {"code":<number>,"message":<string>}, which is the standard. See this thread:
http://www.bitcoin.org/smf/index.php?topic=969.0

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.12/

=References=
<references/>

Changelog

2012-06-12T22:49:14Z

BlueMatt: /* 0.4.10.4.1 release announcement */ Remove Boxes

{{stub}}

This page aggregates the changelogs that have been posted on the forum for the Bitcoin releases.
Note that some download links are not longer valid as highly insecure versions may have been deleted, or links may have changed.

=Changelogs=

==0.5.X==
After 0.5.1, all subsequent releases are stable maintenance releases, 0.6.0 is based on 0.5.1.

===0.5.5<ref>[https://bitcointalk.org/index.php?topic=79651 0.4.6/0.5.5 release announcement]</ref>===
bitcoind and Bitcoin-Qt version 0.5.5 are now available for download at:
Windows: installer | zip (sig)
Source: tar.gz
bitcoind and Bitcoin-Qt version 0.6.0.7 are also tagged in git, but it is recommended to upgrade to 0.6.1.

These are bugfix-only releases.

Please report bugs by replying to this forum thread. Note that the 0.4.x wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr.

BUG FIXES

Version 0.6.0 allowed importing invalid "private keys", which would be unspendable; 0.6.0.7 will now verify the private key is valid, and refuse to import an invalid one
Verify status of encrypt/decrypt calls to detect failed padding
Check blocks for duplicate transactions earlier. Fixes #1167
Upgrade Windows builds to OpenSSL 1.0.1b
Set label when selecting an address that already has a label. Fixes #1080 (Bitcoin-Qt)
JSON-RPC listtransactions's from/count handling is now fixed
Optimize and fix multithreaded access, when checking whether we already know about transactions
Fix potential networking deadlock
Proper support for Growl 1.3 notifications
Display an error, rather than crashing, if encoding a QR Code failed (0.6.0.7)
Don't erroneously set "Display addresses" for users who haven't explicitly enabled it (Bitcoin-Qt)
Some non-ASCII input in JSON-RPC expecting hexadecimal may have been misinterpreted rather than rejected
Missing error condition checking added
Do not show green tick unless all known blocks are downloaded. Fixes #921 (Bitcoin-Qt)
Increase time ago of last block for "up to date" status from 30 to 90 minutes
Show a message box when runaway exception happens (Bitcoin-Qt)
Use a messagebox to display the error when -server is provided without providing a rpc password
Show error message instead of exception crash when unable to bind RPC port (Bitcoin-Qt)
Correct sign message bitcoin address tooltip. Fixes #1050 (Bitcoin-Qt)
Removed "(no label)" from QR Code dialog titlebar if we have no label (0.6.0.7)
Removed an ugly line break in tooltip for mature transactions (0.6.0.7)
Add missing tooltip and key shortcut in settings dialog (part of #1088) (Bitcoin-Qt)
Work around issue in boost::program_options that prevents from compiling in clang
Fixed bugs occurring only on platforms with unsigned characters (such as ARM).
Rename make_windows_icon.py to .sh as it is a shell script. Fixes #1099 (Bitcoin-Qt)
Various trivial internal corrections to types used for counting/size loops and warnings

===0.5.4<ref>[https://bitcointalk.org/index.php?topic=76808.0 0.5.4 release announcement]</ref>===
Bitcoin version 0.5.4 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.4/
NOTE: 0.5.4rc3 is being renamed to 0.5.4 final with no changes.

This is a bugfix-only release in the 0.5.x series, plus a few protocol updates.

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.4#.tar.gz

PROTOCOL UPDATES

BIP 16: Special-case "pay to script hash" logic to enable minimal validation of new transactions.
Support for validating message signatures produced with compressed public keys.

BUG FIXES

Build with thread-safe MingW libraries for Windows, fixing a dangerous memory corruption scenario when exceptions are thrown.
Fix broken testnet mining.
Stop excess inventory relay during initial block download.
When disconnecting a node, clear the received buffer so that we do not process any already received messages.
Yet another attempt at implementing "minimize to tray" that works on all operating systems.
Fix Bitcoin-Qt notifications under Growl 1.3.
Increase required age of Bitcoin-Qt's "not up to date" status from 30 to 90 minutes.
Implemented missing verifications that led to crash on entering some wrong passphrases for encrypted wallets.
Fix default filename suffixes in GNOME save dialog.
Make the "Send coins" tab use the configured unit type, even on the first attempt.
Print detailed wallet loading errors to debug.log when it is corrupt.
Allocate exactly the amount of space needed for signing transactions, instead of a fixed 10k buffer.
Workaround for improbable memory access violation.
Check wallet's minimum version before trying to load it.
Remove wxBitcoin properly when installing Bitcoin-Qt over it. (Windows)
Detail reorganization information better in debug log.
Use a messagebox to display the error when -server is provided without configuring a RPC password.
Testing suite build now honours provided CXXFLAGS.
Removed an extraneous line-break in mature transaction tooltips.
Fix some grammatical errors in translation process documentation.

===0.5.3<ref>[https://bitcointalk.org/index.php?topic=68895.0 0.5.3 release announcement]</ref>===
Bitcoin version 0.5.3 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.3/

This is a bugfix-only release based on 0.5.1.
It also includes a few protocol updates.

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.3#.tar.gz

PROTOCOL UPDATES

BIP 30: Introduce a new network rule: "a block is not valid if it contains a transaction whose hash already exists in the block chain, unless all that transaction's outputs were already spent before said block" beginning on March 15, 2012, 00:00 UTC.
On testnet, allow mining of min-difficulty blocks if 20 minutes have gone by without mining a regular-difficulty block. This is to make testing Bitcoin easier, and will not affect normal mode.

BUG FIXES

Limit the number of orphan transactions stored in memory, to prevent a potential denial-of-service attack by flooding orphan transactions. Also never store invalid transactions at all.
Fix possible buffer overflow on systems with very long application data paths. This is not exploitable.
Resolved multiple bugs preventing long-term unlocking of encrypted wallets
(issue #922).
Only send local IP in "version" messages if it is globally routable (ie, not private), and try to get such an IP from UPnP if applicable.
Reannounce UPnP port forwards every 20 minutes, to workaround routers expiring old entries, and allow the -upnp option to override any stored setting.
Skip splash screen when -min is used, and fix Minimize to Tray function.
Do not blank "label" in Bitcoin-Qt "Send" tab, if the user has already entered something.
Correct various labels and messages.
Various memory leaks and potential null pointer deferences have been fixed.
Handle invalid Bitcoin URIs using "bitcoin://" instead of "bitcoin:".
Several shutdown issues have been fixed.
Revert to "global progress indication", as starting from zero every time was considered too confusing for many users.
Check that keys stored in the wallet are valid at startup, and if not, report corruption.
Enable accessible widgets on Windows, so that people with screen readers such as NVDA can make sense of it.
Various build fixes.
If no password is specified to bitcoind, recommend a secure password.
Automatically focus and scroll to new "Send coins" entries in Bitcoin-Qt.
Show a message box for --help on Windows, for Bitcoin-Qt.
Add missing "About Qt" menu option to show built-in Qt About dialog.
Don't show "-daemon" as an option for Bitcoin-Qt, since it isn't available.
Update hard-coded fallback seed nodes, choosing recent ones with long uptime and versions at least 0.4.0.
Add checkpoint at block 168,000.

===0.5.2<ref>[https://bitcointalk.org/index.php?topic=60146.0 0.5.2 release announcement]</ref>===
Bitcoin version 0.5.2 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.2/

This is a bugfix-only release based on 0.5.1.

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.2#.tar.gz

BUG FIXES

Check all transactions in blocks after the last checkpoint (0.5.0 and 0.5.1 skipped checking ECDSA signatures during initial blockchain download).
Cease locking memory used by non-sensitive information (this caused a huge performance hit on some platforms, especially noticable during initial blockchain download; this was
not a security vulnerability).
Fixed some address-handling deadlocks (client freezes).
No longer accept inbound connections over the internet when Bitcoin is being used with Tor (identity leak).
Re-enable SSL support for the JSON-RPC interface (it was unintentionally disabled for the 0.5.0 and 0.5.1 release Linux binaries).
Use the correct base transaction fee of 0.0005 BTC for accepting transactions into mined blocks (since 0.4.0, it was incorrectly accepting 0.0001 BTC which was only meant to be relayed).
Don't show "IP" for transactions which are not necessarily IP transactions.
Add new DNS seeds (maintained by Pieter Wuille and Luke Dashjr).

===0.5.1<ref>[https://bitcointalk.org/index.php?topic=54717.0 0.5.1 release announcement]</ref>===
Bitcoin version 0.5.1 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.1/

This is a bugfix-only release.

This release includes 13 translations, including 5 new translations:
Italian, Hungarian, Ukranian, Portuguese (Brazilian) and Simplified Chinese.
More translations are welcome; join the project at Transifex if you can help:
https://www.transifex.net/projects/p/bitcoin/

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Project source code is hosted at github; we are no longer
distributing .tar.gz files here, you can get them
directly from github:
https://github.com/bitcoin/bitcoin/tarball/v0.5.1 # .tar.gz
https://github.com/bitcoin/bitcoin/zipball/v0.5.1 # .zip

For Ubuntu users, there is a new ppa maintained by Matt Corallo which
you can add to your system so that it will automatically keep
bitcoin up-to-date. Just type
sudo apt-add-repository ppa:bitcoin/bitcoin
in your terminal, then install the bitcoin-qt package.

BUG FIXES

Re-enable SSL support for the JSON-RPC interface (it was unintentionally
disabled for the 0.5.0 release binaries).

The code that finds peers via "dns seeds" no longer stops bitcoin startup
if one of the dns seed machines is down.

Tooltips on the transaction list view were rendering incorrectly (as black boxes
or with a transparent background).

Prevent a denial-of-service attack involving flooding a bitcoin node with
orphan blocks.

The wallet passphrase dialog now warns you if the caps lock key was pressed.

Improved searching in addresses and labels in bitcoin-qt.

===0.5.0<ref>[https://bitcointalk.org/index.php?topic=52480.0 0.5.0 release announcement]</ref>===
Bitcoin version 0.5.0 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.0/

The major change for this release is a completely new graphical interface that uses the Qt user interface toolkit.

This release include German, Spanish, Spanish-Castilian, Norwegian and Dutch translations. More translations are welcome; join the project at Transifex if you can help:
https://www.transifex.net/projects/p/bitcoin/

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

For Ubuntu users, there is a new ppa maintained by Matt Corallo which you can add to your system so that it will automatically keep bitcoin up-to-date. Just type "sudo apt-add-repository ppa:bitcoin/bitcoin" in your terminal, then install the bitcoin-qt package.

MAJOR BUG FIX (CVE-2011-4447)

The wallet encryption feature introduced in Bitcoin version 0.4.0 did not sufficiently secure the private keys. An attacker who
managed to get a copy of your encrypted wallet.dat file might be able to recover some or all of the unencrypted keys and steal the
associated coins.

If you have a previously encrypted wallet.dat, the first time you run bitcoin-qt or bitcoind the wallet will be rewritten, Bitcoin will
shut down, and you will be prompted to restart it to run with the new, properly encrypted file.

If you had a previously encrypted wallet.dat that might have been copied or stolen (for example, you backed it up to a public
location) you should send all of your bitcoins to yourself using a new bitcoin address and stop using any previously generated addresses.

Wallets encrypted with this version of Bitcoin are written properly.

Technical note: the encrypted wallet's 'keypool' will be regenerated the first time you request a new bitcoin address; to be certain that the
new private keys are properly backed up you should:

1. Run Bitcoin and let it rewrite the wallet.dat file

2. Run it again, then ask it for a new bitcoin address.
Bitcoin-Qt: Address Book, then New Address...
bitcoind: run the 'walletpassphrase' RPC command to unlock the wallet, then run the 'getnewaddress' RPC command.

3. If your encrypted wallet.dat may have been copied or stolen, send all of your bitcoins to the new bitcoin address.

4. Shut down Bitcoin, then backup the wallet.dat file.
IMPORTANT: be sure to request a new bitcoin address before backing up, so that the 'keypool' is regenerated and backed up.

"Security in depth" is always a good idea, so choosing a secure location for the backup and/or encrypting the backup before uploading it is recommended. And as in previous releases, if your machine is infected by malware there are several ways an attacker might steal your bitcoins.

Thanks to Alan Reiner (etotheipi) for finding and reporting this bug.

MAJOR GUI CHANGES

"Splash" graphics at startup that show address/wallet/blockchain loading progress.

"Synchronizing with network" progress bar to show block-chain download progress.

Icons at the bottom of the window that show how well connected you are to the network, with tooltips to display details.

Drag and drop support for bitcoin: URIs on web pages.

Export transactions as a .csv file.

Many other GUI improvements, large and small.

RPC CHANGES

getmemorypool : new RPC command, provides everything needed to construct a block with a custom generation transaction and submit a solution

listsinceblock : new RPC command, list transactions since given block

signmessage/verifymessage : new RPC commands to sign a message with one of your private keys or verify that a message signed by the private key associated with a bitcoin address.

GENERAL CHANGES

Faster initial block download.

==0.4.X==
After 0.4.0, all subsequent releases are stable maintenance releases, 0.5.0 is based on 0.4.0.

===0.4.6<ref>[https://bitcointalk.org/index.php?topic=79651 0.4.6/0.5.5 release announcement]</ref>===
bitcoind version 0.4.6 is now available for download at:
Windows: installer | zip (sig)
Source: tar.gz
bitcoind and Bitcoin-Qt version 0.6.0.7 are also tagged in git, but it is recommended to upgrade to 0.6.1.

These are bugfix-only releases.

Please report bugs by replying to this forum thread. Note that the 0.4.x wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr.

BUG FIXES

Version 0.6.0 allowed importing invalid "private keys", which would be unspendable; 0.6.0.7 will now verify the private key is valid, and refuse to import an invalid one
Verify status of encrypt/decrypt calls to detect failed padding
Check blocks for duplicate transactions earlier. Fixes #1167
Upgrade Windows builds to OpenSSL 1.0.1b
Set label when selecting an address that already has a label. Fixes #1080 (Bitcoin-Qt)
JSON-RPC listtransactions's from/count handling is now fixed
Optimize and fix multithreaded access, when checking whether we already know about transactions
Fix potential networking deadlock
Proper support for Growl 1.3 notifications
Display an error, rather than crashing, if encoding a QR Code failed (0.6.0.7)
Don't erroneously set "Display addresses" for users who haven't explicitly enabled it (Bitcoin-Qt)
Some non-ASCII input in JSON-RPC expecting hexadecimal may have been misinterpreted rather than rejected
Missing error condition checking added
Do not show green tick unless all known blocks are downloaded. Fixes #921 (Bitcoin-Qt)
Increase time ago of last block for "up to date" status from 30 to 90 minutes
Show a message box when runaway exception happens (Bitcoin-Qt)
Use a messagebox to display the error when -server is provided without providing a rpc password
Show error message instead of exception crash when unable to bind RPC port (Bitcoin-Qt)
Correct sign message bitcoin address tooltip. Fixes #1050 (Bitcoin-Qt)
Removed "(no label)" from QR Code dialog titlebar if we have no label (0.6.0.7)
Removed an ugly line break in tooltip for mature transactions (0.6.0.7)
Add missing tooltip and key shortcut in settings dialog (part of #1088) (Bitcoin-Qt)
Work around issue in boost::program_options that prevents from compiling in clang
Fixed bugs occurring only on platforms with unsigned characters (such as ARM).
Rename make_windows_icon.py to .sh as it is a shell script. Fixes #1099 (Bitcoin-Qt)
Various trivial internal corrections to types used for counting/size loops and warnings

===0.4.5===
(No known forum post.)

===0.4.4<ref>[https://bitcointalk.org/index.php?topic=70566.0 0.4.4 release announcement]</ref>===
Bitcoin version 0.4.4 is now available for download at:
http://luke.dashjr.org/programs/bitcoin/files/bitcoind-0.4.4/

This is a bugfix-only release based on 0.4.0.

Please note that the wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr.

Please report bugs for the daemon only using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.4.4#.tar.gz

BUG FIXES

Limit the number of orphan transactions stored in memory, to prevent a potential denial-of-service attack by flooding orphan transactions. Also never store invalid transactions at all.
Fix possible buffer overflow on systems with very long application data paths. This is not exploitable.
Resolved multiple bugs preventing long-term unlocking of encrypted wallets (issue #922).
Only send local IP in "version" messages if it is globally routable (ie, not private), and try to get such an IP from UPnP if applicable.
Reannounce UPnP port forwards every 20 minutes, to workaround routers expiring old entries, and allow the -upnp option to override any stored setting.
Various memory leaks and potential null pointer deferences have been
fixed.
Several shutdown issues have been fixed.
Check that keys stored in the wallet are valid at startup, and if not,
report corruption.
Various build fixes.
If no password is specified to bitcoind, recommend a secure password.
Update hard-coded fallback seed nodes, choosing recent ones with long uptime and versions at least 0.4.0.
Add checkpoint at block 168,000.

===0.4.3<ref>[https://bitcointalk.org/index.php?topic=57734.0 0.4.3 release announcement]</ref>===
bitcoind version 0.4.3 is now available for download at:
http://luke.dashjr.org/programs/bitcoin/files/bitcoind-0.4.3/ (until Gavin uploads to SourceForge)

This is a bugfix-only release based on 0.4.0.

Please note that the wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr.

Please report bugs for the daemon only using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.4.3#.tar.gz

BUG FIXES

Cease locking memory used by non-sensitive information (this caused a huge performance hit on some platforms, especially noticable during initial blockchain download).
Fixed some address-handling deadlocks (client freezes).
No longer accept inbound connections over the internet when Bitcoin is being used with Tor (identity leak).
Use the correct base transaction fee of 0.0005 BTC for accepting transactions into mined blocks (since 0.4.0, it was incorrectly accepting 0.0001 BTC which was only meant to be relayed).
Add new DNS seeds (maintained by Pieter Wuille and Luke Dashjr).

===0.4.2===
(No known forum post.)

===0.4.1<ref>[https://bitcointalk.org/index.php?topic=52503.0 0.4.1 release announcement]</ref>===
Bitcoin version 0.4.1 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.4.1/

This is a bugfix only release based on 0.4.0.

Please report bugs by replying to this forum thread.

MAJOR BUG FIX (CVE-2011-4447)

The wallet encryption feature introduced in Bitcoin version 0.4.0 did not sufficiently secure the private keys. An attacker who
managed to get a copy of your encrypted wallet.dat file might be able to recover some or all of the unencrypted keys and steal the
associated coins.

If you have a previously encrypted wallet.dat, the first time you run wxbitcoin or bitcoind the wallet will be rewritten, Bitcoin will
shut down, and you will be prompted to restart it to run with the new, properly encrypted file.

If you had a previously encrypted wallet.dat that might have been copied or stolen (for example, you backed it up to a public
location) you should send all of your bitcoins to yourself using a new bitcoin address and stop using any previously generated addresses.

Wallets encrypted with this version of Bitcoin are written properly.

Technical note: the encrypted wallet's 'keypool' will be regenerated the first time you request a new bitcoin address; to be certain that the
new private keys are properly backed up you should:

1. Run Bitcoin and let it rewrite the wallet.dat file

2. Run it again, then ask it for a new bitcoin address.
wxBitcoin: new address visible on main window
bitcoind: run the 'walletpassphrase' RPC command to unlock the wallet, then run the 'getnewaddress' RPC command.

3. If your encrypted wallet.dat may have been copied or stolen, send all of your bitcoins to the new bitcoin address.

4. Shut down Bitcoin, then backup the wallet.dat file.
IMPORTANT: be sure to request a new bitcoin address before backing up, so that the 'keypool' is regenerated and backed up.

"Security in depth" is always a good idea, so choosing a secure location for the backup and/or encrypting the backup before uploading it is recommended. And as in previous releases, if your machine is infected by malware there are several ways an attacker might steal your bitcoins.

Thanks to Alan Reiner (etotheipi) for finding and reporting this bug.

===0.4.0<ref>[https://bitcointalk.org/index.php?topic=45410.0 0.4 release announcement]</ref>===
Bitcoin version 0.4.0 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.4.0/

The main feature in this release is wallet private key encryption;
you can set a passphrase that must be entered before sending coins.
See below for more information; if you decide to encrypt your wallet,
WRITE DOWN YOUR PASSPHRASE AND PUT IT IN A SECURE LOCATION. If you
forget or lose your wallet passphrase, you lose your bitcoins.
Previous versions of bitcoin are unable to read encrypted wallets,
and will crash on startup if the wallet is encrypted.

Also note: bitcoin version 0.4 uses a newer version of Berkeley DB
(bdb version 4.8) than previous versions (bdb 4.7). If you upgrade
to version 0.4 and then revert back to an earlier version of bitcoin
the it may be unable to start because bdb 4.7 cannot read bdb 4.8
"log" files.

Notable bug fixes from version 0.3.24:

Fix several bitcoin-becomes-unresponsive bugs due to multithreading
deadlocks.

Optimize database writes for large (lots of inputs) transactions
(fixes a potential denial-of-service attack)

Wallet Encryption

Bitcoin supports native wallet encryption so that people who steal your
wallet file don't automatically get access to all of your Bitcoins.
In order to enable this feature, choose "Encrypt Wallet" from the
Options menu. You will be prompted to enter a passphrase, which
will be used as the key to encrypt your wallet and will be needed
every time you wish to send Bitcoins. If you lose this passphrase,
you will lose access to spend all of the bitcoins in your wallet,
no one, not even the Bitcoin developers can recover your Bitcoins.
This means you are responsible for your own security, store your
passphrase in a secure location and do not forget it.

Remember that the encryption built into bitcoin only encrypts the
actual keys which are required to send your bitcoins, not the full
wallet. This means that someone who steals your wallet file will
be able to see all the addresses which belong to you, as well as the
relevant transactions, you are only protected from someone spending
your coins.

It is recommended that you backup your wallet file before you
encrypt your wallet. To do this, close the Bitcoin client and
copy the wallet.dat file from ~/.bitcoin/ on Linux, /Users/(user
name)/Application Support/Bitcoin/ on Mac OSX, and %APPDATA%/Bitcoin/
on Windows (that is /Users/(user name)/AppData/Roaming/Bitcoin on
Windows Vista and 7 and /Documents and Settings/(user name)/Application
Data/Bitcoin on Windows XP). Once you have copied that file to a
safe location, reopen the Bitcoin client and Encrypt your wallet.
If everything goes fine, delete the backup and enjoy your encrypted
wallet. Note that once you encrypt your wallet, you will never be
able to go back to a version of the Bitcoin client older than 0.4.

Keep in mind that you are always responsible for your own security.
All it takes is a slightly more advanced wallet-stealing trojan which
installs a keylogger to steal your wallet passphrase as you enter it
in addition to your wallet file and you have lost all your Bitcoins.
Wallet encryption cannot keep you safe if you do not practice
good security, such as running up-to-date antivirus software, only
entering your wallet passphrase in the Bitcoin client and using the
same passphrase only as your wallet passphrase.

See the doc/README file in the bitcoin source for technical details
of wallet encryption.

==0.3.X==

===0.3.24<ref>[https://bitcointalk.org/index.php?topic=27187.0 0.3.24 release announcement]</ref>===
Bitcoin v0.3.24 is now available for download at
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.24/

This is another bug fix release. We had hoped to have wallet encryption ready for release, but more urgent fixes for existing clients were needed -- most notably block download problems were getting severe. Wallet encryption is ready for testing at https://github.com/bitcoin/bitcoin/pull/352 for the git-savvy, and hopefully will follow shortly in the next release, v0.4.

Notable fixes in v0.3.24, and the main reasons for this release:

F1) Block downloads were failing or taking unreasonable amounts of time to complete, because the increased size of the block chain was bumping up against some earlier buffer-size DoS limits.

F2) Fix crash caused by loss/lack of network connection.

Notable changes in v0.3.24:

C1) DNS seeding enabled by default.

C2) UPNP enabled by default in the GUI client. The percentage of bitcoin clients that accept incoming connections is quite small, and that is a problem. This should help. bitcoind, and unofficial builds, are unchanged (though we encourage use of "-upnp" to help the network!)

C3) Initial unit testing framework. Bitcoin sorely needs automated tests, and this is a beginning. Contributions welcome.

C4) Internal wallet code cleanup. While invisible to an end user, this change provides the basis for v0.4's wallet encryption.

===0.3.23<ref>[https://bitcointalk.org/index.php?topic=16553.0 0.3.23 release announcement]</ref>===
Win32, Linux, MacOSX and source releases for bitcoin v0.3.23 have been uploaded to
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.23/

This is another quick bugfix release, trying to deal with the influx of new bitcoin users.

Main items of note:

* P2P connect-to-node logic changed to reduce timeout a bit. The network saw a huge influx of new users, who do not permit incoming connections. This change is a short-term hack, to more quickly hunt for useful P2P connections. Better "leaf node" logic is in the works, but this should let us limp along until then. One may use -upnp to properly forward ports, and help the network.
* Transaction fee reduced to 0.0005 for new transactions
* Client will relay transactions with fees as low as 0.0001 BTC

===0.3.22<ref>[https://bitcointalk.org/index.php?topic=12269.0 0.3.22 release announcement]</ref>===
Download URL: https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.22/

This is largely a bugfix and TX fee schedule release. We also hope to make 0.3.23 a quick release, to fix problems that the network has seen due to explosive growth in the past week.

Notable changes:
* Client will accept and relay TX's with 0.0005 BTC fee schedule (users still pay 0.01 BTC per kb, until next version)
* Non-standard transactions accepted on testnet
* Source code tree reorganized (prep for autotools build)
* Remove "Generate Coins" option from GUI, and remove 4way SSE miner. Internal reference CPU miner remains available, but users are directed to external miners for best hash production.
* IRC is overflowing. Client now bootstraps to channels #bitcoin00 - #bitcoin99
* DNS names now may be used with -addnode, -connect (requires -dns to enable)

RPC changes:
* 'listtransactions' adds 'from' param, for range queries
* 'move' may take account balances negative
* 'settxfee' added, to manually set TX fee

===0.3.21<ref>[https://bitcointalk.org/index.php?topic=6642.0 0.3.21 release announcement]</ref>===
Binaries for Bitcoin version 0.3.21 are available at:
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.21/

Changes and new features from the 0.3.20 release include:

* Universal Plug and Play support. Enable automatic opening of a port for incoming connections by running bitcoin or bitcoind with the - -upnp=1 command line switch or using the Options dialog box.

* Support for full-precision bitcoin amounts. You can now send, and bitcoin will display, bitcoin amounts smaller than 0.01. However, sending fewer than 0.01 bitcoins still requires a 0.01 bitcoin fee (so you can send 1.0001 bitcoins without a fee, but you will be asked to pay a fee if you try to send 0.0001).

* A new method of finding bitcoin nodes to connect with, via DNS A records. Use the -dnsseed option to enable.

For developers, changes to bitcoin's remote-procedure-call API:

* New rpc command "sendmany" to send bitcoins to more than one address in a single transaction.

* Several bug fixes, including a serious intermittent bug that would sometimes cause bitcoind to stop accepting rpc requests.

* -logtimestamps option, to add a timestamp to each line in debug.log.

* Immature blocks (newly generated, under 120 confirmations) are now shown in listtransactions.

===0.3.20.2<ref>[https://bitcointalk.org/index.php?topic=4167.0 0.3.20.2 release announcement]</ref>===
The maxsendbuffer bug (0.3.20.1 clients not being able to download the block chain from other 0.3.20.1 clients) was only going to get
worse as people upgraded, so I cherry-picked the bug fix and created a minor release yesterday.

The Amazon Machine Images I used to do the builds are available:

ami-38a05251 Bitcoin-v0.3.20.2 Mingw (Windows; Administrator password 'bitcoin development')
ami-30a05259 Bitcoin_0.3.20.2 Linux32
ami-8abc4ee3 Bitcoin_0.3.20.2 Linux64

(mac build will be done soon)

If you have already downloaded version 0.3.20.1, please either add this to your bitcoin.conf file:

maxsendbuffer=10000
maxreceivebuffer=10000

... or download the new version.

===0.3.20.1===
(No known forum post.)

===0.3.20<ref>[https://bitcointalk.org/index.php?topic=2953.0 0.3.20 release announcement]</ref>===
Please checkout the git integration branch from:

https://github.com/bitcoin/bitcoin

... and help test. The new features that need testing are:

* -nolisten : https://github.com/bitcoin/bitcoin/pull/11
* -rescan : scan block chain for missing wallet transactions
* -printtoconsole : https://github.com/bitcoin/bitcoin/pull/37
* RPC gettransaction details : https://github.com/bitcoin/bitcoin/pull/24
* listtransactions new features : https://github.com/bitcoin/bitcoin/pull/10

Bug fixes that also need testing:

* -maxconnections= : https://github.com/bitcoin/bitcoin/pull/42
* RPC listaccounts minconf : https://github.com/bitcoin/bitcoin/pull/27
* RPC move, add time to output : https://github.com/bitcoin/bitcoin/pull/21
* ...and several improvements to --help output.

This needs more testing on Windows! Please drop me a quick private message, email, or IRC message if you are able to do some testing. If you find bugs, please open an issue at:

https://github.com/bitcoin/bitcoin/issues

===0.3.19<ref>[https://bitcointalk.org/index.php?topic=2228.0 0.3.19 release announcement]</ref>===
There's more work to do on DoS, but I'm doing a quick build of what I have so far in case it's needed, before venturing into more complex ideas. The build for this is version 0.3.19.

- Added some DoS controls
As Gavin and I have said clearly before, the software is not at all resistant to DoS attack. This is one improvement, but there are still more ways to attack than I can count.

I'm leaving the -limitfreerelay part as a switch for now and it's there if you need it.

- Removed "safe mode" alerts
"safe mode" alerts was a temporary measure after the 0.3.9 overflow bug. We can say all we want that users can just run with "-disablesafemode", but it's better just not to have it for the sake of appearances. It was never intended as a long term feature. Safe mode can still be triggered by seeing a longer (greater total PoW) invalid block chain.

===0.3.18<ref>[https://bitcointalk.org/index.php?topic=2162.0 0.3.18 release announcement]</ref>===

Changes:
* Fixed a wallet.dat compatibility problem if you downgraded from 0.3.17 and then upgraded again
* IsStandard() check to only include known transaction types in blocks
* Jgarzik's optimisation to speed up the initial block download a little

The main addition in this release is the Accounts-Based JSON-RPC commands that Gavin's been working on (more details at http://www.bitcoin.org/smf/index.php?topic=1886.0).
* getaccountaddress
* sendfrom
* move
* getbalance
* listtransactions

===0.3.17<ref>[https://bitcointalk.org/index.php?topic=1946.0 0.3.17 release announcement]</ref>===

Version 0.3.17 is now available.

Changes:
* new getwork, thanks m0mchil
* added transaction fee setting in UI options menu
* free transaction limits
* sendtoaddress returns transaction id instead of "sent"
* getaccountaddress <account>

The UI transaction fee setting was easy since it was still there from 0.1.5 and all I had to do was re-enable it.

The accounts-based commands: move, sendfrom and getbalance <account> will be in the next release. We still have some more changes to make first.

===0.3.16===

Never released.

===0.3.15<ref>[https://bitcointalk.org/index.php?topic=1780.0 0.3.15 release announcement]</ref>===

* paytxfee switch is now per KB, so it adds the correct fee for large transactions
* sending avoids using coins with less than 6 confirmations if it can
* BitcoinMiner processes transactions in priority order based on age of dependencies
* make sure generation doesn't start before block 74000 downloaded
* bugfixes by Dean Gores
* testnet, keypoololdest and paytxfee added to getinfo

===0.3.14<ref>[https://bitcointalk.org/index.php?topic=1528.0 0.3.14 release announcement]</ref>===

Version 0.3.14 is now available
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.14/

Changes:
* Key pool feature for safer wallet backup
Gavin Andresen:
* TEST network mode with switch -testnet
* Option to use SSL for JSON-RPC connections on unix/osx
* validateaddress RPC command
eurekafag:
* Russian translation

===0.3.13<ref>[https://bitcointalk.org/index.php?topic=1327.0 0.3.13 release announcement]</ref>===

Version 0.3.13 is now available. You should upgrade to prevent potential problems with 0/unconfirmed transactions. Note: 0.3.13 prevents problems if you haven't already spent a 0/unconfirmed transaction, but if that already happened, you need 0.3.13.2.

Changes:
* Don't count or spend payments until they have 1 confirmation.
* Internal version number from 312 to 31300.
* Only accept transactions sent by IP address if -allowreceivebyip is specified.
* Dropped DB_PRIVATE Berkeley DB flag.
* Fix problem sending the last cent with sub-cent fractional change.
* Auto-detect whether to use 128-bit 4-way SSE2 on Linux.
Gavin Andresen:
* Option -rpcallowip= to accept json-rpc connections from another machine.
* Clean shutdown on SIGTERM on Linux.

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.13/

(Thanks Laszlo for the Mac OSX build!)

Note:
The SSE2 auto-detect in the Linux 64-bit version doesn't work with AMD in 64-bit mode. Please try this instead and let me know if it gets it right:
http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gz

You can still control the SSE2 use manually with -4way and -4way=0.

Version 0.3.13.2 (SVN rev 161) has improvements for the case where you already had 0/unconfirmed transactions that you might have already spent. Here's a Windows build of it:
http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe

===0.3.12<ref>[https://bitcointalk.org/index.php?topic=999.0 0.3.12 release announcement]</ref>===

Version 0.3.12 is now available.

Features:
* json-rpc errors return a more standard error object. (thanks to Gavin Andresen)
* json-rpc command line returns exit codes.
* json-rpc "backupwallet" command.
* Recovers and continues if an exception is caused by a message you received. Other nodes shouldn't be able to cause an exception, and it hasn't happened before, but if a way is found to cause an exception, this would keep it from being used to stop network nodes.

If you have json-rpc code that checks the contents of the error string, you need to change it to expect error objects of the form {"code":<number>,"message":<string>}, which is the standard. See this thread:
http://www.bitcoin.org/smf/index.php?topic=969.0

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.12/

=References=
<references/>

Changelog

2012-06-12T22:48:39Z

BlueMatt: 0.5.X

{{stub}}

This page aggregates the changelogs that have been posted on the forum for the Bitcoin releases.
Note that some download links are not longer valid as highly insecure versions may have been deleted, or links may have changed.

=Changelogs=

==0.5.X==
After 0.5.1, all subsequent releases are stable maintenance releases, 0.6.0 is based on 0.5.1.

===0.5.5<ref>[https://bitcointalk.org/index.php?topic=79651 0.4.6/0.5.5 release announcement]</ref>===
bitcoind and Bitcoin-Qt version 0.5.5 are now available for download at:
Windows: installer | zip (sig)
Source: tar.gz
bitcoind and Bitcoin-Qt version 0.6.0.7 are also tagged in git, but it is recommended to upgrade to 0.6.1.

These are bugfix-only releases.

Please report bugs by replying to this forum thread. Note that the 0.4.x wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr.

BUG FIXES

Version 0.6.0 allowed importing invalid "private keys", which would be unspendable; 0.6.0.7 will now verify the private key is valid, and refuse to import an invalid one
Verify status of encrypt/decrypt calls to detect failed padding
Check blocks for duplicate transactions earlier. Fixes #1167
Upgrade Windows builds to OpenSSL 1.0.1b
Set label when selecting an address that already has a label. Fixes #1080 (Bitcoin-Qt)
JSON-RPC listtransactions's from/count handling is now fixed
Optimize and fix multithreaded access, when checking whether we already know about transactions
Fix potential networking deadlock
Proper support for Growl 1.3 notifications
Display an error, rather than crashing, if encoding a QR Code failed (0.6.0.7)
Don't erroneously set "Display addresses" for users who haven't explicitly enabled it (Bitcoin-Qt)
Some non-ASCII input in JSON-RPC expecting hexadecimal may have been misinterpreted rather than rejected
Missing error condition checking added
Do not show green tick unless all known blocks are downloaded. Fixes #921 (Bitcoin-Qt)
Increase time ago of last block for "up to date" status from 30 to 90 minutes
Show a message box when runaway exception happens (Bitcoin-Qt)
Use a messagebox to display the error when -server is provided without providing a rpc password
Show error message instead of exception crash when unable to bind RPC port (Bitcoin-Qt)
Correct sign message bitcoin address tooltip. Fixes #1050 (Bitcoin-Qt)
Removed "(no label)" from QR Code dialog titlebar if we have no label (0.6.0.7)
Removed an ugly line break in tooltip for mature transactions (0.6.0.7)
Add missing tooltip and key shortcut in settings dialog (part of #1088) (Bitcoin-Qt)
Work around issue in boost::program_options that prevents from compiling in clang
Fixed bugs occurring only on platforms with unsigned characters (such as ARM).
Rename make_windows_icon.py to .sh as it is a shell script. Fixes #1099 (Bitcoin-Qt)
Various trivial internal corrections to types used for counting/size loops and warnings

===0.5.4<ref>[https://bitcointalk.org/index.php?topic=76808.0 0.5.4 release announcement]</ref>===
Bitcoin version 0.5.4 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.4/
NOTE: 0.5.4rc3 is being renamed to 0.5.4 final with no changes.

This is a bugfix-only release in the 0.5.x series, plus a few protocol updates.

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.4#.tar.gz

PROTOCOL UPDATES

BIP 16: Special-case "pay to script hash" logic to enable minimal validation of new transactions.
Support for validating message signatures produced with compressed public keys.

BUG FIXES

Build with thread-safe MingW libraries for Windows, fixing a dangerous memory corruption scenario when exceptions are thrown.
Fix broken testnet mining.
Stop excess inventory relay during initial block download.
When disconnecting a node, clear the received buffer so that we do not process any already received messages.
Yet another attempt at implementing "minimize to tray" that works on all operating systems.
Fix Bitcoin-Qt notifications under Growl 1.3.
Increase required age of Bitcoin-Qt's "not up to date" status from 30 to 90 minutes.
Implemented missing verifications that led to crash on entering some wrong passphrases for encrypted wallets.
Fix default filename suffixes in GNOME save dialog.
Make the "Send coins" tab use the configured unit type, even on the first attempt.
Print detailed wallet loading errors to debug.log when it is corrupt.
Allocate exactly the amount of space needed for signing transactions, instead of a fixed 10k buffer.
Workaround for improbable memory access violation.
Check wallet's minimum version before trying to load it.
Remove wxBitcoin properly when installing Bitcoin-Qt over it. (Windows)
Detail reorganization information better in debug log.
Use a messagebox to display the error when -server is provided without configuring a RPC password.
Testing suite build now honours provided CXXFLAGS.
Removed an extraneous line-break in mature transaction tooltips.
Fix some grammatical errors in translation process documentation.

===0.5.3<ref>[https://bitcointalk.org/index.php?topic=68895.0 0.5.3 release announcement]</ref>===
Bitcoin version 0.5.3 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.3/

This is a bugfix-only release based on 0.5.1.
It also includes a few protocol updates.

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.3#.tar.gz

PROTOCOL UPDATES

BIP 30: Introduce a new network rule: "a block is not valid if it contains a transaction whose hash already exists in the block chain, unless all that transaction's outputs were already spent before said block" beginning on March 15, 2012, 00:00 UTC.
On testnet, allow mining of min-difficulty blocks if 20 minutes have gone by without mining a regular-difficulty block. This is to make testing Bitcoin easier, and will not affect normal mode.

BUG FIXES

Limit the number of orphan transactions stored in memory, to prevent a potential denial-of-service attack by flooding orphan transactions. Also never store invalid transactions at all.
Fix possible buffer overflow on systems with very long application data paths. This is not exploitable.
Resolved multiple bugs preventing long-term unlocking of encrypted wallets
(issue #922).
Only send local IP in "version" messages if it is globally routable (ie, not private), and try to get such an IP from UPnP if applicable.
Reannounce UPnP port forwards every 20 minutes, to workaround routers expiring old entries, and allow the -upnp option to override any stored setting.
Skip splash screen when -min is used, and fix Minimize to Tray function.
Do not blank "label" in Bitcoin-Qt "Send" tab, if the user has already entered something.
Correct various labels and messages.
Various memory leaks and potential null pointer deferences have been fixed.
Handle invalid Bitcoin URIs using "bitcoin://" instead of "bitcoin:".
Several shutdown issues have been fixed.
Revert to "global progress indication", as starting from zero every time was considered too confusing for many users.
Check that keys stored in the wallet are valid at startup, and if not, report corruption.
Enable accessible widgets on Windows, so that people with screen readers such as NVDA can make sense of it.
Various build fixes.
If no password is specified to bitcoind, recommend a secure password.
Automatically focus and scroll to new "Send coins" entries in Bitcoin-Qt.
Show a message box for --help on Windows, for Bitcoin-Qt.
Add missing "About Qt" menu option to show built-in Qt About dialog.
Don't show "-daemon" as an option for Bitcoin-Qt, since it isn't available.
Update hard-coded fallback seed nodes, choosing recent ones with long uptime and versions at least 0.4.0.
Add checkpoint at block 168,000.

===0.5.2<ref>[https://bitcointalk.org/index.php?topic=60146.0 0.5.2 release announcement]</ref>===
Bitcoin version 0.5.2 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.2/

This is a bugfix-only release based on 0.5.1.

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.2#.tar.gz

BUG FIXES

Check all transactions in blocks after the last checkpoint (0.5.0 and 0.5.1 skipped checking ECDSA signatures during initial blockchain download).
Cease locking memory used by non-sensitive information (this caused a huge performance hit on some platforms, especially noticable during initial blockchain download; this was
not a security vulnerability).
Fixed some address-handling deadlocks (client freezes).
No longer accept inbound connections over the internet when Bitcoin is being used with Tor (identity leak).
Re-enable SSL support for the JSON-RPC interface (it was unintentionally disabled for the 0.5.0 and 0.5.1 release Linux binaries).
Use the correct base transaction fee of 0.0005 BTC for accepting transactions into mined blocks (since 0.4.0, it was incorrectly accepting 0.0001 BTC which was only meant to be relayed).
Don't show "IP" for transactions which are not necessarily IP transactions.
Add new DNS seeds (maintained by Pieter Wuille and Luke Dashjr).

===0.5.1<ref>[https://bitcointalk.org/index.php?topic=54717.0 0.5.1 release announcement]</ref>===
Bitcoin version 0.5.1 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.1/

This is a bugfix-only release.

This release includes 13 translations, including 5 new translations:
Italian, Hungarian, Ukranian, Portuguese (Brazilian) and Simplified Chinese.
More translations are welcome; join the project at Transifex if you can help:
https://www.transifex.net/projects/p/bitcoin/

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Project source code is hosted at github; we are no longer
distributing .tar.gz files here, you can get them
directly from github:
https://github.com/bitcoin/bitcoin/tarball/v0.5.1 # .tar.gz
https://github.com/bitcoin/bitcoin/zipball/v0.5.1 # .zip

For Ubuntu users, there is a new ppa maintained by Matt Corallo which
you can add to your system so that it will automatically keep
bitcoin up-to-date. Just type
sudo apt-add-repository ppa:bitcoin/bitcoin
in your terminal, then install the bitcoin-qt package.

BUG FIXES

Re-enable SSL support for the JSON-RPC interface (it was unintentionally
disabled for the 0.5.0 release binaries).

The code that finds peers via "dns seeds" no longer stops bitcoin startup
if one of the dns seed machines is down.

Tooltips on the transaction list view were rendering incorrectly (as black boxes
or with a transparent background).

Prevent a denial-of-service attack involving flooding a bitcoin node with
orphan blocks.

The wallet passphrase dialog now warns you if the caps lock key was pressed.

Improved searching in addresses and labels in bitcoin-qt.

===0.5.0<ref>[https://bitcointalk.org/index.php?topic=52480.0 0.5.0 release announcement]</ref>===
Bitcoin version 0.5.0 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.0/

The major change for this release is a completely new graphical interface that uses the Qt user interface toolkit.

This release include German, Spanish, Spanish-Castilian, Norwegian and Dutch translations. More translations are welcome; join the project at Transifex if you can help:
https://www.transifex.net/projects/p/bitcoin/

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

For Ubuntu users, there is a new ppa maintained by Matt Corallo which you can add to your system so that it will automatically keep bitcoin up-to-date. Just type "sudo apt-add-repository ppa:bitcoin/bitcoin" in your terminal, then install the bitcoin-qt package.

MAJOR BUG FIX (CVE-2011-4447)

The wallet encryption feature introduced in Bitcoin version 0.4.0 did not sufficiently secure the private keys. An attacker who
managed to get a copy of your encrypted wallet.dat file might be able to recover some or all of the unencrypted keys and steal the
associated coins.

If you have a previously encrypted wallet.dat, the first time you run bitcoin-qt or bitcoind the wallet will be rewritten, Bitcoin will
shut down, and you will be prompted to restart it to run with the new, properly encrypted file.

If you had a previously encrypted wallet.dat that might have been copied or stolen (for example, you backed it up to a public
location) you should send all of your bitcoins to yourself using a new bitcoin address and stop using any previously generated addresses.

Wallets encrypted with this version of Bitcoin are written properly.

Technical note: the encrypted wallet's 'keypool' will be regenerated the first time you request a new bitcoin address; to be certain that the
new private keys are properly backed up you should:

1. Run Bitcoin and let it rewrite the wallet.dat file

2. Run it again, then ask it for a new bitcoin address.
Bitcoin-Qt: Address Book, then New Address...
bitcoind: run the 'walletpassphrase' RPC command to unlock the wallet, then run the 'getnewaddress' RPC command.

3. If your encrypted wallet.dat may have been copied or stolen, send all of your bitcoins to the new bitcoin address.

4. Shut down Bitcoin, then backup the wallet.dat file.
IMPORTANT: be sure to request a new bitcoin address before backing up, so that the 'keypool' is regenerated and backed up.

"Security in depth" is always a good idea, so choosing a secure location for the backup and/or encrypting the backup before uploading it is recommended. And as in previous releases, if your machine is infected by malware there are several ways an attacker might steal your bitcoins.

Thanks to Alan Reiner (etotheipi) for finding and reporting this bug.

MAJOR GUI CHANGES

"Splash" graphics at startup that show address/wallet/blockchain loading progress.

"Synchronizing with network" progress bar to show block-chain download progress.

Icons at the bottom of the window that show how well connected you are to the network, with tooltips to display details.

Drag and drop support for bitcoin: URIs on web pages.

Export transactions as a .csv file.

Many other GUI improvements, large and small.

RPC CHANGES

getmemorypool : new RPC command, provides everything needed to construct a block with a custom generation transaction and submit a solution

listsinceblock : new RPC command, list transactions since given block

signmessage/verifymessage : new RPC commands to sign a message with one of your private keys or verify that a message signed by the private key associated with a bitcoin address.

GENERAL CHANGES

Faster initial block download.

==0.4.X==
After 0.4.0, all subsequent releases are stable maintenance releases, 0.5.0 is based on 0.4.0.

===0.4.6<ref>[https://bitcointalk.org/index.php?topic=79651 0.4.6/0.5.5 release announcement]</ref>===
bitcoind version 0.4.6 is now available for download at:
Windows: installer | zip (sig)
Source: tar.gz
bitcoind and Bitcoin-Qt version 0.6.0.7 are also tagged in git, but it is recommended to upgrade to 0.6.1.

These are bugfix-only releases.

Please report bugs by replying to this forum thread. Note that the 0.4.x wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr.

BUG FIXES

Version 0.6.0 allowed importing invalid "private keys", which would be unspendable; 0.6.0.7 will now verify the private key is valid, and refuse to import an invalid one
Verify status of encrypt/decrypt calls to detect failed padding
Check blocks for duplicate transactions earlier. Fixes #1167
Upgrade Windows builds to OpenSSL 1.0.1b
Set label when selecting an address that already has a label. Fixes #1080 (Bitcoin-Qt)
JSON-RPC listtransactions's from/count handling is now fixed
Optimize and fix multithreaded access, when checking whether we already know about transactions
Fix potential networking deadlock
Proper support for Growl 1.3 notifications
Display an error, rather than crashing, if encoding a QR Code failed (0.6.0.7)
Don't erroneously set "Display addresses" for users who haven't explicitly enabled it (Bitcoin-Qt)
Some non-ASCII input in JSON-RPC expecting hexadecimal may have been misinterpreted rather than rejected
Missing error condition checking added
Do not show green tick unless all known blocks are downloaded. Fixes #921 (Bitcoin-Qt)
Increase time ago of last block for "up to date" status from 30 to 90 minutes
Show a message box when runaway exception happens (Bitcoin-Qt)
Use a messagebox to display the error when -server is provided without providing a rpc password
Show error message instead of exception crash when unable to bind RPC port (Bitcoin-Qt)
Correct sign message bitcoin address tooltip. Fixes #1050 (Bitcoin-Qt)
Removed "(no label)" from QR Code dialog titlebar if we have no label (0.6.0.7)
Removed an ugly line break in tooltip for mature transactions (0.6.0.7)
Add missing tooltip and key shortcut in settings dialog (part of #1088) (Bitcoin-Qt)
Work around issue in boost::program_options that prevents from compiling in clang
Fixed bugs occurring only on platforms with unsigned characters (such as ARM).
Rename make_windows_icon.py to .sh as it is a shell script. Fixes #1099 (Bitcoin-Qt)
Various trivial internal corrections to types used for counting/size loops and warnings

===0.4.5===
(No known forum post.)

===0.4.4<ref>[https://bitcointalk.org/index.php?topic=70566.0 0.4.4 release announcement]</ref>===
Bitcoin version 0.4.4 is now available for download at:
http://luke.dashjr.org/programs/bitcoin/files/bitcoind-0.4.4/

This is a bugfix-only release based on 0.4.0.

Please note that the wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr.

Please report bugs for the daemon only using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.4.4#.tar.gz

BUG FIXES

Limit the number of orphan transactions stored in memory, to prevent a potential denial-of-service attack by flooding orphan transactions. Also never store invalid transactions at all.
Fix possible buffer overflow on systems with very long application data paths. This is not exploitable.
Resolved multiple bugs preventing long-term unlocking of encrypted wallets (issue #922).
Only send local IP in "version" messages if it is globally routable (ie, not private), and try to get such an IP from UPnP if applicable.
Reannounce UPnP port forwards every 20 minutes, to workaround routers expiring old entries, and allow the -upnp option to override any stored setting.
Various memory leaks and potential null pointer deferences have been
fixed.
Several shutdown issues have been fixed.
Check that keys stored in the wallet are valid at startup, and if not,
report corruption.
Various build fixes.
If no password is specified to bitcoind, recommend a secure password.
Update hard-coded fallback seed nodes, choosing recent ones with long uptime and versions at least 0.4.0.
Add checkpoint at block 168,000.

===0.4.3<ref>[https://bitcointalk.org/index.php?topic=57734.0 0.4.3 release announcement]</ref>===
bitcoind version 0.4.3 is now available for download at:
http://luke.dashjr.org/programs/bitcoin/files/bitcoind-0.4.3/ (until Gavin uploads to SourceForge)

This is a bugfix-only release based on 0.4.0.

Please note that the wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr.

Please report bugs for the daemon only using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.4.3#.tar.gz

BUG FIXES

Cease locking memory used by non-sensitive information (this caused a huge performance hit on some platforms, especially noticable during initial blockchain download).
Fixed some address-handling deadlocks (client freezes).
No longer accept inbound connections over the internet when Bitcoin is being used with Tor (identity leak).
Use the correct base transaction fee of 0.0005 BTC for accepting transactions into mined blocks (since 0.4.0, it was incorrectly accepting 0.0001 BTC which was only meant to be relayed).
Add new DNS seeds (maintained by Pieter Wuille and Luke Dashjr).

===0.4.2===
(No known forum post.)

===0.4.1<ref>[https://bitcointalk.org/index.php?topic=52503.0 0.4.1 release announcement]</ref>===
Bitcoin version 0.4.1 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.4.1/

This is a bugfix only release based on 0.4.0.

Please report bugs by replying to this forum thread.

MAJOR BUG FIX (CVE-2011-4447)

The wallet encryption feature introduced in Bitcoin version 0.4.0 did not sufficiently secure the private keys. An attacker who
managed to get a copy of your encrypted wallet.dat file might be able to recover some or all of the unencrypted keys and steal the
associated coins.

If you have a previously encrypted wallet.dat, the first time you run wxbitcoin or bitcoind the wallet will be rewritten, Bitcoin will
shut down, and you will be prompted to restart it to run with the new, properly encrypted file.

If you had a previously encrypted wallet.dat that might have been copied or stolen (for example, you backed it up to a public
location) you should send all of your bitcoins to yourself using a new bitcoin address and stop using any previously generated addresses.

Wallets encrypted with this version of Bitcoin are written properly.

Technical note: the encrypted wallet's 'keypool' will be regenerated the first time you request a new bitcoin address; to be certain that the
new private keys are properly backed up you should:

1. Run Bitcoin and let it rewrite the wallet.dat file

2. Run it again, then ask it for a new bitcoin address.
wxBitcoin: new address visible on main window
bitcoind: run the 'walletpassphrase' RPC command to unlock the wallet, then run the 'getnewaddress' RPC command.

3. If your encrypted wallet.dat may have been copied or stolen, send all of your bitcoins to the new bitcoin address.

4. Shut down Bitcoin, then backup the wallet.dat file.
IMPORTANT: be sure to request a new bitcoin address before backing up, so that the 'keypool' is regenerated and backed up.

"Security in depth" is always a good idea, so choosing a secure location for the backup and/or encrypting the backup before uploading it is recommended. And as in previous releases, if your machine is infected by malware there are several ways an attacker might steal your bitcoins.

Thanks to Alan Reiner (etotheipi) for finding and reporting this bug.

===0.4.0<ref>[https://bitcointalk.org/index.php?topic=45410.0 0.4 release announcement]</ref>===
Bitcoin version 0.4.0 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.4.0/

The main feature in this release is wallet private key encryption;
you can set a passphrase that must be entered before sending coins.
See below for more information; if you decide to encrypt your wallet,
WRITE DOWN YOUR PASSPHRASE AND PUT IT IN A SECURE LOCATION. If you
forget or lose your wallet passphrase, you lose your bitcoins.
Previous versions of bitcoin are unable to read encrypted wallets,
and will crash on startup if the wallet is encrypted.

Also note: bitcoin version 0.4 uses a newer version of Berkeley DB
(bdb version 4.8) than previous versions (bdb 4.7). If you upgrade
to version 0.4 and then revert back to an earlier version of bitcoin
the it may be unable to start because bdb 4.7 cannot read bdb 4.8
"log" files.

Notable bug fixes from version 0.3.24:

Fix several bitcoin-becomes-unresponsive bugs due to multithreading
deadlocks.

Optimize database writes for large (lots of inputs) transactions
(fixes a potential denial-of-service attack)

Wallet Encryption

Bitcoin supports native wallet encryption so that people who steal your
wallet file don't automatically get access to all of your Bitcoins.
In order to enable this feature, choose "Encrypt Wallet" from the
Options menu. You will be prompted to enter a passphrase, which
will be used as the key to encrypt your wallet and will be needed
every time you wish to send Bitcoins. If you lose this passphrase,
you will lose access to spend all of the bitcoins in your wallet,
no one, not even the Bitcoin developers can recover your Bitcoins.
This means you are responsible for your own security, store your
passphrase in a secure location and do not forget it.

Remember that the encryption built into bitcoin only encrypts the
actual keys which are required to send your bitcoins, not the full
wallet. This means that someone who steals your wallet file will
be able to see all the addresses which belong to you, as well as the
relevant transactions, you are only protected from someone spending
your coins.

It is recommended that you backup your wallet file before you
encrypt your wallet. To do this, close the Bitcoin client and
copy the wallet.dat file from ~/.bitcoin/ on Linux, /Users/(user
name)/Application Support/Bitcoin/ on Mac OSX, and %APPDATA%/Bitcoin/
on Windows (that is /Users/(user name)/AppData/Roaming/Bitcoin on
Windows Vista and 7 and /Documents and Settings/(user name)/Application
Data/Bitcoin on Windows XP). Once you have copied that file to a
safe location, reopen the Bitcoin client and Encrypt your wallet.
If everything goes fine, delete the backup and enjoy your encrypted
wallet. Note that once you encrypt your wallet, you will never be
able to go back to a version of the Bitcoin client older than 0.4.

Keep in mind that you are always responsible for your own security.
All it takes is a slightly more advanced wallet-stealing trojan which
installs a keylogger to steal your wallet passphrase as you enter it
in addition to your wallet file and you have lost all your Bitcoins.
Wallet encryption cannot keep you safe if you do not practice
good security, such as running up-to-date antivirus software, only
entering your wallet passphrase in the Bitcoin client and using the
same passphrase only as your wallet passphrase.

See the doc/README file in the bitcoin source for technical details
of wallet encryption.

==0.3.X==

===0.3.24<ref>[https://bitcointalk.org/index.php?topic=27187.0 0.3.24 release announcement]</ref>===
Bitcoin v0.3.24 is now available for download at
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.24/

This is another bug fix release. We had hoped to have wallet encryption ready for release, but more urgent fixes for existing clients were needed -- most notably block download problems were getting severe. Wallet encryption is ready for testing at https://github.com/bitcoin/bitcoin/pull/352 for the git-savvy, and hopefully will follow shortly in the next release, v0.4.

Notable fixes in v0.3.24, and the main reasons for this release:

F1) Block downloads were failing or taking unreasonable amounts of time to complete, because the increased size of the block chain was bumping up against some earlier buffer-size DoS limits.

F2) Fix crash caused by loss/lack of network connection.

Notable changes in v0.3.24:

C1) DNS seeding enabled by default.

C2) UPNP enabled by default in the GUI client. The percentage of bitcoin clients that accept incoming connections is quite small, and that is a problem. This should help. bitcoind, and unofficial builds, are unchanged (though we encourage use of "-upnp" to help the network!)

C3) Initial unit testing framework. Bitcoin sorely needs automated tests, and this is a beginning. Contributions welcome.

C4) Internal wallet code cleanup. While invisible to an end user, this change provides the basis for v0.4's wallet encryption.

===0.3.23<ref>[https://bitcointalk.org/index.php?topic=16553.0 0.3.23 release announcement]</ref>===
Win32, Linux, MacOSX and source releases for bitcoin v0.3.23 have been uploaded to
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.23/

This is another quick bugfix release, trying to deal with the influx of new bitcoin users.

Main items of note:

* P2P connect-to-node logic changed to reduce timeout a bit. The network saw a huge influx of new users, who do not permit incoming connections. This change is a short-term hack, to more quickly hunt for useful P2P connections. Better "leaf node" logic is in the works, but this should let us limp along until then. One may use -upnp to properly forward ports, and help the network.
* Transaction fee reduced to 0.0005 for new transactions
* Client will relay transactions with fees as low as 0.0001 BTC

===0.3.22<ref>[https://bitcointalk.org/index.php?topic=12269.0 0.3.22 release announcement]</ref>===
Download URL: https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.22/

This is largely a bugfix and TX fee schedule release. We also hope to make 0.3.23 a quick release, to fix problems that the network has seen due to explosive growth in the past week.

Notable changes:
* Client will accept and relay TX's with 0.0005 BTC fee schedule (users still pay 0.01 BTC per kb, until next version)
* Non-standard transactions accepted on testnet
* Source code tree reorganized (prep for autotools build)
* Remove "Generate Coins" option from GUI, and remove 4way SSE miner. Internal reference CPU miner remains available, but users are directed to external miners for best hash production.
* IRC is overflowing. Client now bootstraps to channels #bitcoin00 - #bitcoin99
* DNS names now may be used with -addnode, -connect (requires -dns to enable)

RPC changes:
* 'listtransactions' adds 'from' param, for range queries
* 'move' may take account balances negative
* 'settxfee' added, to manually set TX fee

===0.3.21<ref>[https://bitcointalk.org/index.php?topic=6642.0 0.3.21 release announcement]</ref>===
Binaries for Bitcoin version 0.3.21 are available at:
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.21/

Changes and new features from the 0.3.20 release include:

* Universal Plug and Play support. Enable automatic opening of a port for incoming connections by running bitcoin or bitcoind with the - -upnp=1 command line switch or using the Options dialog box.

* Support for full-precision bitcoin amounts. You can now send, and bitcoin will display, bitcoin amounts smaller than 0.01. However, sending fewer than 0.01 bitcoins still requires a 0.01 bitcoin fee (so you can send 1.0001 bitcoins without a fee, but you will be asked to pay a fee if you try to send 0.0001).

* A new method of finding bitcoin nodes to connect with, via DNS A records. Use the -dnsseed option to enable.

For developers, changes to bitcoin's remote-procedure-call API:

* New rpc command "sendmany" to send bitcoins to more than one address in a single transaction.

* Several bug fixes, including a serious intermittent bug that would sometimes cause bitcoind to stop accepting rpc requests.

* -logtimestamps option, to add a timestamp to each line in debug.log.

* Immature blocks (newly generated, under 120 confirmations) are now shown in listtransactions.

===0.3.20.2<ref>[https://bitcointalk.org/index.php?topic=4167.0 0.3.20.2 release announcement]</ref>===
The maxsendbuffer bug (0.3.20.1 clients not being able to download the block chain from other 0.3.20.1 clients) was only going to get
worse as people upgraded, so I cherry-picked the bug fix and created a minor release yesterday.

The Amazon Machine Images I used to do the builds are available:

ami-38a05251 Bitcoin-v0.3.20.2 Mingw (Windows; Administrator password 'bitcoin development')
ami-30a05259 Bitcoin_0.3.20.2 Linux32
ami-8abc4ee3 Bitcoin_0.3.20.2 Linux64

(mac build will be done soon)

If you have already downloaded version 0.3.20.1, please either add this to your bitcoin.conf file:

maxsendbuffer=10000
maxreceivebuffer=10000

... or download the new version.

===0.3.20.1===
(No known forum post.)

===0.3.20<ref>[https://bitcointalk.org/index.php?topic=2953.0 0.3.20 release announcement]</ref>===
Please checkout the git integration branch from:

https://github.com/bitcoin/bitcoin

... and help test. The new features that need testing are:

* -nolisten : https://github.com/bitcoin/bitcoin/pull/11
* -rescan : scan block chain for missing wallet transactions
* -printtoconsole : https://github.com/bitcoin/bitcoin/pull/37
* RPC gettransaction details : https://github.com/bitcoin/bitcoin/pull/24
* listtransactions new features : https://github.com/bitcoin/bitcoin/pull/10

Bug fixes that also need testing:

* -maxconnections= : https://github.com/bitcoin/bitcoin/pull/42
* RPC listaccounts minconf : https://github.com/bitcoin/bitcoin/pull/27
* RPC move, add time to output : https://github.com/bitcoin/bitcoin/pull/21
* ...and several improvements to --help output.

This needs more testing on Windows! Please drop me a quick private message, email, or IRC message if you are able to do some testing. If you find bugs, please open an issue at:

https://github.com/bitcoin/bitcoin/issues

===0.3.19<ref>[https://bitcointalk.org/index.php?topic=2228.0 0.3.19 release announcement]</ref>===
There's more work to do on DoS, but I'm doing a quick build of what I have so far in case it's needed, before venturing into more complex ideas. The build for this is version 0.3.19.

- Added some DoS controls
As Gavin and I have said clearly before, the software is not at all resistant to DoS attack. This is one improvement, but there are still more ways to attack than I can count.

I'm leaving the -limitfreerelay part as a switch for now and it's there if you need it.

- Removed "safe mode" alerts
"safe mode" alerts was a temporary measure after the 0.3.9 overflow bug. We can say all we want that users can just run with "-disablesafemode", but it's better just not to have it for the sake of appearances. It was never intended as a long term feature. Safe mode can still be triggered by seeing a longer (greater total PoW) invalid block chain.

===0.3.18<ref>[https://bitcointalk.org/index.php?topic=2162.0 0.3.18 release announcement]</ref>===

Changes:
* Fixed a wallet.dat compatibility problem if you downgraded from 0.3.17 and then upgraded again
* IsStandard() check to only include known transaction types in blocks
* Jgarzik's optimisation to speed up the initial block download a little

The main addition in this release is the Accounts-Based JSON-RPC commands that Gavin's been working on (more details at http://www.bitcoin.org/smf/index.php?topic=1886.0).
* getaccountaddress
* sendfrom
* move
* getbalance
* listtransactions

===0.3.17<ref>[https://bitcointalk.org/index.php?topic=1946.0 0.3.17 release announcement]</ref>===

Version 0.3.17 is now available.

Changes:
* new getwork, thanks m0mchil
* added transaction fee setting in UI options menu
* free transaction limits
* sendtoaddress returns transaction id instead of "sent"
* getaccountaddress <account>

The UI transaction fee setting was easy since it was still there from 0.1.5 and all I had to do was re-enable it.

The accounts-based commands: move, sendfrom and getbalance <account> will be in the next release. We still have some more changes to make first.

===0.3.16===

Never released.

===0.3.15<ref>[https://bitcointalk.org/index.php?topic=1780.0 0.3.15 release announcement]</ref>===

* paytxfee switch is now per KB, so it adds the correct fee for large transactions
* sending avoids using coins with less than 6 confirmations if it can
* BitcoinMiner processes transactions in priority order based on age of dependencies
* make sure generation doesn't start before block 74000 downloaded
* bugfixes by Dean Gores
* testnet, keypoololdest and paytxfee added to getinfo

===0.3.14<ref>[https://bitcointalk.org/index.php?topic=1528.0 0.3.14 release announcement]</ref>===

Version 0.3.14 is now available
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.14/

Changes:
* Key pool feature for safer wallet backup
Gavin Andresen:
* TEST network mode with switch -testnet
* Option to use SSL for JSON-RPC connections on unix/osx
* validateaddress RPC command
eurekafag:
* Russian translation

===0.3.13<ref>[https://bitcointalk.org/index.php?topic=1327.0 0.3.13 release announcement]</ref>===

Version 0.3.13 is now available. You should upgrade to prevent potential problems with 0/unconfirmed transactions. Note: 0.3.13 prevents problems if you haven't already spent a 0/unconfirmed transaction, but if that already happened, you need 0.3.13.2.

Changes:
* Don't count or spend payments until they have 1 confirmation.
* Internal version number from 312 to 31300.
* Only accept transactions sent by IP address if -allowreceivebyip is specified.
* Dropped DB_PRIVATE Berkeley DB flag.
* Fix problem sending the last cent with sub-cent fractional change.
* Auto-detect whether to use 128-bit 4-way SSE2 on Linux.
Gavin Andresen:
* Option -rpcallowip= to accept json-rpc connections from another machine.
* Clean shutdown on SIGTERM on Linux.

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.13/

(Thanks Laszlo for the Mac OSX build!)

Note:
The SSE2 auto-detect in the Linux 64-bit version doesn't work with AMD in 64-bit mode. Please try this instead and let me know if it gets it right:
http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gz

You can still control the SSE2 use manually with -4way and -4way=0.

Version 0.3.13.2 (SVN rev 161) has improvements for the case where you already had 0/unconfirmed transactions that you might have already spent. Here's a Windows build of it:
http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe

===0.3.12<ref>[https://bitcointalk.org/index.php?topic=999.0 0.3.12 release announcement]</ref>===

Version 0.3.12 is now available.

Features:
* json-rpc errors return a more standard error object. (thanks to Gavin Andresen)
* json-rpc command line returns exit codes.
* json-rpc "backupwallet" command.
* Recovers and continues if an exception is caused by a message you received. Other nodes shouldn't be able to cause an exception, and it hasn't happened before, but if a way is found to cause an exception, this would keep it from being used to stop network nodes.

If you have json-rpc code that checks the contents of the error string, you need to change it to expect error objects of the form {"code":<number>,"message":<string>}, which is the standard. See this thread:
http://www.bitcoin.org/smf/index.php?topic=969.0

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.12/

=References=
<references/>

Changelog

2012-06-12T22:30:30Z

BlueMatt: Add 0.4.X

Changelog

2012-06-12T22:09:40Z

BlueMatt: /* 0.4.00.4 release announcement */

{{stub}}

This page aggregates the changelogs that have been posted on the forum for the Bitcoin releases.

=Changelogs=

==0.4.0<ref>[https://bitcointalk.org/index.php?topic=45410.0 0.4 release announcement]</ref>==
Bitcoin version 0.4.0 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.4.0/

The main feature in this release is wallet private key encryption;
you can set a passphrase that must be entered before sending coins.
See below for more information; if you decide to encrypt your wallet,
WRITE DOWN YOUR PASSPHRASE AND PUT IT IN A SECURE LOCATION. If you
forget or lose your wallet passphrase, you lose your bitcoins.
Previous versions of bitcoin are unable to read encrypted wallets,
and will crash on startup if the wallet is encrypted.

Also note: bitcoin version 0.4 uses a newer version of Berkeley DB
(bdb version 4.8) than previous versions (bdb 4.7). If you upgrade
to version 0.4 and then revert back to an earlier version of bitcoin
the it may be unable to start because bdb 4.7 cannot read bdb 4.8
"log" files.

Notable bug fixes from version 0.3.24:

Fix several bitcoin-becomes-unresponsive bugs due to multithreading
deadlocks.

Optimize database writes for large (lots of inputs) transactions
(fixes a potential denial-of-service attack)

Wallet Encryption

Bitcoin supports native wallet encryption so that people who steal your
wallet file don't automatically get access to all of your Bitcoins.
In order to enable this feature, choose "Encrypt Wallet" from the
Options menu. You will be prompted to enter a passphrase, which
will be used as the key to encrypt your wallet and will be needed
every time you wish to send Bitcoins. If you lose this passphrase,
you will lose access to spend all of the bitcoins in your wallet,
no one, not even the Bitcoin developers can recover your Bitcoins.
This means you are responsible for your own security, store your
passphrase in a secure location and do not forget it.

Remember that the encryption built into bitcoin only encrypts the
actual keys which are required to send your bitcoins, not the full
wallet. This means that someone who steals your wallet file will
be able to see all the addresses which belong to you, as well as the
relevant transactions, you are only protected from someone spending
your coins.

It is recommended that you backup your wallet file before you
encrypt your wallet. To do this, close the Bitcoin client and
copy the wallet.dat file from ~/.bitcoin/ on Linux, /Users/(user
name)/Application Support/Bitcoin/ on Mac OSX, and %APPDATA%/Bitcoin/
on Windows (that is /Users/(user name)/AppData/Roaming/Bitcoin on
Windows Vista and 7 and /Documents and Settings/(user name)/Application
Data/Bitcoin on Windows XP). Once you have copied that file to a
safe location, reopen the Bitcoin client and Encrypt your wallet.
If everything goes fine, delete the backup and enjoy your encrypted
wallet. Note that once you encrypt your wallet, you will never be
able to go back to a version of the Bitcoin client older than 0.4.

Keep in mind that you are always responsible for your own security.
All it takes is a slightly more advanced wallet-stealing trojan which
installs a keylogger to steal your wallet passphrase as you enter it
in addition to your wallet file and you have lost all your Bitcoins.
Wallet encryption cannot keep you safe if you do not practice
good security, such as running up-to-date antivirus software, only
entering your wallet passphrase in the Bitcoin client and using the
same passphrase only as your wallet passphrase.

See the doc/README file in the bitcoin source for technical details
of wallet encryption.

==0.3.24<ref>[https://bitcointalk.org/index.php?topic=27187.0 0.3.24 release announcement]</ref>==
Bitcoin v0.3.24 is now available for download at
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.24/

This is another bug fix release. We had hoped to have wallet encryption ready for release, but more urgent fixes for existing clients were needed -- most notably block download problems were getting severe. Wallet encryption is ready for testing at https://github.com/bitcoin/bitcoin/pull/352 for the git-savvy, and hopefully will follow shortly in the next release, v0.4.

Notable fixes in v0.3.24, and the main reasons for this release:

F1) Block downloads were failing or taking unreasonable amounts of time to complete, because the increased size of the block chain was bumping up against some earlier buffer-size DoS limits.

F2) Fix crash caused by loss/lack of network connection.

Notable changes in v0.3.24:

C1) DNS seeding enabled by default.

C2) UPNP enabled by default in the GUI client. The percentage of bitcoin clients that accept incoming connections is quite small, and that is a problem. This should help. bitcoind, and unofficial builds, are unchanged (though we encourage use of "-upnp" to help the network!)

C3) Initial unit testing framework. Bitcoin sorely needs automated tests, and this is a beginning. Contributions welcome.

C4) Internal wallet code cleanup. While invisible to an end user, this change provides the basis for v0.4's wallet encryption.

==0.3.23<ref>[https://bitcointalk.org/index.php?topic=16553.0 0.3.23 release announcement]</ref>==
Win32, Linux, MacOSX and source releases for bitcoin v0.3.23 have been uploaded to
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.23/

This is another quick bugfix release, trying to deal with the influx of new bitcoin users.

Main items of note:

* P2P connect-to-node logic changed to reduce timeout a bit. The network saw a huge influx of new users, who do not permit incoming connections. This change is a short-term hack, to more quickly hunt for useful P2P connections. Better "leaf node" logic is in the works, but this should let us limp along until then. One may use -upnp to properly forward ports, and help the network.
* Transaction fee reduced to 0.0005 for new transactions
* Client will relay transactions with fees as low as 0.0001 BTC

==0.3.22<ref>[https://bitcointalk.org/index.php?topic=12269.0 0.3.22 release announcement]</ref>==
Download URL: https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.22/

This is largely a bugfix and TX fee schedule release. We also hope to make 0.3.23 a quick release, to fix problems that the network has seen due to explosive growth in the past week.

Notable changes:
* Client will accept and relay TX's with 0.0005 BTC fee schedule (users still pay 0.01 BTC per kb, until next version)
* Non-standard transactions accepted on testnet
* Source code tree reorganized (prep for autotools build)
* Remove "Generate Coins" option from GUI, and remove 4way SSE miner. Internal reference CPU miner remains available, but users are directed to external miners for best hash production.
* IRC is overflowing. Client now bootstraps to channels #bitcoin00 - #bitcoin99
* DNS names now may be used with -addnode, -connect (requires -dns to enable)

RPC changes:
* 'listtransactions' adds 'from' param, for range queries
* 'move' may take account balances negative
* 'settxfee' added, to manually set TX fee

==0.3.21<ref>[https://bitcointalk.org/index.php?topic=6642.0 0.3.21 release announcement]</ref>==
Binaries for Bitcoin version 0.3.21 are available at:
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.21/

Changes and new features from the 0.3.20 release include:

* Universal Plug and Play support. Enable automatic opening of a port for incoming connections by running bitcoin or bitcoind with the - -upnp=1 command line switch or using the Options dialog box.

* Support for full-precision bitcoin amounts. You can now send, and bitcoin will display, bitcoin amounts smaller than 0.01. However, sending fewer than 0.01 bitcoins still requires a 0.01 bitcoin fee (so you can send 1.0001 bitcoins without a fee, but you will be asked to pay a fee if you try to send 0.0001).

* A new method of finding bitcoin nodes to connect with, via DNS A records. Use the -dnsseed option to enable.

For developers, changes to bitcoin's remote-procedure-call API:

* New rpc command "sendmany" to send bitcoins to more than one address in a single transaction.

* Several bug fixes, including a serious intermittent bug that would sometimes cause bitcoind to stop accepting rpc requests.

* -logtimestamps option, to add a timestamp to each line in debug.log.

* Immature blocks (newly generated, under 120 confirmations) are now shown in listtransactions.

==0.3.20.2<ref>[https://bitcointalk.org/index.php?topic=4167.0 0.3.20.2 release announcement]</ref>==
The maxsendbuffer bug (0.3.20.1 clients not being able to download the block chain from other 0.3.20.1 clients) was only going to get
worse as people upgraded, so I cherry-picked the bug fix and created a minor release yesterday.

The Amazon Machine Images I used to do the builds are available:

ami-38a05251 Bitcoin-v0.3.20.2 Mingw (Windows; Administrator password 'bitcoin development')
ami-30a05259 Bitcoin_0.3.20.2 Linux32
ami-8abc4ee3 Bitcoin_0.3.20.2 Linux64

(mac build will be done soon)

If you have already downloaded version 0.3.20.1, please either add this to your bitcoin.conf file:

maxsendbuffer=10000
maxreceivebuffer=10000

... or download the new version.

==0.3.20.1==
(No known forum post.)

==0.3.20<ref>[https://bitcointalk.org/index.php?topic=2953.0 0.3.20 release announcement]</ref>==
Please checkout the git integration branch from:

https://github.com/bitcoin/bitcoin

... and help test. The new features that need testing are:

* -nolisten : https://github.com/bitcoin/bitcoin/pull/11
* -rescan : scan block chain for missing wallet transactions
* -printtoconsole : https://github.com/bitcoin/bitcoin/pull/37
* RPC gettransaction details : https://github.com/bitcoin/bitcoin/pull/24
* listtransactions new features : https://github.com/bitcoin/bitcoin/pull/10

Bug fixes that also need testing:

* -maxconnections= : https://github.com/bitcoin/bitcoin/pull/42
* RPC listaccounts minconf : https://github.com/bitcoin/bitcoin/pull/27
* RPC move, add time to output : https://github.com/bitcoin/bitcoin/pull/21
* ...and several improvements to --help output.

This needs more testing on Windows! Please drop me a quick private message, email, or IRC message if you are able to do some testing. If you find bugs, please open an issue at:

https://github.com/bitcoin/bitcoin/issues

==0.3.19<ref>[https://bitcointalk.org/index.php?topic=2228.0 0.3.19 release announcement]</ref>==
There's more work to do on DoS, but I'm doing a quick build of what I have so far in case it's needed, before venturing into more complex ideas. The build for this is version 0.3.19.

- Added some DoS controls
As Gavin and I have said clearly before, the software is not at all resistant to DoS attack. This is one improvement, but there are still more ways to attack than I can count.

I'm leaving the -limitfreerelay part as a switch for now and it's there if you need it.

- Removed "safe mode" alerts
"safe mode" alerts was a temporary measure after the 0.3.9 overflow bug. We can say all we want that users can just run with "-disablesafemode", but it's better just not to have it for the sake of appearances. It was never intended as a long term feature. Safe mode can still be triggered by seeing a longer (greater total PoW) invalid block chain.

==0.3.18<ref>[https://bitcointalk.org/index.php?topic=2162.0 0.3.18 release announcement]</ref>==

Changes:
* Fixed a wallet.dat compatibility problem if you downgraded from 0.3.17 and then upgraded again
* IsStandard() check to only include known transaction types in blocks
* Jgarzik's optimisation to speed up the initial block download a little

The main addition in this release is the Accounts-Based JSON-RPC commands that Gavin's been working on (more details at http://www.bitcoin.org/smf/index.php?topic=1886.0).
* getaccountaddress
* sendfrom
* move
* getbalance
* listtransactions

==0.3.17<ref>[https://bitcointalk.org/index.php?topic=1946.0 0.3.17 release announcement]</ref>==

Version 0.3.17 is now available.

Changes:
* new getwork, thanks m0mchil
* added transaction fee setting in UI options menu
* free transaction limits
* sendtoaddress returns transaction id instead of "sent"
* getaccountaddress <account>

The UI transaction fee setting was easy since it was still there from 0.1.5 and all I had to do was re-enable it.

The accounts-based commands: move, sendfrom and getbalance <account> will be in the next release. We still have some more changes to make first.

==0.3.16==

Never released.

==0.3.15<ref>[https://bitcointalk.org/index.php?topic=1780.0 0.3.15 release announcement]</ref>==

* paytxfee switch is now per KB, so it adds the correct fee for large transactions
* sending avoids using coins with less than 6 confirmations if it can
* BitcoinMiner processes transactions in priority order based on age of dependencies
* make sure generation doesn't start before block 74000 downloaded
* bugfixes by Dean Gores
* testnet, keypoololdest and paytxfee added to getinfo

==0.3.14<ref>[https://bitcointalk.org/index.php?topic=1528.0 0.3.14 release announcement]</ref>==

Version 0.3.14 is now available
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.14/

Changes:
* Key pool feature for safer wallet backup
Gavin Andresen:
* TEST network mode with switch -testnet
* Option to use SSL for JSON-RPC connections on unix/osx
* validateaddress RPC command
eurekafag:
* Russian translation

==0.3.13<ref>[https://bitcointalk.org/index.php?topic=1327.0 0.3.13 release announcement]</ref>==

Version 0.3.13 is now available. You should upgrade to prevent potential problems with 0/unconfirmed transactions. Note: 0.3.13 prevents problems if you haven't already spent a 0/unconfirmed transaction, but if that already happened, you need 0.3.13.2.

Changes:
* Don't count or spend payments until they have 1 confirmation.
* Internal version number from 312 to 31300.
* Only accept transactions sent by IP address if -allowreceivebyip is specified.
* Dropped DB_PRIVATE Berkeley DB flag.
* Fix problem sending the last cent with sub-cent fractional change.
* Auto-detect whether to use 128-bit 4-way SSE2 on Linux.
Gavin Andresen:
* Option -rpcallowip= to accept json-rpc connections from another machine.
* Clean shutdown on SIGTERM on Linux.

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.13/

(Thanks Laszlo for the Mac OSX build!)

Note:
The SSE2 auto-detect in the Linux 64-bit version doesn't work with AMD in 64-bit mode. Please try this instead and let me know if it gets it right:
http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gz

You can still control the SSE2 use manually with -4way and -4way=0.

Version 0.3.13.2 (SVN rev 161) has improvements for the case where you already had 0/unconfirmed transactions that you might have already spent. Here's a Windows build of it:
http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe

==0.3.12<ref>[https://bitcointalk.org/index.php?topic=999.0 0.3.12 release announcement]</ref>==

Version 0.3.12 is now available.

Features:
* json-rpc errors return a more standard error object. (thanks to Gavin Andresen)
* json-rpc command line returns exit codes.
* json-rpc "backupwallet" command.
* Recovers and continues if an exception is caused by a message you received. Other nodes shouldn't be able to cause an exception, and it hasn't happened before, but if a way is found to cause an exception, this would keep it from being used to stop network nodes.

If you have json-rpc code that checks the contents of the error string, you need to change it to expect error objects of the form {"code":<number>,"message":<string>}, which is the standard. See this thread:
http://www.bitcoin.org/smf/index.php?topic=969.0

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.12/

=References=
<references/>

Changelog

2012-06-12T22:09:21Z

BlueMatt: Fix Formatting

Changelog

2012-06-12T22:08:45Z

BlueMatt: Add 0.4

{{stub}}

This page aggregates the changelogs that have been posted on the forum for the Bitcoin releases.

=Changelogs=

==0.4.0<ref>[https://bitcointalk.org/index.php?topic=45410.0 0.4 release announcement]</ref>==
Bitcoin version 0.4.0 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.4.0/

The main feature in this release is wallet private key encryption;
you can set a passphrase that must be entered before sending coins.
See below for more information; if you decide to encrypt your wallet,
WRITE DOWN YOUR PASSPHRASE AND PUT IT IN A SECURE LOCATION. If you
forget or lose your wallet passphrase, you lose your bitcoins.
Previous versions of bitcoin are unable to read encrypted wallets,
and will crash on startup if the wallet is encrypted.

Also note: bitcoin version 0.4 uses a newer version of Berkeley DB
(bdb version 4.8) than previous versions (bdb 4.7). If you upgrade
to version 0.4 and then revert back to an earlier version of bitcoin
the it may be unable to start because bdb 4.7 cannot read bdb 4.8
"log" files.

Notable bug fixes from version 0.3.24:
--------------------------------------

Fix several bitcoin-becomes-unresponsive bugs due to multithreading
deadlocks.

Optimize database writes for large (lots of inputs) transactions
(fixes a potential denial-of-service attack)

Wallet Encryption
-----------------
Bitcoin supports native wallet encryption so that people who steal your
wallet file don't automatically get access to all of your Bitcoins.
In order to enable this feature, choose "Encrypt Wallet" from the
Options menu. You will be prompted to enter a passphrase, which
will be used as the key to encrypt your wallet and will be needed
every time you wish to send Bitcoins. If you lose this passphrase,
you will lose access to spend all of the bitcoins in your wallet,
no one, not even the Bitcoin developers can recover your Bitcoins.
This means you are responsible for your own security, store your
passphrase in a secure location and do not forget it.

Remember that the encryption built into bitcoin only encrypts the
actual keys which are required to send your bitcoins, not the full
wallet. This means that someone who steals your wallet file will
be able to see all the addresses which belong to you, as well as the
relevant transactions, you are only protected from someone spending
your coins.

It is recommended that you backup your wallet file before you
encrypt your wallet. To do this, close the Bitcoin client and
copy the wallet.dat file from ~/.bitcoin/ on Linux, /Users/(user
name)/Application Support/Bitcoin/ on Mac OSX, and %APPDATA%/Bitcoin/
on Windows (that is /Users/(user name)/AppData/Roaming/Bitcoin on
Windows Vista and 7 and /Documents and Settings/(user name)/Application
Data/Bitcoin on Windows XP). Once you have copied that file to a
safe location, reopen the Bitcoin client and Encrypt your wallet.
If everything goes fine, delete the backup and enjoy your encrypted
wallet. Note that once you encrypt your wallet, you will never be
able to go back to a version of the Bitcoin client older than 0.4.

Keep in mind that you are always responsible for your own security.
All it takes is a slightly more advanced wallet-stealing trojan which
installs a keylogger to steal your wallet passphrase as you enter it
in addition to your wallet file and you have lost all your Bitcoins.
Wallet encryption cannot keep you safe if you do not practice
good security, such as running up-to-date antivirus software, only
entering your wallet passphrase in the Bitcoin client and using the
same passphrase only as your wallet passphrase.

See the doc/README file in the bitcoin source for technical details
of wallet encryption.

==0.3.24<ref>[https://bitcointalk.org/index.php?topic=27187.0 0.3.24 release announcement]</ref>==
Bitcoin v0.3.24 is now available for download at
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.24/

This is another bug fix release. We had hoped to have wallet encryption ready for release, but more urgent fixes for existing clients were needed -- most notably block download problems were getting severe. Wallet encryption is ready for testing at https://github.com/bitcoin/bitcoin/pull/352 for the git-savvy, and hopefully will follow shortly in the next release, v0.4.

Notable fixes in v0.3.24, and the main reasons for this release:

F1) Block downloads were failing or taking unreasonable amounts of time to complete, because the increased size of the block chain was bumping up against some earlier buffer-size DoS limits.

F2) Fix crash caused by loss/lack of network connection.

Notable changes in v0.3.24:

C1) DNS seeding enabled by default.

C2) UPNP enabled by default in the GUI client. The percentage of bitcoin clients that accept incoming connections is quite small, and that is a problem. This should help. bitcoind, and unofficial builds, are unchanged (though we encourage use of "-upnp" to help the network!)

C3) Initial unit testing framework. Bitcoin sorely needs automated tests, and this is a beginning. Contributions welcome.

C4) Internal wallet code cleanup. While invisible to an end user, this change provides the basis for v0.4's wallet encryption.

==0.3.23<ref>[https://bitcointalk.org/index.php?topic=16553.0 0.3.23 release announcement]</ref>==
Win32, Linux, MacOSX and source releases for bitcoin v0.3.23 have been uploaded to
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.23/

This is another quick bugfix release, trying to deal with the influx of new bitcoin users.

Main items of note:

* P2P connect-to-node logic changed to reduce timeout a bit. The network saw a huge influx of new users, who do not permit incoming connections. This change is a short-term hack, to more quickly hunt for useful P2P connections. Better "leaf node" logic is in the works, but this should let us limp along until then. One may use -upnp to properly forward ports, and help the network.
* Transaction fee reduced to 0.0005 for new transactions
* Client will relay transactions with fees as low as 0.0001 BTC

==0.3.22<ref>[https://bitcointalk.org/index.php?topic=12269.0 0.3.22 release announcement]</ref>==
Download URL: https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.22/

This is largely a bugfix and TX fee schedule release. We also hope to make 0.3.23 a quick release, to fix problems that the network has seen due to explosive growth in the past week.

Notable changes:
* Client will accept and relay TX's with 0.0005 BTC fee schedule (users still pay 0.01 BTC per kb, until next version)
* Non-standard transactions accepted on testnet
* Source code tree reorganized (prep for autotools build)
* Remove "Generate Coins" option from GUI, and remove 4way SSE miner. Internal reference CPU miner remains available, but users are directed to external miners for best hash production.
* IRC is overflowing. Client now bootstraps to channels #bitcoin00 - #bitcoin99
* DNS names now may be used with -addnode, -connect (requires -dns to enable)

RPC changes:
* 'listtransactions' adds 'from' param, for range queries
* 'move' may take account balances negative
* 'settxfee' added, to manually set TX fee

==0.3.21<ref>[https://bitcointalk.org/index.php?topic=6642.0 0.3.21 release announcement]</ref>==
Binaries for Bitcoin version 0.3.21 are available at:
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.21/

Changes and new features from the 0.3.20 release include:

* Universal Plug and Play support. Enable automatic opening of a port for incoming connections by running bitcoin or bitcoind with the - -upnp=1 command line switch or using the Options dialog box.

* Support for full-precision bitcoin amounts. You can now send, and bitcoin will display, bitcoin amounts smaller than 0.01. However, sending fewer than 0.01 bitcoins still requires a 0.01 bitcoin fee (so you can send 1.0001 bitcoins without a fee, but you will be asked to pay a fee if you try to send 0.0001).

* A new method of finding bitcoin nodes to connect with, via DNS A records. Use the -dnsseed option to enable.

For developers, changes to bitcoin's remote-procedure-call API:

* New rpc command "sendmany" to send bitcoins to more than one address in a single transaction.

* Several bug fixes, including a serious intermittent bug that would sometimes cause bitcoind to stop accepting rpc requests.

* -logtimestamps option, to add a timestamp to each line in debug.log.

* Immature blocks (newly generated, under 120 confirmations) are now shown in listtransactions.

==0.3.20.2<ref>[https://bitcointalk.org/index.php?topic=4167.0 0.3.20.2 release announcement]</ref>==
The maxsendbuffer bug (0.3.20.1 clients not being able to download the block chain from other 0.3.20.1 clients) was only going to get
worse as people upgraded, so I cherry-picked the bug fix and created a minor release yesterday.

The Amazon Machine Images I used to do the builds are available:

ami-38a05251 Bitcoin-v0.3.20.2 Mingw (Windows; Administrator password 'bitcoin development')
ami-30a05259 Bitcoin_0.3.20.2 Linux32
ami-8abc4ee3 Bitcoin_0.3.20.2 Linux64

(mac build will be done soon)

If you have already downloaded version 0.3.20.1, please either add this to your bitcoin.conf file:

maxsendbuffer=10000
maxreceivebuffer=10000

... or download the new version.

==0.3.20.1==
(No known forum post.)

==0.3.20<ref>[https://bitcointalk.org/index.php?topic=2953.0 0.3.20 release announcement]</ref>==
Please checkout the git integration branch from:

https://github.com/bitcoin/bitcoin

... and help test. The new features that need testing are:

* -nolisten : https://github.com/bitcoin/bitcoin/pull/11
* -rescan : scan block chain for missing wallet transactions
* -printtoconsole : https://github.com/bitcoin/bitcoin/pull/37
* RPC gettransaction details : https://github.com/bitcoin/bitcoin/pull/24
* listtransactions new features : https://github.com/bitcoin/bitcoin/pull/10

Bug fixes that also need testing:

* -maxconnections= : https://github.com/bitcoin/bitcoin/pull/42
* RPC listaccounts minconf : https://github.com/bitcoin/bitcoin/pull/27
* RPC move, add time to output : https://github.com/bitcoin/bitcoin/pull/21
* ...and several improvements to --help output.

This needs more testing on Windows! Please drop me a quick private message, email, or IRC message if you are able to do some testing. If you find bugs, please open an issue at:

https://github.com/bitcoin/bitcoin/issues

==0.3.19<ref>[https://bitcointalk.org/index.php?topic=2228.0 0.3.19 release announcement]</ref>==
There's more work to do on DoS, but I'm doing a quick build of what I have so far in case it's needed, before venturing into more complex ideas. The build for this is version 0.3.19.

- Added some DoS controls
As Gavin and I have said clearly before, the software is not at all resistant to DoS attack. This is one improvement, but there are still more ways to attack than I can count.

I'm leaving the -limitfreerelay part as a switch for now and it's there if you need it.

- Removed "safe mode" alerts
"safe mode" alerts was a temporary measure after the 0.3.9 overflow bug. We can say all we want that users can just run with "-disablesafemode", but it's better just not to have it for the sake of appearances. It was never intended as a long term feature. Safe mode can still be triggered by seeing a longer (greater total PoW) invalid block chain.

==0.3.18<ref>[https://bitcointalk.org/index.php?topic=2162.0 0.3.18 release announcement]</ref>==

Changes:
* Fixed a wallet.dat compatibility problem if you downgraded from 0.3.17 and then upgraded again
* IsStandard() check to only include known transaction types in blocks
* Jgarzik's optimisation to speed up the initial block download a little

The main addition in this release is the Accounts-Based JSON-RPC commands that Gavin's been working on (more details at http://www.bitcoin.org/smf/index.php?topic=1886.0).
* getaccountaddress
* sendfrom
* move
* getbalance
* listtransactions

==0.3.17<ref>[https://bitcointalk.org/index.php?topic=1946.0 0.3.17 release announcement]</ref>==

Version 0.3.17 is now available.

Changes:
* new getwork, thanks m0mchil
* added transaction fee setting in UI options menu
* free transaction limits
* sendtoaddress returns transaction id instead of "sent"
* getaccountaddress <account>

The UI transaction fee setting was easy since it was still there from 0.1.5 and all I had to do was re-enable it.

The accounts-based commands: move, sendfrom and getbalance <account> will be in the next release. We still have some more changes to make first.

==0.3.16==

Never released.

==0.3.15<ref>[https://bitcointalk.org/index.php?topic=1780.0 0.3.15 release announcement]</ref>==

* paytxfee switch is now per KB, so it adds the correct fee for large transactions
* sending avoids using coins with less than 6 confirmations if it can
* BitcoinMiner processes transactions in priority order based on age of dependencies
* make sure generation doesn't start before block 74000 downloaded
* bugfixes by Dean Gores
* testnet, keypoololdest and paytxfee added to getinfo

==0.3.14<ref>[https://bitcointalk.org/index.php?topic=1528.0 0.3.14 release announcement]</ref>==

Version 0.3.14 is now available
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.14/

Changes:
* Key pool feature for safer wallet backup
Gavin Andresen:
* TEST network mode with switch -testnet
* Option to use SSL for JSON-RPC connections on unix/osx
* validateaddress RPC command
eurekafag:
* Russian translation

==0.3.13<ref>[https://bitcointalk.org/index.php?topic=1327.0 0.3.13 release announcement]</ref>==

Version 0.3.13 is now available. You should upgrade to prevent potential problems with 0/unconfirmed transactions. Note: 0.3.13 prevents problems if you haven't already spent a 0/unconfirmed transaction, but if that already happened, you need 0.3.13.2.

Changes:
* Don't count or spend payments until they have 1 confirmation.
* Internal version number from 312 to 31300.
* Only accept transactions sent by IP address if -allowreceivebyip is specified.
* Dropped DB_PRIVATE Berkeley DB flag.
* Fix problem sending the last cent with sub-cent fractional change.
* Auto-detect whether to use 128-bit 4-way SSE2 on Linux.
Gavin Andresen:
* Option -rpcallowip= to accept json-rpc connections from another machine.
* Clean shutdown on SIGTERM on Linux.

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.13/

(Thanks Laszlo for the Mac OSX build!)

Note:
The SSE2 auto-detect in the Linux 64-bit version doesn't work with AMD in 64-bit mode. Please try this instead and let me know if it gets it right:
http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gz

You can still control the SSE2 use manually with -4way and -4way=0.

Version 0.3.13.2 (SVN rev 161) has improvements for the case where you already had 0/unconfirmed transactions that you might have already spent. Here's a Windows build of it:
http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe

==0.3.12<ref>[https://bitcointalk.org/index.php?topic=999.0 0.3.12 release announcement]</ref>==

Version 0.3.12 is now available.

Features:
* json-rpc errors return a more standard error object. (thanks to Gavin Andresen)
* json-rpc command line returns exit codes.
* json-rpc "backupwallet" command.
* Recovers and continues if an exception is caused by a message you received. Other nodes shouldn't be able to cause an exception, and it hasn't happened before, but if a way is found to cause an exception, this would keep it from being used to stop network nodes.

If you have json-rpc code that checks the contents of the error string, you need to change it to expect error objects of the form {"code":<number>,"message":<string>}, which is the standard. See this thread:
http://www.bitcoin.org/smf/index.php?topic=969.0

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.12/

=References=
<references/>

Changelog

2012-06-12T22:07:34Z

BlueMatt: Update references.

{{stub}}

This page aggregates the changelogs that have been posted on the forum for the Bitcoin releases.

=Changelogs=

==0.3.24<ref>[https://bitcointalk.org/index.php?topic=27187.0 0.3.24 release announcement]</ref>==
Bitcoin v0.3.24 is now available for download at
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.24/

This is another bug fix release. We had hoped to have wallet encryption ready for release, but more urgent fixes for existing clients were needed -- most notably block download problems were getting severe. Wallet encryption is ready for testing at https://github.com/bitcoin/bitcoin/pull/352 for the git-savvy, and hopefully will follow shortly in the next release, v0.4.

Notable fixes in v0.3.24, and the main reasons for this release:

F1) Block downloads were failing or taking unreasonable amounts of time to complete, because the increased size of the block chain was bumping up against some earlier buffer-size DoS limits.

F2) Fix crash caused by loss/lack of network connection.

Notable changes in v0.3.24:

C1) DNS seeding enabled by default.

C2) UPNP enabled by default in the GUI client. The percentage of bitcoin clients that accept incoming connections is quite small, and that is a problem. This should help. bitcoind, and unofficial builds, are unchanged (though we encourage use of "-upnp" to help the network!)

C3) Initial unit testing framework. Bitcoin sorely needs automated tests, and this is a beginning. Contributions welcome.

C4) Internal wallet code cleanup. While invisible to an end user, this change provides the basis for v0.4's wallet encryption.

==0.3.23<ref>[https://bitcointalk.org/index.php?topic=16553.0 0.3.23 release announcement]</ref>==
Win32, Linux, MacOSX and source releases for bitcoin v0.3.23 have been uploaded to
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.23/

This is another quick bugfix release, trying to deal with the influx of new bitcoin users.

Main items of note:

* P2P connect-to-node logic changed to reduce timeout a bit. The network saw a huge influx of new users, who do not permit incoming connections. This change is a short-term hack, to more quickly hunt for useful P2P connections. Better "leaf node" logic is in the works, but this should let us limp along until then. One may use -upnp to properly forward ports, and help the network.
* Transaction fee reduced to 0.0005 for new transactions
* Client will relay transactions with fees as low as 0.0001 BTC

==0.3.22<ref>[https://bitcointalk.org/index.php?topic=12269.0 0.3.22 release announcement]</ref>==
Download URL: https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.22/

This is largely a bugfix and TX fee schedule release. We also hope to make 0.3.23 a quick release, to fix problems that the network has seen due to explosive growth in the past week.

Notable changes:
* Client will accept and relay TX's with 0.0005 BTC fee schedule (users still pay 0.01 BTC per kb, until next version)
* Non-standard transactions accepted on testnet
* Source code tree reorganized (prep for autotools build)
* Remove "Generate Coins" option from GUI, and remove 4way SSE miner. Internal reference CPU miner remains available, but users are directed to external miners for best hash production.
* IRC is overflowing. Client now bootstraps to channels #bitcoin00 - #bitcoin99
* DNS names now may be used with -addnode, -connect (requires -dns to enable)

RPC changes:
* 'listtransactions' adds 'from' param, for range queries
* 'move' may take account balances negative
* 'settxfee' added, to manually set TX fee

==0.3.21<ref>[https://bitcointalk.org/index.php?topic=6642.0 0.3.21 release announcement]</ref>==
Binaries for Bitcoin version 0.3.21 are available at:
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.21/

Changes and new features from the 0.3.20 release include:

* Universal Plug and Play support. Enable automatic opening of a port for incoming connections by running bitcoin or bitcoind with the - -upnp=1 command line switch or using the Options dialog box.

* Support for full-precision bitcoin amounts. You can now send, and bitcoin will display, bitcoin amounts smaller than 0.01. However, sending fewer than 0.01 bitcoins still requires a 0.01 bitcoin fee (so you can send 1.0001 bitcoins without a fee, but you will be asked to pay a fee if you try to send 0.0001).

* A new method of finding bitcoin nodes to connect with, via DNS A records. Use the -dnsseed option to enable.

For developers, changes to bitcoin's remote-procedure-call API:

* New rpc command "sendmany" to send bitcoins to more than one address in a single transaction.

* Several bug fixes, including a serious intermittent bug that would sometimes cause bitcoind to stop accepting rpc requests.

* -logtimestamps option, to add a timestamp to each line in debug.log.

* Immature blocks (newly generated, under 120 confirmations) are now shown in listtransactions.

==0.3.20.2<ref>[https://bitcointalk.org/index.php?topic=4167.0 0.3.20.2 release announcement]</ref>==
The maxsendbuffer bug (0.3.20.1 clients not being able to download the block chain from other 0.3.20.1 clients) was only going to get
worse as people upgraded, so I cherry-picked the bug fix and created a minor release yesterday.

The Amazon Machine Images I used to do the builds are available:

ami-38a05251 Bitcoin-v0.3.20.2 Mingw (Windows; Administrator password 'bitcoin development')
ami-30a05259 Bitcoin_0.3.20.2 Linux32
ami-8abc4ee3 Bitcoin_0.3.20.2 Linux64

(mac build will be done soon)

If you have already downloaded version 0.3.20.1, please either add this to your bitcoin.conf file:

maxsendbuffer=10000
maxreceivebuffer=10000

... or download the new version.

==0.3.20.1==
(No known forum post.)

==0.3.20<ref>[https://bitcointalk.org/index.php?topic=2953.0 0.3.20 release announcement]</ref>==
Please checkout the git integration branch from:

https://github.com/bitcoin/bitcoin

... and help test. The new features that need testing are:

* -nolisten : https://github.com/bitcoin/bitcoin/pull/11
* -rescan : scan block chain for missing wallet transactions
* -printtoconsole : https://github.com/bitcoin/bitcoin/pull/37
* RPC gettransaction details : https://github.com/bitcoin/bitcoin/pull/24
* listtransactions new features : https://github.com/bitcoin/bitcoin/pull/10

Bug fixes that also need testing:

* -maxconnections= : https://github.com/bitcoin/bitcoin/pull/42
* RPC listaccounts minconf : https://github.com/bitcoin/bitcoin/pull/27
* RPC move, add time to output : https://github.com/bitcoin/bitcoin/pull/21
* ...and several improvements to --help output.

This needs more testing on Windows! Please drop me a quick private message, email, or IRC message if you are able to do some testing. If you find bugs, please open an issue at:

https://github.com/bitcoin/bitcoin/issues

==0.3.19<ref>[https://bitcointalk.org/index.php?topic=2228.0 0.3.19 release announcement]</ref>==
There's more work to do on DoS, but I'm doing a quick build of what I have so far in case it's needed, before venturing into more complex ideas. The build for this is version 0.3.19.

- Added some DoS controls
As Gavin and I have said clearly before, the software is not at all resistant to DoS attack. This is one improvement, but there are still more ways to attack than I can count.

I'm leaving the -limitfreerelay part as a switch for now and it's there if you need it.

- Removed "safe mode" alerts
"safe mode" alerts was a temporary measure after the 0.3.9 overflow bug. We can say all we want that users can just run with "-disablesafemode", but it's better just not to have it for the sake of appearances. It was never intended as a long term feature. Safe mode can still be triggered by seeing a longer (greater total PoW) invalid block chain.

==0.3.18<ref>[https://bitcointalk.org/index.php?topic=2162.0 0.3.18 release announcement]</ref>==

Changes:
* Fixed a wallet.dat compatibility problem if you downgraded from 0.3.17 and then upgraded again
* IsStandard() check to only include known transaction types in blocks
* Jgarzik's optimisation to speed up the initial block download a little

The main addition in this release is the Accounts-Based JSON-RPC commands that Gavin's been working on (more details at http://www.bitcoin.org/smf/index.php?topic=1886.0).
* getaccountaddress
* sendfrom
* move
* getbalance
* listtransactions

==0.3.17<ref>[https://bitcointalk.org/index.php?topic=1946.0 0.3.17 release announcement]</ref>==

Version 0.3.17 is now available.

Changes:
* new getwork, thanks m0mchil
* added transaction fee setting in UI options menu
* free transaction limits
* sendtoaddress returns transaction id instead of "sent"
* getaccountaddress <account>

The UI transaction fee setting was easy since it was still there from 0.1.5 and all I had to do was re-enable it.

The accounts-based commands: move, sendfrom and getbalance <account> will be in the next release. We still have some more changes to make first.

==0.3.16==

Never released.

==0.3.15<ref>[https://bitcointalk.org/index.php?topic=1780.0 0.3.15 release announcement]</ref>==

* paytxfee switch is now per KB, so it adds the correct fee for large transactions
* sending avoids using coins with less than 6 confirmations if it can
* BitcoinMiner processes transactions in priority order based on age of dependencies
* make sure generation doesn't start before block 74000 downloaded
* bugfixes by Dean Gores
* testnet, keypoololdest and paytxfee added to getinfo

==0.3.14<ref>[https://bitcointalk.org/index.php?topic=1528.0 0.3.14 release announcement]</ref>==

Version 0.3.14 is now available
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.14/

Changes:
* Key pool feature for safer wallet backup
Gavin Andresen:
* TEST network mode with switch -testnet
* Option to use SSL for JSON-RPC connections on unix/osx
* validateaddress RPC command
eurekafag:
* Russian translation

==0.3.13<ref>[https://bitcointalk.org/index.php?topic=1327.0 0.3.13 release announcement]</ref>==

Version 0.3.13 is now available. You should upgrade to prevent potential problems with 0/unconfirmed transactions. Note: 0.3.13 prevents problems if you haven't already spent a 0/unconfirmed transaction, but if that already happened, you need 0.3.13.2.

Changes:
* Don't count or spend payments until they have 1 confirmation.
* Internal version number from 312 to 31300.
* Only accept transactions sent by IP address if -allowreceivebyip is specified.
* Dropped DB_PRIVATE Berkeley DB flag.
* Fix problem sending the last cent with sub-cent fractional change.
* Auto-detect whether to use 128-bit 4-way SSE2 on Linux.
Gavin Andresen:
* Option -rpcallowip= to accept json-rpc connections from another machine.
* Clean shutdown on SIGTERM on Linux.

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.13/

(Thanks Laszlo for the Mac OSX build!)

Note:
The SSE2 auto-detect in the Linux 64-bit version doesn't work with AMD in 64-bit mode. Please try this instead and let me know if it gets it right:
http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gz

You can still control the SSE2 use manually with -4way and -4way=0.

Version 0.3.13.2 (SVN rev 161) has improvements for the case where you already had 0/unconfirmed transactions that you might have already spent. Here's a Windows build of it:
http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe

==0.3.12<ref>[https://bitcointalk.org/index.php?topic=999.0 0.3.12 release announcement]</ref>==

Version 0.3.12 is now available.

Features:
* json-rpc errors return a more standard error object. (thanks to Gavin Andresen)
* json-rpc command line returns exit codes.
* json-rpc "backupwallet" command.
* Recovers and continues if an exception is caused by a message you received. Other nodes shouldn't be able to cause an exception, and it hasn't happened before, but if a way is found to cause an exception, this would keep it from being used to stop network nodes.

If you have json-rpc code that checks the contents of the error string, you need to change it to expect error objects of the form {"code":<number>,"message":<string>}, which is the standard. See this thread:
http://www.bitcoin.org/smf/index.php?topic=969.0

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.12/

=References=
<references/>

Comparison of mining pools

2012-02-17T01:46:39Z

BlueMatt: Update p2pool hashrate

Reward types & explanation:
* '''DGM''' - Double Geometric Method. A hybrid between PPLNS and Geometric reward types that enables to operator to absorb some of the variance risk. Operator receives portion of payout on short rounds and returns it on longer rounds to normalize payments. [https://bitcointalk.org/index.php?topic=39497.0]
* '''Prop.''' - Proportional. When block is found, the reward is distributed among all workers proportionally to how much shares each of them has found.
* '''PPLNS''' - Pay Per Last N Shares. Similar to proportional, but instead of looking at the number of shares in the round, instead looks at the last N shares, regardless of round boundaries.
* '''PPS''' - Pay Per Share. Each submitted share is worth certain amount of BC. Since finding a block requires <current difficulty> shares ''on average'', a PPS method with 0% fee would be 50 BTC divided by <current difficulty>. It is risky for pool operators, hence the fee is highest.
* '''SMPPS''' - Shared Maximum Pay Per Share. Like Pay Per Share, but never pays more than the pool earns. [http://eligius.st/wiki/index.php/Shared_Maximum_PPS]
* '''ESMPPS''' - Equalized Shared Maximum Pay Per Share. Like SMPPS, but equalizes payments fairly among all those who are owed. [http://forum.bitcoin.org/index.php?topic=12181.msg378851#msg378851]
* '''CPPSRB''' - Capped Pay Per Share with Recent Backpay.
* '''Score''' - Score based system: a proportional reward, but weighed by time submitted. Each submitted share is worth more in the function of time ''t'' since start of current round. For each share score is updated by: score += exp(t/C). This makes later shares worth much more than earlier shares, thus the miner's score quickly diminishes when they stop mining on the pool. Rewards are calculated proportionally to scores (and not to shares). (at slush's pool C=300 seconds, and every hour scores are normalized)
[http://eligius.st/~luke-jr/samples/800MH-3/ Visual examples of the various payout methods]

{| class="wikitable sortable"
|-
! Name !! Location !! GH/s<ref name="hashrate2">Note that pool hashrate is largely irrelevant but can be seen as a popularity measurement. Note however that it is a theoretical security issue if one pool gains above 50% of the total computational power of the network, thus consider joining a pool based on other metrics.</ref> !! Merged Mining<ref name="merged">Merged mining allows miners to mine on multiple [[block chains]] at the same time with the same hashing.</ref> !! Reward Type !! Transaction fees !! Fee PPS !! Fee Prop / Score !! Protocol !! Launched !! Forum !! Website
|-
| [[50BTC]] || Germany || 170 || No || PPS+stales<ref name="stales">Pool also rewards stale shares</ref> || kept by pool || 3% || || RPC+LP || 2011-11-11 || [http://bitcointalk.org/index.php?topic=54673.0 Link] || [http://50btc.com/ Link]
|-
| [[ABCPool.co|ABCPool.co]] || USA || 430 || ? || PPS<ref name="stales"></ref> || kept by pool || 4%<ref name="donations">Donations are possible</ref> || || RPC+LP || 2011-08-02 || [http://bitcointalk.org/index.php?topic=33586.0 Link] || [http://www.ABCPool.co/ Link]
|-
| [[ArsBitcoin|ArsBitcoin]] || USA || 433 || No || SMPPS || kept by pool || 0%<ref name="donations">Donations are possible</ref> || || RPC+LP || 2011-06-15 || [http://forum.bitcoin.org/index.php?topic=18567.0 Link] || [https://arsbitcoin.com/ Link]
|-
| [[Bitcash.cz|Bitcash.cz]] || Czech Republic || 14 || ? || Prop. || kept by pool || || 0% || RPC+LP || 2011-07-21 || [http://bitcash.cz/forum/ Link] ||
[http://bitcash.cz/pool/ Link]
|-
| [[Bitcoin-Station|Bitcoin-Station]] || Germany || 5 || ? || Prop. || kept by pool || || 2% || RPC+LP || 2011-09-11 || || [https://bitcoin-station.com/ Link]
|-
| [[Betcoin.co_Pool|Betcoin.co Pool]] || USA || 5.9 || ? || PPLNS || kept by pool || || 0% || RPC+LP || 2011-07-07 || [http://forum.bitcoin.org/index.php?topic=26439.0 Link] || [http://pool.betcoin.co/ Link]
|-
| [[Bitarama|Bitarama.com]] || USA || 0.021 || ? || Prop || kept by pool || || || RPC+LP || 2011-08-02 || || [http://www.bitarama.com/ Link]
|-
| [[Bitclockers|BitClockers]] || USA, EU || 325 || ? || Prop. || kept by pool || || 2% || RPC+LP || 2011-05-27 || [http://forum.bitcoin.org/index.php?topic=10127.0 Link] || [http://bitclockers.com/ Link]
|-
| [[Bitcoin_Pool|Bitcoin Mining Pool]] || USA || 51 || ? || Prop. || kept by pool || || 0%<ref name="donations">Donations are possible</ref> || RPC+LP || Unknown || [http://bitcoinpool.com/forum/ Link] || [http://www.bitcoinpool.com/ Link]
|-
| [[Bitcoin_Pooled_Mining|Bitcoin Pooled Mining (Slush)]] || EU/London || 1454 || [[NMC]] || Score || kept by pool || || 2% || RPC+LP || 2010-11-27 || [http://forum.bitcoin.org/index.php?topic=1976.0 Link] || [http://mining.bitcoin.cz/ Link]
|-
| [[Bitcoinitalia]] || Italy || 0.45 || ? || Prop. || kept by pool || || 0% || RPC+LP || 2011-07-12 || [http://forum.bitcoin.org/index.php?topic=26634.0 Link] || [http://www.btcfarm.us/ Link]
|-
| [[Bitcoins.lc]] || EU || 387 || ? || Prop. || kept by pool || || 0% || RPC+LP || 2011-05-27 || [http://forum.bitcoin.org/index.php?topic=10121.0 Link] || [http://www.bitcoins.lc/ Link]
|-
| [[BitLotto Pool]] || Los Angeles || 0.4 || ? || Prop || kept by pool || || || RPC+LP || 2011-06-08 || [http://forum.bitcoin.org/index.php?topic=13794.0 Link] || [http://www.bitlottopool.com/ Link]
|-
| [[BitMinter]] || Germany || 120 || [[NMC]] || PPLNS || shared || || 0% || RPC+LP || 2011-06-18 || [https://bitcointalk.org/index.php?topic=27062.0 Link] || [https://bitminter.com Link]
|-
| [[Bitp.it]] || USA || 20 || ? || ESMPPS || kept by pool || || 0% || RPC+LP || 2011-06-08 || [http://forum.bitcoin.org/index.php?topic=12181.0 Link] || [https://pool.bitp.it Link]
|-
| [[BitPenny]] || USA || 10 || No || CPPSRB || 97% shared || 3% || || Proprietary<ref name="local">Proprietary-protocol pools (BitPenny and p2pool) provide JSON-RPC to miners locally.</ref> || 2011-02-08 || [https://bitcointalk.org/index.php?topic=36371.0 Link] || [http://bitpenny.com/ Link]
|-
| [[BTC Guild]] || USA, EU || 1410 || [[NMC]] || PPS || kept by pool || 5% || || RPC+LP || 2011-05-09 || [http://forum.bitcoin.org/index.php?topic=7760.0 Link] || [http://www.btcguild.com/ Link]
|-
| [[BTCMine]] || UK || 175 || ? || Score || kept by pool || || 2% || RPC+LP || 2011-03-11 || [http://forum.bitcoin.org/index.php?topic=4251.0 Link] || [http://www.btcmine.com/ Link]
|-
| [[btcmp.com]] || Germany || 18 || ? || PPS || kept by pool || || 0% || RPC+LP || 2011-06-28 || || [http://www.btcmp.com/ Link]
|-
| [[Btcserv|BTCServ]] || Germany || 71 || Converted to BC || PPS || kept by pool || 0% || || RPC+LP || 2011-07-09 || [http://forum.bitcoin.org/index.php?topic=27101.0 Link] || [http://btcserv.net/ Link]
|-
| [[Btcworld.de]] || Germany || 2.5 || ? || Prop || kept by pool || || ? || RPC+LP || 2011-06-18 || || [http://btcworld.de/ Link]
|-
| [http://chwpool.kr105.com/ CHWpool] || Chile || 0 || ? || Prop || kept by pool || || 1% || RPC+LP || 2011-06-30 || || [http://chwpool.kr105.com/ Link]
|-
| [[Coinotron|Coinotron]] || Poland || 7 || ? || Prop || kept by pool || || 0% || RPC+LP || 2011-07-06 || [http://forum.bitcoin.org/index.php?topic=26727.0 Link] || [http://www.coinotron.com Link]
|-
| [[DeepBit]] || Germany || 3673 || No || PPS / Prop. || kept by pool || 10% || 3% || RPC+LP || 2011-02-26 || [http://forum.bitcoin.org/index.php?topic=3889.0 Link] || [http://deepbit.net/ Link]
|-
| [[Eclipse Mining Consortium]] || USA / Europe / AU / Asia || 500|| [[NMC]] || DGM || kept by pool || || 0% || RPC+LP || 2011-06-14 || [http://forum.bitcoin.org/index.php?topic=16385.0 Link] || [https://eclipsemc.com Link]
|-
| [[Eligius]] || Germany || 450  || [[NMC]] || SMPPS || kept by pool || 0.000001%<ref name="donations">Donations are possible</ref> || || RPC+LP || 2011-04-27 || [https://bitcointalk.org/index.php?topic=6667.0 Link] || [http://eligius.st Link]
|-
| [[MasterPool]] || Germany || 20 || [[NMC]] || PPLNS || shared || || 1 or 2%<ref name="payoutfee">Fee is a payout fee. Instant payout: 2%. Scheduled payout (each night): 1%</ref> || RPC+LP || 2011-07-18 || [https://bitcointalk.org/index.php?topic=42667.0 Link] || [https://www.masterpool.eu Link]
|-
| [[Mineco.in]] || UK || 94 || ? || PPLNS || shared || || 0% || RPC+LP || 2011-06-15 || [http://forum.bitcoin.org/index.php?topic=17310.0 Link] || [https://mineco.in/ Link]
|-
| [[Mining Team Reddit (MtRed)]] || USA, EU || 95 || [[NMC]] || PPS || kept by pool || 7% || || RPC+LP || 2011-05-25 || [http://forum.bitcoin.org/index.php?topic=15929.0 1] [http://reddit.com/r/mtred/ 2] || [http://www.mtred.com/ Link]
|-
| [[NoFeeMining]] || USA || 0 (closed) || ? || RSMPPS || shared || || 0% || RPC+LP || 2011-06-17 || [http://forum.bitcoin.org/index.php?topic=18301.0 Link] || [http://nofeemining.appspot.com/ Link]
|-
| [[Ozco.in]] || USA/EU/AUS || 88 || [[NMC]] || DGM || kept by pool || || 0% || RPC+LP || 2011-06-07 || [http://forum.bitcoin.org/index.php?topic=14085.0/ Link] || [http://www.ozco.in Link]
|-
| [[P2Pool]] || Earth (P2P) || 271 || Yes/Solo<ref>P2Pool supports merged mining but payouts in the merged chain are not pooled.</ref> || PPLNS || shared || || <0%<ref>People are donating ''to'' P2Pool miners to encourage people to use it. The P2Pool author also accepts optional donations.</ref> || Proprietary<ref name="local"/> || 2011-06-17 || [http://forum.bitcoin.org/index.php?topic=18313.0 Link] || [https://en.bitcoin.it/wiki/P2Pool Link]
|-
| [[PolMine]] || Poland || 52 || ? || PPS || shared || 2% || || RPC || 2011-06-13 || [http://forum.polmine.pl/ Link] || [https://polmine.pl/ Link]
|-
| [[pool.itzod.ru]] || Russian Federation || 35 || Converted to BTC || RSMPPS || shared || 0% || 0% || RPC+LP || 2011-08-01 || [https://bitcointalk.org/index.php?topic=25127.0 Link] [https://bitcointalk.org/index.php?topic=44024.0 Link] || [http://pool.itzod.ru/ Link]
|-
| [[rfcpool]] || UK, EU || 60 || No || PPLNS || shared || 0%<ref name="donations">Donations are possible</ref> || 0%<ref name="donations">Donations are possible</ref> || RPC+LP || 2011-07-05 || [http://forum.bitcoin.org/index.php?topic=26164.0/ Link] || [https://www.rfcpool.com Link]
|-
| [[Simplecoin|Simplecoin.us]] || US || 25 || [[NMC]] || SMPPS / PPLNS / Prop || kept by pool || 0%<ref name="donations">Donations are possible</ref> || 0%<ref name="donations">Donations are possible</ref> || RPC+LP || 2011-06-02 || [http://forum.bitcoin.org/index.php?topic=11186.0 Link] || [http://simplecoin.us/ Link]
|-
| [[Triplemining]] || Europe || 40 || ? || PPLNS || kept by pool || || 0% <ref name="jackpot">Triplemining keeps 1% to redistribute using a weekly jackpot and affiliations</ref> || RPC+LP || 2011-06-28 || [http://forum.bitcoin.org/index.php?topic=23664.0 Link] || [http://tinyurl.com/triplemining Link]
|-
| [[UnitedMiners]] || US || 2 || ? || Prop || kept by pool || || 0% || RPC+LP || 2011-06-28 || [http://forum.bitcoin.org/index.php?topic=23664.0 Link] || [http://www.unitedminers.com Link]
|-
| [[yourbtc.net]] || Germany || 18 || [[NMC]] || DGM || shared || || 0% || RPC+LP || 2011-09-10 || [http://bitcointalk.org/index.php?topic=42631.0 Link] || [http://yourbtc.net/ Link]
|-
| [[pool.mkalinin.ru]] || Russia || 16 || No || PPLNS || kept by pool || || 0% || RPC+LP || 2011-07-20 || [https://bitcointalk.org/index.php?topic=30703.0 Link] || [http://pool.mkalinin.ru/ Link]
|}
<references/>

== See also ==
*[[Pooled mining]]
*[http://bcx.me/ Bitcoin Mining Pool Tracker]
*[http://blockchain.info/pools Hashrate distribution pie chart]

[[Category:Mining]]

BIP 0021

2012-01-31T21:21:23Z

BlueMatt: Specify number locale, s/mustimplement/req/

<pre>
BIP: 21
Title: URI Scheme
Author: Nils Schneider <nils.schneider@gmail.com>
Matt Corallo <bip21@bluematt.me>
Status: Draft
Type: Standards Track
Created: 29-01-2012
</pre>

This BIP is a modification of an earlier [[BIP 0020]] by Luke Dashjr. BIP 0020 was based off an earlier document by Nils Schneider. The alternative payment amounts in BIP 0020 have been removed.

==Abstract==
This BIP proposes a URI scheme for making Bitcoin payments.

==Motivation==
The purpose of this URI scheme is to enable users to easily make payments by simply clicking links on webpages or scanning QR Codes.

==Specification==

=== General rules for handling (important!) ===

Bitcoin clients MUST NOT act on URIs without getting the user's authorization.
They SHOULD require the user to manually approve each payment individually, though in some cases they MAY allow the user to automatically make this decision.

=== Operating system integration ===
Graphical bitcoin clients SHOULD register themselves as the handler for the "bitcoin:" URI scheme by default, if no other handler is already registered. If there is already a registered handler, they MAY prompt the user to change it once when they first run the client.

=== BNF grammar ===

(See also [[#Simpler syntax|a simpler representation of syntax]])

bitcoinurn = "bitcoin:" bitcoinaddress [ "?" bitcoinparams ]
bitcoinaddress = base58 *base58
bitcoinparams = *bitcoinparam
bitcoinparam = amountparam | labelparam | messageparam | otherparam | reqparam
amountparam = "amount=" *digit [ "." *digit ]
labelparam = "label=" *pchar
messageparam = "message=" *pchar
otherparam = pchar *pchar "=" *pchar
reqparam = "req:" pchar *pchar "=" *pchar

=== Query Keys ===

*label: Label for that address (e.g. name of receiver)
*address: bitcoin address
*message: message that shown to the user after scanning the QR code
*size: amount of base bitcoin units ([[#Transfer amount/size|see below]])
*(others): optional, for future extensions

==== Transfer amount/size ====

If an amount is provided, it MUST be specified in decimal BTC.
All amounts MUST contain no commas and use a period (.) as the separating character to separate whole numbers and decimal fractions.
I.e. amount=50.00 or amount=50 is treated as 50 BTC, and amount=50,000.00 is invalid.

Bitcoin clients MAY display the amount in any format that is not intended to deceive the user.
They SHOULD choose a format that is foremost least confusing, and only after that most reasonable given the amount requested.
For example, so long as the majority of users work in BTC units, values should always be displayed in BTC by default, even if mBTC or TBC would otherwise be a more logical interpretation of the amount.
== Rationale ==

===Payment identifiers, not person identifiers===
Current best practices are that a unique address should be used for every transaction.
Therefore, a URI scheme should not represent an exchange of personal information, but a one-time payment.

===Accessibility (URI scheme name)===
Should someone from the outside happen to see such a URI, the URI scheme name already gives a description.
A quick search should then do the rest to help them find the resources needed to make their payment.
Other proposed names sound much more cryptic; the chance that someone googles that out of curiosity are much slimmer.
Also, very likely, what he will find are mostly technical specifications - not the best introduction to bitcoin.

==Forward compatibility==
Variables which are prefixed with a req: are considered required. If a client does not implement any variables which are prefixed with req:, it MUST consider the entire URI invalid. Any other variables which are not implemented, but which are not prefixed with a req:, can be safely ignored.

==Backward compatibility==
As this BIP is written, several clients already implement a bitcoin: URI scheme similar to this one, however usually without the additional "req:" prefix requirement. Thus, it is recommended that additional variables prefixed with req: not be used in a mission-critical way until a grace period of 6 months from the finalization of this BIP has passed in order to allow client developers to release new versions, and users of old clients to upgrade.

== Appendix ==

=== Simpler syntax ===

This section is non-normative and does not cover all possible syntax.
Please see the [[#BNF grammar|BNF grammar]] above for the normative syntax.

[foo] means optional, <bar> are placeholders

bitcoin:<address>[?amount=<amount>][?label=<label>][?message=<message>]

=== Examples ===

Just the address:
bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W

Address with name:
bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?label=Luke-Jr

Request 20.30 BTC to "Luke-Jr":
bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=20.3&label=Luke-Jr

Request 50 BTC with message:
bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=50&label=Luke-Jr&message=Donation%20for%20project%20xyz

Some future version that has variables which are (currently) not understood and required and thus invalid:
bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?req:somethingyoudontunderstand=50&req:somethingelseyoudontget=999

Some future version that has variables which are (currently) not understood but not required and thus valid:
bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?somethingyoudontunderstand=50&somethingelseyoudontget=999

Characters must be URI encoded properly.

== Reference Implementations ==
=== Bitcoin clients ===
* [[Bitcoin-Qt]] supports the old version of Bitcoin URIs (ie without the req: prefix), with Windows and KDE integration as of commit 70f55355e29c8e45b607e782c5d76609d23cc858.

[[Category:Developer]]
[[Category:Technical]]
[[Category:BIP|D]]

BIP 0021

2012-01-31T18:15:34Z

BlueMatt: Replace version with mustimplement. replace sample address with invalid sample address from wikipedia.

<pre>
BIP: 21
Title: URI Scheme
Author: Nils Schneider <nils.schneider@gmail.com>
Matt Corallo <bip21@bluematt.me>
Status: Draft
Type: Standards Track
Created: 29-01-2012
</pre>

This BIP is a modification of an earlier [[BIP 0020]] by Luke Dashjr. BIP 0020 was based off an earlier document by Nils Schneider. The alternative payment amounts in BIP 0020 have been removed.

==Abstract==
This BIP proposes a URI scheme for making Bitcoin payments.

==Motivation==
The purpose of this URI scheme is to enable users to easily make payments by simply clicking links on webpages or scanning QR Codes.

==Specification==

=== General rules for handling (important!) ===

Bitcoin clients MUST NOT act on URIs without getting the user's authorization.
They SHOULD require the user to manually approve each payment individually, though in some cases they MAY allow the user to automatically make this decision.

=== Operating system integration ===
Graphical bitcoin clients SHOULD register themselves as the handler for the "bitcoin:" URI scheme by default, if no other handler is already registered. If there is already a registered handler, they MAY prompt the user to change it once when they first run the client.

=== BNF grammar ===

(See also [[#Simpler syntax|a simpler representation of syntax]])

bitcoinurn = "bitcoin:" bitcoinaddress [ "?" bitcoinparams ]
bitcoinaddress = base58 *base58
bitcoinparams = *bitcoinparam
bitcoinparam = amountparam | labelparam | messageparam | otherparam | mustimplementparam
amountparam = "amount=" *digit [ "." *digit ]
labelparam = "label=" *pchar
messageparam = "message=" *pchar
otherparam = pchar *pchar "=" *pchar
mustimplementparam = "mustimplement:" pchar *pchar "=" *pchar

=== Query Keys ===

*label: Label for that address (e.g. name of receiver)
*address: bitcoin address
*message: message that shown to the user after scanning the QR code
*size: amount of base bitcoin units ([[#Transfer amount/size|see below]])
*(others): optional, for future extensions

==== Transfer amount/size ====

If an amount is provided, it must be specified in decimal BTC.
I.e. amount=50.00 is treated as 50 BTC.

Bitcoin clients MAY display the amount in any format that is not intended to deceive the user.
They SHOULD choose a format that is foremost least confusing, and only after that most reasonable given the amount requested.
For example, so long as the majority of users work in BTC units, values should always be displayed in BTC by default, even if mBTC or TBC would otherwise be a more logical interpretation of the amount.

== Rationale ==

===Payment identifiers, not person identifiers===
Current best practices are that a unique address should be used for every transaction.
Therefore, a URI scheme should not represent an exchange of personal information, but a one-time payment.

===Accessibility (URI scheme name)===
Should someone from the outside happen to see such a URI, the URI scheme name already gives a description.
A quick search should then do the rest to help them find the resources needed to make their payment.
Other proposed names sound much more cryptic; the chance that someone googles that out of curiosity are much slimmer.
Also, very likely, what he will find are mostly technical specifications - not the best introduction to bitcoin.

==Forward compatibility==
Variables which are prefixed with a mustimplement: are considered required. If a client does not implement any variables which are prefixed with mustimplement:, it MUST consider the entire URI invalid. Any other variables which are not implemented, but which are not prefixed with a mustimplement:, can be safely ignored.

==Backward compatibility==
As this BIP is written, several clients already implement a bitcoin: URI scheme similar to this one, however usually without the additional "mustimplement:" prefix requirement. Thus, it is recommended that additional variables prefixed with mustimplement: not be used in a mission-critical way until a grace period of 6 months from the finalization of this BIP has passed in order to allow client developers to release new versions, and users of old clients to upgrade.

== Appendix ==

=== Simpler syntax ===

This section is non-normative and does not cover all possible syntax.
Please see the [[#BNF grammar|BNF grammar]] above for the normative syntax.

[foo] means optional, <bar> are placeholders

bitcoin:<address>[?amount=<amount>][?label=<label>][?message=<message>]

=== Examples ===

Just the address:
bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W

Address with name:
bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?label=Luke-Jr

Request 20.30 BTC to "Luke-Jr":
bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=20.3&label=Luke-Jr

Request 50 BTC with message:
bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=50&label=Luke-Jr&message=Donation%20for%20project%20xyz

Some future version that has variables which are (currently) not understood and required and thus invalid:
bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?mustimplement:somethingyoudontunderstand=50&mustimplement:somethingelseyoudontget=999

Some future version that has variables which are (currently) not understood but not required and thus valid:
bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?somethingyoudontunderstand=50&somethingelseyoudontget=999

Characters must be URI encoded properly.

== Reference Implementations ==
=== Bitcoin clients ===
* [[Bitcoin-Qt]] supports the old version of Bitcoin URIs (ie without the mustimplement: prefix), with Windows and KDE integration as of commit 70f55355e29c8e45b607e782c5d76609d23cc858.

[[Category:Developer]]
[[Category:Technical]]
[[Category:BIP|D]]

BIP 0021

2012-01-31T17:32:18Z

BlueMatt:

<pre>
BIP: 21
Title: URI Scheme
Author: Nils Schneider <nils.schneider@gmail.com>
Matt Corallo <bip21@bluematt.me>
Status: Draft
Type: Standards Track
Created: 29-01-2012
</pre>

This BIP is a modification of an earlier [[BIP 0020]] by Luke Dashjr. BIP 0020 was based off an earlier document by Nils Schneider. The alternative payment amounts in BIP 0020 have been removed.

==Abstract==
This BIP proposes a URI scheme for making Bitcoin payments.

==Motivation==
The purpose of this URI scheme is to enable users to easily make payments by simply clicking links on webpages or scanning QR Codes.

==Specification==

=== General rules for handling (important!) ===

Bitcoin clients MUST NOT act on URIs without getting the user's authorization.
They SHOULD require the user to manually approve each payment individually, though in some cases they MAY allow the user to automatically make this decision.

=== Operating system integration ===
Graphical bitcoin clients SHOULD register themselves as the handler for the "bitcoin:" URI scheme by default, if no other handler is already registered. If there is already a registered handler, they MAY prompt the user to change it once when they first run the client.

=== BNF grammar ===

(See also [[#Simpler syntax|a simpler representation of syntax]])

bitcoinurn = "bitcoin:" bitcoinaddress [ ";version=" bitcoinversion ] [ "?" bitcoinparams ]
bitcoinaddress = base58 *base58
bitcoinversion = "1.0"
bitcoinparams = *bitcoinparam
bitcoinparam = amountparam | labelparam | messageparam | otherparam
amountparam = "amount=" *digit [ "." *digit ]
labelparam = "label=" *pchar
messageparam = "message=" *pchar
otherparam = pchar *pchar "=" *pchar

=== Query Keys ===

*label: Label for that address (e.g. name of receiver)
*address: bitcoin address
*message: message that shown to the user after scanning the QR code
*size: amount of base bitcoin units ([[#Transfer amount/size|see below]])
*(others): optional, for future extensions

==== Transfer amount/size ====

If an amount is provided, it must be specified in decimal BTC.
I.e. amount=50.00 is treated as 50 BTC.

Bitcoin clients MAY display the amount in any format that is not intended to deceive the user.
They SHOULD choose a format that is foremost least confusing, and only after that most reasonable given the amount requested.
For example, so long as the majority of users work in BTC units, values should always be displayed in BTC by default, even if mBTC or TBC would otherwise be a more logical interpretation of the amount.

== Rationale ==

===Payment identifiers, not person identifiers===
Current best practices are that a unique address should be used for every transaction.
Therefore, a URI scheme should not represent an exchange of personal information, but a one-time payment.

===Accessibility (URI scheme name)===
Should someone from the outside happen to see such a URI, the URI scheme name already gives a description.
A quick search should then do the rest to help them find the resources needed to make their payment.
Other proposed names sound much more cryptic; the chance that someone googles that out of curiosity are much slimmer.
Also, very likely, what he will find are mostly technical specifications - not the best introduction to bitcoin.

==Forward compatibility==
We want URIs generated in 2011 to still work in 2036: think about extensibility.
Of course we can make only educated guesses about the future, but don't act as if there is none.
This should be the best we can do, but it should not be seen as set in stone.
Make it possible for later generations to improve our work, to mend our errors, without breaking the URIs created now.

== Appendix ==

=== Simpler syntax ===

This section is non-normative and does not cover all possible syntax.
Please see the [[#BNF grammar|BNF grammar]] above for the normative syntax.

[foo] means optional, <bar> are placeholders

bitcoin:<address>[;version=1.0][?amount=<amount>][?label=<label>][?message=<message>]

=== Examples ===

Just the address:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L

Address with name:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?label=Luke-Jr

Request 20.30 BTC to "Luke-Jr":
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=20.3&label=Luke-Jr

Request 50 BTC with message:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=50&label=Luke-Jr&message=Donation%20for%20project%20xyz

Characters must be URI encoded properly.

== Reference Implementations ==
=== Bitcoin clients ===
* [[Bitcoin-Qt]] supports all valid Bitcoin URIs, with Windows and KDE integration as of commit 70f55355e29c8e45b607e782c5d76609d23cc858.

[[Category:Developer]]
[[Category:Technical]]
[[Category:BIP|D]]

BIP 0021

2012-01-31T16:01:15Z

BlueMatt: Remove send crap

<pre>
BIP: 21
Title: URI Scheme
Author: Nils Schneider <nils.schneider@gmail.com>
Matt Corallo
Status: Draft
Type: Standards Track
Created: 29-01-2011
</pre>

This BIP is a modification of an earlier [[BIP 0020]] by Luke Dashjr. BIP 0020 was based off an earlier document by Nils Schneider. The alternative payment amounts in BIP 0020 have been removed.

==Abstract==
This BIP proposes a URI scheme for making Bitcoin payments.

==Motivation==
The purpose of this URI scheme is to enable users to easily make payments by simply clicking links on webpages or scanning QR Codes.

==Specification==

=== General rules for handling (important!) ===

Bitcoin clients MUST NOT act on URIs without getting the user's authorization.
They SHOULD require the user to manually approve each payment individually, though in some cases they MAY allow the user to automatically make this decision.

=== Operating system integration ===
Graphical bitcoin clients SHOULD register themselves as the handler for the "bitcoin:" URI scheme by default, if no other handler is already registered. If there is already a registered handler, they MAY prompt the user to change it once when they first run the client.

=== BNF grammar ===

(See also [[#Simpler syntax|a simpler representation of syntax]])

bitcoinurn = "bitcoin:" bitcoinaddress [ ";version=" bitcoinversion ] [ "?" bitcoinparams ]
bitcoinaddress = base58 *base58
bitcoinversion = "1.0"
bitcoinparams = *bitcoinparam
bitcoinparam = amountparam | labelparam | messageparam | otherparam
amountparam = "amount=" *digit [ "." *digit ]
labelparam = "label=" *pchar
messageparam = "message=" *pchar
otherparam = pchar *pchar "=" *pchar

=== Query Keys ===

*label: Label for that address (e.g. name of receiver)
*address: bitcoin address
*message: message that shown to the user after scanning the QR code
*size: amount of base bitcoin units ([[#Transfer amount/size|see below]])
*(others): optional, for future extensions

==== Transfer amount/size ====

If an amount is provided, it must be specified in decimal BTC.
I.e. amount=50.00 is treated as 50 BTC.

Bitcoin clients MAY display the amount in any format that is not intended to deceive the user.
They SHOULD choose a format that is foremost least confusing, and only after that most reasonable given the amount requested.
For example, so long as the majority of users work in BTC units, values should always be displayed in BTC by default, even if mBTC or TBC would otherwise be a more logical interpretation of the amount.

== Rationale ==

===Payment identifiers, not person identifiers===
Current best practices are that a unique address should be used for every transaction.
Therefore, a URI scheme should not represent an exchange of personal information, but a one-time payment.

===Accessibility (URI scheme name)===
Should someone from the outside happen to see such a URI, the URI scheme name already gives a description.
A quick search should then do the rest to help them find the resources needed to make their payment.
Other proposed names sound much more cryptic; the chance that someone googles that out of curiosity are much slimmer.
Also, very likely, what he will find are mostly technical specifications - not the best introduction to bitcoin.

==Forward compatibility==
We want URIs generated in 2011 to still work in 2036: think about extensibility.
Of course we can make only educated guesses about the future, but don't act as if there is none.
This should be the best we can do, but it should not be seen as set in stone.
Make it possible for later generations to improve our work, to mend our errors, without breaking the URIs created now.

== Appendix ==

=== Simpler syntax ===

This section is non-normative and does not cover all possible syntax.
Please see the [[#BNF grammar|BNF grammar]] above for the normative syntax.

[foo] means optional, <bar> are placeholders

bitcoin:<address>[;version=1.0][?amount=<amount>][?label=<label>][?message=<message>]

=== Examples ===

Just the address:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L

Address with name:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?label=Luke-Jr

Request 20.30 BTC to "Luke-Jr":
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=20.3&label=Luke-Jr

Request 50 BTC with message:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=50&label=Luke-Jr&message=Donation%20for%20project%20xyz

Characters must be URI encoded properly.

== Reference Implementations ==
=== Bitcoin clients ===
* [[Bitcoin-Qt]] supports all valid Bitcoin URIs, with Windows and KDE integration as of commit 70f55355e29c8e45b607e782c5d76609d23cc858.

[[Category:Developer]]
[[Category:Technical]]
[[Category:BIP|D]]

BIP 0020

2012-01-29T22:58:45Z

BlueMatt: s/Final/Draft/ and is now competing with BIP 21

<pre>
BIP: 20
Title: URI Scheme
Author: Luke Dashjr <luke+bip@dashjr.org>
Nils Schneider <nils.schneider@gmail.com>
Status: Draft
Type: Standards Track
Created: 10-01-2011
</pre>

==Abstract==
This BIP proposes a URI scheme for making Bitcoin payments.

==Motivation==
The purpose of this URI scheme is to enable users to easily make payments by simply clicking links on webpages or scanning QR Codes.

==Specification==

=== General rules for handling (important!) ===

Bitcoin clients MUST NOT act on URIs without getting the user's authorization.
They SHOULD require the user to manually approve each payment individually, though in some cases they MAY allow the user to automatically make this decision.

=== Operating system integration ===
Graphical bitcoin clients SHOULD register themselves as the handler for the "bitcoin:" URI scheme by default, if no other handler is already registered. If there is already a registered handler, they MAY prompt the user to change it once when they first run the client.

=== BNF grammar ===

(See also [[#Simpler syntax|a simpler representation of syntax]])

bitcoinurn = "bitcoin:" bitcoinaddress [ ";version=" bitcoinversion ] [ "?" bitcoinparams ]
bitcoinaddress = base58 *base58
bitcoinversion = "1.0"
bitcoinparams = *bitcoinparam
bitcoinparam = amountparam | labelparam | messageparam | sendparam | otherparam
amountparam = "amount=" amount
amount = amountdecimal | amounthex
amountdecimal = *digit [ "." *digit ] [ "X" *digit ]
amounthex = "x" *hexdigit [ "." *hexdigit ] [ "X" *hexdigit ]
labelparam = "label=" *pchar
messageparam = "message=" *pchar
sendparam = "send=" *pchar
otherparam = pchar *pchar "=" *pchar

=== Query Keys ===

*label: Label for that address (e.g. name of receiver)
*address: bitcoin address
*message: message that shown to the user after scanning the QR code
*size: amount of base bitcoin units ([[#Transfer amount/size|see below]])
*send: used to send bitcoin, rather than to request them
*(others): optional, for future extensions

==== Transfer amount/size ====

If an amount is provided, it may be specified either in decimal or, when prefixed with a single "x" character, hexadecimal.
The number SHOULD be followed by "X" <digits> to signify an exponent to the base multiplier.
Thus, "X8" multiplies your number by 100,000,000.
For decimal values, this means the standard BTC unit.
For hexadecimal values, this means ᵇTBC units (which are equivalent to 42.94967296 BTC).
If exponent is omitted, implementations SHOULD assume X8 for decimal numbers, and X4 for hexadecimal numbers.
I.e. amount=50.00 is treated as 50 BTC, and amount=x40 is treated as 40 TBC.
When specifying bitcoin base units, "X0" SHOULD be used.

Bitcoin clients MAY display the amount in any format that is not intended to deceive the user.
They SHOULD choose a format that is foremost least confusing, and only after that most reasonable given the amount requested.
For example, so long as the majority of users work in BTC units, values should always be displayed in BTC by default, even if mBTC or TBC would otherwise be a more logical interpretation of the amount.

== Rationale ==

===Payment identifiers, not person identifiers===
Current best practices are that a unique address should be used for every transaction.
Therefore, a URI scheme should not represent an exchange of personal information, but a one-time payment.

===Accessibility (URI scheme name)===
Should someone from the outside happen to see such a URI, the URI scheme name already gives a description.
A quick search should then do the rest to help them find the resources needed to make their payment.
Other proposed names sound much more cryptic; the chance that someone googles that out of curiosity are much slimmer.
Also, very likely, what he will find are mostly technical specifications - not the best introduction to bitcoin.

==Forward compatibility==
We want URIs generated in 2011 to still work in 2036: think about extensibility.
Of course we can make only educated guesses about the future, but don't act as if there is none.
This should be the best we can do, but it should not be seen as set in stone.
Make it possible for later generations to improve our work, to mend our errors, without breaking the URIs created now.

== Appendix ==

=== Simpler syntax ===

This section is non-normative and does not cover all possible syntax.
Please see the [[#BNF grammar|BNF grammar]] above for the normative syntax.

[foo] means optional, <bar> are placeholders

bitcoin:<address>[;version=1.0][?amount=<amount>][?label=<label>][?message=<message>][?send=<private key>]

=== Examples ===

Just the address:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L

Address with name:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?label=Luke-Jr

Request 20.30 BTC to "Luke-Jr":
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=20.3X8&label=Luke-Jr

Request 400 TBC:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=x400X4

Request 4000 TBC:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=x4X7

Request 5 uBTC:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=5X2

Request 50 BTC with message:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=50X8&label=Luke-Jr&message=Donation%20for%20project%20xyz

Send 1 BTC:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=1X8&send=S4b3N3oGqDqR5jNuxEvDwf

Characters must be URI encoded properly.

===Sending money via private key===
To send a payment to someone else first construct a new keypair. You may want to use a [[mini private key format]], or you may also use a full private key for more security depending on the amount being sent and how long you expect to pass before a claim. Now create and publish a transaction with an output of the amount you wish to send. Use this script in that output:

<pubkey> OP_CHECKSIG

Construct an address from the public key. Encode the URI as below:

bitcoin:<address>?send=<base 58 encoded private key>

You may optionally include amount or message fields as well. In a wallet to claim money sent this way search for an incoming transaction with the output script form above, where <address> matches the public key in the script. When you find the transaction create a claim transaction with an input script of this form:

<sig>

This claims the money you were sent. Until your claim transaction has confirmed the sender may take their money back.

== Reference Implementations ==
=== Bitcoin clients ===
* [[Spesmilo]] supports all valid Bitcoin URIs, with Windows and KDE integration

=== Parsing amount ===
==== ECMAScript ====
reAmount = /^(([\d.]+)(X(\d+))?|x([\da-f]*)(\.([\da-f]*))?(X([\da-f]+))?)$/i;
function parseAmount(txt) {
var m = txt.match(reAmount);
return m[5] ? (
(
parseInt(m[5], 16) +
(m[7] ? (parseInt(m[7], 16) * Math.pow(16, -(m[7].length))) : 0)
) * (
m[9] ? Math.pow(16, parseInt(m[9], 16)) : 0x10000
)
) : (
m[2]
*
(m[4] ? Math.pow(10, m[4]) : 1e8)
);
}

==== Python ====
m = re.match(r'^(([\d.]+)(X(\d+))?|x([\da-f]*)(\.([\da-f]*))?(X([\da-f]+))?)$', amount, re.IGNORECASE)
if m.group(5):
amount = float(int(m.group(5), 16))
if m.group(7):
amount += float(int(m.group(7), 16)) * pow(16, -(len(m.group(7))))
if m.group(9):
amount *= pow(16, int(m.group(9), 16))
else:
amount *= 0x10000
else:
amount = Decimal(m.group(2))
if m.group(4):
amount *= 10 ** int(m.group(4))
else:
amount *= 100000000

==== C# ====
Regex amountExpression = new Regex(@"^(([\d.]+)(X(\d+))?|x([\da-f]*)(\.([\da-f]*))?(X([\da-f]+))?)$", RegexOptions.IgnoreCase);
Match match = amountExpression.Match(value);
if (match.Success)
{
if (match.Groups[5].Success)
{
long hexDecimal = 0;
if (match.Groups[7].Success)
hexDecimal = Convert.ToInt64(match.Groups[7].Value, 16) * (long)Math.Pow(16, -match.Groups[7].Length);

long hexExponent = 0x10000;
if (match.Groups[9].Success)
hexExponent = (long)Math.Pow(16, Convert.ToInt32(match.Groups[9].Value, 16));

Amount = (Convert.ToInt64(match.Groups[5].Value, 16) + hexDecimal) * hexExponent;
}
else
{
long decimalExponent = 100000000;
if (match.Groups[4].Success)
decimalExponent = (long)Math.Pow(10, int.Parse(match.Groups[4].Value));
Amount = (long)(decimal.Parse(match.Groups[2].Value) * decimalExponent);
}
}

[[Category:Developer]]
[[Category:Technical]]
[[Category:BIP|D]]

BIP 0021

2012-01-29T22:58:28Z

BlueMatt: s/Final/Draft/

BIP 0021

2012-01-29T22:58:05Z

BlueMatt: BIP 21 aka BIP 20 without Luke's crap which was voted against.

<pre>
BIP: 20
Title: URI Scheme
Author: Luke Dashjr <luke+bip@dashjr.org>
Nils Schneider <nils.schneider@gmail.com>
Status: Final
Type: Standards Track
Created: 10-01-2011
</pre>

==Abstract==
This BIP proposes a URI scheme for making Bitcoin payments.

==Motivation==
The purpose of this URI scheme is to enable users to easily make payments by simply clicking links on webpages or scanning QR Codes.

==Specification==

=== General rules for handling (important!) ===

Bitcoin clients MUST NOT act on URIs without getting the user's authorization.
They SHOULD require the user to manually approve each payment individually, though in some cases they MAY allow the user to automatically make this decision.

=== Operating system integration ===
Graphical bitcoin clients SHOULD register themselves as the handler for the "bitcoin:" URI scheme by default, if no other handler is already registered. If there is already a registered handler, they MAY prompt the user to change it once when they first run the client.

=== BNF grammar ===

(See also [[#Simpler syntax|a simpler representation of syntax]])

bitcoinurn = "bitcoin:" bitcoinaddress [ ";version=" bitcoinversion ] [ "?" bitcoinparams ]
bitcoinaddress = base58 *base58
bitcoinversion = "1.0"
bitcoinparams = *bitcoinparam
bitcoinparam = amountparam | labelparam | messageparam | sendparam | otherparam
amountparam = "amount=" *digit [ "." *digit ]
labelparam = "label=" *pchar
messageparam = "message=" *pchar
sendparam = "send=" *pchar
otherparam = pchar *pchar "=" *pchar

=== Query Keys ===

*label: Label for that address (e.g. name of receiver)
*address: bitcoin address
*message: message that shown to the user after scanning the QR code
*size: amount of base bitcoin units ([[#Transfer amount/size|see below]])
*send: used to send bitcoin, rather than to request them
*(others): optional, for future extensions

==== Transfer amount/size ====

If an amount is provided, it must be specified in decimal BTC.
I.e. amount=50.00 is treated as 50 BTC.

Bitcoin clients MAY display the amount in any format that is not intended to deceive the user.
They SHOULD choose a format that is foremost least confusing, and only after that most reasonable given the amount requested.
For example, so long as the majority of users work in BTC units, values should always be displayed in BTC by default, even if mBTC or TBC would otherwise be a more logical interpretation of the amount.

== Rationale ==

===Payment identifiers, not person identifiers===
Current best practices are that a unique address should be used for every transaction.
Therefore, a URI scheme should not represent an exchange of personal information, but a one-time payment.

===Accessibility (URI scheme name)===
Should someone from the outside happen to see such a URI, the URI scheme name already gives a description.
A quick search should then do the rest to help them find the resources needed to make their payment.
Other proposed names sound much more cryptic; the chance that someone googles that out of curiosity are much slimmer.
Also, very likely, what he will find are mostly technical specifications - not the best introduction to bitcoin.

==Forward compatibility==
We want URIs generated in 2011 to still work in 2036: think about extensibility.
Of course we can make only educated guesses about the future, but don't act as if there is none.
This should be the best we can do, but it should not be seen as set in stone.
Make it possible for later generations to improve our work, to mend our errors, without breaking the URIs created now.

== Appendix ==

=== Simpler syntax ===

This section is non-normative and does not cover all possible syntax.
Please see the [[#BNF grammar|BNF grammar]] above for the normative syntax.

[foo] means optional, <bar> are placeholders

bitcoin:<address>[;version=1.0][?amount=<amount>][?label=<label>][?message=<message>][?send=<private key>]

=== Examples ===

Just the address:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L

Address with name:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?label=Luke-Jr

Request 20.30 BTC to "Luke-Jr":
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=20.3&label=Luke-Jr

Request 50 BTC with message:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=50&label=Luke-Jr&message=Donation%20for%20project%20xyz

Send 1 BTC:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=1&send=S4b3N3oGqDqR5jNuxEvDwf

Characters must be URI encoded properly.

===Sending money via private key===
To send a payment to someone else first construct a new keypair. You may want to use a [[mini private key format]], or you may also use a full private key for more security depending on the amount being sent and how long you expect to pass before a claim. Now create and publish a transaction with an output of the amount you wish to send. Use this script in that output:

<pubkey> OP_CHECKSIG

Construct an address from the public key. Encode the URI as below:

bitcoin:<address>?send=<base 58 encoded private key>

You may optionally include amount or message fields as well. In a wallet to claim money sent this way search for an incoming transaction with the output script form above, where <address> matches the public key in the script. When you find the transaction create a claim transaction with an input script of this form:

<sig>

This claims the money you were sent. Until your claim transaction has confirmed the sender may take their money back.

== Reference Implementations ==
=== Bitcoin clients ===
* [[Bitcoin-Qt]] supports all valid Bitcoin URIs, with Windows and KDE integration as of commit 70f55355e29c8e45b607e782c5d76609d23cc858.

[[Category:Developer]]
[[Category:Technical]]
[[Category:BIP|D]]

Incidents

2012-01-23T22:33:32Z

BlueMatt: Later stuff was completely off-topic.

== Micropayment contamination ==
Around September 29, 2010, people started [http://www.bitcoin.org/smf/index.php?topic=1306.0 reporting] that their sent transactions would not confirm. This happened because people modified Bitcoin to send sub-0.01 transactions without any fees. A 0.01 fee was at that time required by the network for such transactions (essentially prohibiting them), so the transactions remained at 0 confirmations forever. This became a more serious issue because Bitcoin would send transactions using bitcoins gotten from transactions with 0 confirmations, and these resulting transactions would also never confirm. Because Bitcoin tends to prefer sending smaller coins, these invalid transactions quickly multiplied, contaminating the wallets of everyone who received them.

Bitcoin was changed to only select coins with at least 1 confirmation. The remaining sub-0.01 transactions were cleared by generators who modified their version of Bitcoin to not require the micropayment fee. It took a while for everything to get cleared, though, because many of the intermediate transactions had been forgotten by the network by this point and had to be rebroadcast by the original senders.

== Value overflow ==

On August 15 2010, it was [http://bitcointalk.org/index.php?topic=822.0 discovered] that block 74638 contained a transaction that created over 184 billion bitcoins for two different addresses. This was possible because the code used for checking transactions before including them in a block didn't account for the case of outputs so large that they overflowed when summed. A new version was published within a few hours of the discovery. The block chain had to be forked. Although many unpatched nodes continued to build on the "bad" block chain, the "good" block chain overtook it at a block height of 74691. The bad transaction no longer exists for people using the longest chain.

The block and transaction:
<pre>CBlock(hash=0000000000790ab3, ver=1, hashPrevBlock=0000000000606865, hashMerkleRoot=618eba,
nTime=1281891957, nBits=1c00800e, nNonce=28192719, vtx=2)
CTransaction(hash=012cd8, ver=1, vin.size=1, vout.size=1, nLockTime=0)
CTxIn(COutPoint(000000, -1), coinbase 040e80001c028f00)
CTxOut(nValue=50.51000000, scriptPubKey=0x4F4BA55D1580F8C3A8A2C7)
CTransaction(hash=1d5e51, ver=1, vin.size=1, vout.size=2, nLockTime=0)
CTxIn(COutPoint(237fe8, 0), scriptSig=0xA87C02384E1F184B79C6AC)
CTxOut(nValue=92233720368.54275808, scriptPubKey=OP_DUP OP_HASH160 0xB7A7)
CTxOut(nValue=92233720368.54275808, scriptPubKey=OP_DUP OP_HASH160 0x1512)
vMerkleTree: 012cd8 1d5e51 618eba

Block hash: 0000000000790ab3f22ec756ad43b6ab569abf0bddeb97c67a6f7b1470a7ec1c
Transaction hash: 1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9</pre>

== OP_CHECKSIG abuse ==

On July 29 2010, it was discovered that block [http://blockexplorer.com/block/00000000000997f9fd2fe1ee376293ef8c42ad09193a5d2086dddf8e5c426b56 71036] contained several transactions with a ton of OP_CHECKSIG commands. There should only ever be one such command. This caused every node to do extra unnecessary work, and it could have been used as a denial-of-service attack. A new version of Bitcoin was quickly released. The new version did not cause a fork on the main network, though it did cause one on the test network (where someone had played around with the attack more).

== LSHIFT and RETURN bugs ==

On July 28 2010 two bugs were discovered and demonstrated on the test network. The first caused bitcoin to crash on some machines when processing a transaction containing an OP_LSHIFT. The second exploited another bug in the transaction handling code and allowed an attacker to spend coins that they did not own. Neither were exploited on the main network, and both were fixed by Bitcoin version 0.3.5.

After these bugs were discovered, many currently-unused [[script]] words were disabled for safety.

== ASCII embedding into blockchain ==

Security researchers Dan Kaminsky and Travis Goodspeed successfully embedded [http://pastebin.com/raw.php?i=BUB3dygQ extraneous text] into the blockchain from a mined block. This was disclosed on July 31, 2011, prior to Kaminsky's presentation at the Black Hat Briefings conference entitled [http://www.slideshare.net/dakami/black-ops-of-tcpip-2011-black-hat-usa-2011 Black Ops Of TCP/IP 2011].

Though Block chain embedding should not really be seen as an attack (BitCoin is ultimately a channel by which arbitrary data is validated and retained over time), the ability of users to store arbitrary data in the blockchain is a potential avenue for abuse. That said, placing arbitrary data in a coinbase does not require additional space on user's drives (as the [[genesis block]] did).
[[Category:Technical]]

Developers

2011-09-07T19:34:58Z

BlueMatt:

* '''This list is not complete.''' Please make updates/corrections as needed.
* Attempt to sort by contribution
* Legend:
** "Author" = original author; "Lead" = current project lead
{|
| style="background:#90ff90" | active maintainer
| style="background:#ffffaa" | has made contributions
| style="background:#ff9090" | no involvement
|}

{|
! Name !! Original !! BitcoinJ !! Tools !! Spesmilo !! Gentoo !! Supybot !! Other
|-
| Satoshi Nakamoto
|style="background:#90ff90"|Author/Retired
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| Bitcoin original designer
|-
| [[Gavin Andresen]]
|style="background:#90ff90"|Lead
| {{Table Value No}}
|style="background:#90ff90"|Author
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| sirius-m
|style="background:#90ff90"|Retired
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| tcatm
| {{Table Value Yes}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
|-
| Jeff Garzik
| {{Table Value Yes}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|style="background:#90ff90"|cpuminer, pushpool
|-
| TD
| {{Table Value No}}
|style="background:#90ff90"|Author
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Daniel Folkinshteyn
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
|-
| Luke Dashjr
|style="background:#ffffaa"|Few
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
| {{Table Value Yes}}
| {{Table Value Yes}}
|style="background:#90ff90"|URI, Wallet protocols
|-
| genjix
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|style="background:#90ff90"|Author
| {{Table Value No}}
| {{Table Value No}}
|-
| Matt Giuca
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value Yes}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Mizery De Aria
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|style="background:#90ff90"|Author
| {{Table Value No}}
|-
| Laurent Bachelier
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
| {{Table Value No}}
|-
| Florian Schmaus
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
| {{Table Value No}}
|-
| BioMike
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value Yes}}
| {{Table Value No}}
|-
| Chris Moore
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Matt Corallo
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Pieter Wuille
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Marius Hanne
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| David FRANCOIS
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Nils Schneider
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Giel van Schijndel
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Fabian H jr.
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| ovdeathiam
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Dev Random
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Michal Zima
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Venkatesh Srinivas
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Vegard Nossum
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| JoelKatz
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Joerie de Gram
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Johannes Henninger
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Jeroenz0r
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Han Lin Yap
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Wladimir J. van der Laan
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Abraham Jewowich
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Michael Bemmerl
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Eric Hosmer
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Dawid Spiechowicz
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Stéphane Gimenez
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Patrick Varilly
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Jay Weisskopf
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Dylan Noblesmith
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| James Burkle
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Jordan Lewis
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Dean Lee
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| xHire
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| HostFat
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Jakob Kramer
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| ariel
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| dabaopku
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Federico Faggiano
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| m0ray
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Danube
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Carlos Pizarro
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Blitzboom
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Daniel Holbert
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Jaromil
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Carlo Alberto Ferraris
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Forrest Voight
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Amir Yalon
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| John Maguire
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Ricardo M. Correia
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Dan Helfman
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| gjs278
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Dan Loewenherz
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Eric Swanson
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Santiago M. Mola
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Shane Wegner
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Sven Slootweg
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| ojab
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| sandos
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| Witchspace
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|-
| laszloh
|style="background:#ffffaa"|
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
| {{Table Value No}}
|}

==See Also==

* [[Original client developers]]
* [[People]]

[[Category:Developer]]

Network

2011-07-27T13:03:29Z

BlueMatt: /* Bootstrapping */

Bitcoin uses a simple broadcast network to propagate transactions and blocks. All communications are done over TCP. Bitcoin is fully able to use ports other than 8333 via the -port parameter. IPv6 is currently not supported.

== Messages ==
* ''version'' - Information about program version and block count. Exchanged when first connecting.
* ''verack'' - Sent in response to a version message to acknowledge that we are willing to connect.
* ''addr'' - List of one or more IP addresses and ports.
* ''inv'' - "I have these blocks/transactions: ..." Normally sent only when a ''new'' block or transaction is being relayed. This is only a list, not the actual data.
* ''getdata'' - Request a single block or transaction by hash.
* ''getblocks'' - Request an ''inv'' of all blocks in a range.
* ''getheaders'' - Request a ''headers'' message containing all block headers in a range.
* ''tx'' - Send a transaction. This is only sent in response to a ''getdata'' request.
* ''block'' - Send a block. This is only sent in response to a ''getdata'' request.
* ''headers'' - Send up to 2,000 block headers. Non-generators can download the headers of blocks instead of entire blocks.
* ''getaddr'' - Request an ''addr'' message containing a bunch of known-active peers (for bootstrapping).
* ''submitorder'', ''checkorder'', and ''reply'' - Used when performing an [[IP address|IP transaction]].
* ''alert'' - Send a network alert.
* ''ping'' - Does nothing. Used to check that the connection is still online. A TCP error will occur if the connection has died.

More information and in-depth technical information is in the [[Protocol Specification]].

== Connection ==

To connect to a peer, you send a ''version'' message containing your version number, block count, and current time. The remote peer will send back a ''verack'' message and his own ''version'' message if he is accepting connections from your version. You will respond with your own ''verack'' if you are accepting connections from his version.

The time data from all of your peers is collected, and the median is used by Bitcoin for all network tasks that use the time (except for other version messages).

You then exchange ''getaddr'' and ''addr'' messages, storing all addresses that you don't know about. Normally ''addr'' messages only contain one address, but in this initial exchange it contains many recent peers.

== Standard relaying ==

When someone sends a transaction, they send an ''inv'' message containing it to all of their peers. Their peers will request the full transaction with ''getdata''. If they consider the transaction valid after receiving it, they will also broadcast the transaction to all of their peers with an ''inv'', and so on. Peers only ask for or relay transactions if they don't already have them. A peer will never rebroadcast a transaction that it already knows about, though transactions will eventually be forgotten if they don't get into a block after a while. The sender and receiver of the transaction will rebroadcast, however.

Anyone who is generating will collect valid received transactions and work on including them in a block. When someone does find a block, they send an ''inv'' containing it to all of their peers, as above. It works the same as transactions.

Everyone broadcasts an ''addr'' containing their own IP address every 24 hours. Nodes relay these messages to a couple of their peers and store the address if it's new to them. Through this system, everyone has a reasonably clear picture of which IPs are connected to the network at the moment. After connecting to the network, you get added to everyone's address database almost instantly because of your initial ''addr''.

Network alerts are broadcast with ''alert'' messages. No ''inv''-like system is used; these contain the entire alert. If a received alert is valid (signed by one of the people with the private key), it is relayed to all peers. For as long as an alert is still in effect, it is rebroadcast at the start of every new connection.

== Initial block download ==

At the start of a connection, you send a ''getblocks'' message containing the hash of the latest block you know about. If the peer doesn't think that this is the latest block, it will send an ''inv'' that contains up to 500 blocks ahead of the one you listed. You will then request all of these blocks with ''getdata'', and the peer will send them to you with ''block'' messages. After you have downloaded and processed all of these blocks, you will send another ''getblocks'', etc., until you have all of the blocks.

0.3.18 introduced new ''headers'' and ''getheaders'' messages. These are not currently used, but they will be used by non-generators to download block headers without the corresponding block bodies. Only the headers are necessary for verifying received transactions -- full blocks are only needed by generators. Instead of the ''getblocks/inv/getdata/block'' sequence, non-generators will send a ''getheaders'' message (very like ''getblocks''), and the peer will immediately respond with a ''headers'' message containing up to 2,000 of the next headers. This will make initial block download ''much'' faster.

== Bootstrapping ==

You choose which peers to connect to by sorting your address database by the time since you last saw the address and then adding a bit of randomization.

Bitcoin has three methods of finding peers.

=== Addr ===

The ''addr'' messages described above create an effect similar to the IRC bootstrapping method. You know reasonably quickly whenever a peer joins, though you won't know for a while when they leave.

Bitcoin comes with a list of addresses known as "seed nodes". If you are unable to connect to IRC and you've never connected to the network before, the client will update the address database by connecting to one of the nodes from this list.

The -addnode command line option can be used to manually add a node. The -connect option can force bitcoin to only connect to a specific node.

=== DNS ===

Bitcoin looks up the IP Addresses of several host names and adds those to the list of potential addresses. This is intended to replace the IRC seeding mechanism in future releases.

=== IRC ===

Bitcoin joins a random channel between #bitcoin00 and #bitcoin99 on irc.lfnet.org. Your nick is set to an encoded form of your IP address. By decoding all the nicks of all users on the channel, you get a list of all IP addresses currently connected to Bitcoin.

For hosts that cannot make outbound connections on port 6667, the lfnet servers are also [[FAQ#Do_I_need_to_configure_my_firewall_to_run_bitcoin?|listening on port 7777]].

== Heartbeat ==

If thirty minutes or more has passed since the client has transmitted any messages it will transmit a message to keep the connection to the peer node alive.

If ninety minutes has passed since a peer node has communicated any messages, then the client will assume that connection has closed.

== See Also ==

* [[Protocol Specification]]

[[Category:Technical]]

Network

2011-07-27T12:58:05Z

BlueMatt:

Bitcoin uses a simple broadcast network to propagate transactions and blocks. All communications are done over TCP. Bitcoin is fully able to use ports other than 8333 via the -port parameter. IPv6 is currently not supported.

== Messages ==
* ''version'' - Information about program version and block count. Exchanged when first connecting.
* ''verack'' - Sent in response to a version message to acknowledge that we are willing to connect.
* ''addr'' - List of one or more IP addresses and ports.
* ''inv'' - "I have these blocks/transactions: ..." Normally sent only when a ''new'' block or transaction is being relayed. This is only a list, not the actual data.
* ''getdata'' - Request a single block or transaction by hash.
* ''getblocks'' - Request an ''inv'' of all blocks in a range.
* ''getheaders'' - Request a ''headers'' message containing all block headers in a range.
* ''tx'' - Send a transaction. This is only sent in response to a ''getdata'' request.
* ''block'' - Send a block. This is only sent in response to a ''getdata'' request.
* ''headers'' - Send up to 2,000 block headers. Non-generators can download the headers of blocks instead of entire blocks.
* ''getaddr'' - Request an ''addr'' message containing a bunch of known-active peers (for bootstrapping).
* ''submitorder'', ''checkorder'', and ''reply'' - Used when performing an [[IP address|IP transaction]].
* ''alert'' - Send a network alert.
* ''ping'' - Does nothing. Used to check that the connection is still online. A TCP error will occur if the connection has died.

More information and in-depth technical information is in the [[Protocol Specification]].

== Connection ==

To connect to a peer, you send a ''version'' message containing your version number, block count, and current time. The remote peer will send back a ''verack'' message and his own ''version'' message if he is accepting connections from your version. You will respond with your own ''verack'' if you are accepting connections from his version.

The time data from all of your peers is collected, and the median is used by Bitcoin for all network tasks that use the time (except for other version messages).

You then exchange ''getaddr'' and ''addr'' messages, storing all addresses that you don't know about. Normally ''addr'' messages only contain one address, but in this initial exchange it contains many recent peers.

== Standard relaying ==

When someone sends a transaction, they send an ''inv'' message containing it to all of their peers. Their peers will request the full transaction with ''getdata''. If they consider the transaction valid after receiving it, they will also broadcast the transaction to all of their peers with an ''inv'', and so on. Peers only ask for or relay transactions if they don't already have them. A peer will never rebroadcast a transaction that it already knows about, though transactions will eventually be forgotten if they don't get into a block after a while. The sender and receiver of the transaction will rebroadcast, however.

Anyone who is generating will collect valid received transactions and work on including them in a block. When someone does find a block, they send an ''inv'' containing it to all of their peers, as above. It works the same as transactions.

Everyone broadcasts an ''addr'' containing their own IP address every 24 hours. Nodes relay these messages to a couple of their peers and store the address if it's new to them. Through this system, everyone has a reasonably clear picture of which IPs are connected to the network at the moment. After connecting to the network, you get added to everyone's address database almost instantly because of your initial ''addr''.

Network alerts are broadcast with ''alert'' messages. No ''inv''-like system is used; these contain the entire alert. If a received alert is valid (signed by one of the people with the private key), it is relayed to all peers. For as long as an alert is still in effect, it is rebroadcast at the start of every new connection.

== Initial block download ==

At the start of a connection, you send a ''getblocks'' message containing the hash of the latest block you know about. If the peer doesn't think that this is the latest block, it will send an ''inv'' that contains up to 500 blocks ahead of the one you listed. You will then request all of these blocks with ''getdata'', and the peer will send them to you with ''block'' messages. After you have downloaded and processed all of these blocks, you will send another ''getblocks'', etc., until you have all of the blocks.

0.3.18 introduced new ''headers'' and ''getheaders'' messages. These are not currently used, but they will be used by non-generators to download block headers without the corresponding block bodies. Only the headers are necessary for verifying received transactions -- full blocks are only needed by generators. Instead of the ''getblocks/inv/getdata/block'' sequence, non-generators will send a ''getheaders'' message (very like ''getblocks''), and the peer will immediately respond with a ''headers'' message containing up to 2,000 of the next headers. This will make initial block download ''much'' faster.

== Bootstrapping ==

You choose which peers to connect to by sorting your address database by the time since you last saw the address and then adding a bit of randomization.

Bitcoin has two methods of finding peers.

=== IRC ===

Bitcoin joins the #bitcoin channel on irc.lfnet.org. Your nick is set to an encoded form of your IP address. By decoding all the nicks of all users on the channel, you get a list of all IP addresses currently connected to Bitcoin.

For hosts that cannot make outbound connections on port 6667, the lfnet servers are also [[FAQ#Do_I_need_to_configure_my_firewall_to_run_bitcoin?|listening on port 7777]].

=== Addr ===

The ''addr'' messages described above create an effect similar to the IRC bootstrapping method. You know reasonably quickly whenever a peer joins, though you won't know for a while when they leave.

Bitcoin comes with a list of addresses known as "seed nodes". If you are unable to connect to IRC and you've never connected to the network before, the client will update the address database by connecting to one of the nodes from this list.

The -addnode command line option can be used to manually add a node. The -connect option can force bitcoin to only connect to a specific node.

== Heartbeat ==

If thirty minutes or more has passed since the client has transmitted any messages it will transmit a message to keep the connection to the peer node alive.

If ninety minutes has passed since a peer node has communicated any messages, then the client will assume that connection has closed.

== See Also ==

* [[Protocol Specification]]

[[Category:Technical]]

Talk:The way To manufacture a Realistic Water Text Effect

2011-05-24T20:14:43Z

BlueMatt:

This has nothing to do with Bitcoin. Not sure why it exists here. - [[User:Sgornick|Sgornick]] 11:34, 23 May 2011 (GMT)

Should be deleted [[User:BlueMatt|BlueMatt]] 20:14, 24 May 2011 (GMT)

Talk:The way To manufacture a Realistic Water Text Effect

2011-05-24T20:14:29Z

BlueMatt:

This has nothing to do with Bitcoin. Not sure why it exists here. - [[User:Sgornick|Sgornick]] 11:34, 23 May 2011 (GMT)
Should be deleted [[User:BlueMatt|BlueMatt]] 20:14, 24 May 2011 (GMT)

BIP 0020

2011-05-09T16:10:54Z

BlueMatt: Undo revision 8182 by Luke-jr (talk)

This is about creating a URI scheme for bitcoin.
Previous discussion was in [http://www.bitcoin.org/smf/index.php?topic=55.0 this forum thread].
x-btc specification is at [[x-btc]].

==RFC 3986==
'''the following is taken from wikipedia'''

Internet standard [http://rfc.net/std0066.html STD 66] (also RFC 3986) defines the generic syntax to be used in all URI schemes. Every URI is defined as consisting of four parts, as follows:

<code><nowiki><scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]</nowiki></code>

The '''scheme name''' consists of a letter followed by any combination of letters, digits, and the plus ("+"), period ("."), or hyphen ("-") characters; and is terminated by a colon (":").

The '''hierarchical part''' of the URI is intended to hold identification information hierarchical in nature. Usually this part begins with a double forward slash ("//"), followed by an ''authority'' part and an optional ''path''.

* The '''authority''' part holds an optional user information part terminated with "@" (e.g. <code><nowiki>username:password@</nowiki></code>), a hostname (i.e. domain name or IP address), and an optional port number preceded by a colon ":".

* The '''path''' part is a sequence of segments (conceptually similar to directories, though not necessarily representing them) separated by a forward slash ("/"). Each segment can contain parameters separated from it using a semicolon (";"), though this is rarely used in practice.

The '''query''' is an optional part separated with a question mark, which contains additional identification information which is not hierarchical in nature. The query string syntax is not generically defined, but is commonly organized as a sequence of <code><nowiki><key>=<value></nowiki></code> pairs separated by a semicolon<ref>
RFC 1866 section 8.2.1 : by Tim Berners-Lee in 1995 encourages CGI authors to support ';' in addition to '&'.
</ref><ref>
[http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.2.2 HTML 4.01 Specification: Implementation, and Design Notes]: "CGI implementors support the use of ";" in place of "&" to save authors the trouble of escaping "&" characters in this manner."
</ref><ref>
[http://www.w3.org/MarkUp/html-spec/html-spec_foot.html#FOOT26 Hypertext Markup Language - 2.0]
"CGI implementors are encouraged to support the use of ';' in place of '&' "
</ref> or separated by an ampersand, for example:
Semicolon: <code><nowiki>key1=value1;key2=value2;key3=value3</nowiki></code>
Ampersand: <code><nowiki>key1=value1&key2=value2&key3=value3</nowiki></code>

The '''fragment''' is an optional part separated from the front parts by a hash ("#"). It holds additional identifying information that provides direction to a secondary resource, e.g. a section heading in an article identified by the remainder of the URI. When the primary resource is an HTML document, the '''fragment''' is often an <code>id</code> attribute of a specific element and web browsers will make sure this element is visible.

==Proposed specification==

[] means optional, <> are placeholders

bitcoin:<address>[?][amount=<size>][&][label=<label>][&][message=<message>]

=== Query Keys ===

*label: Label for that address (e.g. name of receiver)
*address: bitcoin address
*message: optional message that is shown to the user after scanning the QR code
*size: amount of bitcoins (full Decimal BitCoins)

==== Transfer amount/size ====

If an amount is provided, it may be specified in standard BTC decimal units.

=== Examples ===

Just the address:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L

Address with name:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?label=Luke-Jr

Request to send 20.30 BTC to "Luke-Jr":
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=20.3&label=Luke-Jr

Request to send 100 TBC:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=0.16777216

Request to send 5 uBTC:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=0.000005

Request to send 50 BTC with message:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=50&label=Luke-Jr&message=Donation%20for%20project%20xyz

Characters must be URI encoded properly.

=== BNF syntax ===

bitcoinurn = "bitcoin:" bitcoinaddress [ ";version=" bitcoinversion ] [ "?" bitcoinparams ]
bitcoinaddress = FIXME :)
bitcoinversion = "1.0"
bitcoinparams = *bitcoinparam
bitcoinparam = amountparam | labelparam | messageparam
amountparam = "amount=" amount
amount = amountdecimal | amounthex
amountdecimal = digits [ "X" digits ]
amounthex = "x" hexdigits [ "X" hexdigits ]
labelparam = "label=" *uchar
messageparam = "label=" *uchar

=== Parsing amount ===
Note that most of these have support for more specifiers of amount and have capabilities beyond what is needed to support this specification.
==== ECMAScript ====
reAmount = /^(([\d.]+)(X(\d+))?|x([\da-f]*)(\.([\da-f]*))?(X([\da-f]+))?)$/i;
function parseAmount(txt) {
var m = txt.match(reAmount);
return m[5] ? (
(
parseInt(m[5], 16) +
(m[7] ? (parseInt(m[7], 16) * Math.pow(16, -(m[7].length))) : 0)
) * (
m[9] ? Math.pow(16, parseInt(m[9], 16)) : 0x10000
)
) : (
m[2]
*
(m[4] ? Math.pow(10, m[4]) : 1e8)
);
}

==== Python ====
m = re.match(r'^(([\d.]+)(X(\d+))?|x([\da-f]*)(\.([\da-f]*))?(X([\da-f]+))?)$', amount, re.IGNORECASE)
if m.group(5):
amount = float(int(m.group(5), 16))
if m.group(7):
amount += float(int(m.group(7), 16)) * pow(16, -(len(m.group(7))))
if m.group(9):
amount *= pow(16, int(m.group(9), 16))
else:
amount *= 0x10000
else:
amount = Decimal(m.group(2))
if m.group(4):
amount *= 10 ** int(m.group(4))
else:
amount *= 100000000

==== C# ====
Regex amountExpression = new Regex(@"^(([\d.]+)(X(\d+))?|x([\da-f]*)(\.([\da-f]*))?(X([\da-f]+))?)$", RegexOptions.IgnoreCase);
Match match = amountExpression.Match(value);
if (match.Success)
{
if (match.Groups[5].Success)
{
long hexDecimal = 0;
if (match.Groups[7].Success)
hexDecimal = Convert.ToInt64(match.Groups[7].Value, 16) * (long)Math.Pow(16, -match.Groups[7].Length);

long hexExponent = 0x10000;
if (match.Groups[9].Success)
hexExponent = (long)Math.Pow(16, Convert.ToInt32(match.Groups[9].Value, 16));

Amount = (Convert.ToInt64(match.Groups[5].Value, 16) + hexDecimal) * hexExponent;
}
else
{
long decimalExponent = 100000000;
if (match.Groups[4].Success)
decimalExponent = (long)Math.Pow(10, int.Parse(match.Groups[4].Value));
Amount = (long)(decimal.Parse(match.Groups[2].Value) * decimalExponent);
}
}

==Requirements==

===Payment identifiers, not person identifiers===
In my opinion, the most basic idea of the URI scheme (as this is a currency) is to facilitate payment. So the URIs should represent first and foremost payments. If it represents something else, this needs to be specified. Thus
<code>
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L
</code>
represents a '''payment''' to me using my bitcoin address, not my bitcoin address itself. So after parsing the URI (via link/qr/whatever) the application should open a transaction window with the address filled in. You then need to add an amount and confirm the payment.
If your application is smart, it will also have a button "just store the address". But the point I am trying to make is that the default use of the URI should be for payment, nor for exchanging addresses.

===Accessibility===
'''Imported from the forum:''' I like the simplicity of bitcoin:xxxxxxxxxxxxx and very much approve of its accessibility. Should someone from the outside happen to see such a URI, the protocol name already gives a description. A quick google search should then do the rest. x-btc sounds much more cryptic; the chance that someone googles that out of curiosity are much slimmer. Also, very likely, what s/he will find are mostly technical specifications. Not a good introduction to bitcoin.

For the same reason I am for using '&' as a delimiter for key-value pairs. People know it from URLs. Make it easy for people to understand what is going on.

===Keep it simple===
Don't explicitly write down information that can be inferred. Don't mark the address as an address. If there is no address, this does lose much of its utility. We could, however, specify 'address' as a reserved word, so that <code>
bitcoin:address?amount=50X8
</code>
would initiate a transaction with the amount filled in, but with a blank address. I am not convinced that there is a use case, though.

===Use-cases===
Before the URI scheme is finalised one should think long and hard about use cases. in what circumstances will which people use this, and for what?
* an online shop has a 'buy this' link, which uses the URI scheme.
**PROBLEM: click on the link opens the application; how does the merchant notice this?
***POSSIBLE SOLUTION: javascript can detect the click.
***POSSIBLE SOLUTION: the checkout site checks its bitcoin account for payment via HTTP request.
**PROBLEM: the time problem (~10 minutes) is very apparent here; nobody wants to wait 10 minutes for the transaction to be confirmed.
* a person only has an online client, no actual application
**PROBLEM: how to redirect the URI so that the online client gets a notice?
***POSSIBLE SOLUTION: Small application and/or browser plugins to redirect the handler call to the designated online wallet.

===Backwards compatibility===
We want URIs generated in 2011 to still work in 2036. Think about extensibility. Of course we can make only educated guesses (and nothing more!) about the future, but don't act as if there is none. This should be the best we can do, but it should not be seen as set in stone. Make it possible for later generations to improve our work, to mend our errors, without breaking the URIs created now. Version incompatibility is the easiest thing to drive users crazy: "I just upgraded to this shiny new version. What? It doesn't support the old format? AAAAAAARRRGH!"

==References==
<references/>

BIP 0020

2011-05-09T14:20:50Z

BlueMatt: Changed to match the new spec as voted on in the forums quite a while ago.

Fallback Nodes

2011-05-03T10:29:49Z

BlueMatt: /* IPv4 Nodes */

This is a list of nodes which are considered reliable. Nodes from this list which are down for more than 24 hours will be automatically removed and status of each node is displayed and updated every hour by [[User:WikiBot|WikiBot]].

== How to use this list ==

=== Connect to nodes ===

You can connect to these nodes with the ''-addnode=ip'' switch instead of the usual node harvesting process (through IRC or via the embedded nodelist). You can connect to more than one node by using ''-addnode=ip'' more than once. It is usually a good idea to connect to more than one of these nodes.

==== Nodes without a fixed ip ====

If the node IP is not fixed (see "Fixed" column), you will have to resolve the node's name (first column) each time the IP changes. Some nodes may have their ip change once a day, some others once a month, and some others may stay on the same IP for years. Still, as long as the IP is not fixed, there is no guarantee it will stay the same.

The [[Original Bitcoin client]] do not support hostnames to the ''-addnode'' parameter, so you must do the resolving part for it. For example on linux:
bitcoind -addnode=$(host theymos.ath.cx |sed s/"^.*has address "//)

=== IP Transactions ===

You can also send [[IP Transactions]] to these nodes. If you include your bitcoin address in the "message" field, you may have your coins back.

=== Tor network ===

To use tor .onion addresses, you need to map virtual ips via the ''torrc'' file:

mapaddress 192.0.2.2 ijzt2eeizty3p5xe.onion
mapaddress 192.0.2.3 j43z65b6r2usg3vk.onion
mapaddress 192.0.2.4 pvuif6nonbhj3o3r.onion

Once you have configured and restarted tor, 192.0.2.2 will connect to ijzt2eeizty3p5xe.onion when accessed through the Tor proxy (and likewise for the other IPs/onions). You can then run Bitcoin with -addnode=192.0.2.2, or even send bitcoins to that IP address. You can use any arbitrary IP addresses with MapAddress, though some of the common non-routable ranges (10.*, 192.168.*) will not work due to a Bitcoin bug. 192.0.2.1-192.0.2.255 is the recommended range because it is both non-routable and compatible with Bitcoin.

== Nodes list ==

=== IPv4 Nodes ===

{|class="wikitable sortable"
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-

| ndrix.com || mndrix || 64.22.103.150 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.21}} || 2011-04-17 12:00:08 || ?
|-
| 69.164.218.197 || Gavin Andresen || 69.164.218.197 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.21}} || 2011-04-17 12:00:08 || ?
|-
| jun.dashjr.org || Lightfoot Hosting || 173.242.112.53 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.21}} || 2011-04-17 12:00:08 || ?
|-
| mining.bitcoin.cz || slush || 178.79.147.99 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.21}} || 2011-04-17 12:00:08 || No
|-
| 217.157.1.202 || kseistrup || 217.157.1.202 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.21}} || 2011-04-17 12:00:09 || ?
|-
| bitcoin.csy.ca || Martok || 128.189.187.27 || {{Table Value Unknown}} || {{Fallback Nodes/Node Up|version=0.3.21}} || 2011-04-17 12:00:09 || ?
|-
| nat.router.dashjr.org || Luke-Jr || 71.1.74.69 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.3.21}} || 2011-04-17 12:00:10 || ?
|-
| bitcoin.sipa.be || sipa || 178.18.90.41 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.3.21}} || 2011-04-17 12:00:10 || No
|-
| bluematt.me || BlueMatt || 62.155.236.249 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.3.21}} || 2011-05-03 12:29:00 || No
|-
| bitcoin.chrishowie.com || cdhowie || 68.169.45.99 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-04-17 12:00:10 || No
|-
| btc1.justmoon.net || justmoon || 109.75.176.226 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-04-17 12:00:10 || Yes
|-
| bitcoins.ca || humble || 142.58.248.28 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-04-17 12:00:10 || Yes
|-
| BiddingPond.com || BiddingPond || 184.106.111.41 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-04-17 12:00:10 || ?
|-
| bitcoin.isdigital.com || joecolotti || 50.7.251.192 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-04-17 12:00:11 || Yes
|-
| zack.home.chrishowie.com || cdhowie || 98.222.140.181 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-04-17 12:00:11 || No
|-
| 178.63.15.200 || hendi || 178.63.15.200 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.1]}} || 2011-04-17 12:00:11 || ?
|-
| theymos.ath.cx || theymos || 99.27.237.13 || {{Table Value Unknown}} || {{Fallback Nodes/Node Up|version=0.3.19[.2]}} || 2011-04-17 12:00:12 || Yes
|-
| fallback1.bitcoin.me.uk || Vladimir || 91.85.220.84 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.19}} || 2011-04-17 12:00:12 || No
|-
| 109.75.176.193 || MagicalTux [DE] || 109.75.176.193 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.19}} || 2011-04-17 12:00:12 || No
|-
| 173.224.125.222 || MagicalTux [US] || 173.224.125.222 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.19}} || 2011-04-17 12:00:12 || No
|-
| 178.63.62.15 || MagicalTux [DE] || 178.63.62.15 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.19}} || 2011-04-17 12:00:12 || No
|-
| bitlex.co.cc || BitLex || 78.34.69.123 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.3.19}} || 2011-04-17 12:00:13 || Yes
|-
| 74.82.216.10 || thufir || 74.82.216.10 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.10}} || 2011-04-17 12:00:13 || Yes
|-
| 74.57.236.239 || ? || 74.57.236.239 || {{Table Value Yes}} || {{Fallback Nodes/Node Old|version=0.3.0}} || 2011-04-17 12:00:13 || ?
|-
| 67.176.86.181 || BobSGI || 67.176.86.181 ||
|-
| BTCSportsBet.com || Cusipzzz || 109.75.176.39 || {{Table Value Yes}}

|}

=== Tor nodes ===

{|class="wikitable sortable"
! Hostname !! Owner !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-
| ijzt2eeizty3p5xe.onion || ? || ? || 2011-02-11 || Yes
|-
| j43z65b6r2usg3vk.onion || Dybbuk || ? || 2011-02-11 || Yes
|-
| pvuif6nonbhj3o3r.onion || ? || ? || 2011-02-11 || Yes
|-
| c5qvugpewwyyy5oz.onion || ? || ? || 2011-02-11 || Yes
|-
| vso3r6cmjoomhhgg.onion || echelon || ? || 2011-02-11 || Yes
|-
| rnam4cxam62nkcyf.onion || BitLex || ? || 2011-02-11 || Yes
|-
| bitcoinbudtoeks7.onion || ? || ? || 2011-02-11 || ?
|-
| iy6ni3wkqazp4ytu.onion || ? || ? || 2011-02-11 || ?
|-
| h4kklwodpcmo6cbq.onion || ? || ? || 2011-02-11 || ?
|-
| vv6kcfscuntybrzm.onion || ? || ? || 2011-02-11 || ?
|-
| nlnsivjku4x4lu5n.onion || ? || ? || 2011-02-11 || ?
|-
| xqzfakpeuvrobvpj.onion || ? || ? || 2010-11-13 || No
|}

== Adding a node ==

Before adding yourself as a fallback node, you should be sure your node will stay online for a long time. If a node is offline for more than 24 hours it will be removed from the list. To accept IP transactions you will have to add the ''-allowreceivebyip'' flag to your command line parameters.

To add a node in this list, you just need the ip/hostname and your name, the other fields will be filled automatically. Insert the following lines before the <tt>END NODELIST</tt> line:

<nowiki>|-
| ip || your name</nowiki>

Please note that a bot will connect to your node every hour to check its status and version.