Bitcoin Wiki - User contributions [en]

Laszlo Hanyecz

2024-02-16T00:50:00Z

Nealmcb: Update price for 2021 peak?

{{infobox person|name=Laszlo Hanyecz|image=
|names=laszlo, laszloh
|active=2010-2011, 2014
|knownfor=First buyer of a good
|bitcointalk=[https://bitcointalk.org/index.php?action=profile;u=143 laszlo]}}
'''Laszlo Hanyecz''' ('''laszlo''') made the first documented purchase of a good with bitcoin when he bought two Domino's pizzas from [[jercos]] for 10,000 BTC. laszlo had made contributions to Bitcoin's source code in the past.
==Pizza==
[[File:laszlospizza.jpg|thumb|left|The pizzas bought by laszlo]]On May 17, 2010, laszlo posted a request to buy pizza with bitcoin. It was on May 22 that he reported successfully trading 10,000 BTC for two pizzas, with '''jercos''' ordering the pizza and receiving the coins. The bitcoins were quoted at $41 at the time of the offer.
===Pizza Index===
The Pizza Index is the value of the bitcoins spent on the pizzas, were they to be sold rather than spent on pizza. It started at $41 when the transaction actually occurred, and rose significantly since then, topping at $600 million in November 2021.
===Bitcoin Pizza Day===
To commemorate the transaction, May 22 is dubbed '''Bitcoin Pizza Day'''. Pizza providers worldwide offer discounts to bitcoin users to commemorate laszlo's purchase.
[[Category:2010 events]]
[[Category:Notable transactions]]

Category:History

2011-11-23T22:04:19Z

Nealmcb: clarify peak market cap

* August 18, 2008
** Domain name "bitcoin.org" registered.
* October 31, 2008
** [http://article.gmane.org/gmane.comp.encryption.general/12588/ Bitcoin design paper] published
* November 09, 2008
** Bitcoin project registered at SourceForge.net
* January 3, 2009
** Genesis block established at 18:15:05 GMT
* January 11, 2009
** Bitcoin v0.1 released and announced on the [http://www.mail-archive.com/cryptography@metzdowd.com/msg10152.html cryptography mailing list]
* December 16, 2009
** Bitcoin v0.2 released
* December 30, 2009
** First difficulty increase at 06:11:04 GMT
* February 6, 2010
** [[Bitcoin Market]] established
* May 22, 2010
** laszlo first to buy pizza with Bitcoins [http://www.bitcoin.org/smf/index.php?topic=137.msg1195#msg1195 agreeing] upon paying 10,000 BTC for ~$25 worth of pizza courtesy of jercos
* July 7, 2010
** Bitcoin v0.3 released
* July 11, 2010
** Bitcoin v0.3 release [http://news.slashdot.org/story/10/07/11/1747245/Bitcoin-Releases-Version-03 mentioned on slashdot], bringing a large influx of new bitcoin users.
* July 12, 2010
** Beginning of a 10x increase in exchange value over a 5 day period, from about $0.008/BTC to $0.08/BTC
* July 17, 2010
** [[MtGox]] established
* July 18, 2010
** ArtForz generated his first block after establishing his personal OpenCL GPU hash farm
* August 15, 2010
** Bug in the bitcoin code allows a bad transaction into block 74638. Users quickly adopt fixed code and the "good" block chain overtook the bad one at a block height of 74691, 53 blocks later ([[Incidents#Value_overflow]]).
* September 14, 2010
** jgarzik [http://www.bitcoin.org/smf/index.php?topic=133.msg12921#msg12921 offered] 10,000 BTC (valued at ~$600-650) to puddinpop to open source their windows-based CUDA client
* September 18, 2010
** puddinpop [http://www.bitcoin.org/smf/index.php?topic=133.msg13135#msg13135 released] source to their windows-based CUDA client under MIT license
* September 29, 2010
** kermit [http://www.bitcoin.org/smf/index.php?topic=1306.0 discovered] a microtransactions exploit which precipitated the Bitcoin v0.3.13 release
* October 01, 2010
** First public OpenCL miner released
* October 04, 2010
** Original Bitcoin History wiki page (this page) established (ooh so meta) on Bitcoin.org's wiki.
* October 07, 2010
** Exchange rate started climbing up from $0.06/BTC after several flat months.
* October 28, 2010
** First bitcoin short sale transaction initiated, with a loan of 100 BTC by nanotube to [[User:Kiba|kiba]], facilitated by the [[Bitcoin-otc|#bitcoin-otc]] market.
* November 6, 2010
** The [http://www.bitcoin.org/smf/index.php?topic=1672 Bitcoin economy passed US $1 million]. The MtGox price touched USD $0.50/BTC.
* December 7, 2010
** Bitcoind was compiled for the Nokia N900 mobile computer by doublec. The following day, ribuck sent him 0.42 BTC in the first portable-to-portable Bitcoin transaction.
* December 9, 2010
** The generation difficulty passed 10,000.
** First bitcoin call option contract sold, from nanotube to [[User:Sgornick|sgornick]], via the [[Bitcoin-otc|#bitcoin-otc]] market.
* December 16, 2010
** [http://mining.bitcoin.cz/ Bitcoin Pooled Mining], operated by slush, found its first block
* January 2, 2011
** [[Tonal BitCoin]] units standardized.
* January 8, 2011
** [[History of Bitcoin]] page (this page) created after replicating from original Bitcoin History page on Bitcoin.org.
** Bitcoin Pooled Mining reached a total of 10,000 Mhash/s
* January 27, 2011
** Largest numeric value ever traded for bitcoins thus far occurred on this date. Three currency bills from Zimbabwe, known as Zimdollars, were traded on [[Bitcoin-otc|#bitcoin-otc]] at the rate of 4 BTC for each of the one-hundred trillion dollar ($100,000,000,000,000) Zimbabwe notes<ref>Serial numbers for Zimdollars sold: AA1669317, AA1669318 and AA1669319</ref>
* January 28, 2011
** Block 105000 was generated. This means that 5.25 million bitcoins have been generated, which is just over one-quarter of the eventual total of nearly 21 million.
* February 9, 2011
** Decimal Bitcoin reached parity with the US dollar, touching $1 per BTC at [[MtGox]].
* February 10, 2011
** Bitcoin.org website struggles to handle [http://www.bitcoin.org/smf/index.php?topic=3444.0 traffic] resulting from mentions on Slashdot<ref>[http://news.slashdot.org/story/11/02/10/189246/Online-Only-Currency-BitCoin-Reaches-Dollar-Parity Online-Only Currency BitCoin Reaches Dollar Parity]</ref>, Hacker News and Twitter following the news that parity had been reached.
* February 14, 2011
** A vehicle was, for the first time, offered in exchange for a certain number of bitcoins<ref>[http://www.bitcoin.org/smf/index.php?topic=3485.0 Car for Sale - Australia]</ref>.
* March 6, 2011
** Total Bitcoin network computation speed for a short time [http://bitcoin.sipa.be/speed-lin.png reached an all-time high of almost 900Ghash/sec], dropping to 500Ghash/sec soon after. Some speculate that this was due to some supercomputer or bot-net that joined the network ([http://bitcoin.atspace.com/mysteryminer.html mystery miner]).
* March 18, 2011
** BTC/USD exchange rate reaches a 6-week low point at almost $0.70/BTC, after what appeared to be a short burst of, possibly automated, BTC sales at progressively lower prices. BTC price had been declining since the February 9 high.
* March 25, 2011
** Difficulty decreased nearly 10%. A decrease has only occurred once before, and this decrease of nearly 10% was the largest.
* March 27, 2011
** The first market for exchanging bitcoins to and from the British Pound Sterling BTC/GBP, [[Britcoin]], opens.
* March 31, 2011
** The first market for exchanging bitcoins to and from Brazilian Reals, [[Bitcoin Brazil]], opens.
* April 5, 2011
** The first market for exchanging bitcoins to and from the Polish złoty, [[BitMarket.eu]], opens.
* April 12, 2011
** First bitcoin put option contract sold via the [[Bitcoin-otc|#bitcoin-otc]] market.
* April 16, 2011
** TIME does [http://techland.time.com/2011/04/16/online-cash-bitcoin-could-challenge-governments/ an article on Bitcoin].
* April 23, 2011
** BTC/USD exchange rate reaches and passes parity with the Euro (EUR) on [[MtGox]] exchange.
** BTC/USD exchange rate reaches and passes parity with the British Sterling Pound (GBP) on [[MtGox]] exchange.
** Value of the Bitcoin money stock at current exchange rate passes $10 million USD threshold.
* April 27, 2011
** [[VirWoX]] opens first market to trade bitcoins against a virtual currency on BTC/SL (Second Life Lindens) exchange.
* April 28, 2011
** Block [http://blockexplorer.com/b/120630 120,630] is first to be mined using split allocation of the generation reward.
* April 30, 2011
** The generation difficulty passed 100,000.
* June 2, 2011
** The exchange rate at [[MtGox]] touched 10 USD per BTC.
* June 3, 2011
** [[Tonal Bitcoin]] reached parity with the US cent, touching 1¢ per TBC at [[Bitcoin Market]].
* June 8, 2011
** The [[MtGox]] exchange rate peaked at 31.91 USD, at a "market capitalization" of about $206 M [http://bitcoin.stackexchange.com/questions/2047/market-capitalization-over-time].
* June 12, 2011
** The [[MtGox]] exchange rate briefly dropped to near 10 USD four days after the peak, in its largest percentage price retreat to date.
* June 13, 2011
** Forum user allinvain claimed to have had [http://forum.bitcoin.org/index.php?topic=16457.0 25,000 BTC stolen] from his Bitcoin wallet (approx. USD equivalent $375,000).
* June 19, 2011
** The MtGox database was compromised and the user table was leaked, containing details of 60,000 usernames, email addresses and password hashes, some of which were based on a highly vulnerable hashing algorithm.
* June 19, 2011
** Someone was able to access an admin account at MtGox and issue sell orders for hundreds of thousands of fake bitcoins, forcing the MtGox price down from $17.51 per bitcoin to $0.01. MtGox announced that these trades would be reversed. Trading was halted at MtGox for 7 days (and also briefly at TradeHill and Britcoin while their security was reviewed).
* June 19, 2011
** Some of the users on the leaked MtGox database had used the same username at MyBitcoin and had their passwords hacked. About 600 of them had their balance [http://forum.bitcoin.org/index.php?topic=22221.msg279396#msg279396 stolen from their MyBitcoin accounts]. One user lost over 2000 BTC.
* June 20, 2011
** The EFF announced that it was no longer accepting Bitcoin donations due to legal uncertainties.
* June 24, 2011
** The generation difficulty passed 1,000,000 with Block [http://blockexplorer.com/b/133056 133056].
* July 22, 2011
** [[BitCoins Mobile]], the first Bitcoin application for iPad was released by [http://www.intervex.net Intervex Digital].
* August 20, 2011
** First Bitcoin Conference and World Expo held -- in NYC.
* August 23, 2011
** [[P2Pool]], the first P2P decentralized pool, mines its first Bitcoin mainnet block (Block [http://blockexplorer.com/b/142312 142,312]).
* August 30, 2011
** Difficulty adjustment at block [http://blockexplorer.com/b/143136 143,136] marks the first back-to-back drop.
* November 15, 2011
** First CVE (CVE-2011-4447) assigned to a Bitcoin client exploit.

==References==
<references />

Bitcoin Days Destroyed

2011-09-17T16:17:26Z

Nealmcb: distinguish percent-based measures from raw

Bitcoin Days Destroyed is a measure of the transaction volume of Bitcoin. <ref>[http://forum.bitcoin.org/index.php?topic=6172.msg90789#msg90789 ByteCoin's Proposal to use Bitcoin Days Destroyed as a measure of transaction volume]</ref> A bounty for a script to compute the Bitcoin Days Destroyed by the transactions in a block has been awarded. <ref>[http://forum.bitcoin.org/index.php?topic=9300.0 Bounty Award to develop a script to compute the BitcoinDays Destroyed by the transactions in a block.]</ref> [[Abe]] is a [[block chain browser]] that computes this statistic in real time.

==Calculation==

===Example===

If someone has 100BTC that they received a week ago and they spend it then 700 bitcoin days have been destroyed. If they take those 100BTC and send them to several addresses and then spend them then although the total transaction volume could be arbitrarily large the number of bitcoindays destroyed is still 700.

==Graph of Percentage of Bitcoin Days Destroyed==

Percentage of Bitcoin Days destroyed vs block number, as of June 17th 2011.
[[File:June-17th-days-destroyed.png]]

==See Also==

* [[Abe]] Alternate Block Explorer

==External Links==

* [http://abe.john-edwin-tobey.org/chain/Bitcoin?count=2016 Percent BitcoinDays Destroyed Metric - Previous 2016 blocks]
* [http://banana.mine.nu/daysdest.html Real-time BitcoinDays Destroyed Chart]

==References==
<references/>

[[Category:Economics]]

Block hashing algorithm

2011-07-20T00:37:08Z

Nealmcb: 256 bits

When generating, you constantly hash the block header. The block is also occasionally updated as you are working on it. A block header contains these fields:
{| class="wikitable"
|-
! Field
! Purpose
! Updated when...
! Size (Bytes)
|-
|Version
|Block version number
|You upgrade the software and it specifies a new version
|4
|-
|Previous hash
|Hash of the previous block
|A new block comes in
|32
|-
|Merkle root
|256-bit hash based on all of the transactions
|A transaction is accepted
|32
|-
|Timestamp
|Current timestamp
|Every few seconds
|4
|-
|"Bits"
|Current [[target]] in compact format
|The [[difficulty]] is adjusted
|4
|-
|Nonce
|32-bit number (starts at 0)
|A hash is tried (increments)
|4
|}

The body of the block contains the transactions. These are hashed only indirectly through the Merkle root. Because transactions aren't hashed directly, hashing a block with 1 transaction takes exactly the same amount of effort as hashing a block with 10,000 transactions.

Most of these fields will be the same for all users. There might be some minor variation in the timestamps. The nonce will usually be different, but it increases in a strictly linear way. "Nonce" starts at 0 and is incremented for each hash. Whenever Nonce overflows (which it does frequently), the extraNonce portion of the generation transaction is incremented, which changes the Merkle root.

Given just those fields, people would frequently generate the exact same sequence of hashes as each other and the fastest CPU would almost always win. However, it is (nearly) impossible for two people to have the same Merkle root because the first transaction in your block is a generation "sent" to one of ''your'' unique Bitcoin addresses. Since your block is different from everyone else's blocks, you are (nearly) guaranteed to produce different hashes. Every hash you calculate has the same chance of winning as every other hash calculated by the network.

Bitcoin uses: SHA256(SHA256(Block_Header)) but you have to be careful about byte-order.

For example, this python code will calculate the hash of the block with the smallest hash as of June 2011, [http://blockexplorer.com/block/00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d Block 125552]. The header is built from the six fields described above, concatenated together as little-endian values in hex notation:

>>> import hashlib
>>> header_hex = ("01000000" +
"81cd02ab7e569e8bcd9317e2fe99f2de44d49ab2b8851ba4a308000000000000" +
"e320b6c2fffc8d750423db8b1eb942ae710e951ed797f7affc8892b0f1fc122b" +
"c7f5d74d" +
"f2b9441a" +
"42a14695")
>>> header_bin = header_hex.decode('hex')
>>> hash = hashlib.sha256(hashlib.sha256(header_bin).digest()).digest()
>>> hash.encode('hex_codec')
'1dbd981fe6985776b644b173a4d0385ddc1aa2a829688d1e0000000000000000'
>>> hash[::-1].encode('hex_codec')
'00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d'

Note that the actual hash has lots of trailing zero bits when interpreted (by default) as a 256-bit big-endian number (in keeping with the big-endian constants in the definition of SHA-256. But when interpreted as bitcoin does as a little-endian number, the hash has lots of leading zero bits, and this is what shows up e.g. in the output of blockexplorer.

For another example, [http://pastebin.com/n8UEGA86 here] is a version in plain C without any optimization, threading or error checking.

[[Category:Technical]]

Block hashing algorithm

2011-07-20T00:13:35Z

Nealmcb: use decode rather than binascii a2b

When generating, you constantly hash the block header. The block is also occasionally updated as you are working on it. A block header contains these fields:
{| class="wikitable"
|-
! Field
! Purpose
! Updated when...
! Size (Bytes)
|-
|Version
|Block version number
|You upgrade the software and it specifies a new version
|4
|-
|Previous hash
|Hash of the previous block
|A new block comes in
|32
|-
|Merkle root
|256-bit hash based on all of the transactions
|A transaction is accepted
|32
|-
|Timestamp
|Current timestamp
|Every few seconds
|4
|-
|"Bits"
|Current [[target]] in compact format
|The [[difficulty]] is adjusted
|4
|-
|Nonce
|32-bit number (starts at 0)
|A hash is tried (increments)
|4
|}

The body of the block contains the transactions. These are hashed only indirectly through the Merkle root. Because transactions aren't hashed directly, hashing a block with 1 transaction takes exactly the same amount of effort as hashing a block with 10,000 transactions.

Most of these fields will be the same for all users. There might be some minor variation in the timestamps. The nonce will usually be different, but it increases in a strictly linear way. "Nonce" starts at 0 and is incremented for each hash. Whenever Nonce overflows (which it does frequently), the extraNonce portion of the generation transaction is incremented, which changes the Merkle root.

Given just those fields, people would frequently generate the exact same sequence of hashes as each other and the fastest CPU would almost always win. However, it is (nearly) impossible for two people to have the same Merkle root because the first transaction in your block is a generation "sent" to one of ''your'' unique Bitcoin addresses. Since your block is different from everyone else's blocks, you are (nearly) guaranteed to produce different hashes. Every hash you calculate has the same chance of winning as every other hash calculated by the network.

Bitcoin uses: SHA256(SHA256(Block_Header)) but you have to be careful about byte-order.

For example, this python code will calculate the hash of the block with the smallest hash as of June 2011, [http://blockexplorer.com/block/00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d Block 125552]. The header is built from the six fields described above, concatenated together as little-endian values in hex notation:

>>> import hashlib
>>> header_hex = ("01000000" +
"81cd02ab7e569e8bcd9317e2fe99f2de44d49ab2b8851ba4a308000000000000" +
"e320b6c2fffc8d750423db8b1eb942ae710e951ed797f7affc8892b0f1fc122b" +
"c7f5d74d" +
"f2b9441a" +
"42a14695")
>>> header_bin = header_hex.decode('hex')
>>> hash = hashlib.sha256(hashlib.sha256(header_bin).digest()).digest()
>>> hash.encode('hex_codec')
'1dbd981fe6985776b644b173a4d0385ddc1aa2a829688d1e0000000000000000'
>>> hash[::-1].encode('hex_codec')
'00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d'

Note that the actual hash has lots of trailing zero bits when interpreted (by default) as a 128-bit big-endian number (in keeping with the big-endian constants in the definition of SHA-256. But when interpreted as bitcoin does as a little-endian number, the hash has lots of leading zero bits, and this is what shows up e.g. in the output of blockexplorer.

For another example, [http://pastebin.com/n8UEGA86 here] is a version in plain C without any optimization, threading or error checking.

[[Category:Technical]]

Category:History

2011-07-17T14:41:43Z

Nealmcb: update mtgox breakin

* August 18, 2008
** Domain name "bitcoin.org" registered.
* October 31, 2008
** [http://article.gmane.org/gmane.comp.encryption.general/12588/ Bitcoin design paper] published
* November 09, 2008
** Bitcoin project registered at SourceForge.net
* January 3, 2009
** Genesis block established at 18:15:05 GMT
* January 11, 2009
** Bitcoin v0.1 released and announced on the [http://www.mail-archive.com/cryptography@metzdowd.com/msg10152.html cryptography mailing list]
* December 16, 2009
** Bitcoin v0.2 released
* December 30, 2009
** First difficulty increase at 06:11:04 GMT
* February 6, 2010
** [[Bitcoin Market]] established
* May 22, 2010
** laszlo first to buy pizza with Bitcoins [http://www.bitcoin.org/smf/index.php?topic=137.msg1195#msg1195 agreeing] upon paying 10,000 BTC for ~$25 worth of pizza courtesy of jercos
* July 7, 2010
** Bitcoin v0.3 released
* July 11, 2010
** Bitcoin v0.3 release [http://news.slashdot.org/story/10/07/11/1747245/Bitcoin-Releases-Version-03 mentioned on slashdot], bringing a large influx of new bitcoin users.
* July 12, 2010
** Beginning of a 10x increase in exchange value over a 5 day period, from about $0.008/BTC to $0.08/BTC
* July 17, 2010
** [[MtGox]] established
* July 18, 2010
** ArtForz generated his first block after establishing his personal OpenCL GPU hash farm
* August 15, 2010
** Bug in the bitcoin code allows a bad transaction into block 74638. Users quickly adopt fixed code and the "good" block chain overtook the bad one at a block height of 74691, 53 blocks later ([[Incidents#Value_overflow]]).
* September 14, 2010
** jgarzik [http://www.bitcoin.org/smf/index.php?topic=133.msg12921#msg12921 offered] 10,000 BTC (valued at ~$600-650) to puddinpop to open source their windows-based CUDA client
* September 18, 2010
** puddinpop [http://www.bitcoin.org/smf/index.php?topic=133.msg13135#msg13135 released] source to their windows-based CUDA client under MIT license
* September 29, 2010
** kermit [http://www.bitcoin.org/smf/index.php?topic=1306.0 discovered] a microtransactions exploit which precipitated the Bitcoin v0.3.13 release
* October 01, 2010
** First public OpenCL miner released
* October 04, 2010
** Original Bitcoin History wiki page (this page) established (ooh so meta) on Bitcoin.org's wiki.
* October 07, 2010
** Exchange rate started climbing up from $0.06/BTC after several flat months.
* October 28, 2010
** First bitcoin short sale transaction initiated, with a loan of 100 BTC by nanotube to [[User:Kiba|kiba]], facilitated by the [[Bitcoin-otc|#bitcoin-otc]] market.
* November 6, 2010
** The [http://www.bitcoin.org/smf/index.php?topic=1672 Bitcoin economy passed US $1 million]. The MtGox price touched USD $0.50/BTC.
* December 7, 2010
** Bitcoind was compiled for the Nokia N900 mobile computer by doublec. The following day, ribuck sent him 0.42 BTC in the first portable-to-portable Bitcoin transaction.
* December 9, 2010
** The generation difficulty passed 10,000.
** First bitcoin call option contract sold, from nanotube to [[User:Sgornick|sgornick]], via the [[Bitcoin-otc|#bitcoin-otc]] market.
* December 16, 2010
** [http://mining.bitcoin.cz/ Bitcoin Pooled Mining], operated by slush, found its first block
* January 2, 2011
** [[Tonal BitCoin]] units standardized.
* January 8, 2011
** [[History of Bitcoin]] page (this page) created after replicating from original Bitcoin History page on Bitcoin.org.
** Bitcoin Pooled Mining reached a total of 10,000 Mhash/s
* January 27, 2011
** Largest numeric value ever traded for bitcoins thus far occurred on this date. Three currency bills from Zimbabwe, known as Zimdollars, were traded on [[Bitcoin-otc|#bitcoin-otc]] at the rate of 4 BTC for each of the one-hundred trillion dollar ($100,000,000,000,000) Zimbabwe notes<ref>Serial numbers for Zimdollars sold: AA1669317, AA1669318 and AA1669319</ref>
* January 28, 2011
** Block 105000 was generated. This means that 5.25 million bitcoins have been generated, which is just over one-quarter of the eventual total of nearly 21 million.
* February 9, 2011
** Decimal Bitcoin reached parity with the US dollar, touching $1 per BTC at [[MtGox]].
* February 10, 2011
** Bitcoin.org website struggles to handle [http://www.bitcoin.org/smf/index.php?topic=3444.0 traffic] resulting from mentions on Slashdot<ref>[http://news.slashdot.org/story/11/02/10/189246/Online-Only-Currency-BitCoin-Reaches-Dollar-Parity Online-Only Currency BitCoin Reaches Dollar Parity]</ref>, Hacker News and Twitter following the news that parity had been reached.
* February 14, 2011
** A vehicle was, for the first time, offered in exchange for a certain number of bitcoins<ref>[http://www.bitcoin.org/smf/index.php?topic=3485.0 Car for Sale - Australia]</ref>.
* March 6, 2011
** Total Bitcoin network computation speed for a short time [http://bitcoin.sipa.be/speed-lin.png reached an all-time high of almost 900Ghash/sec], dropping to 500Ghash/sec soon after. Some speculate that this was due to some supercomputer or bot-net that joined the network ([http://bitcoin.atspace.com/mysteryminer.html mystery miner]).
* March 18, 2011
** BTC/USD exchange rate reaches a 6-week low point at almost $0.70/BTC, after what appeared to be a short burst of, possibly automated, BTC sales at progressively lower prices. BTC price had been declining since the February 9 high.
* March 25, 2011
** Difficulty decreased nearly 10%. A decrease has only occurred once before, and this decrease of nearly 10% was the largest.
* March 27, 2011
** The first market for exchanging bitcoins to and from the British Pound Sterling BTC/GBP, [[Britcoin]], opens.
* March 31, 2011
** The first market for exchanging bitcoins to and from Brazilian Reals, [[Bitcoin Brazil]], opens.
* April 5, 2011
** The first market for exchanging bitcoins to and from the Polish złoty, [[BitMarket.eu]], opens.
* April 12, 2011
** First bitcoin put option contract sold via the [[Bitcoin-otc|#bitcoin-otc]] market.
* April 16, 2011
** TIME does [http://techland.time.com/2011/04/16/online-cash-bitcoin-could-challenge-governments/ an article on Bitcoin].
* April 23, 2011
** BTC/USD exchange rate reaches and passes parity with the Euro (EUR) on [[MtGox]] exchange.
** BTC/USD exchange rate reaches and passes parity with the British Sterling Pound (GBP) on [[MtGox]] exchange.
** Value of the Bitcoin money stock at current exchange rate passes $10 million USD threshold.
* April 27, 2011
** [[VirWoX]] opens first market to trade bitcoins against a virtual currency on BTC/SL (Second Life Lindens) exchange.
* April 28, 2011
** Block [http://blockexplorer.com/b/120630 120,630] is first to be mined using split allocation of the generation reward.
* April 30, 2011
** The generation difficulty passed 100,000.
* May 10, 2011
** The exchange rate at [[MtGox]] touched 6 USD per BTC.
* June 3, 2011
** [[Tonal Bitcoin]] reached parity with the US cent, touching 1¢ per TBC at [[Bitcoin Market]].
* June 10, 2011
** The [[MtGox]] exchange rate peaked above 31 USD, before dropping to below 10 USD four days later, in its largest percentage price retreat to date.
* June 13, 2011
** Forum user allinvain claimed to have had [http://forum.bitcoin.org/index.php?topic=16457.0 25,000 BTC stolen] from his Bitcoin wallet (approx. USD equivalent $375,000).
* June 19, 2011
** The MtGox database was compromised and the user table was leaked, containing details of 60,000 usernames, email addresses and password hashes, some of which were based on a highly vulnerable hashing algorithm.
* June 19, 2011
** Someone was able to access an admin account at MtGox and issue sell orders for hundreds of thousands of fake bitcoins, forcing the MtGox price down from $17.51 per bitcoin to $0.01. MtGox announced that these trades would be reversed. Trading was halted at MtGox for 7 days (and also briefly at TradeHill and Britcoin while their security was reviewed).
* June 19, 2011
** Some of the users on the leaked MtGox database had used the same username at MyBitcoin and had their passwords hacked. About 600 of them had their balance [http://forum.bitcoin.org/index.php?topic=22221.msg279396#msg279396 stolen from their MyBitcoin accounts]. One user lost over 2000 BTC.
* June 20, 2011
** The EFF announced that it was no longer accepting Bitcoin donations due to legal uncertainties.
* June 24, 2011
** The generation difficulty passed 1,000,000 with Block [http://blockexplorer.com/b/133056 133056].

==References==
<references />

Protocol documentation

2011-07-15T19:37:05Z

Nealmcb: /* block */ link to details on Block hashing algorithm

Sources:
* [[Original Bitcoin client]] source

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

==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_.

=== Signatures ===

Bitcoin uses [http://en.wikipedia.org/wiki/Elliptic_curve_cryptography Elliptic Curve] [http://en.wikipedia.org/wiki/Digital_Signature_Algorithm Digital Signature Algorithm] (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 strings representing the coordinates of a point on the curve. Signatures use [http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER encoding] to pack the r and s components into a single byte stream (because this is what OpenSSL produces by default).

=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== 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)) (not included in version or verack)
|-
| ? || payload || uchar[] || The actual data
|}

The version and verack messages do not have a checksum, the payload starts 4 bytes earlier.

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 + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + 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 || 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'''.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 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_me || net_addr || The network address of the node emitting this message
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || The network address seen by the node emitting this message (ie, the address of the receiving node)
|-
| 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.
|-
| ? || sub_version_num || [[#Variable length string|var_str]] || Secondary Version information (0x00 if string is 0 bytes long)
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || int32_t || The last block received by the emitting node
|}

If the emitter of the packet has version >= 209, 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 (note the message header for this version message does not have a checksum):
<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 DA F6 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
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 DA F6 - Sender 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 - Recipient 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'' for clients >= 209. 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 ....

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
</pre>

=== addr ===

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

Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || Number of address entries
|-
| 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 || 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 || 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 at hash_start, up to hash_stop or 500 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getblocks again with the last known hash.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || the protocol version
|-
| 1+ || start count || 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>
$step = 1
loop until at genesis block:
store current block hash
move backwards by $step
if number of stored hashes > 10:
$step *= 2
store genesis block
</pre>

=== getheaders ===

Return a ''headers'' packet containing the headers for blocks starting at hash_start, up to hash_stop or 2000 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getheaders again with the last known hash. 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).

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || number of hash_start entries
|-
| 32+ || hash_start || char[32] || hash of the last known block of the emitting node
|-
| 32 || hash_stop || char[32] || hash of the last desired block. Set to zero to get as many blocks as possible (2000)
|}

=== 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 || 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 || 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 || var_int || The length of the signature script
|-
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization
|-
| 4 || 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 || uint64_t || Transaction Value
|-
| 1+ || pk_script length || 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 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
|-
| ? || txn_count || 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 || var_int || Number of block headers
|-
| 77x? || headers || block_header[] || Block headers
|}

=== 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.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || System message which is coded to convey some information to all nodes in the network
|-
| ? || signature || var_str || A signature which can be confirmed with a public key verifying that it is Satoshi (the originator of Bitcoins) who has "authorized" or created the message
|}

The signature is to be compared to this ECDSA public key:

04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

Source: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== 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]]

Miner fees

2011-07-15T17:11:18Z

Nealmcb: get new minimum in the article.... Still need more clarity on changes in 0.3.23 compared to previous versions

[[File:fee.png|thumb|Receiving a transaction fee of 0.44 BC]]
Transaction fees may be included with any transfer of bitcoins from one address to another. At the moment, many [[transactions]] are typically processed in a way where no fee is expected at all, but for transactions which draw coins from many bitcoin addresses and therefore have a large data size, a small transaction fee is usually expected.

The transaction fee is processed by and received by the bitcoin miner. When a new bitcoin block is generated with a successful hash, the information for all of the transactions is included with the block and all transaction fees are collected by that user creating the block, who is free to assign those fees to himself.

Transaction fees are voluntary on the part of the person making the bitcoin transaction, as the person attempting to make a transaction can include any fee or none at all in the transaction. On the other hand, nobody mining new bitcoins necessarily needs to accept the transactions and include them in the new block being created. The transaction fee is therefore an incentive on the part of the bitcoin user to make sure that a particular transaction will get included into the next block which is generated.

It is envisioned that over time the cumulative effect of collecting transaction fees will allow somebody creating new blocks to "earn" more bitcoins than will be mined from new bitcoins created by the new block itself. This is also an incentive to keep trying to create new blocks even if the value of the newly created block from the mining activity is zero in the far future.

It works like this:
* Whoever sends the transaction is often able to guess an appropriate fee based on their own fee rules. The [[Original Bitcoin client|original client]] will always assess the transaction, and if a fee will typically be expected, it will not allow you to send the transaction without the calculated fee.
* The user is prompted to confirm the fee before the transaction is sent.
* The sender makes a transaction with more coins in the ''In'' portion than the ''Out'' portion so that there are “leftovers” not assigned to any address.
* Whoever ends up publishing the [[block]] which contains this transaction will take these (and any other) leftover coins. They are included with their normal generated coins and is an extra bonus for creating the block.
* If a generating node receives a transaction that should include a transaction fee but doesn't, they may refuse to include it in their blocks. It might be included in a later block if someone is willing to accept it. Generators can't force a certain fee on transactions -- they can only accept or reject the transaction's “fee offer”.
[[File:lfm_fee.png|thumb|This balance is made entirely of 0.01 BTC cents. Since sending them requires a lot of data, a very large fee is required.]]

Different bitcoin clients and different versions have different rules for determining which transactions to accept and how large of a fee to send.

Current default rules for the original Bitcoin client (Bitcoin 0.3.23):
* minimum TX fee for new transactions reduced to 0.0005 BTC.

Original Bitcoin client version 0.3.20:
* 0.01 BTC fee if sending any transaction less than 0.01 BTC. This is to help prevent DoS attacks against the network. Remember: fees are not network-enforced, so it's still ''possible'' to send these small transactions without the fee -- you just have to generate the blocks that contain them yourself (after modifying Bitcoin).
* 0.01 BTC fee per kilobyte of transaction, but:
** If the blocksize (size of all transactions currently waiting to be included in a block) is less than 27 kB, transactions are free.
** If the blocksize is more than 250 kB, transactions get increasingly more expensive as the blocksize approaches the limit of 500 kB. Sending a transaction when the blocksize is 400 kB will cost 5 times the normal amount; sending when it's 499 kB will cost 500x, etc.
* Transactions within each fee tier are prioritized based on several factors. Most importantly, a transaction has more priority if the coins it is using have a lot of confirmations. Someone spamming the network will almost certainly be re-using the same coins, which will lower the priority of their transactions. Priority is also increased for transactions with more BTC, and reduced for transactions with more data.
* If the blocksize is over 4kB, free transactions in the above rules are only allowed if the transaction's priority is above a certain level.

Note that if you want to send a transaction with less than the default rules, or if you are a miner and want to include them in your blocks, you may need to peer with the [[Free transaction relay policy|Free transaction relay network]].

An advantage for bitcoin users to include a transaction fee is that the likelihood of getting a transaction included into the next block is going to be higher than if a transaction fee is not included. This is a trade off of time vs. money put forward on the transaction fees, as you can be patient with a low or non-existent fee included in a transaction, or you can make sure that the transaction is processed immediately by including a higher fee than is typical.

The rules are far from set in stone, and the network can support many different rules simultaneously. If there are 10 generating nodes that never require a transaction fee and your client is modified to never send any transaction fee, then your transactions will eventually be picked up by one of those free nodes when they generate a block, though it will probably take a very long time. In the far future, different rules about transaction fees among generating nodes will probably create a clear choice between fees and transaction speed. For example, you might choose to spend 2% for a guaranteed spot in the next block or 0.01% for the transaction to be sent in a few hours.

As an example, clients that have block generation turned off don't know what the current blocksize is, and will therefore never pay a fee on transactions under 10 kilobytes. If you notice that your sent transactions take a very long time to accrue confirmations, this is possibly the cause. If this happens a lot (probably because the network is under attack), run Bitcoin with the -paytxfee switch: -paytxfee=0.01 will force a minimum fee of 0.01 per kilobyte for all sent transactions, which will prioritize your transactions over all free transactions.
[[File:feesend.png|thumb|Sending a transaction when the sender doesn't have enough money to actually pay the fee]]

ArtForz, who makes up a large percentage of the network's CPU power, never charged transaction fees (even for micro-transactions) for a period of several months.

==Technical info==

Transaction priority is calculated as a value-weighted sum of input age, divided by transaction size in bytes:
priority = sum(input_value_in_base_units * input_age)/size_in_bytes
Transactions need to have a priority of above 57,600,000 to avoid the enforced limit (as of client version 0.3.21). This threshold is written in the code as COIN * 144 / 250, suggesting that the threshold represents a one day old, 1 btc coin (144 is the expected number of blocks per day) and a transaction size of 250 bytes.

So, for example, a transaction that has 2 inputs, one of 5 btc with 10 confirmations, and one of 2 btc with 3 confirmations, and has a size of 500bytes, will have a priority of
(500000000 * 10 + 200000000 * 3) / 500 = 11,800,000

==See Also==

* [[Free transaction relay policy]]

[[Category:Technical]]
[[Category:Vocabulary]]
[[Category:Mining]]

Block hashing algorithm

2011-07-13T17:35:40Z

Nealmcb: note endian issues and add simple in-line example

When generating, you constantly hash the block header. The block is also occasionally updated as you are working on it. A block header contains these fields:
{| class="wikitable"
|-
! Field
! Purpose
! Updated when...
! Size (Bytes)
|-
|Version
|Block version number
|You upgrade the software and it specifies a new version
|4
|-
|Previous hash
|Hash of the previous block
|A new block comes in
|32
|-
|Merkle root
|256-bit hash based on all of the transactions
|A transaction is accepted
|32
|-
|Timestamp
|Current timestamp
|Every few seconds
|4
|-
|"Bits"
|Current [[target]] in compact format
|The [[difficulty]] is adjusted
|4
|-
|Nonce
|32-bit number (starts at 0)
|A hash is tried (increments)
|4
|}

The body of the block contains the transactions. These are hashed only indirectly through the Merkle root. Because transactions aren't hashed directly, hashing a block with 1 transaction takes exactly the same amount of effort as hashing a block with 10,000 transactions.

Most of these fields will be the same for all users. There might be some minor variation in the timestamps. The nonce will usually be different, but it increases in a strictly linear way. "Nonce" starts at 0 and is incremented for each hash. Whenever Nonce overflows (which it does frequently), the extraNonce portion of the generation transaction is incremented, which changes the Merkle root.

Given just those fields, people would frequently generate the exact same sequence of hashes as each other and the fastest CPU would almost always win. However, it is (nearly) impossible for two people to have the same Merkle root because the first transaction in your block is a generation "sent" to one of ''your'' unique Bitcoin addresses. Since your block is different from everyone else's blocks, you are (nearly) guaranteed to produce different hashes. Every hash you calculate has the same chance of winning as every other hash calculated by the network.

Bitcoin uses: SHA256(SHA256(Block_Header)) but you have to be careful about byte-order.

For example, this python code will calculate the hash of the block with the smallest hash as of June 2011, [http://blockexplorer.com/block/00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d Block 125552]. The header is built from the six fields described above, concatenated together as little-endian values in hex notation:

>>> import hashlib, binascii
>>> header_hex = ("01000000" +
"81cd02ab7e569e8bcd9317e2fe99f2de44d49ab2b8851ba4a308000000000000" +
"e320b6c2fffc8d750423db8b1eb942ae710e951ed797f7affc8892b0f1fc122b" +
"c7f5d74d" +
"f2b9441a" +
"42a14695")
>>> header_bin = binascii.a2b_hex(header_hex)
>>> hash = hashlib.sha256(hashlib.sha256(header_bin).digest()).digest()
>>> hash.encode('hex_codec')
'1dbd981fe6985776b644b173a4d0385ddc1aa2a829688d1e0000000000000000'
>>> hash[::-1].encode('hex_codec')
'00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d'

Note that the actual hash has lots of trailing zero bits when interpreted (by default) as a 128-bit big-endian number (in keeping with the big-endian constants in the definition of SHA-256. But when interpreted as bitcoin does as a little-endian number, the hash has lots of leading zero bits, and this is what shows up e.g. in the output of blockexplorer.

For another example, [http://pastebin.com/n8UEGA86 here] is a version in plain C without any optimization, threading or error checking.

[[Category:Technical]]

Category:History

2011-06-06T20:02:07Z

Nealmcb: expand on block 74638 problem and touch up some other entries for consistency

* August 18, 2008
** Domain name "bitcoin.org" registered.
* October 31, 2008
** [http://article.gmane.org/gmane.comp.encryption.general/12588/ Bitcoin design paper] published
* November 09, 2008
** Bitcoin project registered at SourceForge.net
* January 3, 2009
** Genesis block established at 18:15:05 GMT
* January 11, 2009
** Bitcoin v0.1 released and announced on the [http://www.mail-archive.com/cryptography@metzdowd.com/msg10152.html cryptography mailing list]
* December 16, 2009
** Bitcoin v0.2 released
* December 30, 2009
** First difficulty increase at 06:11:04 GMT
* February 6, 2010
** [[Bitcoin Market]] established
* May 22, 2010
** laszlo first to buy pizza with Bitcoins [http://www.bitcoin.org/smf/index.php?topic=137.msg1195#msg1195 agreeing] upon paying 10,000 BTC for ~$25 worth of pizza courtesy of jercos
* July 7, 2010
** Bitcoin v0.3 released
* July 11, 2010
** Bitcoin v0.3 release [http://news.slashdot.org/story/10/07/11/1747245/Bitcoin-Releases-Version-03 mentioned on slashdot], bringing a large influx of new bitcoin users.
* July 12, 2010
** Beginning of a 10x increase in exchange value over a 5 day period, from about $0.008/BTC to $0.08/BTC
* July 17, 2010
** [[MtGox]] established
* July 18, 2010
** ArtForz generated his first block after establishing his personal OpenCL GPU hash farm
* August 15, 2010
** Bug in the bitcoin code allows a bad transaction into block 74638. Users quickly adopt fixed code and the "good" block chain overtook the bad one at a block height of 74691, 53 blocks later ([[Incidents#Value_overflow]]).
* September 14, 2010
** jgarzik [http://www.bitcoin.org/smf/index.php?topic=133.msg12921#msg12921 offered] 10,000 BTC (valued at ~$600-650) to puddinpop to open source their windows-based CUDA client
* September 18, 2010
** puddinpop [http://www.bitcoin.org/smf/index.php?topic=133.msg13135#msg13135 released] source to their windows-based CUDA client under MIT license
* September 29, 2010
** kermit [http://www.bitcoin.org/smf/index.php?topic=1306.0 discovered] a microtransactions exploit which precipitated the Bitcoin v0.3.13 release
* October 01, 2010
** First public OpenCL miner released
* October 04, 2010
** Original Bitcoin History wiki page (this page) established (ooh so meta) on Bitcoin.org's wiki.
* October 07, 2010
** Exchange rate started climbing up from $0.06/BTC after several flat months.
* October 28, 2010
** First bitcoin short sale transaction initiated, with a loan of 100 BTC by nanotube to [[User:Kiba|kiba]], facilitated by the [[Bitcoin-otc|#bitcoin-otc]] market.
* November 6, 2010
** The [http://www.bitcoin.org/smf/index.php?topic=1672 Bitcoin economy passed US $1 million]. The MtGox price touched USD $0.50/BTC.
* December 7, 2010
** Bitcoind was compiled for the Nokia N900 mobile computer by doublec. The following day, ribuck sent him 0.42 BTC in the first portable-to-portable Bitcoin transaction.
* December 9, 2010
** The generation difficulty passed 10,000.
** First bitcoin call option contract sold, from nanotube to [[User:Sgornick|sgornick]], via the [[Bitcoin-otc|#bitcoin-otc]] market.
* December 16, 2010
** [http://mining.bitcoin.cz/ Bitcoin Pooled Mining], operated by slush, found its first block
* January 2, 2011
** [[Tonal BitCoin]] units standardized.
* January 8, 2011
** [[History of Bitcoin]] page (this page) created after replicating from original Bitcoin History page on Bitcoin.org.
** Bitcoin Pooled Mining reached a total of 10,000 Mhash/s
* January 27, 2011
** Largest numeric value ever traded for bitcoins thus far occurred on this date. Three currency bills from Zimbabwe, known as Zimdollars, were traded on [[Bitcoin-otc|#bitcoin-otc]] at the rate of 4 BTC for each of the one-hundred trillion dollar ($100,000,000,000,000) Zimbabwe notes<ref>Serial numbers for Zimdollars sold: AA1669317, AA1669318 and AA1669319</ref>
* January 28, 2011
** Block 105000 was generated. This means that 5.25 million bitcoins have been generated, which is just over one-quarter of the eventual total of nearly 21 million.
* February 9, 2011
** Decimal Bitcoin reached parity with the US dollar, touching $1 per BTC at [[MtGox]].
* February 10, 2011
** Bitcoin.org website struggles to handle [http://www.bitcoin.org/smf/index.php?topic=3444.0 traffic] resulting from mentions on Slashdot<ref>[http://news.slashdot.org/story/11/02/10/189246/Online-Only-Currency-BitCoin-Reaches-Dollar-Parity Online-Only Currency BitCoin Reaches Dollar Parity]</ref>, Hacker News and Twitter following the news that parity had been reached.
* February 14, 2011
** A vehicle was, for the first time, offered in exchange for a certain number of bitcoins<ref>[http://www.bitcoin.org/smf/index.php?topic=3485.0 Car for Sale - Australia]</ref>.
* March 6, 2011
** Total Bitcoin network computation speed for a short time [http://bitcoin.sipa.be/speed-lin.png reached an all-time high of almost 900Ghash/sec], dropping to 500Ghash/sec soon after. Some speculate that this was due to some supercomputer or bot-net that joined the network ([http://bitcoin.atspace.com/mysteryminer.html mystery miner]).
* March 18, 2011
** BTC/USD exchange rate reaches a 6-week low point at almost $0.70/BTC, after what appeared to be a short burst of, possibly automated, BTC sales at progressively lower prices. BTC price had been declining since the February 9 high.
* March 25, 2011
** Difficulty decreased nearly 10%. A decrease has only occurred once before, and this decrease of nearly 10% was the largest.
* March 27, 2011
** The first market for exchanging bitcoins to and from the British Pound Sterling BTC/GBP, [[Britcoin]], opens.
* March 31, 2011
** The first market for exchanging bitcoins to and from Brazilian Reals, [[Bitcoin Brazil]], opens.
* April 5, 2011
** The first market for exchanging bitcoins to and from the Polish złoty, [[BitMarket.eu]], opens.
* April 12, 2011
** First bitcoin put option contract sold via the [[Bitcoin-otc|#bitcoin-otc]] market.
* April 16, 2011
** TIME does [http://techland.time.com/2011/04/16/online-cash-bitcoin-could-challenge-governments/ an article on Bitcoin].
* April 23, 2011
** BTC/USD exchange rate reaches and passes parity with the Euro (EUR) on [[MtGox]] exchange.
** BTC/USD exchange rate reaches and passes parity with the British Sterling Pound (GBP) on [[MtGox]] exchange.
** Value of the Bitcoin money stock at current exchange rate passes $10 million USD threshold.
* April 27, 2011
** [[VirWoX]] opens first market to trade bitcoins against a virtual currency on BTC/SL (Second Life Lindens) exchange.
* April 28, 2011
** Block [http://blockexplorer.com/b/120630 120,630] is first to be mined using split allocation of the generation reward.
* April 30, 2011
** The generation difficulty passed 100,000.
* May 10, 2011
** The exchange rate at [[MtGox]] touched 6 USD per BTC.
* June 3, 2011
** [[Tonal Bitcoin]] reached parity with the US cent, touching 1¢ per TBC at [[Bitcoin Market]].

==References==
<references />

Category:History

2011-06-06T19:33:28Z

Nealmcb: oops - get the increase factor right....

* August 18, 2008
** Domain name "bitcoin.org" registered.
* October 31, 2008
** [http://article.gmane.org/gmane.comp.encryption.general/12588/ Bitcoin design paper] published
* November 09, 2008
** Bitcoin project registered at SourceForge.net
* January 3, 2009
** Genesis block established at 18:15:05 GMT
* January 11, 2009
** Bitcoin v0.1 released and announced on the [http://www.mail-archive.com/cryptography@metzdowd.com/msg10152.html cryptography mailing list]
* December 16, 2009
** Bitcoin v0.2 released
* December 30, 2009
** First difficulty increase at 06:11:04 GMT
* February 6, 2010
** [[Bitcoin Market]] established
* May 22, 2010
** laszlo first to buy pizza with Bitcoins [http://www.bitcoin.org/smf/index.php?topic=137.msg1195#msg1195 agreeing] upon paying 10,000 BTC for ~$25 worth of pizza courtesy of jercos
* July 7, 2010
** Bitcoin v0.3 released
* July 11, 2010
** Bitcoin v0.3 release [http://news.slashdot.org/story/10/07/11/1747245/Bitcoin-Releases-Version-03 mentioned on slashdot], bringing a large influx of new bitcoin users.
* July 12, 2010
** Beginning of a 10x increase in bitcoin exchange value over a 5 day period, from about $0.008 to $0.08
* July 17, 2010
** [[MtGox]] established
* July 18, 2010
** ArtForz generated his first block after establishing his personal OpenCL GPU hash farm
* August 15, 2010
** [[Incidents#Value_overflow|74638]]
* September 14, 2010
** jgarzik [http://www.bitcoin.org/smf/index.php?topic=133.msg12921#msg12921 offered] 10,000 BTC (valued at ~$600-650) to puddinpop to open source their windows-based CUDA client
* September 18, 2010
** puddinpop [http://www.bitcoin.org/smf/index.php?topic=133.msg13135#msg13135 released] source to their windows-based CUDA client under MIT license
* September 29, 2010
** kermit [http://www.bitcoin.org/smf/index.php?topic=1306.0 discovered] a microtransactions exploit which precipitated the Bitcoin v0.3.13 release
* October 01, 2010
** First public OpenCL miner released
* October 04, 2010
** Original Bitcoin History wiki page (this page) established (ooh so meta) on Bitcoin.org's wiki.
* October 07, 2010
** Exchange rate started climbing up from $0.06 after several flat months.
* October 28, 2010
** First bitcoin short sale transaction initiated, with a loan of 100 BTC by nanotube to [[User:Kiba|kiba]], facilitated by the [[Bitcoin-otc|#bitcoin-otc]] market.
* November 6, 2010
** The [http://www.bitcoin.org/smf/index.php?topic=1672 Bitcoin economy passed US $1 million]. The MtGox price touched USD $0.50.
* December 7, 2010
** Bitcoind was compiled for the Nokia N900 mobile computer by doublec. The following day, ribuck sent him 0.42 BTC in the first portable-to-portable Bitcoin transaction.
* December 9, 2010
** The generation difficulty passed 10,000.
** First bitcoin call option contract sold, from nanotube to [[User:Sgornick|sgornick]], via the [[Bitcoin-otc|#bitcoin-otc]] market.
* December 16, 2010
** [http://mining.bitcoin.cz/ Bitcoin Pooled Mining], operated by slush, found its first block
* January 2, 2011
** [[Tonal BitCoin]] units standardized.
* January 8, 2011
** [[History of Bitcoin]] page (this page) created after replicating from original Bitcoin History page on Bitcoin.org.
** Bitcoin Pooled Mining reached a total of 10,000 Mhash/s
* January 27, 2011
** Largest numeric value ever traded for bitcoins thus far occurred on this date. Three currency bills from Zimbabwe, known as Zimdollars, were traded on [[Bitcoin-otc|#bitcoin-otc]] at the rate of 4 BTC for each of the one-hundred trillion dollar ($100,000,000,000,000) Zimbabwe notes<ref>Serial numbers for Zimdollars sold: AA1669317, AA1669318 and AA1669319</ref>
* January 28, 2011
** Block 105000 was generated. This means that 5.25 million bitcoins have been generated, which is just over one-quarter of the eventual total of nearly 21 million.
* February 9, 2011
** Decimal Bitcoin reached parity with the US dollar, touching $1 per BTC at [[MtGox]].
* February 10, 2011
** Bitcoin.org website struggles to handle [http://www.bitcoin.org/smf/index.php?topic=3444.0 traffic] resulting from mentions on Slashdot<ref>[http://news.slashdot.org/story/11/02/10/189246/Online-Only-Currency-BitCoin-Reaches-Dollar-Parity Online-Only Currency BitCoin Reaches Dollar Parity]</ref>, Hacker News and Twitter following the news that parity had been reached.
* February 14, 2011
** A vehicle was, for the first time, offered in exchange for a certain number of bitcoins<ref>[http://www.bitcoin.org/smf/index.php?topic=3485.0 Car for Sale - Australia]</ref>.
* March 6, 2011
** Total Bitcoin network computation speed for a short time [http://bitcoin.sipa.be/speed-lin.png reached an all-time high of almost 900Ghash/sec], dropping to 500Ghash/sec soon after. Some speculate that this was due to some supercomputer or bot-net that joined the network ([http://bitcoin.atspace.com/mysteryminer.html mystery miner]).
* March 18, 2011
** BTC/USD exchange rate reaches a 6-week low point at almost $0.70/BTC, after what appeared to be a short burst of, possibly automated, BTC sales at progressively lower prices. BTC price had been declining since the February 9 high.
* March 25, 2011
** Difficulty decreased nearly 10%. A decrease has only occurred once before, and this decrease of nearly 10% was the largest.
* March 27, 2011
** The first market for exchanging bitcoins to and from the British Pound Sterling BTC/GBP, [[Britcoin]], opens.
* March 31, 2011
** The first market for exchanging bitcoins to and from Brazilian Reals, [[Bitcoin Brazil]], opens.
* April 5, 2011
** The first market for exchanging bitcoins to and from the Polish złoty, [[BitMarket.eu]], opens.
* April 12, 2011
** First bitcoin put option contract sold via the [[Bitcoin-otc|#bitcoin-otc]] market.
* April 16, 2011
** TIME does [http://techland.time.com/2011/04/16/online-cash-bitcoin-could-challenge-governments/ an article on Bitcoin].
* April 23, 2011
** BTC/USD exchange rate reaches and passes parity with the Euro (EUR) on [[MtGox]] exchange.
** BTC/USD exchange rate reaches and passes parity with the British Sterling Pound (GBP) on [[MtGox]] exchange.
** Value of the Bitcoin money stock at current exchange rate passes $10 million USD threshold.
* April 27, 2011
** [[VirWoX]] opens first market to trade bitcoins against a virtual currency on BTC/SL (Second Life Lindens) exchange.
* April 28, 2011
** Block [http://blockexplorer.com/b/120630 120,630] is first to be mined using split allocation of the generation reward.
* April 30, 2011
** The generation difficulty passed 100,000.
* May 10, 2011
** The exchange rate at [[MtGox]] touched 6 USD per BTC.
* June 3, 2011
** [[Tonal Bitcoin]] reached parity with the US cent, touching 1¢ per TBC at [[Bitcoin Market]].

==References==
<references />

Category:History

2011-06-06T19:30:24Z

Nealmcb: add some exchange rate turning points

* August 18, 2008
** Domain name "bitcoin.org" registered.
* October 31, 2008
** [http://article.gmane.org/gmane.comp.encryption.general/12588/ Bitcoin design paper] published
* November 09, 2008
** Bitcoin project registered at SourceForge.net
* January 3, 2009
** Genesis block established at 18:15:05 GMT
* January 11, 2009
** Bitcoin v0.1 released and announced on the [http://www.mail-archive.com/cryptography@metzdowd.com/msg10152.html cryptography mailing list]
* December 16, 2009
** Bitcoin v0.2 released
* December 30, 2009
** First difficulty increase at 06:11:04 GMT
* February 6, 2010
** [[Bitcoin Market]] established
* May 22, 2010
** laszlo first to buy pizza with Bitcoins [http://www.bitcoin.org/smf/index.php?topic=137.msg1195#msg1195 agreeing] upon paying 10,000 BTC for ~$25 worth of pizza courtesy of jercos
* July 7, 2010
** Bitcoin v0.3 released
* July 11, 2010
** Bitcoin v0.3 release [http://news.slashdot.org/story/10/07/11/1747245/Bitcoin-Releases-Version-03 mentioned on slashdot], bringing a large influx of new bitcoin users.
* July 12, 2010
** Beginning of a doubling of bitcoin exchange value over a 5 day period, from about $0.008 to $0.08
* July 17, 2010
** [[MtGox]] established
* July 18, 2010
** ArtForz generated his first block after establishing his personal OpenCL GPU hash farm
* August 15, 2010
** [[Incidents#Value_overflow|74638]]
* September 14, 2010
** jgarzik [http://www.bitcoin.org/smf/index.php?topic=133.msg12921#msg12921 offered] 10,000 BTC (valued at ~$600-650) to puddinpop to open source their windows-based CUDA client
* September 18, 2010
** puddinpop [http://www.bitcoin.org/smf/index.php?topic=133.msg13135#msg13135 released] source to their windows-based CUDA client under MIT license
* September 29, 2010
** kermit [http://www.bitcoin.org/smf/index.php?topic=1306.0 discovered] a microtransactions exploit which precipitated the Bitcoin v0.3.13 release
* October 01, 2010
** First public OpenCL miner released
* October 04, 2010
** Original Bitcoin History wiki page (this page) established (ooh so meta) on Bitcoin.org's wiki.
* October 07, 2010
** Exchange rate started climbing up from $0.06 after several flat months.
* October 28, 2010
** First bitcoin short sale transaction initiated, with a loan of 100 BTC by nanotube to [[User:Kiba|kiba]], facilitated by the [[Bitcoin-otc|#bitcoin-otc]] market.
* November 6, 2010
** The [http://www.bitcoin.org/smf/index.php?topic=1672 Bitcoin economy passed US $1 million]. The MtGox price touched USD $0.50.
* December 7, 2010
** Bitcoind was compiled for the Nokia N900 mobile computer by doublec. The following day, ribuck sent him 0.42 BTC in the first portable-to-portable Bitcoin transaction.
* December 9, 2010
** The generation difficulty passed 10,000.
** First bitcoin call option contract sold, from nanotube to [[User:Sgornick|sgornick]], via the [[Bitcoin-otc|#bitcoin-otc]] market.
* December 16, 2010
** [http://mining.bitcoin.cz/ Bitcoin Pooled Mining], operated by slush, found its first block
* January 2, 2011
** [[Tonal BitCoin]] units standardized.
* January 8, 2011
** [[History of Bitcoin]] page (this page) created after replicating from original Bitcoin History page on Bitcoin.org.
** Bitcoin Pooled Mining reached a total of 10,000 Mhash/s
* January 27, 2011
** Largest numeric value ever traded for bitcoins thus far occurred on this date. Three currency bills from Zimbabwe, known as Zimdollars, were traded on [[Bitcoin-otc|#bitcoin-otc]] at the rate of 4 BTC for each of the one-hundred trillion dollar ($100,000,000,000,000) Zimbabwe notes<ref>Serial numbers for Zimdollars sold: AA1669317, AA1669318 and AA1669319</ref>
* January 28, 2011
** Block 105000 was generated. This means that 5.25 million bitcoins have been generated, which is just over one-quarter of the eventual total of nearly 21 million.
* February 9, 2011
** Decimal Bitcoin reached parity with the US dollar, touching $1 per BTC at [[MtGox]].
* February 10, 2011
** Bitcoin.org website struggles to handle [http://www.bitcoin.org/smf/index.php?topic=3444.0 traffic] resulting from mentions on Slashdot<ref>[http://news.slashdot.org/story/11/02/10/189246/Online-Only-Currency-BitCoin-Reaches-Dollar-Parity Online-Only Currency BitCoin Reaches Dollar Parity]</ref>, Hacker News and Twitter following the news that parity had been reached.
* February 14, 2011
** A vehicle was, for the first time, offered in exchange for a certain number of bitcoins<ref>[http://www.bitcoin.org/smf/index.php?topic=3485.0 Car for Sale - Australia]</ref>.
* March 6, 2011
** Total Bitcoin network computation speed for a short time [http://bitcoin.sipa.be/speed-lin.png reached an all-time high of almost 900Ghash/sec], dropping to 500Ghash/sec soon after. Some speculate that this was due to some supercomputer or bot-net that joined the network ([http://bitcoin.atspace.com/mysteryminer.html mystery miner]).
* March 18, 2011
** BTC/USD exchange rate reaches a 6-week low point at almost $0.70/BTC, after what appeared to be a short burst of, possibly automated, BTC sales at progressively lower prices. BTC price had been declining since the February 9 high.
* March 25, 2011
** Difficulty decreased nearly 10%. A decrease has only occurred once before, and this decrease of nearly 10% was the largest.
* March 27, 2011
** The first market for exchanging bitcoins to and from the British Pound Sterling BTC/GBP, [[Britcoin]], opens.
* March 31, 2011
** The first market for exchanging bitcoins to and from Brazilian Reals, [[Bitcoin Brazil]], opens.
* April 5, 2011
** The first market for exchanging bitcoins to and from the Polish złoty, [[BitMarket.eu]], opens.
* April 12, 2011
** First bitcoin put option contract sold via the [[Bitcoin-otc|#bitcoin-otc]] market.
* April 16, 2011
** TIME does [http://techland.time.com/2011/04/16/online-cash-bitcoin-could-challenge-governments/ an article on Bitcoin].
* April 23, 2011
** BTC/USD exchange rate reaches and passes parity with the Euro (EUR) on [[MtGox]] exchange.
** BTC/USD exchange rate reaches and passes parity with the British Sterling Pound (GBP) on [[MtGox]] exchange.
** Value of the Bitcoin money stock at current exchange rate passes $10 million USD threshold.
* April 27, 2011
** [[VirWoX]] opens first market to trade bitcoins against a virtual currency on BTC/SL (Second Life Lindens) exchange.
* April 28, 2011
** Block [http://blockexplorer.com/b/120630 120,630] is first to be mined using split allocation of the generation reward.
* April 30, 2011
** The generation difficulty passed 100,000.
* May 10, 2011
** The exchange rate at [[MtGox]] touched 6 USD per BTC.
* June 3, 2011
** [[Tonal Bitcoin]] reached parity with the US cent, touching 1¢ per TBC at [[Bitcoin Market]].

==References==
<references />

Category:History

2011-06-06T17:26:59Z

Nealmcb: domain name - earliest entry now

* August 18, 2008
** Domain name "bitcoin.org" registered.
* October 31, 2008
** [http://article.gmane.org/gmane.comp.encryption.general/12588/ Bitcoin design paper] published
* November 09, 2008
** Bitcoin project registered at SourceForge.net
* January 3, 2009
** Genesis block established at 18:15:05 GMT
* January 11, 2009
** Bitcoin v0.1 released and announced on the [http://www.mail-archive.com/cryptography@metzdowd.com/msg10152.html cryptography mailing list]
* December 16, 2009
** Bitcoin v0.2 released
* December 30, 2009
** First difficulty increase at 06:11:04 GMT
* February 6, 2010
** [[Bitcoin Market]] established
* May 22, 2010
** laszlo first to buy pizza with Bitcoins [http://www.bitcoin.org/smf/index.php?topic=137.msg1195#msg1195 agreeing] upon paying 10,000 BTC for ~$25 worth of pizza courtesy of jercos
* July 7, 2010
** Bitcoin v0.3 released
* July 11, 2010
** Bitcoin v0.3 release [http://news.slashdot.org/story/10/07/11/1747245/Bitcoin-Releases-Version-03 mentioned on slashdot], bringing a large influx of new bitcoin users.
* July 17, 2010
** [[MtGox]] established
* July 18, 2010
** ArtForz generated his first block after establishing his personal OpenCL GPU hash farm
* August 15, 2010
** [[Incidents#Value_overflow|74638]]
* September 14, 2010
** jgarzik [http://www.bitcoin.org/smf/index.php?topic=133.msg12921#msg12921 offered] 10,000 BTC (valued at ~$600-650) to puddinpop to open source their windows-based CUDA client
* September 18, 2010
** puddinpop [http://www.bitcoin.org/smf/index.php?topic=133.msg13135#msg13135 released] source to their windows-based CUDA client under MIT license
* September 29, 2010
** kermit [http://www.bitcoin.org/smf/index.php?topic=1306.0 discovered] a microtransactions exploit which precipitated the Bitcoin v0.3.13 release
* October 01, 2010
** First public OpenCL miner released
* October 04, 2010
** Original Bitcoin History wiki page (this page) established (ooh so meta) on Bitcoin.org's wiki.
* October 28, 2010
** First bitcoin short sale transaction initiated, with a loan of 100 BTC by nanotube to [[User:Kiba|kiba]], facilitated by the [[Bitcoin-otc|#bitcoin-otc]] market.
* November 6, 2010
** The [http://www.bitcoin.org/smf/index.php?topic=1672 Bitcoin economy passed US $1 million]. The MtGox price touched USD $0.50.
* December 7, 2010
** Bitcoind was compiled for the Nokia N900 mobile computer by doublec. The following day, ribuck sent him 0.42 BTC in the first portable-to-portable Bitcoin transaction.
* December 9, 2010
** The generation difficulty passed 10,000.
** First bitcoin call option contract sold, from nanotube to [[User:Sgornick|sgornick]], via the [[Bitcoin-otc|#bitcoin-otc]] market.
* December 16, 2010
** [http://mining.bitcoin.cz/ Bitcoin Pooled Mining], operated by slush, found its first block
* January 2, 2011
** [[Tonal BitCoin]] units standardized.
* January 8, 2011
** [[History of Bitcoin]] page (this page) created after replicating from original Bitcoin History page on Bitcoin.org.
** Bitcoin Pooled Mining reached a total of 10,000 Mhash/s
* January 27, 2011
** Largest numeric value ever traded for bitcoins thus far occurred on this date. Three currency bills from Zimbabwe, known as Zimdollars, were traded on [[Bitcoin-otc|#bitcoin-otc]] at the rate of 4 BTC for each of the one-hundred trillion dollar ($100,000,000,000,000) Zimbabwe notes<ref>Serial numbers for Zimdollars sold: AA1669317, AA1669318 and AA1669319</ref>
* January 28, 2011
** Block 105000 was generated. This means that 5.25 million bitcoins have been generated, which is just over one-quarter of the eventual total of nearly 21 million.
* February 9, 2011
** Decimal Bitcoin reached parity with the US dollar, touching $1 per BTC at [[MtGox]].
* February 10, 2011
** Bitcoin.org website struggles to handle [http://www.bitcoin.org/smf/index.php?topic=3444.0 traffic] resulting from mentions on Slashdot<ref>[http://news.slashdot.org/story/11/02/10/189246/Online-Only-Currency-BitCoin-Reaches-Dollar-Parity Online-Only Currency BitCoin Reaches Dollar Parity]</ref>, Hacker News and Twitter following the news that parity had been reached.
* February 14, 2011
** A vehicle was, for the first time, offered in exchange for a certain number of bitcoins<ref>[http://www.bitcoin.org/smf/index.php?topic=3485.0 Car for Sale - Australia]</ref>.
* March 6, 2011
** Total Bitcoin network computation speed for a short time [http://bitcoin.sipa.be/speed-lin.png reached an all-time high of almost 900Ghash/sec], dropping to 500Ghash/sec soon after. Some speculate that this was due to some supercomputer or bot-net that joined the network ([http://bitcoin.atspace.com/mysteryminer.html mystery miner]).
* March 18, 2011
** BTC/USD exchange rate reaches a 6-week low point at almost $0.70/BTC, after what appeared to be a short burst of, possibly automated, BTC sales at progressively lower prices. BTC price had been declining since the February 9 high.
* March 25, 2011
** Difficulty decreased nearly 10%. A decrease has only occurred once before, and this decrease of nearly 10% was the largest.
* March 27, 2011
** The first market for exchanging bitcoins to and from the British Pound Sterling BTC/GBP, [[Britcoin]], opens.
* March 31, 2011
** The first market for exchanging bitcoins to and from Brazilian Reals, [[Bitcoin Brazil]], opens.
* April 5, 2011
** The first market for exchanging bitcoins to and from the Polish złoty, [[BitMarket.eu]], opens.
* April 12, 2011
** First bitcoin put option contract sold via the [[Bitcoin-otc|#bitcoin-otc]] market.
* April 16, 2011
** TIME does [http://techland.time.com/2011/04/16/online-cash-bitcoin-could-challenge-governments/ an article on Bitcoin].
* April 23, 2011
** BTC/USD exchange rate reaches and passes parity with the Euro (EUR) on [[MtGox]] exchange.
** BTC/USD exchange rate reaches and passes parity with the British Sterling Pound (GBP) on [[MtGox]] exchange.
** Value of the Bitcoin money stock at current exchange rate passes $10 million USD threshold.
* April 27, 2011
** [[VirWoX]] opens first market to trade bitcoins against a virtual currency on BTC/SL (Second Life Lindens) exchange.
* April 28, 2011
** Block [http://blockexplorer.com/b/120630 120,630] is first to be mined using split allocation of the generation reward.
* April 30, 2011
** The generation difficulty passed 100,000.
* May 10, 2011
** The exchange rate at [[MtGox]] touched 6 USD per BTC.
* June 3, 2011
** [[Tonal Bitcoin]] reached parity with the US cent, touching 1¢ per TBC at [[Bitcoin Market]].

==References==
<references />

In-store Transactions

2011-06-05T23:29:11Z

Nealmcb: put best solution first

A common question people have about Bitcoin is how it can be used for in-person transactions, like at a supermarket.

Today, Bitcoin is software that runs on your desktop or laptop computer. You can also host your wallet with an online service like MyBitcoin. Neither solution is convenient for the supermarket use case. The most commonly proposed solutions are:

__TOC__

We examine these solutions here.

== Smart phones ==

The best solution is to use smart phones. Communication can be via unencrypted Bluetooth or using NFC. Near field communications is a form of radio that travels only a few centimeters, so to use it devices must be touched together. In such a setup, you touch your phone to another NFC aware device like another phone, or for the supermarket a simple NFC transmitter. That device sends a Bitcoin address and a requested amount, which is displayed on the devices screen. Confirming the payment causes the phone to create, sign and broadcast the Bitcoin transaction as normal. The supermarkets Bitcoin node will receive the transaction a few seconds later.

To ensure you're paying who you think you're paying, the address can itself be signed with an 'extended validation' certificate as issued by various SSL certificate authorities. The EV standard and auditing process ensures they are only issued to organizations that can prove their identity to a high level of assurance. The phone can then show the organizational name rather than the raw Bitcoin address.

Because you own the device and carry it with you, there's no risk of a corrupt merchant or criminal tampering with the device when you are not around to see it, as has happened with smart card readers. Modern phones can encrypt locally stored data like a wallet such that it can't be extracted unless the right PIN is provided. Whilst physical tamper resistance isn't as strong as with a smartcard, it's probably strong enough to ensure that if a phone is stolen, there is sufficient time to reach a backup and move the coins in it to a new address rendering the stolen wallet worthless.

This solution has another advantage over smart cards - namely that the hardware to do it is being mass manufactured and many people have access to it. This means that in person transactions don't require any complex setup or special hardware. You can pay your friends in the pub as easily as you can pay the supermarket.

== Smart cards ==

Today one of the most common ways to pay in supermarkets is with cards you either swipe (magstripe cards) or insert into a reader and enter a PIN (smartcards). It's natural to think of applying the same techniques to Bitcoin, for instance by putting the private keys inside the card.

Unfortunately there is no decentralized way to create such a system. The EMV smartcard framework used throughout Europe today is a combination of standards created by the major card processors that covers not just smartcards but also the readers as well, for instance to try and ensure tamper resistance.

Without central certification of what EMV calls ''payment entry devices'' (PEDs), anyone is free to create a PED that ''looks'' real, and displays the transaction you expect to be paying on screen, but actually sends an entirely different transaction to be signed by the card. The system is only secure when the readers can be trusted. Even if some central authority certifies PEDs, if their tamperproofing fails the certification is worthless. The tamperproofing done by Ingenico and others on their EMV PEDs turned out to be insufficient and has been attacked several times, in one notable incident, readers had GSM taps installed at the factory before distribution.

It's worth noting that the physical smart card form is an accident of history. VISA already offers [http://usa.visa.com/personal/cards/paywave/micro_tag.html keyfobs] that do the same thing but use near-field communication (NFC) technology.

== Paper Bitcoins ==

Another common way to pay at the supermarket is with paper money. There have been various efforts to allow Bitcoins to be printed out and passed around, for instance [http://www.bitcoin.org/smf/index.php?topic=3716.0 this one]. The private keys are printed on the paper. But putting private keys on the paper itself simply means anyone who receives the note can take away the underlying Bitcoins backing it.

Solution to this would be to create a paper money where you can see if someone have been using the private key, and a solution to this is found here [http://bitbills.com/ Bitbills]. But even this is secure (or secure enough) only through huge anti-counterfeiting efforts by a large central authority, in the USA this is the Secret Service. The techniques of making paper money hard to forge are not widely available.

==See Also==

* [[Merchant Howto]]

[[Category:Technical]]

Browser-based wallet

2011-06-05T23:25:51Z

Nealmcb: /* Things to be aware of */ note lowered anonymity

A '''browser-based wallet''' or '''wallet service''' is an online account with an external provider where bitcoins can be stored. Examples include accounts on currency exchange [[:Category:Markets|Markets]], online [[:Category:Services|Services]] and with ecommerce transaction processors such as [[MyBitcoin]].

==Benefits==
* Use of a browser-based wallet provider may help improve [[anonymity]] against third-parties who watch your IP address use.
* An account with a wallet service can generally be established in just minutes.
* Some bitcoin users store some or all of their bitcoins in a browser-based wallet to avoid having to worry about keeping a local wallet [[Securing_your_wallet|secure]].
* Some services that allow withdrawals to any Bitcoin address, such as [[MtGox]], can be used like browser-based wallets for making payments. Simply using the withdrawal feature to withdraw to an address that is not yours is functionally equivalent to sending a Bitcoin payment to that address.

==Things to be aware of==

When bitcoins are stored online, the provider retains full control of those amounts. You are trusting a third party to maintain your Bitcoin balance on your behalf. In comparison, if you run the Bitcoin software yourself, you are in full control of your coins so long as the wallet file stored on your computer is kept secret and secure.

Other relevant things:

* You typically have less anonymity with respect to those who run the online wallet site.
* If a payment is made from an online wallet, the transaction's "from" [[address]] is an address for the wallet provider and not an address reserved specifically for the sender. This is because the wallet service provider may service the payment from any coins in its possession - your balance is not associated with any particular coins, any more than your balance at your local bank is associated with any specific bills. Thus if the recipient were to "return" any bitcoins to the same address they were sent from, the sender would not receive those bitcoins.

* Not all wallet providers reserve a bitcoin address for the account holder indefinitely. Bitcoin addresses generally work best when one is assigned for each use. There is the risk of showing an address from a wallet provider in a directory or on a web page (for donations, as an example) as there is the possibility that at the future date when those bitcoins are sent that the intended recipient still has the wallet account. The same concern applies should the wallet provider cease operations.

* There is no trivial way to guarantee that the amount of bitcoins showing for the account holder's balance are truly being held in reserve by the wallet provider.
** Some providers describe their reserve policy in their terms of service (TOS). For example, [http://www.mybitcoin.com/legal/terms.php MyBitcoin's TOS] states:
:: <tt>6. OBLIGATIONS OF MYBITCOIN LLC<br>6.1 MYBITCOIN LLC will ensure that for all Bitcoins in circulation in the MyBitcoin System there is at all times an identical quantity of unencumbered Bitcoins held in MYBITCOIN LLC's master Bitcoin wallet.</tt>

* Transactions to a Bitcoin address from the same wallet provider are usually completed internally and, if so, will not be processed on the Bitcoin P2P network. Auditing tools such as the [[Block Explorer]] will not show any activity for this transaction.
** Some wallet providers allow amounts below 0.01 BTC to be sent if the transaction is to another account holder on the same service. This allows an inexpensive and immediate method to detect if the recipient is using the same wallet provider. For example, MyBitcoin will report an error when attempting to send an amount smaller than 0.01 BTC to a Bitcoin address that is not for another MyBitcoin account.

* The wallet service provider's wallet may be vulnerable to security breaches, loss, or theft. Because Bitcoin transactions are irreversible, there may be limited or no recovery if a provider's master wallet is compromised. Wallet providers who implement preventative controls - such as keeping their reserves in an [[offline wallet]] - are likely to be safer.

==See Also==

* [[Buying bitcoins]]
* [[Selling bitcoins]]
* [[Bitcoin faucet]]
* List of [[:Category:eWallets|eWallets]]

Browser-based wallet

2011-06-05T23:24:24Z

Nealmcb: /* Benefits */ qualify anonymity

A '''browser-based wallet''' or '''wallet service''' is an online account with an external provider where bitcoins can be stored. Examples include accounts on currency exchange [[:Category:Markets|Markets]], online [[:Category:Services|Services]] and with ecommerce transaction processors such as [[MyBitcoin]].

==Benefits==
* Use of a browser-based wallet provider may help improve [[anonymity]] against third-parties who watch your IP address use.
* An account with a wallet service can generally be established in just minutes.
* Some bitcoin users store some or all of their bitcoins in a browser-based wallet to avoid having to worry about keeping a local wallet [[Securing_your_wallet|secure]].
* Some services that allow withdrawals to any Bitcoin address, such as [[MtGox]], can be used like browser-based wallets for making payments. Simply using the withdrawal feature to withdraw to an address that is not yours is functionally equivalent to sending a Bitcoin payment to that address.

==Things to be aware of==

When bitcoins are stored online, the provider retains full control of those amounts. You are trusting a third party to maintain your Bitcoin balance on your behalf. In comparison, if you run the Bitcoin software yourself, you are in full control of your coins so long as the wallet file stored on your computer is kept secret and secure.

Other relevant things:

* If a payment is made from an online wallet, the transaction's "from" [[address]] is an address for the wallet provider and not an address reserved specifically for the sender. This is because the wallet service provider may service the payment from any coins in its possession - your balance is not associated with any particular coins, any more than your balance at your local bank is associated with any specific bills. Thus if the recipient were to "return" any bitcoins to the same address they were sent from, the sender would not receive those bitcoins.

* Not all wallet providers reserve a bitcoin address for the account holder indefinitely. Bitcoin addresses generally work best when one is assigned for each use. There is the risk of showing an address from a wallet provider in a directory or on a web page (for donations, as an example) as there is the possibility that at the future date when those bitcoins are sent that the intended recipient still has the wallet account. The same concern applies should the wallet provider cease operations.

* There is no trivial way to guarantee that the amount of bitcoins showing for the account holder's balance are truly being held in reserve by the wallet provider.
** Some providers describe their reserve policy in their terms of service (TOS). For example, [http://www.mybitcoin.com/legal/terms.php MyBitcoin's TOS] states:
:: <tt>6. OBLIGATIONS OF MYBITCOIN LLC<br>6.1 MYBITCOIN LLC will ensure that for all Bitcoins in circulation in the MyBitcoin System there is at all times an identical quantity of unencumbered Bitcoins held in MYBITCOIN LLC's master Bitcoin wallet.</tt>

* Transactions to a Bitcoin address from the same wallet provider are usually completed internally and, if so, will not be processed on the Bitcoin P2P network. Auditing tools such as the [[Block Explorer]] will not show any activity for this transaction.
** Some wallet providers allow amounts below 0.01 BTC to be sent if the transaction is to another account holder on the same service. This allows an inexpensive and immediate method to detect if the recipient is using the same wallet provider. For example, MyBitcoin will report an error when attempting to send an amount smaller than 0.01 BTC to a Bitcoin address that is not for another MyBitcoin account.

* The wallet service provider's wallet may be vulnerable to security breaches, loss, or theft. Because Bitcoin transactions are irreversible, there may be limited or no recovery if a provider's master wallet is compromised. Wallet providers who implement preventative controls - such as keeping their reserves in an [[offline wallet]] - are likely to be safer.

==See Also==

* [[Buying bitcoins]]
* [[Selling bitcoins]]
* [[Bitcoin faucet]]
* List of [[:Category:eWallets|eWallets]]