https://tests.bitcoin.it/w/api.php?action=feedcontributions&user=Giszmo&feedformat=atomBitcoin Wiki - User contributions [en]2024-03-29T12:47:49ZUser contributionsMediaWiki 1.30.0https://tests.bitcoin.it/w/index.php?title=Safewallet.in&diff=68328Safewallet.in2020-12-29T03:45:58Z<p>Giszmo: wikified</p>
<hr />
<div>SafeWallet [https://web.archive.org/web/20170921031936/http://safewallet.us/ was an online wallet].</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Safewallet.in&diff=68327Safewallet.in2020-12-29T03:45:39Z<p>Giszmo: wikified</p>
<hr />
<div>SafeWallet [[https://web.archive.org/web/20170921031936/http://safewallet.us/ was an online wallet]].</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Safewallet.in&diff=68326Safewallet.in2020-12-29T03:44:07Z<p>Giszmo: How do I delete pages in this wiki?</p>
<hr />
<div>SafeWallet [was an online wallet](https://web.archive.org/web/20170921031936/http://safewallet.us/).</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Segwit_support&diff=63594Segwit support2017-07-09T00:56:20Z<p>Giszmo: </p>
<hr />
<div><big><big>'''PLEASE NOTE:''' This list is not yet complete.</big></big><br />
<br />
'''Developers/businesses: Please add a row for yourself in the applicable table to reflect your positions. If for some reason you don't already have a wiki account that can edit the page, make an account and ask luke-jr for help if you get caught in the anti-spam.'''<br />
<br />
{| class="wikitable"<br />
| {{No}} || doesn't support (but might or might not go along with it with sufficient community support)<br />
|-<br />
| {{Deficient}} || okay with the idea, but considers it to have insufficient community support<br />
|-<br />
| {{Evaluating}} || still evaluating the idea<br />
|-<br />
| {{AccJuly}} || it is a workable solution, provided it is activated before August 1 (and therefore BIP148-compatible)<br />
|-<br />
| {{Wanting}} || positively likes the idea, but considers it to have insufficient community support<br />
|-<br />
| {{Weak}} || better than nothing at all<br />
|-<br />
| {{Acceptable}} || it is a workable solution<br />
|-<br />
| {{Prefer}} || it is what he would choose if it was only up to him and no outside influences<br />
|}<br />
<br />
__TOC__<br />
<br />
==Developers==<br />
<br />
<!-- README: please keep alphabetically ordered by surname! --><br />
<br />
''Note that support for a given proposal does not mean developers support merging it into Core or any other specific codebase.''<br />
<br />
{| class="wikitable sortable"<br />
! rowspan=2 | Developer<br />
! rowspan=2 | Aff* <!-- Using one year before the the creation date of this page as the benchmark. Do not list yourself as affiliated with a project that you haven't made meaningful contributions to since then. --><br />
! Segwit itself<br />
! colspan=3 | Deployment methods<br />
! colspan=2 | Hardfork bundles (Silbert agreement)<br />
|-<br />
! [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP 141] !! [https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki BIP 148] !! [https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki BIP 149] !! [https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki BIP 91] || Segwit2x || [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014445.html COOP]<br />
|-<br />
| Karl-Johan Alm || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}<br />
|-<br />
| Bryan Bishop || || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| ฿tcDrak || Core || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}} || {{No}}<br />
|-<br />
| Andrew Chow || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Wang Chun || [[F2Pool]] || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{Acceptable}} || {{AccJuly}} ||<br />
|-<br />
| Matt Corallo || Core || {{Prefer}} || {{No}} || || {{Acceptable}} || {{No|LOL}} ||<br />
|-<br />
| Johnathan Corgan || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{No}} || {{No}} || {{No}}<br />
|-<br />
| Luke Dashjr || Core || {{Prefer}} || {{Prefer}} || {{No}} || {{AccJuly}} || {{No}} || {{Deficient}}<br />
|-<br />
| Christian Decker || c-lightning || {{Prefer}} || {{Acceptable}} || || || || <br />
|-<br />
| Nicolas Dorier || Core || {{Prefer}} || {{Deficient}} || {{Acceptable}} || {{AccJuly}} || ||<br />
|-<br />
| Thaddeus Dryja || lit || {{Prefer}} || {{No}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}<br />
|-<br />
| Marco Falke || Core || {{Prefer}} || {{Deficient}} || {{Prefer}} || {{Deficient}} || ||<br />
|-<br />
| Mark Friedenbach || BIP 68/112 || {{Prefer}} || {{Prefer}} || {{No}} || {{AccJuly}} || {{No|LOL}} || {{No|Nope}}<br />
|-<br />
| Pavel Janik || Core || {{Prefer}} || {{No}} || {{Acceptable}} || {{No}} || {{No}} || {{No}}<br />
|-<br />
| Thomas Kerin || Core || {{Prefer}} || {{Wanting}} || {{Prefer}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Johnson Lau || Core || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Acceptable}} || ||<br />
|-<br />
| Eric Lombrozo || || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{AccJuly}} || {{No}} || {{No}}<br />
|-<br />
| Greg Maxwell || Core || {{Prefer}} || {{Deficient}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Alex Morcos || Core || {{Prefer}} || {{Deficient}} || {{Acceptable}} || {{Weak}} || {{No}} ||<br />
|-<br />
| nopara73 || TumbleBit || {{Weak}} || {{Wanting}} || {{Prefer}} || || ||<br />
|-<br />
| Laolu "roasbeef" Osuntokun || lnd || {{Prefer}} || || || || {{No}} ||<br />
|-<br />
| Jeremy Rubin || Core || {{Prefer}} || {{Deficient}} || {{No}} || {{AccJuly}} || {{No}} || {{No}}<br />
|-<br />
| Pavol "stick" Rusnak || [[TREZOR]] || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{AccJuly}} || {{No}} || {{No}}<br />
|-<br />
| Rusty Russell || c-lightning || {{Prefer}} || {{Prefer}} || || || ||<br />
|-<br />
| Gregory Sanders || Core || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Weak}} || {{No}} ||<br />
|-<br />
| Jonas Schnelli || Core || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}<br />
|-<br />
| Patrick Strateman || Core || {{Prefer}} || || || || {{No}} || {{No}}<br />
|-<br />
| Paul Sztorc || || {{Prefer}} || {{Deficient}} || {{Wanting}} || {{AccJuly}} || {{Evaluating}} || {{No}}<br />
|-<br />
| Amir Taaki || libbtc || {{Acceptable}} || {{Prefer}} || || || {{No}} || {{No}} <br />
|-<br />
| Jorge Timon || Core || {{Prefer}} || {{No}} || {{Prefer}} || {{Deficient}} || {{No}} || {{No}}<br />
|-<br />
| Peter Todd || || {{Prefer}} || {{Deficient}} || {{Wanting}} || {{AccJuly}} || {{No|LOL}} ||<br />
|-<br />
| Warren Togami || Elements || {{Prefer}} || {{Prefer}} || {{Acceptable}} || || ||<br />
|-<br />
| Wladimir van der Laan || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}<br />
|-<br />
| Thomas Voegtlin || Electrum || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}<br />
|-<br />
| Leo Wandersleb || Mycelium || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Pieter Wuille || Core || {{Prefer}} || || || || {{No}} ||<br />
|}<br />
<br />
* "affiliation" is an optional field for the company or project the individual is associated with, that most qualifies the person to comment on the matter and is not meant as a company or project endorsement of the individual's position.<br />
<br />
==Businesses==<br />
<br />
'''When adding companies below, sources for each position MUST be provided.'''<br />
<br />
{| class="wikitable sortable"<br />
! rowspan=2 | Company <br />
! rowspan=2 | Service<br />
! Segwit itself<br />
! colspan=3 | Deployment methods<br />
! colspan=2 | Hardfork bundles (Silbert agreement)<br />
|-<br />
! [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP 141] !! [https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki BIP 148] !! [https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki BIP 149] !! [https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki BIP 91] || Segwit2x || [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014445.html COOP]<br />
|-<br />
| Abra || wallet || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || {{AccJuly}} || {{AccJuly}}<ref name="silbert" /> ||<br />
|-<br />
| Bitcoin India || exchange/miner || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || || ||<br />
|-<br />
| BitcoinReminder.com || service || {{Prefer}}<ref name="bitcoinreminder_com">[https://bitcoinreminder.com/informations/poli BitcoinReminder.com's position on scaling proposals]</ref> || {{Prefer}}<ref name="bitcoinreminder_com"/> || {{Acceptable}}<ref name="bitcoinreminder_com"/> || {{Weak}}<ref name="bitcoinreminder_com"/> || {{No|LOL}}<ref name="bitcoinreminder_com"/> || {{No}}<ref name="bitcoinreminder_com"/><br />
|-<br />
| Bitfinex || exchange || {{Acceptable}}<ref name="coindance" /> || {{Acceptable}} || || || ||<br />
|-<br />
| Bitfury || miner || {{Prefer}}<ref name="coindance" /> || {{Acceptable}} || || {{AccJuly}} || {{AccJuly}}<ref name="silbert" /> ||<br />
|-<br />
| Bitmain || miner || {{AccJuly}}<ref name="bitmain">[https://blog.bitmain.com/en/uahf-contingency-plan-uasf-bip148/ Bitmain's plot against BIP148]</ref> || {{No}} || || {{AccJuly}} || {{AccJuly}}<ref name="bitmain" /> ||<br />
|-<br />
| Bitonic/BL3P.eu || exchange || {{Prefer}}<ref name="bitonic">[https://bitonic.nl/en/news/138/our-position-on-scaling-proposals Bitonic's position on scaling proposals]</ref> || {{Prefer}}<ref name="bitonic"/> || {{Acceptable}}<ref name="bitonic"/> || {{Weak}}<ref name="bitonic"/> || {{No|LOL}}<ref name="bitonic"/> || {{No}}<br />
|-<br />
| Bitpay || wallet || {{Prefer}}<ref name="bccore_swadoption"/> || {{No}} || || {{Prefer}} || {{Prefer}}<ref name="silbert" /> ||<br />
|-<br />
| Bitrated || reputation || {{Acceptable}}<ref name="bitrated">[https://twitter.com/bitrated/status/876805892003553281]</ref> || {{Acceptable}}<ref name="bitrated" /> || {{Prefer}}<ref name="bitrated" /> || {{AccJuly}}<ref name="bitrated" /> || {{No}}<ref name="bitrated" /><ref>[https://medium.com/@shesek/why-i-dont-support-the-compromise-efforts-9d73a8cce6be Why I don’t support horse-trading compromises for Bitcoin protocol development]</ref> ||<br />
|-<br />
| Bitrefill || merchant || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || || ||<br />
|-<br />
| Bitsquare || exchange || {{Prefer}} || {{Prefer}}<ref name="bitsquare">[https://forum.bitsquare.io/t/bitsquare-will-support-uasf-bitcoin-not-bitmaincoin/2265 Bitsquare will support UASF Bitcoin not BitMainCoin]</ref> || {{Acceptable}}<ref name="bitsquare"/> || || ||<br />
|-<br />
| Bitstamp || exchange || || || || || ||<br />
|-<br />
| Bittylicious || exchange || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref>[https://twitter.com/Bittylicious_/status/867305106668224513 Bittylicious answer on Twitter]</ref> || || || ||<br />
|-<br />
| Blockchain.info || wallet || {{Acceptable}}<ref name="bccore_swadoption"/> || || || {{AccJuly}} || {{AccJuly}}<ref name="silbert" /> || <br />
|-<br />
| blockonomics || || {{Prefer}} || {{Prefer}}<ref>[https://twitter.com/blockonomics_co/status/851738251509497856 blockonomics announcement on Twitter]</ref> || || || ||<br />
|-<br />
| Bustabit|| gambling || {{Prefer}}<ref name="bustabit">[https://www.bustabit.com/statement-on-forks Bustabit Statement on Bitcoin Forks]</ref> || {{Acceptable}}<ref name="bustabit"/> || || || {{AccJuly}}<ref name="bustabit"/> ||<br />
|-<br />
| Bylls || payments / exchange || {{Prefer}}<ref name="bylls">[https://twitter.com/myBylls/status/877959773794316288 Bylls supports Segwit softfork but no current HF plan]</ref> || {{Prefer}}<ref name="bylls">[https://twitter.com/myBylls/status/877959773794316288 Bylls supports Segwit softfork but no current HF plan]</ref> || {{Acceptable}}<ref name="bylls">[https://twitter.com/myBylls/status/877965277316730880 Bylls twitter statement]</ref> || {{AccJuly}}<ref name="bylls">[https://twitter.com/myBylls/status/877965277316730880 Bylls twitter statement]</ref> || {{No}}<ref name="bylls">[https://twitter.com/myBylls/status/877965277316730880 Bylls twitter statement]</ref> || {{No}}<ref name="bylls">[https://twitter.com/myBylls/status/877965277316730880 Bylls twitter statement]</ref><br />
|-<br />
| Ciphrex || wallet / dev stack || {{Prefer}}<ref name="coindance" /> || {{Acceptable}}<ref name="coindance" /> || || || ||<br />
|-<br />
| Coinbase || wallet || {{Acceptable}}<ref name="bccore_swadoption"/> || || || {{AccJuly}} || {{AccJuly}}<ref name="silbert" /> || <br />
|-<br />
| CoinGate || exchange || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || || ||<br />
|-<br />
| CoinJar || wallet || || {{Evaluating}}<ref>[https://twitter.com/GetCoinJar/status/875581525730787329 CoinJar answer on Twitter]</ref> || || || ||<br />
|-<br />
| Coinkite || || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || || ||<br />
|-<br />
| coinomi || wallet || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || || ||<br />
|-<br />
| DigitalBitbox || wallet(hardware) || {{Prefer}} || {{Acceptable}} || {{Prefer}}|| || ||<br />
|-<br />
| Échange de Montréal || exchange || {{Prefer}}<ref name="echangedemontreal" /> || {{Prefer}}<ref name="echangedemontreal" /> || || ||<br />
|-<br />
| Jaxx || || {{Prefer}}<ref name="jaxx">[https://twitter.com/Jaxx_Support/status/882607648457334785 Jaxx tweet]</ref> || {{Acceptable}}<ref name="jaxx"/> || || {{AccJuly}}<ref name="jaxx"/> || {{AccJuly}}<ref name="jaxx"/> ||<br />
|-<br />
| Kraken || exchange || || || || || ||<br />
|-<br />
| LightningASIC || miner || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || || ||<br />
|-<br />
| OneHash || betting || {{Prefer}}<ref>[https://blog.onehash.com/sick-of-presidential-election-3f1a2defbbbf OneHash, "Sick of presidential election ?!"]</ref> || || || {{AccJuly}} || {{AccJuly}}<ref name="silbert" /> ||<br />
|-<br />
| Poloniex || exchange || || || || || ||<br />
|-<br />
|QUOINE || exchange, trading, financial services || {{Evaluating}}<ref name="coindance" /> || {{Evaluating}}<ref name="coindance" /> || {{Evaluating}}<ref name="coindance" /> || {{Evaluating}}<ref name="coindance" /> || {{Evaluating}}<ref name="coindance" /> || {{Evaluating}}<ref name="coindance" /> <br />
|-<br />
| Slushpool || miner || {{Prefer}}<ref name="coindance" /> || {{Acceptable}}<ref name="coindance" /> || || || ||<br />
|-<br />
| TheRockTrading || exchange || || {{Evaluating}}<ref>[https://twitter.com/TheRockTrading/status/872464394034315269 @TheRockTrading message on Twitter]</ref> || || || ||<br />
|-<br />
| Vaultoro || exchange || {{Prefer}}<ref name="coindance" /> || {{Acceptable}}<ref name="coindance" /> || || {{AccJuly}} || {{AccJuly}}<ref name="silbert" /> ||<br />
|-<br />
| Walltime || exchange || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || || ||<br />
|-<br />
| Xapo || wallet || {{Prefer}}<ref name="coindance" /> || || || {{AccJuly}}<ref name="xapo">[https://twitter.com/tedmrogers/status/883061218545614848 Xapo tweet]</ref> || {{AccJuly}}<ref name="xapo"/> || <br />
|-<br />
|}<br />
<br />
<br />
<references><br />
<ref name="bccore_swadoption">[https://bitcoincore.org/en/segwit_adoption/ Bitcoin Core's Segwit adoption list]</ref><br />
<ref name="coindance">[https://coin.dance/poli Coin Dance, "Global Bitcoin Political Support & Public Opinion"]</ref><br />
<ref name="silbert">[https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77 Digital Currency Group, "Bitcoin Scaling Agreement at Consensus 2017"]</ref><br />
<ref name="echangedemontreal">[https://twitter.com/echangedemtl/status/875781093261271040 Échange de Montréal on twitter]</ref><br />
</references></div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Miner_fees&diff=63517Miner fees2017-06-25T19:53:20Z<p>Giszmo: /* See Also */ added jochen hoenicke's mempool visualisation</p>
<hr />
<div><br />
'''Transaction fees''' may be included with any transfer of bitcoins from one address to another.<br />
<br />
==Background==<br />
<br />
[[File:fee.png|thumb|Receiving the fees from hundreds of transactions (0.44 BTC)]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Traditionally, the sender pays the full Bitcoin network fee; deducting the fee from the amount received by the recipient will often be considered an incomplete payment.<br />
<br />
==Reference Implementation==<br />
<br />
The following sections describe the behavior of the [[Original Bitcoin client|reference implementation]] as of version 0.12.0. Earlier versions treated fees differently, as do other popular implementations (including possible later versions).<br />
<br />
===Sending===<br />
<br />
Users can decide to pay a predefined fee rate by setting `-paytxfee=<n>`<br />
(or `settxfee <n>` rpc during runtime). A value of `n=0` signals Bitcoin<br />
Core to use floating fees. By default, Bitcoin Core will use floating<br />
fees.<br />
<br />
Based on past transaction data, floating fees approximate the fees<br />
required to get into the `m`th block from now. This is configurable<br />
with `-txconfirmtarget=<m>` (default: `2`).<br />
<br />
Sometimes, it is not possible to give good estimates, or an estimate<br />
at all. Therefore, a fallback value can be set with `-fallbackfee=<f>`<br />
(default: `0.0002` BTC/kB).<br />
<br />
At all times, Bitcoin Core will cap fees at `-maxtxfee=<x>` (default:<br />
0.10) BTC.<br />
Furthermore, Bitcoin Core will never create transactions smaller than<br />
the current minimum relay fee.<br />
Finally, a user can set the minimum fee rate for all transactions with<br />
`-mintxfee=<<nowiki>i</nowiki>>`, which defaults to 1000 satoshis per kB.<br />
<br />
<br />
Note that a typical transaction is 500 bytes.<br />
<br />
===Including in Blocks===<br />
<br />
This section describes how the reference implementation selects which transactions to put into new blocks, with default settings. All of the settings may be changed if a miner wants to create larger or smaller blocks containing more or fewer free transactions.<br />
<br />
Then transactions that pay a fee of at least 0.00001 BTC/kb are added to the block, highest-fee-per-kilobyte transactions first, until the block is not more than 750,000 bytes big.<br />
<br />
The remaining transactions remain in the miner's "memory pool", and may be included in later blocks if their priority or fee is large enough.<br />
<br />
For Bitcoin Core 0.12.0 zero bytes<ref>https://github.com/bitcoin/bitcoin/blob/v0.12.0/doc/release-notes.md#relay-and-mining-priority-transactions</ref> in the block are set aside for the highest-[[Transaction_fees#Priority_transactions|priority transactions]]. Transactions are added highest-priority-first to this section of the block.<br />
<br />
===Relaying===<br />
<br />
The reference implementation's rules for relaying transactions across the peer-to-peer network are very similar to the rules for sending transactions, as a value of 0.00001 BTC is used to determine whether or not a transaction is considered "Free". However, the rule that all outputs must be 0.01 BTC or larger does not apply. To prevent "penny-flooding" denial-of-service attacks on the network, the reference implementation caps the number of free transactions it will relay to other nodes to (by default) 15 thousand bytes per minute.<br />
<br />
===Settings===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Setting !! Default Value (units)<br />
|-<br />
| txconfirmtarget || 2 (blocks)<br />
|-<br />
| paytxfee || 0 (BTC/kB)<br />
|-<br />
| mintxfee || 0.00001 (BTC/kB)<br />
|-<br />
| limitfreerelay || 15 (thousand bytes per minute)<br />
|-<br />
| minrelaytxfee || 0.00001 (BTC/kB)<br />
|-<br />
| blockmaxsize || 750000 (bytes)<br />
|-<br />
| blockminsize || 0 (bytes)<br />
|-<br />
| blockprioritysize || 0 (bytes)<br />
|}<br />
<br />
==Fee Plotting Sites==<br />
<br />
As of May 2016, the following sites seem to plot the required fee, in satoshi per (kilo)byte, required to get a transaction mined in a certain number of blocks. Note that all these algorithms work in terms of probabilities.<br />
<br />
* https://bitcoinfees.21.co/<br />
* https://bitcoinfees.github.io/<br />
* https://statoshi.info/dashboard/db/fee-estimates<br />
* http://p2sh.info/dashboard/db/fee-estimation<br />
* https://www.bitcoinqueue.com/2d.html<br />
<br />
=== Other Useful Sites ===<br />
<br />
* https://anduck.net/bitcoin/fees/ - Shows what kind of fees filled up recent blocks<br />
* https://btc.com/stats/unconfirmed-tx - the state of the website's mempool broken down by fee rate<br />
* https://jochen-hoenicke.de/queue/#1w - another mempool broken down by fee rate site<br />
* http://mempool.us.to/tx.html - Tells you where a unconfirmed txid is in the queue based on its fee rate (Note that not all miners use the same algorithm)<br />
* https://estimatefee.com/ - You can click any of the transactions in that graph to get more info (like its "effective fee rate" which uses recursive ancestors/descendants for CPFP) and an estimated amount of blocks it'll take to confirm. It works with any transaction in the top 100MB of the bitcoin mempool. And you can enter in any transaction txid for info when you'er wondering why it doesn't confirm.<br />
<br />
==Priority transactions==<br />
<br />
Historically it was not required to include a fee for every transaction. A large portion of miners would mine transactions with no fee given that they had enough "priority". Today, low priority is mostly used as an indicator for spam transactions and almost all miners expect every transaction to include a fee. Today miners choose which transactions to mine only based on fee-rate.<br />
<br />
Transaction priority was calculated as a value-weighted sum of input age, divided by transaction size in bytes:<br />
priority = sum(input_value_in_base_units * input_age)/size_in_bytes<br />
Transactions needed to have a priority above 57,600,000 to avoid the enforced limit (as of client version 0.3.21). This threshold was 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.<br />
<br />
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<br />
(500000000 * 10 + 200000000 * 3) / 500 = 11,200,000<br />
<br />
===Historic rules for free transactions===<br />
A transaction was safe to send without fees if these conditions were met:<br />
<br />
* It is smaller than 1,000 bytes.<br />
* All outputs are 0.01 BTC or larger.<br />
* Its priority is large enough (see above)<br />
<br />
==See Also==<br />
<br />
* [[Free transaction relay policy]]<br />
* [http://bitcoinexchangerate.org/fees Unconfirmed transactions fee chart]<br />
* [https://jochen-hoenicke.de/queue/ historic fees and mempools]<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]<br />
[[Category:Mining]]<br />
[[de:Transaktionsgebühren]]<br />
<br />
{{Bitcoin Core documentation}}</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Segwit_support&diff=63484Segwit support2017-06-19T22:45:28Z<p>Giszmo: /* Developers */</p>
<hr />
<div><big><big>'''PLEASE NOTE:''' This list is not yet complete.</big></big><br />
<br />
'''Developers/businesses: Please add a row for yourself in the applicable table to reflect your positions. If for some reason you don't already have a wiki account that can edit the page, make an account and ask luke-jr for help if you get caught in the anti-spam.'''<br />
<br />
{| class="wikitable"<br />
| {{No}} || doesn't support (but might or might not go along with it with sufficient community support)<br />
|-<br />
| {{Deficient}} || okay with the idea, but considers it to have insufficient community support<br />
|-<br />
| {{Evaluating}} || still evaluating the idea<br />
|-<br />
| {{AccJuly}} || it is a workable solution, provided it is activated before August 1 (and therefore BIP148-compatible)<br />
|-<br />
| {{Wanting}} || positively likes the idea, but considers it to have insufficient community support<br />
|-<br />
| {{Weak}} || better than nothing at all<br />
|-<br />
| {{Acceptable}} || it is a workable solution<br />
|-<br />
| {{Prefer}} || it is what he would choose if it was only up to him and no outside influences<br />
|}<br />
<br />
__TOC__<br />
<br />
==Developers==<br />
<br />
<!-- README: please keep alphabetically ordered by surname! --><br />
<br />
''Note that support for a given proposal does not mean developers support merging it into Core or any other specific codebase.''<br />
<br />
{| class="wikitable sortable"<br />
! rowspan=2 | Developer<br />
! rowspan=2 | Aff* <!-- Using one year before the the creation date of this page as the benchmark. Do not list yourself as affiliated with a project that you haven't made meaningful contributions to since then. --><br />
! Segwit itself<br />
! colspan=3 | Deployment methods<br />
! colspan=2 | Hardfork bundles (Silbert agreement)<br />
|-<br />
! [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP 141] !! [https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki BIP 148] !! [https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki BIP 149] !! [https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki BIP 91] || Segwit2x || [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014445.html COOP]<br />
|-<br />
| Karl-Johan Alm || Core || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}<br />
|-<br />
| Bryan Bishop || Core || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| ฿tcDrak || Core || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}} || {{No}}<br />
|-<br />
| Andrew Chow || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Wang Chun || [[F2Pool]] || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{Acceptable}} || {{AccJuly}} ||<br />
|-<br />
| Matt Corallo || Core || {{Prefer}} || {{No}} || || {{Acceptable}} || {{No|LOL}} ||<br />
|-<br />
| Johnathan Corgan || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{No}} || {{No}} || {{No}}<br />
|-<br />
| Luke Dashjr || Core || {{Prefer}} || {{Prefer}} || {{No}} || {{AccJuly}} || {{No}} || {{Deficient}}<br />
|-<br />
| Christian Decker || c-lightning || {{Prefer}} || {{Acceptable}} || || || || <br />
|-<br />
| Nicolas Dorier || Core || {{Prefer}} || {{Deficient}} || {{Acceptable}} || {{AccJuly}} || ||<br />
|-<br />
| Thaddeus Dryja || lit || {{Prefer}} || {{No}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}<br />
|-<br />
| Marco Falke || Core || {{Prefer}} || {{Deficient}} || {{Prefer}} || {{Deficient}} || ||<br />
|-<br />
| Mark Friedenbach || BIP 68/112 || {{Prefer}} || {{Prefer}} || {{No}} || {{AccJuly}} || {{No|LOL}} || {{No|Nope}}<br />
|-<br />
| Pavel Janik || Core || {{Prefer}} || {{No}} || {{Acceptable}} || {{No}} || {{No}} || {{No}}<br />
|-<br />
| Thomas Kerin || Core || {{Prefer}} || {{Wanting}} || {{Prefer}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Johnson Lau || Core || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Acceptable}} || ||<br />
|-<br />
| Eric Lombrozo || || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{AccJuly}} || {{No}} || {{No}}<br />
|-<br />
| Greg Maxwell || Core || {{Prefer}} || {{Deficient}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Alex Morcos || Core || {{Prefer}} || {{Deficient}} || {{Acceptable}} || {{Weak}} || {{No}} ||<br />
|-<br />
| nopara73 || TumbleBit || {{Weak}} || {{Wanting}} || {{Prefer}} || || ||<br />
|-<br />
| Laolu "roasbeef" Osuntokun || lnd || {{Prefer}} || || || || {{No}} ||<br />
|-<br />
| Jeremy Rubin || Core || {{Prefer}} || {{Deficient}} || {{No}} || {{AccJuly}} || {{No}} || {{No}}<br />
|-<br />
| Pavol "stick" Rusnak || Trezor || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{AccJuly}} || {{No}} || {{No}}<br />
|-<br />
| Rusty Russell || c-lightning || {{Prefer}} || {{Prefer}} || || || ||<br />
|-<br />
| Gregory Sanders || Core || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Weak}} || {{No}} ||<br />
|-<br />
| Jonas Schnelli || Core || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}<br />
|-<br />
| Patrick Strateman || Core || {{Prefer}} || || || || {{No}} || {{No}}<br />
|-<br />
| Paul Sztorc || || {{Prefer}} || {{Deficient}} || {{Wanting}} || {{AccJuly}} || {{Evaluating}} || {{No}}<br />
|-<br />
| Amir Taaki || libbtc || {{Acceptable}} || {{Prefer}} || || || {{No}} || {{No}} <br />
|-<br />
| Jorge Timon || Core || {{Prefer}} || {{No}} || {{Prefer}} || {{Deficient}} || {{No}} || {{No}}<br />
|-<br />
| Peter Todd || Core || {{Prefer}} || {{Acceptable}} || || || ||<br />
|-<br />
| Warren Togami || Elements || {{Prefer}} || {{Prefer}} || {{Acceptable}} || || ||<br />
|-<br />
| Wladimir van der Laan || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}<br />
|-<br />
| Leo Wandersleb || Mycelium || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{AccJuly}} || {{No}}<br />
|-<br />
| Pieter Wuille || Core || {{Prefer}} || || || || {{No}} ||<br />
|}<br />
<br />
* "affiliation" is an optional field for the company or project the individual is associated with, that most qualifies the person to comment on the matter and is not meant as a company or project endorsement of the individual's position.<br />
<br />
==Businesses==<br />
<br />
'''When adding companies below, sources for each position MUST be provided.'''<br />
<br />
{| class="wikitable sortable"<br />
! rowspan=2 | Company <br />
! rowspan=2 | Service<br />
! Segwit itself<br />
! colspan=3 | Deployment methods<br />
! colspan=2 | Hardfork bundles (Silbert agreement)<br />
|-<br />
! [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP 141] !! [https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki BIP 148] !! [https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki BIP 149] !! [https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki BIP 91] || Segwit2x || [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014445.html COOP]<br />
|-<br />
| Abra || wallet || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || {{AccJuly}} || {{AccJuly}}<ref name="silbert" /> ||<br />
|-<br />
| Bitcoin India || exchange/miner || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || || ||<br />
|-<br />
| BitcoinReminder.com || service || {{Prefer}}<ref name="bitcoinreminder_com">[https://bitcoinreminder.com/informations/poli BitcoinReminder.com's position on scaling proposals]</ref> || {{Prefer}}<ref name="bitcoinreminder_com"/> || {{Acceptable}}<ref name="bitcoinreminder_com"/> || {{Weak}}<ref name="bitcoinreminder_com"/> || {{No|LOL}}<ref name="bitcoinreminder_com"/> || {{No}}<ref name="bitcoinreminder_com"/><br />
|-<br />
| Bitfinex || exchange || {{Acceptable}}<ref name="coindance" /> || {{Acceptable}} || || || ||<br />
|-<br />
| Bitfury || miner || {{Prefer}}<ref name="coindance" /> || {{Acceptable}} || || {{AccJuly}} || {{AccJuly}}<ref name="silbert" /> ||<br />
|-<br />
| Bitmain || miner || {{AccJuly}}<ref name="bitmain">[https://blog.bitmain.com/en/uahf-contingency-plan-uasf-bip148/ Bitmain's plot against BIP148]</ref> || {{No}} || || {{AccJuly}} || {{AccJuly}}<ref name="bitmain" /> ||<br />
|-<br />
| Bitonic/BL3P.eu || exchange || {{Prefer}}<ref name="bitonic">[https://bitonic.nl/en/news/138/our-position-on-scaling-proposals Bitonic's position on scaling proposals]</ref> || {{Prefer}}<ref name="bitonic"/> || {{Acceptable}}<ref name="bitonic"/> || {{Weak}}<ref name="bitonic"/> || {{No|LOL}}<ref name="bitonic"/> || {{No}}<br />
|-<br />
| Bitpay || wallet || {{Prefer}}<ref name="bccore_swadoption"/> || {{No}} || || {{Prefer}} || {{Prefer}}<ref name="silbert" /> ||<br />
|-<br />
| Bitrated || reputation || {{Acceptable}}<ref name="bitrated">[https://twitter.com/bitrated/status/876805892003553281]</ref> || {{Acceptable}}<ref name="bitrated" /> || {{Prefer}}<ref name="bitrated" /> || {{AccJuly}}<ref name="bitrated" /> || {{No}}<ref name="bitrated" /><ref>[https://medium.com/@shesek/why-i-dont-support-the-compromise-efforts-9d73a8cce6be Why I don’t support horse-trading compromises for Bitcoin protocol development]</ref> ||<br />
|-<br />
| Bitrefill || merchant || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || || ||<br />
|-<br />
| Bitsquare || exchange || {{Prefer}} || {{Prefer}}<ref name="bitsquare">[https://forum.bitsquare.io/t/bitsquare-will-support-uasf-bitcoin-not-bitmaincoin/2265 Bitsquare will support UASF Bitcoin not BitMainCoin]</ref> || {{Acceptable}}<ref name="bitsquare"/> || || || ||<br />
|-<br />
| Bitstamp || exchange || || || || || ||<br />
|-<br />
| Bittylicious || exchange || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref>[https://twitter.com/Bittylicious_/status/867305106668224513 Bittylicious answer on Twitter]</ref> || || || ||<br />
|-<br />
| Blockchain.info || wallet || {{Acceptable}}<ref name="bccore_swadoption"/> || || || {{AccJuly}} || {{AccJuly}}<ref name="silbert" /> || <br />
|-<br />
| blockonomics || || {{Prefer}} || {{Prefer}}<ref>[https://twitter.com/blockonomics_co/status/851738251509497856 blockonomics announcement on Twitter]</ref> || || || ||<br />
|-<br />
| Bustabit|| gambling || {{Prefer}}<ref name="bustabit">[https://www.bustabit.com/statement-on-forks Bustabit Statement on Bitcoin Forks]</ref> || {{Acceptable}}<ref name="bustabit"/> || || || {{AccJuly}}<ref name="bustabit"/> ||<br />
|-<br />
| Ciphrex || wallet / dev stack || {{Prefer}}<ref name="coindance" /> || {{Acceptable}}<ref name="coindance" /> || || || ||<br />
|-<br />
| Coinbase || wallet || {{Acceptable}}<ref name="bccore_swadoption"/> || || || {{AccJuly}} || {{AccJuly}}<ref name="silbert" /> || <br />
|-<br />
| CoinGate || exchange || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || || ||<br />
|-<br />
| CoinJar || wallet || || {{Evaluating}}<ref>[https://twitter.com/GetCoinJar/status/875581525730787329 CoinJar answer on Twitter]</ref> || || || ||<br />
|-<br />
| Coinkite || || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || || ||<br />
|-<br />
| coinomi || wallet || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || || ||<br />
|-<br />
| DigitalBitbox || wallet(hardware) || {{Prefer}} || {{Acceptable}} || {{Prefer}}|| || ||<br />
|-<br />
| Échange de Montréal || exchange || {{Prefer}}<ref name="echangedemontreal" /> || {{Prefer}}<ref name="echangedemontreal" /> || || ||<br />
|-<br />
| Electrum || wallet || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || || ||<br />
|-<br />
| Kraken || exchange || || || || || ||<br />
|-<br />
| LightningASIC || miner || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || || ||<br />
|-<br />
| OneHash || betting || {{Prefer}}<ref>[https://blog.onehash.com/sick-of-presidential-election-3f1a2defbbbf OneHash, "Sick of presidential election ?!"]</ref> || || || {{AccJuly}} || {{AccJuly}}<ref name="silbert" /> ||<br />
|-<br />
| Poloniex || exchange || || || || || ||<br />
|-<br />
| Slushpool || miner || {{Prefer}}<ref name="coindance" /> || {{Acceptable}}<ref name="coindance" /> || || || ||<br />
|-<br />
| TheRockTrading || exchange || || {{Evaluating}}<ref>[https://twitter.com/TheRockTrading/status/872464394034315269 @TheRockTrading message on Twitter]</ref> || || || ||<br />
|-<br />
| Vaultoro || exchange || {{Prefer}}<ref name="coindance" /> || {{Acceptable}}<ref name="coindance" /> || || {{AccJuly}} || {{AccJuly}}<ref name="silbert" /> ||<br />
|-<br />
| Walltime || exchange || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || || ||<br />
|-<br />
| Xapo || wallet || {{Prefer}}<ref name="coindance" /> || || || {{Prefer}} || {{Prefer}}<ref>[https://twitter.com/tedmrogers/status/867362691370954752 Tweet by president of Xapo]</ref> || <br />
|-<br />
|}<br />
<br />
<references><br />
<ref name="bccore_swadoption">[https://bitcoincore.org/en/segwit_adoption/ Bitcoin Core's Segwit adoption list]</ref><br />
<ref name="coindance">[https://coin.dance/poli Coin Dance, "Global Bitcoin Political Support & Public Opinion"]</ref><br />
<ref name="silbert">[https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77 Digital Currency Group, "Bitcoin Scaling Agreement at Consensus 2017"]</ref><br />
<ref name="echangedemontreal">[https://twitter.com/echangedemtl/status/875781093261271040 Échange de Montréal on twitter]</ref><br />
</references></div>Giszmohttps://tests.bitcoin.it/w/index.php?title=User_talk:Giszmo&diff=63346User talk:Giszmo2017-06-12T22:09:45Z<p>Giszmo: /* table */</p>
<hr />
<div>== Wiki Cleanup ==<br />
<br />
If anyone ever offers to pay you to do this, let me know. I'll help out for free. I agree that the wiki needs some cleaning up and I also work fairly extensively with wiki's. [[User:Zellfaze|Zellfaze]] 01:52, 25 January 2012 (GMT)<br />
: Hi Zellfaze, I updated my user page referring to you as I have no time. [[User:Giszmo|Giszmo]] 13:35, 26 January 2012 (GMT)<br />
<br />
== table ==<br />
<br />
If there isn't another column for affiliation you can't sort by it, I think that is unfortunate. Also, you're going to have people listing "core" as an affiliation even if they're not even involved with the project, and I think that defeats the purpose of the column. --[[User:Gmaxwell|Gmaxwell]] ([[User talk:Gmaxwell|talk]]) 05:03, 12 June 2017 (UTC)<br />
: What? *lookingAroundConfused* Did you want to message me? LukeJr introduced the affiliate column and I have no idea why the headline spans two columns. Funny also that the code comment asks to add people alphabetically by last name, while some don't feature such a thing and sorting by it isn't possible neither. Whatever. I'd only wish that more devs would speak up on the matter. Don't get stuff done with this intensifying drama. --[[User:Giszmo|Giszmo]] ([[User talk:Giszmo|talk]]) 22:09, 12 June 2017 (UTC)</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Segwit_support&diff=63327Segwit support2017-06-12T04:27:14Z<p>Giszmo: made clearer that affiliation does not mean that an individual speaks on behalf of a group. also the old comment was not appropriate for the new column,</p>
<hr />
<div><big><big>'''PLEASE NOTE:''' This list is not yet complete, nor completely vetted by the parties listed for accuracy.</big></big><br />
<br />
'''Developers: Please edit your row (add one if you're missing) to reflect your positions. If for some reason you don't already have a wiki account that can edit the page, make an account and ask luke-jr for help if you get caught in the anti-spam.'''<br />
<br />
{| class="wikitable"<br />
| {{No}} || doesn't support (but might or might not go along with it with sufficient community support)<br />
|-<br />
| {{Deficient}} || okay with the idea, but considers it to have insufficient community support<br />
|-<br />
| {{Evaluating}} || still evaluating the idea<br />
|-<br />
| {{Wanting}} || positively likes the idea, but considers it to have insufficient community support<br />
|-<br />
| {{Weak}} || better than nothing at all<br />
|-<br />
| {{Acceptable}} || it is a workable solution<br />
|-<br />
| {{Prefer}} || it is what he would choose if it was only up to him and no outside influences<br />
|}<br />
<br />
<!-- README: please keep alphabetically ordered by surname! --><br />
<br />
''Note that support for BIP148 does not mean developers support merging it into Core.''<br />
<br />
{| class="wikitable sortable"<br />
! rowspan=2 colspan=2 | Developer & affiliation* <!-- Using one year before the the creation date of this page as the benchmark. --><br />
! Segwit itself<br />
! colspan=3 | Deployment methods<br />
! colspan=2 | Hardfork bundles (Silbert agreement)<br />
|-<br />
! [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP 141] !! [https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki BIP 148] !! [https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki BIP 149] !! [https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki BIP 91] || Segwit2x || [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014445.html COOP]<br />
|-<br />
| ฿tcDrak || Core || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}} || {{No}}<br />
|-<br />
| Bryan Bishop || || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Andrew Chow || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Matt Corallo || Core || {{Prefer}} || {{No}} || || {{Acceptable}} || {{No|LOL}} ||<br />
|-<br />
| Johnathan Corgan || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{No}} || {{No}} || {{No}}<br />
|-<br />
| Suhas Daftuar || Core || {{Prefer}} || {{No}} || || || ||<br />
|-<br />
| Luke Dashjr || Core || {{Prefer}} || {{Prefer}} || {{No}} || {{Acceptable|Acc. until July}} || {{No}} || {{Deficient}}<br />
|-<br />
| Christian Decker || Core || {{Prefer}} || {{Acceptable}} || || || || <br />
|-<br />
| Nicolas Dorier || Core || {{Prefer}} || {{Deficient}} || || || ||<br />
|-<br />
| Marco Falke || Core || {{Prefer}} || {{Deficient}} || || || ||<br />
|-<br />
| Michael Ford || Core || {{Prefer}} || || || || ||<br />
|-<br />
| Mark Friedenbach || || {{Prefer}} || {{Acceptable}} || || || ||<br />
|-<br />
| Pavel Janik || Core || {{Prefer}} || || || || ||<br />
|-<br />
| Thomas Kerin || Core || {{Prefer}} || {{Wanting}} || {{Prefer}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Johnson Lau || Core || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Acceptable}} || ||<br />
|-<br />
| Eric Lombrozo || || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Greg Maxwell || Core || {{Prefer}} || {{Deficient}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Alex Morcos || Core || {{Prefer}} || {{Deficient}} || {{Acceptable}} || {{Weak}} || {{No}} ||<br />
|-<br />
| Pavol "stick" Rusnak || Core || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}<br />
|-<br />
| Rusty Russell || || {{Prefer}} || {{Prefer}} || || || ||<br />
|-<br />
| Gregory Sanders || Core || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Weak}} || {{No}} ||<br />
|-<br />
| Jonas Schnelli || Core || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}<br />
|-<br />
| Patrick Strateman || Core || {{Prefer}} || || || || ||<br />
|-<br />
| Jorge Timon || Core || {{Prefer}} || {{No}} || {{Prefer}} || {{Deficient}} || {{No}} || {{No}}<br />
|-<br />
| Peter Todd || Core || {{Prefer}} || {{Acceptable}} || || || ||<br />
|-<br />
| Warren Togami || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || || ||<br />
|-<br />
| Wladimir van der Laan || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}<br />
|-<br />
| flix1 || || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{Deficient}} || {{Evaluating}} || {{Evaluating}}<br />
|-<br />
| Leo Wandersleb || Mycelium || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}<br />
|}<br />
<br />
* "affiliation" is a company or project the individual is associated with, that most qualifies the person to comment on the matter and is not meant as a company or project endorsement of the individual's position.</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Segwit_support&diff=63324Segwit support2017-06-12T02:48:13Z<p>Giszmo: Showing my support as an identifiable member of the industry</p>
<hr />
<div><big><big>'''PLEASE NOTE:''' This list is not yet complete, nor completely vetted by the parties listed for accuracy.</big></big><br />
<br />
'''Developers: Please edit your row (add one if you're missing) to reflect your positions. If for some reason you don't already have a wiki account that can edit the page, make an account and ask luke-jr for help if you get caught in the anti-spam.'''<br />
<br />
{| class="wikitable"<br />
| {{No}} || doesn't support (but might or might not go along with it with sufficient community support)<br />
|-<br />
| {{Deficient}} || okay with the idea, but considers it to have insufficient community support<br />
|-<br />
| {{Evaluating}} || still evaluating the idea<br />
|-<br />
| {{Wanting}} || positively likes the idea, but considers it to have insufficient community support<br />
|-<br />
| {{Weak}} || better than nothing at all<br />
|-<br />
| {{Acceptable}} || it is a workable solution<br />
|-<br />
| {{Prefer}} || it is what he would choose if it was only up to him and no outside influences<br />
|}<br />
<br />
<!-- README: please keep alphabetically ordered by surname! --><br />
<br />
''Note that support for BIP148 does not mean developers support merging it into Core.''<br />
<br />
{| class="wikitable sortable"<br />
! rowspan=2 | Developer<br />
! colspan=1 | Active in <!-- Using one year before the the creation date of this page as the benchmark. --><br />
! Segwit itself<br />
! colspan=3 | Deployment methods<br />
! colspan=2 | Hardfork bundles (Silbert agreement)<br />
|-<br />
! Core <span style="font-size:50%;">''(1)''</span> !! [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP 141] !! [https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki BIP 148] !! [https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki BIP 149] !! [https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki BIP 91] || Segwit2x || [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014445.html COOP]<br />
|-<br />
| ฿tcDrak || {{Yes}} || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}} || {{No}}<br />
|-<br />
| Bryan Bishop || {{No}} || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Andrew Chow || {{Yes}} || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Matt Corallo || {{Yes}} || {{Prefer}} || {{No}} || || {{Acceptable}} || {{No|LOL}} ||<br />
|-<br />
| Johnathan Corgan || {{Yes}} || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{No}} || {{No}} || {{Evaluating}}<br />
|-<br />
| Suhas Daftuar || {{Yes}} || {{Prefer}} || {{No}} || || || ||<br />
|-<br />
| Luke Dashjr || {{Yes}} || {{Prefer}} || {{Prefer}} || {{No}} || {{Acceptable|Acc. until July}} || {{No}} || {{Deficient}}<br />
|-<br />
| Christian Decker || {{Yes}} || {{Prefer}} || {{Acceptable}} || || || || <br />
|-<br />
| Nicolas Dorier || {{Yes}} || {{Prefer}} || {{Deficient}} || || || ||<br />
|-<br />
| Marco Falke || {{Yes}} || {{Prefer}} || {{Deficient}} || || || ||<br />
|-<br />
| Michael Ford || {{Yes}} || {{Prefer}} || || || || ||<br />
|-<br />
| Mark Friedenbach || {{No}} || {{Prefer}} || {{Acceptable}} || || || ||<br />
|-<br />
| Pavel Janik || {{Yes}} || {{Prefer}} || || || || ||<br />
|-<br />
| Thomas Kerin || {{Yes}} || {{Prefer}} || {{Wanting}} || {{Prefer}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Johnson Lau || {{Yes}} || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Acceptable}} || ||<br />
|-<br />
| Eric Lombrozo || {{No}} || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Greg Maxwell || {{Yes}} || {{Prefer}} || {{Deficient}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}<br />
|-<br />
| Alex Morcos || {{Yes}} || {{Prefer}} || {{Deficient}} || {{Acceptable}} || {{Weak}} || {{No}} ||<br />
|-<br />
| Pavol "stick" Rusnak || {{Yes}} || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}<br />
|-<br />
| Rusty Russell || {{No}} || {{Prefer}} || {{Prefer}} || || || ||<br />
|-<br />
| Gregory Sanders || {{Yes}} || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Weak}} || {{No}} ||<br />
|-<br />
| Jonas Schnelli || {{Yes}} || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}<br />
|-<br />
| Patrick Strateman || {{Yes}} || {{Prefer}} || || || || ||<br />
|-<br />
| Jorge Timon || {{Yes}} || {{Prefer}} || {{No}} || {{Prefer}} || {{Deficient}} || {{No}} || {{No}}<br />
|-<br />
| Peter Todd || {{Yes}} || {{Prefer}} || {{Acceptable}} || || || ||<br />
|-<br />
| Warren Togami || {{Yes}} || {{Prefer}} || {{Prefer}} || {{Acceptable}} || || ||<br />
|-<br />
| Wladimir van der Laan || {{Yes}} || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}<br />
|-<br />
| flix1 || {{No|?}} || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{Deficient}} || {{Evaluating}} || {{Evaluating}}<br />
|-<br />
| Leo Wandersleb || {{No}} || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}<br />
|}<br />
<br />
* (1) using the presence of any commit in the 12 months before the creation date as a benchmark</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Talk:Firstbits&diff=61257Talk:Firstbits2016-06-30T18:06:16Z<p>Giszmo: /* firstbits as a tool to find an address */ new section</p>
<hr />
<div>== Reverting unback claims ==<br />
<br />
Reverting [https://en.bitcoin.it/w/index.php?title=Firstbits&action=historysubmit&diff=24974&oldid=19697 claims] that<br />
<br />
Firstbits is generally considered to be a bad idea because it encourages transaction spam.<br />
This position is held by most, if not all, of Bitcoin developers.<br />
<br />
"transaction spam" is not a generally accepted meaningful term - any transaction is legitimate. Certainly such a strong claim that presumes to speak on behalf of "most or all of the devs" must be backed by evidence.<br />
<br />
Luke-Jr, please do not revert this without a discussion, and do not add the claim with a prefix such as "According to some".<br />
<br />
[[User:Ripper234|Ripper234]] ([[User talk:Ripper234|talk]]) 01:54, 1 May 2013 (GMT)<br />
<br />
: Reverting ''with'' a discussion: I'm not aware of a single developer who disagrees with the position stated. --[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 05:20, 2 May 2013 (GMT)<br />
<br />
== firstbits as a tool to find an address ==<br />
<br />
While I agree with the hefty criticism, I often have the problem that I want to check something about an address (or transaction hash or block hash or ...) and while the first 5 letters would uniquely identify the item, block explorers force me to type it in to provide all letters instead of making "smart suggestions". I guess this use case would be very legitimate. (I would be the first to support a fee penalty for sending to addresses that already had transactions but still, first bits are very relevant identifiers that should be easier to use.)<br />
<br />
--[[User:Giszmo|Giszmo]] ([[User talk:Giszmo|talk]]) 18:06, 30 June 2016 (UTC)</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Brainwallet&diff=58595Brainwallet2015-09-01T14:04:33Z<p>Giszmo: added Ryan's talk video</p>
<hr />
<div>A '''brainwallet''' refers to the concept of storing Bitcoins in one's own mind by memorization of a passphrase. As long as the passphrase is not recorded anywhere, the Bitcoins can be thought of as existing nowhere except in the mind of the holder. If a brainwallet is forgotten or the person dies or is permanently incapacitated, the Bitcoins are lost forever.<br />
<br />
Early brainwallets were created simply by coming up with a passphrase. The phrase is turned into a 256-bit [[private key]] with a hashing or key derivation algorithm (example: SHA256). That private key is then used to compute a Bitcoin address, or a deterministic sequence of addresses. '''WARNING - This method was found to be very insecure. Do not use it. Humans are not a good source of entropy.''' Use the below worked example.<br />
<br />
==Creating a Brainwallet==<br />
<br />
A much safer way of storing money in your brain is to have software generate the cryptographic entropy and then memorize it. For example wallets like [[Electrum]], [[Armory]] and [[Mycelium]] create backup mnemonic words seeds. Using techniques like memory pegging allow them to be memorized and recalled easily. Using a deterministic wallet with multiple addresses also stops the problems associated with [[address reuse]].<br />
<br />
===Worked Example===<br />
<br />
# On a computer with no malware, run [[Electrum]] and generate the 13-word recovery seed.<br />
# Memorize the seed using http://en.wikipedia.org/wiki/Mnemonic_peg_system<br />
# When spending or saving, restore the wallet from memory using the seed.<br />
# Use the master public key to create an online watch-only wallet, where you can send to but not spend.<br />
# Spend from the wallet in the manner of [[Cold_storage|deep cold storage]]. Transferring the unsigned transaction to the cold storage computer, signing it and broadcasting to the network.<br />
<br />
====Example Mnemonic Peg====<br />
To memorize a mnemonic seed with this method you must invent a story which hits the words as "keynotes". Try to make it like a fairy tale story, use imagery. Make it somehow striking and emotionally resonant. When remembering you just remember the key words, not all the other words - the other can be remembered more as images and thoughts (which are hard to write down)<br />
<br />
Let's say we have this seed:<br />
<br />
witch collapse practice feed shame open despair creek road again ice least<br />
<br />
You'd imagine walking through a building familiar to you, maybe your own home or workplace or school.<br />
<br />
* You imagine looking in the first room and seeing your mother dressed as a '''witch''', playing the jenga boardgame until the tower '''collapses'''.<br />
* You walk to the next room and see your father '''practising''' with a longbow, he shoots a chicken to '''feeds''' himself.<br />
* In the next room you see your brother naked in '''shame''' attempting to cover himself, he's looking through a window thats '''open''' and flapping in the wind.<br />
* Now you reach the kitchen, girlfriend is looking at Picasso's [https://en.wikipedia.org/wiki/Guernica_%28Picasso%29 Guernica] on the wall. She is in '''despair''' from it. Next to it is a television playing the show Dawson's '''Creek'''.<br />
* Next you're in the garage, your childhood friend is working on his car. He plans to go on a '''road''' trip for the 5th time this month, he's going '''again'''.<br />
* Finally to go outside to the garden. It's early spring and the ground is covered in melting '''ice'''. Two of your other friends are there, one friend has a huge basket of apples, the other has a smaller basket but you're holding only some apples. You've got the '''least''' apples.<br />
<br />
Repeat this story in your head several times over a short period - the first few days. It will sink in, deep, after that. You'll only have to revisit it very occasionally. After a while you can ignore it for months and it'll still come back, not that I'd recommend relying on that.<br />
<br />
==Possible Dangers==<br />
<br />
===Low Entropy from Human-Generated Passphrases===<br />
<br />
Practically everyone who knows about or cares loudly yells at people DO NOT USE BRAINWALLETS. We've seen pretty concrete evidence that users are resistant to good advice in this space, and they are shocked when their favorite quotation is cracked and they lose their coins (But it was 60 characters long! I even added a special character! how is this possible?!), the existing sites promoting this stuff won't use a KDF stronger than SHA256*1 because "users are stupid if they use weak passwords".<br />
<br />
''Brainwallets.<br />
<br />
FOR GODS SAKE. DON'T DO IT. YOU MAY THINK YOU ARE SMART ENOUGH. SO DID EVERYONE ELSE WHO GOT ROBBED. HUMANS ARE NOT A GOOD SOURCE OF ENTROPY.<br />
<br />
YOU HAVE A SCHEME? Pfft. THE SPACE OF ALL SCHEMES YOU'RE LIKELY TO HAVE PROBABLY ONLY HAS A FEW BITS OF ENTROPY. RANDOM PHRASE IN A BOOK? THERE ARE ONLY ABOUT 30 BITS OF SENTENCE SELECTION IN A LIBRARY.<br />
<br />
OH NO. YOU ARE NOT LISTENING TO ME, ARE YOU?<br />
<br />
OH CRAP. YOU THINK THAT "EIGHT CHARACTERS AND ONE FROM EACH CHARACTER CLASS" APPLIES HERE?? WEBSITE SECURITY MIGHT HAVE TO DEAL WITH 1000 ATTEMPTS PER SECOND, BUT SOME DUDE WITH A FPGA FARM IS PROBABLY PRECOMPUTING A BILLION BRAINWALLETS PER SECOND. JUST STOP.<br />
<br />
NOOOOOOOOOOOO.<br />
<br />
Well, now that you have no more Bitcoin I guess we don't have to worry about you using a brainwallet.<br />
<br />
Cheers.'' <ref>[https://bitcointalk.org/index.php?topic=311000.msg3345309#msg3345309 Re: hardening brain-wallets with a useful blind proof of work ]</ref><br />
<br />
====Ryan Castellucci DEFCON Talk====<br />
<br />
Ryan Castellucci gave a talk at DEFCON23 about cracking brainwallet passphrases. Although brainwallet passphrases were being exploited for years by this point, the talk helped bring the issues to more popular consciousness.<ref>[https://rya.nc/cracking_cryptocurrency_brainwallets.pdf Ryan Castellucci DEFCON Talk]</ref><ref>[https://www.reddit.com/r/Bitcoin/comments/3g9f1s/why_im_releasing_a_brainwallet_cracker_at_defcon/ Reddit thread on Ryan's talk]</ref><ref>[https://www.youtube.com/watch?v=foil0hzl4Pg a video of Ryan's talk]</ref><br />
<br />
===Falleable Memory===<br />
Human memory can be far more falleable than we normally expect. So if you're only storage is memory you may find that it just vanished one day. Keeping a copy stored on paper somewhere could be a useful backup, depending on circumstances.<br />
<br />
==References==<br />
<references><br />
</references></div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Invoice_address&diff=46223Invoice address2014-04-08T03:36:31Z<p>Giszmo: removed garbage that my BitChrome plugin added. sorry.</p>
<hr />
<div>A '''Bitcoin address''', or simply '''address''', is an identifier of 27-34 alphanumeric characters, beginning with the number 1 or 3, that represents a possible destination for a Bitcoin payment.<br />
Addresses can be generated at no cost by any user of Bitcoin.<br />
For example, using [[Bitcoin-Qt]], one can click "New Address" and be assigned an address.<br />
It is also possible to get a Bitcoin address using an account at an exchange or online wallet service.<br />
<br />
An example of a Bitcoin address is ''1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa'<ref>[http://blockexplorer.com/b/0 The first Bitcoin Address] ever with a positive balance was ''1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa''</ref>.<br />
<br />
==A Bitcoin address is like an e-mail address==<br />
Like e-mail, you can send bitcoins to a person by sending bitcoins to one of their addresses. A person can have many different Bitcoin addresses and, for increased privacy and as the only way to know what the bitcoins are received for/from, it is recommended that you use a unique address for each transaction. Most Bitcoin software and websites will help with this by generating a brand new address each time you perform a transaction. Some services provide a facility to request a new Bitcoin address for use with their service when desired.<br />
<br />
When using a web site that accepts bitcoins or holds Bitcoin balances on your behalf, that website will assign a Bitcoin address to your account, so you can transfer funds into your account at the site. Very much unlike e-mail, this address may change every time funds come in so care should be taken when sending additional funds to a previously-used address. When you send Bitcoins to your account at a web site, they will usually be credited to your account at that web site after the transaction is [[confirmation|confirmed]].<br />
<br />
==Addresses can be created offline==<br />
Creating addresses can be done without an Internet connection and does not require any contact or registration with the Bitcoin network. The network starts tracking an address when it is first seen in a valid payment transaction.<br />
<br />
It is possible to create large batches of addresses offline using freely available software tools. Generating batches of addresses is useful in several scenarios, such as e-commerce websites where a unique pre-generated address is dispensed to each customer who chooses a "pay with Bitcoin" option.<br />
<br />
An average desktop computer can generate thousands of new Bitcoin addresses a minute. Addresses are created simply by generating random numbers and then performing mathematical operations to derive matching pairs of "public" and "private" keys. Because addresses can be created easily and at minimal cost, it is not uncommon to create temporary addresses that can be discarded if unused.<br />
<br />
==Addresses are case sensitive and exact==<br />
Bitcoin addresses are case-sensitive. Bitcoin addresses should be copied and pasted using the computer's clipboard wherever possible. If you hand-key a Bitcoin address, and each character is not transcribed exactly - including capitalization - the incorrect address will most likely be rejected by the Bitcoin software. You will have to check your entry and try again.<br />
<br />
The probability that a mistyped address is accepted as being valid is 1 in 2<sup>32</sup>, that is, approximately 1 in 4.29 billion.<br />
<br />
==Address validation==<br />
If you would like to validate a Bitcoin address in an application, it is advisable to use a method from [https://bitcointalk.org/index.php?topic=1026.0 this thread] rather than to just check for string length, allowed characters, or that the address starts with a 1 or 3.<br />
<br />
==Addresses have a "private key"==<br />
For most properly-generated Bitcoin addresses, there is at least one secret number known as a [[private key]] which is required for access to the funds assigned to that address.<br />
<br />
When using a Bitcoin client, private keys are typically stored in the [[Wallet|wallet file]]. The private key has a special purpose - it is mathematically needed to create valid transactions that spend the funds originally sent to the address. If the private key to an address is lost (for example, in a hard drive crash, fire or other natural disaster), any associated Bitcoins are effectively lost forever.<br />
<br />
==Multi-signature addresses==<br />
Addresses can be created that require a combination of multiple private keys.<br />
Since these take advantage of newer features, they begin with the newer prefix of 3 instead of the older 1.<br />
These can be thought of as the equivalent of writing a check to two parties - "pay to the order of somebody AND somebody else" - where both parties must endorse the check in order to receive the funds.<br />
<br />
The actual requirement (number of private keys needed, their corresponding public keys, etc.) that must be satisfied to spend the funds is decided in advance by the person generating this type of address, and once an address is created, the requirement cannot be changed without generating a new address.<br />
<br />
==What's in an address==<br />
Most Bitcoin addresses are 34 characters.<br />
They consist of random digits and uppercase and lowercase letters, with the exception that the uppercase letter "O", uppercase letter "I", lowercase letter "l", and the number "0" are never used to prevent visual ambiguity.<br />
<br />
Some Bitcoin addresses can be shorter than 34 characters (as few as 27 in theory) and still be valid.<br />
A significant percentage of Bitcoin addresses are only 33 characters, and some addresses may be even shorter.<br />
Every Bitcoin address stands for a number - somewhat like an account number. These shorter addresses are valid simply because they stand for numbers that happen to start with zeroes, and when the zeroes are omitted, the encoded address gets shorter.<br />
<br />
Several of the characters inside a Bitcoin address are used as a checksum so that typographical errors can be automatically found and rejected. The checksum also allows Bitcoin software to confirm that a 33-character (or shorter) address is in fact valid and isn't simply an address with a missing character.<br />
<br />
==See Also==<br />
* [[Technical background of Bitcoin addresses]]<br />
* [[List of address prefixes]]<br />
* [[Exit Address]]<br />
<br />
== References ==<br />
<references/><br />
<br />
[[Category:Vocabulary]]<br />
<br />
[[es:Dirección]]<br />
[[de:Adresse]]</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Invoice_address&diff=46222Invoice address2014-04-08T03:34:18Z<p>Giszmo: added References section</p>
<hr />
<div>A '''Bitcoin address''', or simply '''address''', is an identifier of 27-34 alphanumeric characters, beginning with the number 1 or 3, that represents a possible destination for a Bitcoin payment.<br />
Addresses can be generated at no cost by any user of Bitcoin.<br />
For example, using [[Bitcoin-Qt]], one can click "New Address" and be assigned an address.<br />
It is also possible to get a Bitcoin address using an account at an exchange or online wallet service.<br />
<br />
An example of a Bitcoin address is ''1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa<span class='bitchrome-address' address='1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa'></span><span class='bitchrome-address' address='1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa<span class='bitchrome-address' address='1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa'></span>'></span>''<ref>[http://blockexplorer.com/b/0 The first Bitcoin Address] ever with a positive balance</ref>.<br />
<br />
==A Bitcoin address is like an e-mail address==<br />
Like e-mail, you can send bitcoins to a person by sending bitcoins to one of their addresses. A person can have many different Bitcoin addresses and, for increased privacy and as the only way to know what the bitcoins are received for/from, it is recommended that you use a unique address for each transaction. Most Bitcoin software and websites will help with this by generating a brand new address each time you perform a transaction. Some services provide a facility to request a new Bitcoin address for use with their service when desired.<br />
<br />
When using a web site that accepts bitcoins or holds Bitcoin balances on your behalf, that website will assign a Bitcoin address to your account, so you can transfer funds into your account at the site. Very much unlike e-mail, this address may change every time funds come in so care should be taken when sending additional funds to a previously-used address. When you send Bitcoins to your account at a web site, they will usually be credited to your account at that web site after the transaction is [[confirmation|confirmed]].<br />
<br />
==Addresses can be created offline==<br />
Creating addresses can be done without an Internet connection and does not require any contact or registration with the Bitcoin network. The network starts tracking an address when it is first seen in a valid payment transaction.<br />
<br />
It is possible to create large batches of addresses offline using freely available software tools. Generating batches of addresses is useful in several scenarios, such as e-commerce websites where a unique pre-generated address is dispensed to each customer who chooses a "pay with Bitcoin" option.<br />
<br />
An average desktop computer can generate thousands of new Bitcoin addresses a minute. Addresses are created simply by generating random numbers and then performing mathematical operations to derive matching pairs of "public" and "private" keys. Because addresses can be created easily and at minimal cost, it is not uncommon to create temporary addresses that can be discarded if unused.<br />
<br />
==Addresses are case sensitive and exact==<br />
Bitcoin addresses are case-sensitive. Bitcoin addresses should be copied and pasted using the computer's clipboard wherever possible. If you hand-key a Bitcoin address, and each character is not transcribed exactly - including capitalization - the incorrect address will most likely be rejected by the Bitcoin software. You will have to check your entry and try again.<br />
<br />
The probability that a mistyped address is accepted as being valid is 1 in 2<sup>32</sup>, that is, approximately 1 in 4.29 billion.<br />
<br />
==Address validation==<br />
If you would like to validate a Bitcoin address in an application, it is advisable to use a method from [https://bitcointalk.org/index.php?topic=1026.0 this thread] rather than to just check for string length, allowed characters, or that the address starts with a 1 or 3.<br />
<br />
==Addresses have a "private key"==<br />
For most properly-generated Bitcoin addresses, there is at least one secret number known as a [[private key]] which is required for access to the funds assigned to that address.<br />
<br />
When using a Bitcoin client, private keys are typically stored in the [[Wallet|wallet file]]. The private key has a special purpose - it is mathematically needed to create valid transactions that spend the funds originally sent to the address. If the private key to an address is lost (for example, in a hard drive crash, fire or other natural disaster), any associated Bitcoins are effectively lost forever.<br />
<br />
==Multi-signature addresses==<br />
Addresses can be created that require a combination of multiple private keys.<br />
Since these take advantage of newer features, they begin with the newer prefix of 3 instead of the older 1.<br />
These can be thought of as the equivalent of writing a check to two parties - "pay to the order of somebody AND somebody else" - where both parties must endorse the check in order to receive the funds.<br />
<br />
The actual requirement (number of private keys needed, their corresponding public keys, etc.) that must be satisfied to spend the funds is decided in advance by the person generating this type of address, and once an address is created, the requirement cannot be changed without generating a new address.<br />
<br />
==What's in an address==<br />
Most Bitcoin addresses are 34 characters.<br />
They consist of random digits and uppercase and lowercase letters, with the exception that the uppercase letter "O", uppercase letter "I", lowercase letter "l", and the number "0" are never used to prevent visual ambiguity.<br />
<br />
Some Bitcoin addresses can be shorter than 34 characters (as few as 27 in theory) and still be valid.<br />
A significant percentage of Bitcoin addresses are only 33 characters, and some addresses may be even shorter.<br />
Every Bitcoin address stands for a number - somewhat like an account number. These shorter addresses are valid simply because they stand for numbers that happen to start with zeroes, and when the zeroes are omitted, the encoded address gets shorter.<br />
<br />
Several of the characters inside a Bitcoin address are used as a checksum so that typographical errors can be automatically found and rejected. The checksum also allows Bitcoin software to confirm that a 33-character (or shorter) address is in fact valid and isn't simply an address with a missing character.<br />
<br />
==See Also==<br />
* [[Technical background of Bitcoin addresses]]<br />
* [[List of address prefixes]]<br />
* [[Exit Address]]<br />
<br />
== References ==<br />
<references/><br />
<br />
[[Category:Vocabulary]]<br />
<br />
[[es:Dirección]]<br />
[[de:Adresse]]</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Invoice_address&diff=46221Invoice address2014-04-08T03:02:56Z<p>Giszmo: Replaced the example of a Bitcoin address with an actual example of a Bitcoin address. Sorry, we wasted some time because of the example actually not being an address. If you revert, put the comment in the ref, not in the code. Thanx.</p>
<hr />
<div>A '''Bitcoin address''', or simply '''address''', is an identifier of 27-34 alphanumeric characters, beginning with the number 1 or 3, that represents a possible destination for a Bitcoin payment.<br />
Addresses can be generated at no cost by any user of Bitcoin.<br />
For example, using [[Bitcoin-Qt]], one can click "New Address" and be assigned an address.<br />
It is also possible to get a Bitcoin address using an account at an exchange or online wallet service.<br />
<br />
An example of a Bitcoin address is ''1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa''<ref>[http://blockexplorer.com/b/0 The first Bitcoin Address] ever with a positive balance</ref>.<br />
<br />
==A Bitcoin address is like an e-mail address==<br />
Like e-mail, you can send bitcoins to a person by sending bitcoins to one of their addresses. A person can have many different Bitcoin addresses and, for increased privacy and as the only way to know what the bitcoins are received for/from, it is recommended that you use a unique address for each transaction. Most Bitcoin software and websites will help with this by generating a brand new address each time you perform a transaction. Some services provide a facility to request a new Bitcoin address for use with their service when desired.<br />
<br />
When using a web site that accepts bitcoins or holds Bitcoin balances on your behalf, that website will assign a Bitcoin address to your account, so you can transfer funds into your account at the site. Very much unlike e-mail, this address may change every time funds come in so care should be taken when sending additional funds to a previously-used address. When you send Bitcoins to your account at a web site, they will usually be credited to your account at that web site after the transaction is [[confirmation|confirmed]].<br />
<br />
==Addresses can be created offline==<br />
Creating addresses can be done without an Internet connection and does not require any contact or registration with the Bitcoin network. The network starts tracking an address when it is first seen in a valid payment transaction.<br />
<br />
It is possible to create large batches of addresses offline using freely available software tools. Generating batches of addresses is useful in several scenarios, such as e-commerce websites where a unique pre-generated address is dispensed to each customer who chooses a "pay with Bitcoin" option.<br />
<br />
An average desktop computer can generate thousands of new Bitcoin addresses a minute. Addresses are created simply by generating random numbers and then performing mathematical operations to derive matching pairs of "public" and "private" keys. Because addresses can be created easily and at minimal cost, it is not uncommon to create temporary addresses that can be discarded if unused.<br />
<br />
==Addresses are case sensitive and exact==<br />
Bitcoin addresses are case-sensitive. Bitcoin addresses should be copied and pasted using the computer's clipboard wherever possible. If you hand-key a Bitcoin address, and each character is not transcribed exactly - including capitalization - the incorrect address will most likely be rejected by the Bitcoin software. You will have to check your entry and try again.<br />
<br />
The probability that a mistyped address is accepted as being valid is 1 in 2<sup>32</sup>, that is, approximately 1 in 4.29 billion.<br />
<br />
==Address validation==<br />
If you would like to validate a Bitcoin address in an application, it is advisable to use a method from [https://bitcointalk.org/index.php?topic=1026.0 this thread] rather than to just check for string length, allowed characters, or that the address starts with a 1 or 3.<br />
<br />
==Addresses have a "private key"==<br />
For most properly-generated Bitcoin addresses, there is at least one secret number known as a [[private key]] which is required for access to the funds assigned to that address.<br />
<br />
When using a Bitcoin client, private keys are typically stored in the [[Wallet|wallet file]]. The private key has a special purpose - it is mathematically needed to create valid transactions that spend the funds originally sent to the address. If the private key to an address is lost (for example, in a hard drive crash, fire or other natural disaster), any associated Bitcoins are effectively lost forever.<br />
<br />
==Multi-signature addresses==<br />
Addresses can be created that require a combination of multiple private keys.<br />
Since these take advantage of newer features, they begin with the newer prefix of 3 instead of the older 1.<br />
These can be thought of as the equivalent of writing a check to two parties - "pay to the order of somebody AND somebody else" - where both parties must endorse the check in order to receive the funds.<br />
<br />
The actual requirement (number of private keys needed, their corresponding public keys, etc.) that must be satisfied to spend the funds is decided in advance by the person generating this type of address, and once an address is created, the requirement cannot be changed without generating a new address.<br />
<br />
==What's in an address==<br />
Most Bitcoin addresses are 34 characters.<br />
They consist of random digits and uppercase and lowercase letters, with the exception that the uppercase letter "O", uppercase letter "I", lowercase letter "l", and the number "0" are never used to prevent visual ambiguity.<br />
<br />
Some Bitcoin addresses can be shorter than 34 characters (as few as 27 in theory) and still be valid.<br />
A significant percentage of Bitcoin addresses are only 33 characters, and some addresses may be even shorter.<br />
Every Bitcoin address stands for a number - somewhat like an account number. These shorter addresses are valid simply because they stand for numbers that happen to start with zeroes, and when the zeroes are omitted, the encoded address gets shorter.<br />
<br />
Several of the characters inside a Bitcoin address are used as a checksum so that typographical errors can be automatically found and rejected. The checksum also allows Bitcoin software to confirm that a 33-character (or shorter) address is in fact valid and isn't simply an address with a missing character.<br />
<br />
==See Also==<br />
* [[Technical background of Bitcoin addresses]]<br />
* [[List of address prefixes]]<br />
* [[Exit Address]]<br />
<br />
[[Category:Vocabulary]]<br />
<br />
[[es:Dirección]]<br />
[[de:Adresse]]</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Maximum_transaction_rate&diff=43740Maximum transaction rate2014-01-14T19:27:18Z<p>Giszmo: clarified what "Maximum transaction rate" the article is about</p>
<hr />
<div>The maximum transaction rate is the block size limit divided by the average transaction size. The block size limit is well known, 1MB, however the average transaction size isn't. Here we'll look at what influences that size.<br />
<br />
The minimum sized transaction type<ref name="mintxsize">Even smaller transactions can be made by using empty scriptPubKeys, however such transactions are not secure because anyone can spend them.</ref> is the [[Script#Standard_Generation_Transaction|OP_CHECKSIG transaction]]:<br />
<br />
scriptPubKey: <33 byte compressed pubKey> OP_CHECKSIG<br />
scriptSig: <72 byte signature><br />
<br />
Each transaction input requires at least 41 bytes for the previous transaction reference and other headers and each transaction output requires an additional 9 bytes of headers. Finally every transaction has a header at least 10 bytes long. Added up we get 166 bytes for the minimum-sized Bitcoin transaction. For 1MB (1,000,000 byte) blocks this implies a theoretical maximum rate of 10tx/s.<br />
<br />
However [[Change|change]] complicates the situation. It isn't always possible for a client to find a transaction input of the size required. Thus client software will included additional outputs to themselves for the change, and similarly they will include additional inputs to collect change outputs together when no one output is large enough.<br />
<br />
Users with large wallets, in particular [[eWallets]] such as Instawallet or large exchanges like Mt. Gox are most likely to be able to find transaction outputs of a suitable size for any given payment. It's conceivable that if transaction fees are high enough in the future users who trust each other may get together to use each others wallets to make payments as a way to avoid transaction fees, with the balances settled periodically by some other means.<br />
<br />
== Trust-free Combining ==<br />
<br />
Users can also combine their transactions to make them slightly smaller, and possibly improve privacy. A transaction is invalid until every transaction input is signed for, thus multiple users can create a joint transaction with no risk of their funds being stolen. This reduces average transaction size by 10 bytes, the size of the per-transaction header. Using this technique aggressively results in 156 byte average transactions, or 10.7tx/s.<br />
<br />
== Lower-bound transaction rate ==<br />
<br />
A reasonable, conservative, assumption is to assume that every transaction requires two outputs, including change, and two inputs, consuming change. Assuming that trust-free combining is not used gives us 322 byte transactions, or 5.2tx/s.<br />
<br />
Actual real-world rates will likely be somewhere between those numbers, although equally rates may be less as well if multi-signature transactions are become popular; the figure 7tx/s is commonly quoted as a 'ball-park' approximation in discussions of the [[Scalability|blocksize limit]].<br />
<br />
== The Bitcoin system vs. the Bitcoin blockchain ==<br />
<br />
Numbers discussed here apply to the bitcoin blockchain and are no hard limits to the bitcoin system in a broader sense. Off chain transactions, most notably transaction channels allow arbitrary transaction rates with instant, off the chain (added privacy), secure micro-transactions.<br />
<br />
== Footnotes ==<br />
<references/></div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Bitcoin_symbol&diff=40389Bitcoin symbol2013-08-23T15:58:17Z<p>Giszmo: /* Existing Unicode symbol */ B⃦ Displays poorly on my old ubuntu and on my current debian as well. added that fact to the cons.</p>
<hr />
<div>== Currency code ==<br />
The [https://secure.wikimedia.org/wikipedia/en/wiki/ISO_4217 currency code] for Bitcoin is '''BTC'''. However, at the moment it is an [https://secure.wikimedia.org/wikipedia/en/wiki/ISO_4217#Without_currency_code unofficial code] according to the ISO 4217 standard but the official code according to the Bitcoin community.<br />
<br />
A [https://bitcointalk.org/index.php?topic=7205.msg112577 request] has been made at the [http://www.six-group.com/ organization] maintaining the currency codes in the ISO 4217 standard to support BTC. This has been declined mainly on bases that organizations such as [https://secure.wikimedia.org/wikipedia/en/wiki/Reuters Reuters] and [https://secure.wikimedia.org/wikipedia/en/wiki/Bloomberg Bloomberg] are not reporting on the Bitcoin currency. When this changes, a request can be resubmitted.<br />
<br />
== Currency sign ==<br />
<br />
B⃦ has been the standard currency sign for BTC for a long time. Some existing Unicode symbols have been proposed but also serious work is being done on creating a custom Bitcoin sign with its own official [https://secure.wikimedia.org/wikipedia/en/wiki/Unicode Unicode] that is recognized by the [https://secure.wikimedia.org/wikipedia/en/wiki/Unicode_Consortium Unicode Consortium]. Note that a currency sign is more complex than creating a logo as will be explained below.<br />
<br />
[[File:Example-unicode-reference-currency-signs.png|256px|thumb|right|Examples of Unicode currency sign reference glyphs]]<br />
<br />
=== New Unicode symbol ===<br />
<br />
In some discussions [https://bitcointalk.org/index.php?topic=41.0 41], [https://bitcointalk.org/index.php?topic=369.0 369] and [https://bitcointalk.org/index.php?topic=7215.0 7215] on the Bitcoin forum several designs of an official Bitcoin sign have been proposed. This section on the Wiki is intended to streamline the process of arriving at an official Bitcoin currency sign with its own Unicode character code.<br />
<br />
==== Goal ====<br />
Having a unique Bitcoin currency sign will allow typographers to add their currency sign design in their fonts. This is similar as implementing support for the euro sign. Each font has its own version of the euro sign that fits with the style observed in the characters in the rest of the fonts of their typefaces. Note that the Unicode Consortium does not endorse Bitcoin in any way by assigning a Unicode character code, however, having a Unicode for the Bitcoin sign will also be good for PR and help having Bitcoin be taken more seriously.<br />
<br />
==== Requirements and criteria ====<br />
<br />
A reference Bitcoin sign could/should/must be:<br />
* recognizable as a [https://secure.wikimedia.org/wikipedia/en/wiki/Currency_sign currency sign] such as $ € ¥ £ ¢ (e.g. with one or two vertical or horizontal bars)<br />
* distinct from existing currency signs such as the Thai Baht, ฿<br />
* built from recognizable existing characters found on most [https://secure.wikimedia.org/wikipedia/en/wiki/Keyboard_layout#United_States QWERTY keyboards] such as bar |, minus -, hash # and/or capital B referring to currencies and '''B'''itcoin<br />
* easy to use in handwriting<br />
* easy to compose with one or more [https://help.ubuntu.com/community/GtkComposeTable#The%20Gtk%20Compose%20Table compose sequences] that are still free and refer to the elements recognizable in the sign (for example the euro sign can be composed from = and C even though the = and C are not part of how it is pronounced)<br />
* ''possible'' to implement in [https://secure.wikimedia.org/wikipedia/en/wiki/Serif serif and sans-serif] (Most of the [http://www.unicode.org/charts/PDF/U20A0.pdf Unicode reference implementations] are made with serifs but sans-serif also exist in sans-serif fonts. So a reference implementation in serif to what is found in the PDF is preferred.)<br />
* ''possible'' to implement in regular, italic, bold and bold italic (for sans-serif the italic will simply be a slanted version)<br />
* in [https://secure.wikimedia.org/wikipedia/en/wiki/SVG SVG] and use this [http://pastebin.com/raw.php?i=FVY8W1W3 template] (save as <tt>bitcoin-sign-20110719-template.svg</tt>) with updated metadata and public domain or similar free/open/libre license<br />
<br />
Note that a reference Bitcoin sign will only be used as a reference by the Unicode Consortium and it is up to typographers to implement their version matching the style of their typefaces and fonts.<br />
<br />
==== Submissions====<br />
<br />
It is possible to submit proposals for a '''reference implementation''' below until (community must determine date). They will be judged by (community must form committee for this). If you have problems submitting your design, ask someone with knowledge on editing Wikipedia for help.<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Preview !! Handwritten !! Associations !! Compose sequence(s) !! Designer !! Link to SVG file !! Notes<br />
|-<br />
| [[File:Bitcoin-sign-20110719.png|128px]]<br />
|| [[file:Img075.jpg|128px]]<br />
|| double barred dollar sign ($), capital b (B)<br />
|| B|, |B, B=, =B<br />
|| Pander<br />
|| [http://pastebin.com/raw.php?i=XYsc9DeS bitcoin-sign-20110719.svg]<br />
|| example submission based on [[File:F33980a445.png]]<br />
|-<br />
| [[File:Bitcoin-proposal-1.png|128px]]<br />
|| [[File:Hashbtc.jpg|128px]]<br />
|| hash (#), numeral three (3)<br />
|| B#, #B, 3#, #3<br />
|| Wareen<br />
|| [http://pastebin.com/raw.php?i=MRfcm0Cn Bitcoin-proposal-1.svg]<br />
|| proposal based on original design idea from [https://bitcointalk.org/index.php?topic=41.msg348274#msg348274 RylandAlmanza] and [https://bitcointalk.org/index.php?topic=25102.msg325489#msg325489 netrin]<br />
|}<br />
<br />
=== Existing Unicode symbol ===<br />
<br />
There is a discussion over [https://bitcointalk.org/index.php?topic=369.0 which Unicode symbol might be the best suited] for Bitcoin.<br />
<br />
To type Unicode characters, refer to:<br />
<br />
* [[Microsoft Windows Unicode Input]]<br />
* [[How to easily type the circled B symbol on a Mac]]<br />
<br />
It has led to the following options:<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Proposed character !! Description & Pros & Cons !! Unicode name !! Unicode decimal input !! Unicode hex input<br />
|-<br />
|<center><big>B⃦</big></center>||<br />
*Pros: Similar to current bitcoin.org logo<br />
* Cons: Displays poorly on some systems<br />
|| LATIN CAPITAL LETTER B + COMBINING DOUBLE VERTICAL STROKE OVERLAY || || U+0042 U+20E6<br />
|-<br />
|<center><big>฿</big></center> || <br />
* Pros: Displayed correctly on all known OSes <br />
* Cons: It is already used as the Thai Baht (THB) symbol<br />
|| THAI CURRENCY SYMBOL BAHT || || Alt +0E3F<br />
|-<br />
|<center><big>Ƀ</big></center>||<br />
*Pros: Displayed correctly on all known OSes; standard Latin Extended-B character; [http://www.ecogex.com/bitcoin/ See the project Ƀ Another Bitcoin identity]<br />
|| LATIN CAPITAL LETTER B WITH STROKE || ||Alt +0243<br />
|-<br />
|<center><big>ᗸ</big></center>|| Resembles the struck B while being different from Baht symbol ||CANADIAN SYLLABICS CARRIER KHEE || || Alt +15F8<br />
|-<br />
|<center><big>B⃫</big></center>||<br />
|| LATIN CAPITAL LETTER B + COMBINING LONG DOUBLE SOLIDUS OVERLAY || || U+0042 U+20EB<br />
|-<br />
|<center><big>Ⓑ</big></center>||<br />
*Pros: Similar to current bitcoin.org logo<br />
|| CIRCLED LATIN CAPITAL LETTER B || || Alt +24B7<br />
|-<br />
|<center><big>ⓑ</big></center>||<br />
*Pros: Small b represent the unit bit in computer where capital B is Byte<br />
* Cons: Small fonts are harder to read<br />
|| CIRCLED LATIN SMALL LETTER B || ||Alt +24D1<br />
|-<br />
|<center><big>ᴃ</big></center>|| || LATIN LETTER SMALL CAPITAL BARRED B || ||Alt +1D03<br />
|-<br />
|<center><big>␢</big></center>|| || (Unicode Block: Control Pictures) BLANK SYMBOL (graphic for space) || || Alt +2422<br />
|-<br />
|<center><big>β</big></center>||<br />
*Pros: Fluid look and easy to write; Lowercase<br/><br />
*Cons: Languages that use this character don't consider it a B. in Greek it's a V, and the German character it resembles is a hard S.<br />
|| GREEK SMALL LETTER BETA || ||Alt +03B2<br />
|-<br />
|<center><big>∆</big></center>|| delta for "digital" || Greek capital Delta. (In Greek it's pronounced as the "th" in "then" and not like "d" in "digital". || || U+0394<br />
|-<br />
|<center><big>ɸ</big></center>|| contains 0 and I || Greek small Phi || || U+0278 <br />
|-<br />
|<center><big>币</big></center>|| pronounced "bi", combines "b", turned "c" and "T", many Chinese users, also 网民币 - Wangminbi, "The Netizen's Currency" (pun on Renminbi) || Chinese for "Currency" || || U+5E01<br />
|-<br />
|<center><big>¤</big></center>|| || CURRENCY SIGN ||Alt 0164 ||Alt +00A4<br />
|-<br />
|<center><big>Ƅ</big></center>|| || LATIN CAPITAL LETTER TONE SIX || ||Alt +0184<br />
|-<br />
|<center><big>∄</big></center>|| || (Unicode Block: Mathematical Operators) THERE DOES NOT EXIST || ||Alt +2204<br />
|-<br />
|<center><big>≡</big></center>|| three bars like three bits <br />
* Cons: this resembles the letter ksi (Ξ) in Greek and it sounds like "x" in "axiom".<br />
|| (Unicode Block: Mathematical Operators) IDENTICAL TO || || U+2261 <br />
|-<br />
|<center><big>ઘ</big></center>|| || GUJARATI LETTER GHA (Indo-Aryan language) || ||Alt +0A98<br />
|-<br />
|<center><big>ϭ</big></center>|| || (Unicode Block: Greek and Coptic) COPTIC SMALL LETTER SHIMA || ||Alt +03ED<br />
|-<br />
|<center><big>ⓢ</big></center>|| Purposed as a smaller unit of bitcoin. E.g. A hundredth of a bitcoin || CIRCLED LATIN SMALL LETTER S || || Alt +24E2<br />
|-<br />
|<center><big>◪</big></center>|| || (Unicode Block: Geometric Shapes) SQUARE WITH LOWER RIGHT DIAGONAL HALF BLACK || || Alt +25EA<br />
|-<br />
|<center><big>㋡</big></center>|| ||CIRCLED KATAKANA TU' (Japanese)|| || Alt +32E1<br />
|-<br />
|<center>[[Image:Bat.png|24px|alt=The b'at]]<br><br />
the b'at</center><br />
||<br />
* Pros: Is round like a coin. Contains the B for Bitcoin. Borrows a style widely associated with the Internet. Not used for other meanings.<br />
* Cons: Does not exist in the Unicode standard<br />
* Cons: Very similar to the existing trademarked logo of [http://www.broad.com Broad]<br />
|| n/a || || <br />
|-<br />
|<center>[[Image:Bitcoin Symbol Suggestion circled struck-through B.png|24px]]</center>||<br />
* Cons: Does not exist in the Unicode standard<br />
|| n/a || || <br />
|-<br />
|<center>[[Image:Bitcoin Symbol Suggestion rotated power.png|24px]]</center>||<br />
* Cons: Does not exist in the Unicode standard<br />
|| n/a || || <br />
|-<br />
|<center>A 'C' with '1' and '0' inside [[http://img829.imageshack.us/img829/8840/bitcoinlogodraft.png]]</center>||<br />
* Cons: Does not exist in the Unicode standard <br />
|| n/a || || <br />
|-<br />
|<center>A 'C' with a 'circle' and 'dot' inside [[http://img836.imageshack.us/img836/6006/bitcoinlogodraftii.png]]</center>||<br />
* Cons: Does not exist in the Unicode standard<br />
|| n/a || || <br />
|-<br />
|<center>B-T-C monogram [[http://hosting11.imagecross.com/image-hosting-61/2381unicode1s.png]][[http://hosting11.imagecross.com/image-hosting-61/162bitcoin_uni_s.png]]</center>||<br />
* Cons: Does not exist in the Unicode standard<br />
|| n/a || || <br />
|}<br />
<br />
==See Also==<br />
<br />
* [[Promotional graphics]]<br />
<br />
[[Category:Introduction]]</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Protocol_documentation&diff=38943Protocol documentation2013-06-27T17:42:15Z<p>Giszmo: /* Merkle Trees */ fix. introducing a new "d4" changes the final result (merkle root) from d6 to d7</p>
<hr />
<div>Sources:<br />
* [[Original Bitcoin client]] source<br />
<br />
Type names used in this documentation are from the C99 standard.<br />
<br />
For protocol used in mining, see [[Getwork]].<br />
<br />
==Common standards==<br />
<br />
=== Hashes ===<br />
<br />
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).<br />
<br />
Example of double-SHA-256 encoding of string "hello":<br />
<br />
hello<br />
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)<br />
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)<br />
<br />
For bitcoin addresses (RIPEMD-160) this would give:<br />
<br />
hello<br />
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round is sha-256)<br />
b6a9c8c230722b7c748331a8b450f05566dc7d0f (with ripemd-160)<br />
<br />
=== Merkle Trees ===<br />
<br />
Merkle trees are binary trees of hashes. Merkle trees in bitcoin use a '''double''' SHA-256, the SHA-256 hash of the SHA-256 hash of something.<br />
<br />
If, when forming a row in the tree (other than the root of the tree), it would have an odd number of elements, the final double-hash is duplicated to ensure that the row has an even number of hashes.<br />
<br />
First form the bottom row of the tree with the ordered double-SHA-256 hashes of the byte streams of the transactions in the block.<br />
<br />
Then the row above it consists of half that number of hashes. Each entry is the double-SHA-256 of the 64-byte concatenation of the corresponding two hashes below it in the tree.<br />
<br />
This procedure repeats recursively until we reach a row consisting of just a single double-hash. This is the '''merkle root''' of the tree.<br />
<br />
For example, imagine a block with three transactions ''a'', ''b'' and ''c''. The merkle tree is: <br />
<br />
d1 = dhash(a)<br />
d2 = dhash(b)<br />
d3 = dhash(c)<br />
d4 = dhash(c) # a, b, c are 3. that's an odd number, so we take the c twice<br />
<br />
d5 = dhash(d1 concat d2)<br />
d6 = dhash(d3 concat d4)<br />
<br />
d7 = dhash(d5 concat d6)<br />
<br />
where<br />
<br />
dhash(a) = sha256(sha256(a))<br />
<br />
''d7'' is the merkle root of the 3 transactions in this block.<br />
<br />
Note: Hashes in Merkle Tree displayed in the [[Block Explorer]] are of little-endian notation. For some implementations and [http://www.fileformat.info/tool/hash.htm calculations], the bits need to be reversed before they are hashed, and again after the hashing operation.<br />
<br />
=== Signatures ===<br />
<br />
Bitcoin uses [http://en.wikipedia.org/wiki/Elliptic_curve_cryptography Elliptic Curve] [http://en.wikipedia.org/wiki/Digital_Signature_Algorithm Digital Signature Algorithm] ([http://en.wikipedia.org/wiki/Elliptic_Curve_DSA ECDSA]) to sign transactions. <br />
<br />
For ECDSA the secp256k1 curve from http://www.secg.org/collateral/sec2_final.pdf is used.<br />
<br />
Public keys (in scripts) are given as 04 <x> <y> where ''x'' and ''y'' are 32 byte big-endian integers representing the coordinates of a point on the curve or in compressed form given as <sign> <x> where <sign> is 0x02 if ''y'' is even and 0x03 if ''y'' is odd.<br />
<br />
Signatures use [http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER encoding] to pack the ''r'' and ''s'' components into a single byte stream (this is also what OpenSSL produces by default).<br />
<br />
=== Transaction Verification ===<br />
Transactions are cryptographically signed records that reassign ownership of Bitcoins to new addresses. Transactions have ''inputs'' - records which reference the funds from other previous transactions - and ''outputs'' - records which determine the new owner of the transferred Bitcoins, and which will be referenced as inputs in future transactions as those funds are respent.<br />
<br />
Each ''input'' must have a cryptographic digital signature that unlocks the funds from the prior transaction. Only the person possessing the appropriate [[private key]] is able to create a satisfactory signature; this in effect ensures that funds can only be spent by their owners.<br />
<br />
Each ''output'' determines which Bitcoin address (or other criteria, see [[Scripting]]) is the recipient of the funds.<br />
<br />
In a transaction, the sum of all inputs must be equal to or greater than the sum of all outputs. If the inputs exceed the outputs, the difference is considered a [[transaction fee]], and is redeemable by whoever first includes the transaction into the block chain.<br />
<br />
A special kind of transaction, called a [[coinbase transaction]], has no inputs. It is created by [[miners]], and there is one coinbase transaction per block. Because each block comes with a reward of newly created Bitcoins (e.g. 50 BTC for the first 210,000 blocks), the first transaction of a block is, with few exceptions, the transaction that grants those coins to their recipient (the miner). In addition to the newly created Bitcoins, the coinbase transaction is also used for assigning the recipient of any transaction fees that were paid within the other transactions being included in the same block. The coinbase transaction can assign the entire reward to a single Bitcoin address, or split it in portions among multiple addresses, just like any other transaction. Coinbase transactions always contain outputs totaling the sum of the block reward plus all transaction fees collected from the other transactions in the same block.<br />
<br />
The [[coinbase transaction]] in block zero cannot be spent. This is due to a quirk of the reference client implementation that would open the potential for a block chain fork if some nodes accepted the spend and others did not<ref>[http://bitcointalk.org/index.php?topic=119645.msg1288552#msg1288552 Block 0 Network Fork]</ref>.<br />
<br />
Most Bitcoin outputs encumber the newly transferred coins with a single ECDSA private key. The actual record saved with inputs and outputs isn't necessarily a key, but a ''script''. Bitcoin uses an interpreted scripting system to determine whether an output's criteria have been satisfied, with which more complex operations are possible, such as outputs that require two ECDSA signatures, or two-of-three-signature schemes. An output that references a single Bitcoin address is a ''typical'' output; an output actually contains this information in the form of a script that requires a single ECDSA signature (see [[OP_CHECKSIG]]). The output script specifies what must be provided to unlock the funds later, and when the time comes in the future to spend the transaction in another input, that input must provide all of the thing(s) that satisfy the requirements defined by the original output script.<br />
<br />
=== Addresses ===<br />
<br />
A bitcoin address is in fact the hash of a ECDSA public key, computed this way:<br />
<br />
Version = 1 byte of 0 (zero); on the test network, this is 1 byte of 111<br />
Key hash = Version concatenated with RIPEMD-160(SHA-256(public key))<br />
Checksum = 1st 4 bytes of SHA-256(SHA-256(Key hash))<br />
Bitcoin Address = Base58Encode(Key hash concatenated with Checksum)<br />
<br />
The Base58 encoding used is home made, and has some differences. Especially, leading zeroes are kept as single zeroes when conversion happens.<br />
<br />
== Common structures ==<br />
<br />
Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.<br />
<br />
=== Message structure ===<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || magic || uint32_t || Magic value indicating message origin network, and used to seek to next message when stream state is unknown<br />
|-<br />
| 12 || command || char[12] || ASCII string identifying the packet content, NULL padded (non-NULL padding results in packet rejected)<br />
|-<br />
| 4 || length || uint32_t || Length of payload in number of bytes<br />
|-<br />
| 4 || checksum || uint32_t || First 4 bytes of sha256(sha256(payload))<br />
|-<br />
| ? || payload || uchar[] || The actual data<br />
|}<br />
<br />
<br />
Known magic values:<br />
<br />
{|class="wikitable"<br />
! Network !! Magic value !! Sent over wire as<br />
|-<br />
| main || 0xD9B4BEF9 || F9 BE B4 D9<br />
|-<br />
| testnet || 0xDAB5BFFA || FA BF B5 DA<br />
|-<br />
| testnet3 || 0x0709110B || 0B 11 09 07<br />
|-<br />
| namecoin || 0xFEB4BEF9 || F9 BE B4 FE<br />
|}<br />
<br />
=== Variable length integer ===<br />
<br />
Integer can be encoded depending on the represented value to save space.<br />
Variable length integers always precede an array/vector of a type of data that may vary in length.<br />
Longer numbers are encoded in little endian.<br />
<br />
{|class="wikitable"<br />
! Value !! Storage length !! Format<br />
|-<br />
| < 0xfd || 1 || uint8_t<br />
|-<br />
| <= 0xffff || 3 || 0xfd followed by the length as uint16_t<br />
|-<br />
| <= 0xffffffff || 5 || 0xfe followed by the length as uint32_t<br />
|-<br />
| - || 9 || 0xff followed by the length as uint64_t<br />
|}<br />
<br />
Footnote - if you're reading the Satoshi client code it refers to this as a "CompactSize" - VarInt's are something entirely different to the Satoshi code.<br />
<br />
=== Variable length string ===<br />
<br />
Variable length string can be stored using a variable length integer followed by the string itself.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the string<br />
|-<br />
| ? || string || char[] || The string itself (can be empty)<br />
|}<br />
<br />
=== Network address ===<br />
<br />
When a network address is needed somewhere, this structure is used. This protocol and structure supports IPv6, '''but note that the original client currently only supports IPv4 networking'''. Network addresses are not prefixed with a timestamp in the version message.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || time || uint32 || the Time (version >= 31402)<br />
|-<br />
| 8 || services || uint64_t || same service(s) listed in [[#version|version]]<br />
|-<br />
| 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]<br />
(12 bytes ''00 00 00 00 00 00 00 00 00 00 FF FF'', followed by the 4 bytes of the IPv4 address).<br />
|-<br />
| 2 || port || uint16_t || port number, network byte order<br />
|}<br />
<br />
Hexdump example of Network address structure<br />
<br />
<pre><br />
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .<br />
<br />
Network address:<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK: see services listed under version command)<br />
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<br />
20 8D - Port 8333<br />
</pre><br />
<br />
=== Inventory Vectors ===<br />
<br />
Inventory vectors are used for notifying other nodes about objects they have or data which is being requested.<br />
<br />
Inventory vectors consist of the following data format:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || type || uint32_t || Identifies the object type linked to this inventory<br />
|-<br />
| 32 || hash || char[32] || Hash of the object<br />
|}<br />
<br />
<br />
The object type is currently defined as one of the following possibilities:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 0 || ERROR || Any data of with this number may be ignored<br />
|-<br />
| 1 || MSG_TX || Hash is related to a transaction<br />
|-<br />
| 2 || MSG_BLOCK || Hash is related to a data block<br />
|}<br />
<br />
Other Data Type values are considered reserved for future implementations.<br />
<br />
=== Block Headers ===<br />
<br />
Block headers are sent in a headers packet in response to a getheaders message.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Block version information, based upon the software version creating this block<br />
|-<br />
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references<br />
|-<br />
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block<br />
|-<br />
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)<br />
|-<br />
| 4 || bits || uint32_t || The calculated difficulty target being used for this block<br />
|-<br />
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes<br />
|-<br />
| 1 || txn_count || uint8_t || Number of transaction entries, this value is always 0<br />
|}<br />
<br />
== Message types ==<br />
<br />
=== version ===<br />
<br />
When a node creates an outgoing connection, it will immediately [[Version Handshake|advertise]] its version. The remote node will respond with its version. No futher communication is possible until both peers have exchanged their version.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || int32_t || Identifies protocol version being used by the node<br />
|-<br />
| 8 || services || uint64_t || bitfield of features to be enabled for this connection<br />
|-<br />
| 8 || timestamp || int64_t || standard UNIX timestamp in seconds<br />
|-<br />
| 26 || addr_recv || net_addr || The network address of the node receiving this message<br />
|-<br />
|colspan="4"| version >= 106<br />
|-<br />
| 26 || addr_from || net_addr || The network address of the node emitting this message<br />
|-<br />
| 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.<br />
|-<br />
| ? || user_agent || [[#Variable length string|var_str]] || [[BIP_0014|User Agent]] (0x00 if string is 0 bytes long)<br />
|-<br />
| 4 || start_height || int32_t || The last block received by the emitting node<br />
|-<br />
| 1 || relay || bool || Whether the remote peer should announce relayed transactions or not, see [[BIP 0037]], since version >= 70001<br />
|}<br />
<br />
A "verack" packet shall be sent if the version packet was accepted.<br />
<br />
The following services are currently assigned:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers.<br />
|}<br />
<br />
Hexdump example of version message (OBSOLETE EXAMPLE. This example lacks a checksum and user-agent):<br />
<pre><br />
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....<br />
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........<br />
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............<br />
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................<br />
0040 20 8D 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,<br />
0060 3A B4 57 13 00 55 81 01 00 :.W..U...<br />
<br />
Message header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command<br />
55 00 00 00 - Payload is 85 bytes long<br />
- No checksum in version message until 20 February 2012. See https://bitcointalk.org/index.php?topic=55852.0<br />
Version message:<br />
9C 7C 00 00 - 31900 (version 0.3.19)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)<br />
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 20 8D - Recipient address info - see Network Address<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - Sender address info - see Network Address<br />
DD 9D 20 2C 3A B4 57 13 - Node random unique ID<br />
00 - "" sub-version string (string is 0 bytes long)<br />
55 81 01 00 - Last block sending node has is block #98645<br />
</pre><br />
<br />
And here's a modern (60002) protocol version client advertising itself to a local peer...<br />
<br />
Newer protocol includes the checksum now, this is from a mainline (satoshi) client during <br />
an outgoing connection to another local client, notice that it does not fill out the <br />
address information at all when the source or destination is "unroutable".<br />
<br />
<pre><br />
<br />
0000 f9 be b4 d9 76 65 72 73 69 6f 6e 00 00 00 00 00 ....version.....<br />
0010 64 00 00 00 35 8d 49 32 62 ea 00 00 01 00 00 00 d...5.I2b.......<br />
0020 00 00 00 00 11 b2 d0 50 00 00 00 00 01 00 00 00 .......P........<br />
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ................<br />
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0050 00 00 00 00 00 00 00 00 ff ff 00 00 00 00 00 00 ................<br />
0060 3b 2e b3 5d 8c e6 17 65 0f 2f 53 61 74 6f 73 68 ;..]...e./Satosh<br />
0070 69 3a 30 2e 37 2e 32 2f c0 3e 03 00 i:0.7.2/.>..<br />
<br />
Message Header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command<br />
64 00 00 00 - Payload is 100 bytes long<br />
35 8D 49 32 - payload checksum<br />
<br />
Version message:<br />
62 EA 00 00 - 60002 (protocol version 60002)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)<br />
11 B2 D0 50 00 00 00 00 - Tue Dec 18 10:12:33 PST 2012<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Recipient address info - see Network Address<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Sender address info - see Network Address<br />
3B 2E B3 5D 8C E6 17 65 - Node ID<br />
0F 2F 53 61 74 6F 73 68 69 3A 30 2E 37 2E 32 2F - "/Satoshi:0.7.2/" sub-version string (string is 15 bytes long)<br />
C0 3E 03 00 - Last block sending node has is block #212672<br />
</pre><br />
<br />
=== verack ===<br />
<br />
The ''verack'' message is sent in reply to ''version''. This message consists of only a [[#Message structure|message header]] with the command string "verack".<br />
<br />
Hexdump of the verack message:<br />
<br />
<pre><br />
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......<br />
0010 00 00 00 00 5D F6 E0 E2 ........<br />
<br />
Message header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 61 63 6B 00 00 00 00 00 00 - "verack" command<br />
00 00 00 00 - Payload is 0 bytes long<br />
5D F6 E0 E2 - Checksum<br />
</pre><br />
<br />
=== addr ===<br />
<br />
Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours<br />
<br />
Payload:<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 1+ || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of address entries (max: 1000)<br />
|-<br />
| 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).<br />
|}<br />
<br />
'''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.<br />
<br />
Hexdump example of ''addr'' message:<br />
<pre><br />
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........<br />
0010 1F 00 00 00 ED 52 39 9B 01 E2 15 10 4D 01 00 00 .....R9.....M...<br />
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................<br />
0030 FF 0A 00 00 01 20 8D ..... .<br />
<br />
Message Header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"<br />
1F 00 00 00 - payload is 31 bytes long<br />
ED 52 39 9B - checksum of payload<br />
<br />
Payload:<br />
01 - 1 address in this message<br />
<br />
Address:<br />
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - see version message)<br />
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)<br />
20 8D - port 8333<br />
</pre><br />
<br />
=== inv ===<br />
<br />
Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to ''getblocks''.<br />
<br />
Payload (maximum payload length: 1.8 Megabytes or 50000 entries):<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries<br />
|-<br />
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br />
|}<br />
<br />
=== getdata ===<br />
<br />
getdata is used in response to inv, to retrieve the content of a specific object, and is usually sent after receiving an ''inv'' packet, after filtering known elements. It can be used to retrieve transactions, but only if they are in the memory pool or relay set - arbitrary access to transactions in the chain is not allowed to avoid having clients start to depend on nodes having full transaction indexes (which modern nodes do not).<br />
<br />
Payload (maximum payload length: 1.8 Megabytes or 50000 entries):<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries<br />
|-<br />
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br />
|}<br />
<br />
=== notfound ===<br />
<br />
notfound is a response to a getdata, sent if any requested data items could not be relayed, for example, because the requested transaction was not in the memory pool or relay set.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries<br />
|-<br />
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br />
|}<br />
<br />
=== getblocks ===<br />
<br />
Return an ''inv'' packet containing the list of blocks starting right after the last known hash in the block locator object, up to hash_stop or 500 blocks, whichever comes first. <br />
<br />
The locator hashes are processed by a node in the order as they appear in the message. If a block hash if found in the node's main chain, the list of it's children is returned back via the ''inv'' message and the remaining locators are ignored, no matter if the requested limit was reached, or not.<br />
<br />
To receive the next blocks hashes, one needs to issue getblocks again with a new block locator object. Keep in mind that some clients (specifically the Satoshi client) will gladly provide blocks which are invalid if the block locator object contains a hash on the invalid branch.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || the protocol version<br />
|-<br />
| 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries<br />
|-<br />
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)<br />
|-<br />
| 32 || hash_stop || char[32] || hash of the last desired block; set to zero to get as many blocks as possible (500)<br />
|}<br />
<br />
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:<br />
<br />
<pre><br />
// From libbitcoin which is under AGPL<br />
std::vector<size_t> block_locator_indices(int top_depth)<br />
{<br />
// Start at max_depth<br />
std::vector<size_t> indices;<br />
// Push last 10 indices first<br />
size_t step = 1, start = 0;<br />
for (int i = top_depth; i > 0; i -= step, ++start)<br />
{<br />
if (start >= 10)<br />
step *= 2;<br />
indices.push_back(i);<br />
}<br />
indices.push_back(0);<br />
return indices;<br />
}<br />
</pre><br />
<br />
Note that it is allowed to send in fewer known hashes down to a minimum of just one hash. However, the purpose of the block locator object is to detect a wrong branch in the caller's main chain. If the peer detects that you are off the main chain, it will send in block hashes which are earlier than your last known block. So if you just send in your last known hash and it is off the main chain, the peer starts over at block #1.<br />
<br />
=== getheaders ===<br />
<br />
Return a ''headers'' packet containing the headers of blocks starting right after the last known hash in the block locator object, up to hash_stop or 2000 blocks, whichever comes first. To receive the next block headers, one needs to issue getheaders again with a new block locator object. The ''getheaders'' command is used by thin clients to quickly download the blockchain where the contents of the transactions would be irrelevant (because they are not ours). Keep in mind that some clients (specifically the Satoshi client) will gladly provide headers of blocks which are invalid if the block locator object contains a hash on the invalid branch.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || the protocol version<br />
|-<br />
| 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries<br />
|-<br />
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)<br />
|-<br />
| 32 || hash_stop || char[32] || hash of the last desired block header; set to zero to get as many blocks as possible (2000)<br />
|}<br />
<br />
For the block locator object in this packet, the same rules apply as for the [[Protocol_specification#getblocks|getblocks]] packet.<br />
<br />
=== tx ===<br />
<br />
''tx'' describes a bitcoin transaction, in reply to ''getdata''<br />
<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Transaction data format version<br />
|-<br />
| 1+ || tx_in count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction inputs<br />
|-<br />
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins<br />
|-<br />
| 1+ || tx_out count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction outputs<br />
|-<br />
| 9+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins<br />
|-<br />
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked:<br />
{|class="wikitable"<br />
! Value !! Description<br />
|-<br />
| 0 || Always locked<br />
|-<br />
| < 500000000 || Block number at which this transaction is locked<br />
|-<br />
| >= 500000000 || UNIX timestamp at which this transaction is locked<br />
|}<br />
If all TxIn inputs have final (0xffffffff) sequence numbers then lock_time is irrelevant. Otherwise, the transaction may not be added to a block until after lock_time.<br />
<br />
|}<br />
<br />
TxIn consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure<br />
|-<br />
| 1+ || script length || [[Protocol_specification#Variable_length_integer|var_int]] || The length of the signature script<br />
|-<br />
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization<br />
|-<br />
| 4 || [http://bitcoin.stackexchange.com/q/2025/323 sequence] || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.<br />
|}<br />
<br />
The OutPoint structure consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 32 || hash || char[32] || The hash of the referenced transaction.<br />
|-<br />
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.<br />
|}<br />
<br />
The Script structure consists of a series of pieces of information and operations related to the value of the transaction.<br />
<br />
(Structure to be expanded in the future… see script.h and script.cpp and [[Script]] for more information)<br />
<br />
The TxOut structure consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 8 || value || int64_t || Transaction Value<br />
|-<br />
| 1+ || pk_script length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the pk_script<br />
|-<br />
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.<br />
|}<br />
<br />
Example ''tx'' message:<br />
<pre><br />
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........<br />
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..<br />
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.<br />
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...<br />
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...<br />
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:<br />
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....<br />
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...<br />
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....<br />
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...<br />
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...<br />
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...<br />
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....<br />
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....<br />
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........<br />
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..<br />
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...<br />
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......<br />
<br />
<br />
Message header:<br />
F9 BE B4 D9 - main network magic bytes<br />
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command<br />
02 01 00 00 - payload is 258 bytes long<br />
E2 93 CD BE - checksum of payload<br />
<br />
Transaction:<br />
01 00 00 00 - version<br />
<br />
Inputs:<br />
01 - number of transaction inputs<br />
<br />
Input 1:<br />
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)<br />
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29<br />
00 00 00 00<br />
<br />
8B - script is 139 bytes long<br />
<br />
48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)<br />
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23<br />
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41<br />
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD<br />
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E<br />
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD<br />
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02<br />
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04<br />
2F 46 61 4A 4C 70 C0 F1 4B EF F5<br />
<br />
FF FF FF FF - sequence<br />
<br />
Outputs:<br />
02 - 2 Output Transactions<br />
<br />
Output 1:<br />
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)<br />
19 - pk_script is 25 bytes long<br />
<br />
76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script<br />
A9 D9 EA 1A FB 22 5E 88 AC<br />
<br />
Output 2:<br />
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)<br />
19 - pk_script is 25 bytes long<br />
<br />
76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script<br />
FD A0 B7 8B 4E CC 52 88 AC<br />
<br />
Locktime:<br />
00 00 00 00 - lock time<br />
</pre><br />
<br />
=== block ===<br />
<br />
The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Block version information, based upon the software version creating this block<br />
|-<br />
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references<br />
|-<br />
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block<br />
|-<br />
| 4 || timestamp || uint32_t || A unix timestamp recording when this block was created (Currently limited to dates before the year 2106!)<br />
|-<br />
| 4 || bits || uint32_t || The calculated [[Difficulty|difficulty target]] being used for this block<br />
|-<br />
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes<br />
|-<br />
| ? || txn_count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of transaction entries<br />
|-<br />
| ? || txns || tx[] || Block transactions, in format of "tx" command<br />
|}<br />
<br />
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.<br />
See [[Block hashing algorithm]] for details and an example.<br />
<br />
=== headers ===<br />
<br />
The ''headers'' packet returns block headers in response to a ''getheaders'' packet. <br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of block headers<br />
|-<br />
| 81x? || headers || [[Protocol_specification#Block_Headers|block_header]][] || [[Protocol_specification#Block_Headers|Block headers]]<br />
|}<br />
<br />
Note that the block headers in this packet include a transaction count (a var_int, so there can be more than 81 bytes per header) as opposed to the block headers which are sent to miners.<br />
<br />
=== getaddr ===<br />
<br />
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.<br />
<br />
No additional data is transmitted with this message.<br />
<br />
=== checkorder ===<br />
<br />
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.<br />
<br />
It contains a CWalletTx object<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
|colspan="4"| Fields from CMerkleTx<br />
|-<br />
| ? || hashBlock<br />
|-<br />
| ? || vMerkleBranch<br />
|-<br />
| ? || nIndex<br />
|-<br />
|colspan="4"| Fields from CWalletTx<br />
|-<br />
| ? || vtxPrev<br />
|-<br />
| ? || mapValue<br />
|-<br />
| ? || vOrderForm<br />
|-<br />
| ? || fTimeReceivedIsTxTime<br />
|-<br />
| ? || nTimeReceived<br />
|-<br />
| ? || fFromMe<br />
|-<br />
| ? || fSpent<br />
|}<br />
<br />
=== submitorder ===<br />
<br />
Confirms an order has been submitted. <br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 32 || hash || char[32] || Hash of the transaction<br />
|-<br />
| ? || wallet_entry || CWalletTx || Same payload as checkorder<br />
|}<br />
<br />
=== reply ===<br />
<br />
Generic reply for [[IP Transactions]]<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || reply || uint32_t || reply code<br />
|}<br />
<br />
Possible values:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')<br />
|-<br />
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed<br />
|-<br />
| 2 || DENIED || IP Transactions are not accepted by this node<br />
|}<br />
<br />
=== ping ===<br />
<br />
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. In modern protocol versions, a ''pong'' response is generated using a nonce included in the ping.<br />
<br />
=== filterload, filteradd, filterclear, merkleblock ===<br />
<br />
These messages are related to Bloom filtering of connections and are defined in [[BIP 0037]].<br />
<br />
=== alert ===<br />
<br />
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.<br />
<br />
Alert format:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || payload || var_str || Serialized alert payload<br />
|-<br />
| ? || signature || var_str || An ECDSA signature of the message<br />
|}<br />
<br />
The developers of Satoshi's client use this public key for signing alerts:<br />
04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284<br />
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s<br />
<br />
The payload is serialized into a var_str to ensure that versions using incompatible alert formats can still relay alerts among one another. The current alert payload format is:<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || Version || int32_t || Alert format version<br />
|-<br />
| 8 || RelayUntil || int64_t || The timestamp beyond which nodes should stop relaying this alert<br />
|-<br />
| 8 || Expiration || int64_t || The timestamp beyond which this alert is no longer in effect and should be ignored<br />
|-<br />
| 4 || ID || int32_t || A unique ID number for this alert<br />
|-<br />
| 4 || Cancel || int32_t || All alerts with an ID number less than or equal to this number should be canceled: deleted and not accepted in the future<br />
|-<br />
| ? || setCancel || set<int> || All alert IDs contained in this set should be canceled as above<br />
|-<br />
| 4 || MinVer || int32_t || This alert only applies to versions greater than or equal to this version. Other versions should still relay it.<br />
|-<br />
| 4 || MaxVer || int32_t || This alert only applies to versions less than or equal to this version. Other versions should still relay it.<br />
|-<br />
| ? || setSubVer || set<string> || If this set contains any elements, then only nodes that have their subVer contained in this set are affected by the alert. Other versions should still relay it.<br />
|-<br />
| 4 || Priority || int32_t || Relative priority compared to other alerts<br />
|-<br />
| ? || Comment || string || A comment on the alert that is not displayed<br />
|-<br />
| ? || StatusBar || string || The alert message that is displayed to the user<br />
|-<br />
| ? || Reserved || string || Reserved<br />
|}<br />
<br />
Sample alert (no message header):<br />
73010000003766404f00000000b305434f00000000f2030000f1030000001027000048ee0000<br />
0064000000004653656520626974636f696e2e6f72672f666562323020696620796f75206861<br />
76652074726f75626c6520636f6e6e656374696e672061667465722032302046656272756172<br />
79004730450221008389df45f0703f39ec8c1cc42c13810ffcae14995bb648340219e353b63b<br />
53eb022009ec65e1c1aaeec1fd334c6b684bde2b3f573060d5b70c3a46723326e4e8a4f1<br />
<br />
Version: 1<br />
RelayUntil: 1329620535<br />
Expiration: 1329792435<br />
ID: 1010<br />
Cancel: 1009<br />
setCancel: <empty><br />
MinVer: 10000<br />
MaxVer: 61000<br />
setSubVer: <empty><br />
Priority: 100<br />
Comment: <empty><br />
StatusBar: "See bitcoin.org/feb20 if you have trouble connecting after 20 February"<br />
Reserved: <empty><br />
<br />
== Scripting ==<br />
<br />
See [[script]].<br />
<br />
== Wireshark dissector ==<br />
A dissector for wireshark is being developed at https://github.com/blueCommand/bitcoin-dissector<br />
<br />
==See Also==<br />
<br />
* [[Network]]<br />
* [[Protocol rules]]<br />
* [[Hardfork Wishlist]]<br />
<br />
==References==<br />
<references /><br />
<br />
[[zh-cn:协议说明]]<br />
[[Category:Technical]]<br />
[[Category:Developer]]</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Protocol_documentation&diff=38942Protocol documentation2013-06-27T17:40:50Z<p>Giszmo: /* Merkle Trees */ sorted assignments so stuff gets defined first (north) and used later (south) and added spacing for readability (hope I don't enter some LukeJr religious war again)</p>
<hr />
<div>Sources:<br />
* [[Original Bitcoin client]] source<br />
<br />
Type names used in this documentation are from the C99 standard.<br />
<br />
For protocol used in mining, see [[Getwork]].<br />
<br />
==Common standards==<br />
<br />
=== Hashes ===<br />
<br />
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).<br />
<br />
Example of double-SHA-256 encoding of string "hello":<br />
<br />
hello<br />
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)<br />
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)<br />
<br />
For bitcoin addresses (RIPEMD-160) this would give:<br />
<br />
hello<br />
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round is sha-256)<br />
b6a9c8c230722b7c748331a8b450f05566dc7d0f (with ripemd-160)<br />
<br />
=== Merkle Trees ===<br />
<br />
Merkle trees are binary trees of hashes. Merkle trees in bitcoin use a '''double''' SHA-256, the SHA-256 hash of the SHA-256 hash of something.<br />
<br />
If, when forming a row in the tree (other than the root of the tree), it would have an odd number of elements, the final double-hash is duplicated to ensure that the row has an even number of hashes.<br />
<br />
First form the bottom row of the tree with the ordered double-SHA-256 hashes of the byte streams of the transactions in the block.<br />
<br />
Then the row above it consists of half that number of hashes. Each entry is the double-SHA-256 of the 64-byte concatenation of the corresponding two hashes below it in the tree.<br />
<br />
This procedure repeats recursively until we reach a row consisting of just a single double-hash. This is the '''merkle root''' of the tree.<br />
<br />
For example, imagine a block with three transactions ''a'', ''b'' and ''c''. The merkle tree is: <br />
<br />
d1 = dhash(a)<br />
d2 = dhash(b)<br />
d3 = dhash(c)<br />
d4 = dhash(c) # a, b, c are 3. that's an odd number, so we take the c twice<br />
<br />
d5 = dhash(d1 concat d2)<br />
d6 = dhash(d3 concat d4)<br />
<br />
d7 = dhash(d5 concat d6)<br />
<br />
where<br />
<br />
dhash(a) = sha256(sha256(a))<br />
<br />
''d6'' is the merkle root of the 3 transactions in this block.<br />
<br />
Note: Hashes in Merkle Tree displayed in the [[Block Explorer]] are of little-endian notation. For some implementations and [http://www.fileformat.info/tool/hash.htm calculations], the bits need to be reversed before they are hashed, and again after the hashing operation.<br />
<br />
=== Signatures ===<br />
<br />
Bitcoin uses [http://en.wikipedia.org/wiki/Elliptic_curve_cryptography Elliptic Curve] [http://en.wikipedia.org/wiki/Digital_Signature_Algorithm Digital Signature Algorithm] ([http://en.wikipedia.org/wiki/Elliptic_Curve_DSA ECDSA]) to sign transactions. <br />
<br />
For ECDSA the secp256k1 curve from http://www.secg.org/collateral/sec2_final.pdf is used.<br />
<br />
Public keys (in scripts) are given as 04 <x> <y> where ''x'' and ''y'' are 32 byte big-endian integers representing the coordinates of a point on the curve or in compressed form given as <sign> <x> where <sign> is 0x02 if ''y'' is even and 0x03 if ''y'' is odd.<br />
<br />
Signatures use [http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER encoding] to pack the ''r'' and ''s'' components into a single byte stream (this is also what OpenSSL produces by default).<br />
<br />
=== Transaction Verification ===<br />
Transactions are cryptographically signed records that reassign ownership of Bitcoins to new addresses. Transactions have ''inputs'' - records which reference the funds from other previous transactions - and ''outputs'' - records which determine the new owner of the transferred Bitcoins, and which will be referenced as inputs in future transactions as those funds are respent.<br />
<br />
Each ''input'' must have a cryptographic digital signature that unlocks the funds from the prior transaction. Only the person possessing the appropriate [[private key]] is able to create a satisfactory signature; this in effect ensures that funds can only be spent by their owners.<br />
<br />
Each ''output'' determines which Bitcoin address (or other criteria, see [[Scripting]]) is the recipient of the funds.<br />
<br />
In a transaction, the sum of all inputs must be equal to or greater than the sum of all outputs. If the inputs exceed the outputs, the difference is considered a [[transaction fee]], and is redeemable by whoever first includes the transaction into the block chain.<br />
<br />
A special kind of transaction, called a [[coinbase transaction]], has no inputs. It is created by [[miners]], and there is one coinbase transaction per block. Because each block comes with a reward of newly created Bitcoins (e.g. 50 BTC for the first 210,000 blocks), the first transaction of a block is, with few exceptions, the transaction that grants those coins to their recipient (the miner). In addition to the newly created Bitcoins, the coinbase transaction is also used for assigning the recipient of any transaction fees that were paid within the other transactions being included in the same block. The coinbase transaction can assign the entire reward to a single Bitcoin address, or split it in portions among multiple addresses, just like any other transaction. Coinbase transactions always contain outputs totaling the sum of the block reward plus all transaction fees collected from the other transactions in the same block.<br />
<br />
The [[coinbase transaction]] in block zero cannot be spent. This is due to a quirk of the reference client implementation that would open the potential for a block chain fork if some nodes accepted the spend and others did not<ref>[http://bitcointalk.org/index.php?topic=119645.msg1288552#msg1288552 Block 0 Network Fork]</ref>.<br />
<br />
Most Bitcoin outputs encumber the newly transferred coins with a single ECDSA private key. The actual record saved with inputs and outputs isn't necessarily a key, but a ''script''. Bitcoin uses an interpreted scripting system to determine whether an output's criteria have been satisfied, with which more complex operations are possible, such as outputs that require two ECDSA signatures, or two-of-three-signature schemes. An output that references a single Bitcoin address is a ''typical'' output; an output actually contains this information in the form of a script that requires a single ECDSA signature (see [[OP_CHECKSIG]]). The output script specifies what must be provided to unlock the funds later, and when the time comes in the future to spend the transaction in another input, that input must provide all of the thing(s) that satisfy the requirements defined by the original output script.<br />
<br />
=== Addresses ===<br />
<br />
A bitcoin address is in fact the hash of a ECDSA public key, computed this way:<br />
<br />
Version = 1 byte of 0 (zero); on the test network, this is 1 byte of 111<br />
Key hash = Version concatenated with RIPEMD-160(SHA-256(public key))<br />
Checksum = 1st 4 bytes of SHA-256(SHA-256(Key hash))<br />
Bitcoin Address = Base58Encode(Key hash concatenated with Checksum)<br />
<br />
The Base58 encoding used is home made, and has some differences. Especially, leading zeroes are kept as single zeroes when conversion happens.<br />
<br />
== Common structures ==<br />
<br />
Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.<br />
<br />
=== Message structure ===<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || magic || uint32_t || Magic value indicating message origin network, and used to seek to next message when stream state is unknown<br />
|-<br />
| 12 || command || char[12] || ASCII string identifying the packet content, NULL padded (non-NULL padding results in packet rejected)<br />
|-<br />
| 4 || length || uint32_t || Length of payload in number of bytes<br />
|-<br />
| 4 || checksum || uint32_t || First 4 bytes of sha256(sha256(payload))<br />
|-<br />
| ? || payload || uchar[] || The actual data<br />
|}<br />
<br />
<br />
Known magic values:<br />
<br />
{|class="wikitable"<br />
! Network !! Magic value !! Sent over wire as<br />
|-<br />
| main || 0xD9B4BEF9 || F9 BE B4 D9<br />
|-<br />
| testnet || 0xDAB5BFFA || FA BF B5 DA<br />
|-<br />
| testnet3 || 0x0709110B || 0B 11 09 07<br />
|-<br />
| namecoin || 0xFEB4BEF9 || F9 BE B4 FE<br />
|}<br />
<br />
=== Variable length integer ===<br />
<br />
Integer can be encoded depending on the represented value to save space.<br />
Variable length integers always precede an array/vector of a type of data that may vary in length.<br />
Longer numbers are encoded in little endian.<br />
<br />
{|class="wikitable"<br />
! Value !! Storage length !! Format<br />
|-<br />
| < 0xfd || 1 || uint8_t<br />
|-<br />
| <= 0xffff || 3 || 0xfd followed by the length as uint16_t<br />
|-<br />
| <= 0xffffffff || 5 || 0xfe followed by the length as uint32_t<br />
|-<br />
| - || 9 || 0xff followed by the length as uint64_t<br />
|}<br />
<br />
Footnote - if you're reading the Satoshi client code it refers to this as a "CompactSize" - VarInt's are something entirely different to the Satoshi code.<br />
<br />
=== Variable length string ===<br />
<br />
Variable length string can be stored using a variable length integer followed by the string itself.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the string<br />
|-<br />
| ? || string || char[] || The string itself (can be empty)<br />
|}<br />
<br />
=== Network address ===<br />
<br />
When a network address is needed somewhere, this structure is used. This protocol and structure supports IPv6, '''but note that the original client currently only supports IPv4 networking'''. Network addresses are not prefixed with a timestamp in the version message.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || time || uint32 || the Time (version >= 31402)<br />
|-<br />
| 8 || services || uint64_t || same service(s) listed in [[#version|version]]<br />
|-<br />
| 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]<br />
(12 bytes ''00 00 00 00 00 00 00 00 00 00 FF FF'', followed by the 4 bytes of the IPv4 address).<br />
|-<br />
| 2 || port || uint16_t || port number, network byte order<br />
|}<br />
<br />
Hexdump example of Network address structure<br />
<br />
<pre><br />
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .<br />
<br />
Network address:<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK: see services listed under version command)<br />
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<br />
20 8D - Port 8333<br />
</pre><br />
<br />
=== Inventory Vectors ===<br />
<br />
Inventory vectors are used for notifying other nodes about objects they have or data which is being requested.<br />
<br />
Inventory vectors consist of the following data format:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || type || uint32_t || Identifies the object type linked to this inventory<br />
|-<br />
| 32 || hash || char[32] || Hash of the object<br />
|}<br />
<br />
<br />
The object type is currently defined as one of the following possibilities:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 0 || ERROR || Any data of with this number may be ignored<br />
|-<br />
| 1 || MSG_TX || Hash is related to a transaction<br />
|-<br />
| 2 || MSG_BLOCK || Hash is related to a data block<br />
|}<br />
<br />
Other Data Type values are considered reserved for future implementations.<br />
<br />
=== Block Headers ===<br />
<br />
Block headers are sent in a headers packet in response to a getheaders message.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Block version information, based upon the software version creating this block<br />
|-<br />
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references<br />
|-<br />
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block<br />
|-<br />
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)<br />
|-<br />
| 4 || bits || uint32_t || The calculated difficulty target being used for this block<br />
|-<br />
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes<br />
|-<br />
| 1 || txn_count || uint8_t || Number of transaction entries, this value is always 0<br />
|}<br />
<br />
== Message types ==<br />
<br />
=== version ===<br />
<br />
When a node creates an outgoing connection, it will immediately [[Version Handshake|advertise]] its version. The remote node will respond with its version. No futher communication is possible until both peers have exchanged their version.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || int32_t || Identifies protocol version being used by the node<br />
|-<br />
| 8 || services || uint64_t || bitfield of features to be enabled for this connection<br />
|-<br />
| 8 || timestamp || int64_t || standard UNIX timestamp in seconds<br />
|-<br />
| 26 || addr_recv || net_addr || The network address of the node receiving this message<br />
|-<br />
|colspan="4"| version >= 106<br />
|-<br />
| 26 || addr_from || net_addr || The network address of the node emitting this message<br />
|-<br />
| 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.<br />
|-<br />
| ? || user_agent || [[#Variable length string|var_str]] || [[BIP_0014|User Agent]] (0x00 if string is 0 bytes long)<br />
|-<br />
| 4 || start_height || int32_t || The last block received by the emitting node<br />
|-<br />
| 1 || relay || bool || Whether the remote peer should announce relayed transactions or not, see [[BIP 0037]], since version >= 70001<br />
|}<br />
<br />
A "verack" packet shall be sent if the version packet was accepted.<br />
<br />
The following services are currently assigned:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers.<br />
|}<br />
<br />
Hexdump example of version message (OBSOLETE EXAMPLE. This example lacks a checksum and user-agent):<br />
<pre><br />
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....<br />
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........<br />
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............<br />
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................<br />
0040 20 8D 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,<br />
0060 3A B4 57 13 00 55 81 01 00 :.W..U...<br />
<br />
Message header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command<br />
55 00 00 00 - Payload is 85 bytes long<br />
- No checksum in version message until 20 February 2012. See https://bitcointalk.org/index.php?topic=55852.0<br />
Version message:<br />
9C 7C 00 00 - 31900 (version 0.3.19)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)<br />
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 20 8D - Recipient address info - see Network Address<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - Sender address info - see Network Address<br />
DD 9D 20 2C 3A B4 57 13 - Node random unique ID<br />
00 - "" sub-version string (string is 0 bytes long)<br />
55 81 01 00 - Last block sending node has is block #98645<br />
</pre><br />
<br />
And here's a modern (60002) protocol version client advertising itself to a local peer...<br />
<br />
Newer protocol includes the checksum now, this is from a mainline (satoshi) client during <br />
an outgoing connection to another local client, notice that it does not fill out the <br />
address information at all when the source or destination is "unroutable".<br />
<br />
<pre><br />
<br />
0000 f9 be b4 d9 76 65 72 73 69 6f 6e 00 00 00 00 00 ....version.....<br />
0010 64 00 00 00 35 8d 49 32 62 ea 00 00 01 00 00 00 d...5.I2b.......<br />
0020 00 00 00 00 11 b2 d0 50 00 00 00 00 01 00 00 00 .......P........<br />
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ................<br />
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0050 00 00 00 00 00 00 00 00 ff ff 00 00 00 00 00 00 ................<br />
0060 3b 2e b3 5d 8c e6 17 65 0f 2f 53 61 74 6f 73 68 ;..]...e./Satosh<br />
0070 69 3a 30 2e 37 2e 32 2f c0 3e 03 00 i:0.7.2/.>..<br />
<br />
Message Header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command<br />
64 00 00 00 - Payload is 100 bytes long<br />
35 8D 49 32 - payload checksum<br />
<br />
Version message:<br />
62 EA 00 00 - 60002 (protocol version 60002)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)<br />
11 B2 D0 50 00 00 00 00 - Tue Dec 18 10:12:33 PST 2012<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Recipient address info - see Network Address<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Sender address info - see Network Address<br />
3B 2E B3 5D 8C E6 17 65 - Node ID<br />
0F 2F 53 61 74 6F 73 68 69 3A 30 2E 37 2E 32 2F - "/Satoshi:0.7.2/" sub-version string (string is 15 bytes long)<br />
C0 3E 03 00 - Last block sending node has is block #212672<br />
</pre><br />
<br />
=== verack ===<br />
<br />
The ''verack'' message is sent in reply to ''version''. This message consists of only a [[#Message structure|message header]] with the command string "verack".<br />
<br />
Hexdump of the verack message:<br />
<br />
<pre><br />
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......<br />
0010 00 00 00 00 5D F6 E0 E2 ........<br />
<br />
Message header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 61 63 6B 00 00 00 00 00 00 - "verack" command<br />
00 00 00 00 - Payload is 0 bytes long<br />
5D F6 E0 E2 - Checksum<br />
</pre><br />
<br />
=== addr ===<br />
<br />
Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours<br />
<br />
Payload:<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 1+ || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of address entries (max: 1000)<br />
|-<br />
| 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).<br />
|}<br />
<br />
'''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.<br />
<br />
Hexdump example of ''addr'' message:<br />
<pre><br />
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........<br />
0010 1F 00 00 00 ED 52 39 9B 01 E2 15 10 4D 01 00 00 .....R9.....M...<br />
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................<br />
0030 FF 0A 00 00 01 20 8D ..... .<br />
<br />
Message Header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"<br />
1F 00 00 00 - payload is 31 bytes long<br />
ED 52 39 9B - checksum of payload<br />
<br />
Payload:<br />
01 - 1 address in this message<br />
<br />
Address:<br />
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - see version message)<br />
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)<br />
20 8D - port 8333<br />
</pre><br />
<br />
=== inv ===<br />
<br />
Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to ''getblocks''.<br />
<br />
Payload (maximum payload length: 1.8 Megabytes or 50000 entries):<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries<br />
|-<br />
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br />
|}<br />
<br />
=== getdata ===<br />
<br />
getdata is used in response to inv, to retrieve the content of a specific object, and is usually sent after receiving an ''inv'' packet, after filtering known elements. It can be used to retrieve transactions, but only if they are in the memory pool or relay set - arbitrary access to transactions in the chain is not allowed to avoid having clients start to depend on nodes having full transaction indexes (which modern nodes do not).<br />
<br />
Payload (maximum payload length: 1.8 Megabytes or 50000 entries):<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries<br />
|-<br />
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br />
|}<br />
<br />
=== notfound ===<br />
<br />
notfound is a response to a getdata, sent if any requested data items could not be relayed, for example, because the requested transaction was not in the memory pool or relay set.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries<br />
|-<br />
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br />
|}<br />
<br />
=== getblocks ===<br />
<br />
Return an ''inv'' packet containing the list of blocks starting right after the last known hash in the block locator object, up to hash_stop or 500 blocks, whichever comes first. <br />
<br />
The locator hashes are processed by a node in the order as they appear in the message. If a block hash if found in the node's main chain, the list of it's children is returned back via the ''inv'' message and the remaining locators are ignored, no matter if the requested limit was reached, or not.<br />
<br />
To receive the next blocks hashes, one needs to issue getblocks again with a new block locator object. Keep in mind that some clients (specifically the Satoshi client) will gladly provide blocks which are invalid if the block locator object contains a hash on the invalid branch.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || the protocol version<br />
|-<br />
| 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries<br />
|-<br />
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)<br />
|-<br />
| 32 || hash_stop || char[32] || hash of the last desired block; set to zero to get as many blocks as possible (500)<br />
|}<br />
<br />
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:<br />
<br />
<pre><br />
// From libbitcoin which is under AGPL<br />
std::vector<size_t> block_locator_indices(int top_depth)<br />
{<br />
// Start at max_depth<br />
std::vector<size_t> indices;<br />
// Push last 10 indices first<br />
size_t step = 1, start = 0;<br />
for (int i = top_depth; i > 0; i -= step, ++start)<br />
{<br />
if (start >= 10)<br />
step *= 2;<br />
indices.push_back(i);<br />
}<br />
indices.push_back(0);<br />
return indices;<br />
}<br />
</pre><br />
<br />
Note that it is allowed to send in fewer known hashes down to a minimum of just one hash. However, the purpose of the block locator object is to detect a wrong branch in the caller's main chain. If the peer detects that you are off the main chain, it will send in block hashes which are earlier than your last known block. So if you just send in your last known hash and it is off the main chain, the peer starts over at block #1.<br />
<br />
=== getheaders ===<br />
<br />
Return a ''headers'' packet containing the headers of blocks starting right after the last known hash in the block locator object, up to hash_stop or 2000 blocks, whichever comes first. To receive the next block headers, one needs to issue getheaders again with a new block locator object. The ''getheaders'' command is used by thin clients to quickly download the blockchain where the contents of the transactions would be irrelevant (because they are not ours). Keep in mind that some clients (specifically the Satoshi client) will gladly provide headers of blocks which are invalid if the block locator object contains a hash on the invalid branch.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || the protocol version<br />
|-<br />
| 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries<br />
|-<br />
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)<br />
|-<br />
| 32 || hash_stop || char[32] || hash of the last desired block header; set to zero to get as many blocks as possible (2000)<br />
|}<br />
<br />
For the block locator object in this packet, the same rules apply as for the [[Protocol_specification#getblocks|getblocks]] packet.<br />
<br />
=== tx ===<br />
<br />
''tx'' describes a bitcoin transaction, in reply to ''getdata''<br />
<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Transaction data format version<br />
|-<br />
| 1+ || tx_in count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction inputs<br />
|-<br />
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins<br />
|-<br />
| 1+ || tx_out count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction outputs<br />
|-<br />
| 9+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins<br />
|-<br />
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked:<br />
{|class="wikitable"<br />
! Value !! Description<br />
|-<br />
| 0 || Always locked<br />
|-<br />
| < 500000000 || Block number at which this transaction is locked<br />
|-<br />
| >= 500000000 || UNIX timestamp at which this transaction is locked<br />
|}<br />
If all TxIn inputs have final (0xffffffff) sequence numbers then lock_time is irrelevant. Otherwise, the transaction may not be added to a block until after lock_time.<br />
<br />
|}<br />
<br />
TxIn consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure<br />
|-<br />
| 1+ || script length || [[Protocol_specification#Variable_length_integer|var_int]] || The length of the signature script<br />
|-<br />
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization<br />
|-<br />
| 4 || [http://bitcoin.stackexchange.com/q/2025/323 sequence] || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.<br />
|}<br />
<br />
The OutPoint structure consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 32 || hash || char[32] || The hash of the referenced transaction.<br />
|-<br />
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.<br />
|}<br />
<br />
The Script structure consists of a series of pieces of information and operations related to the value of the transaction.<br />
<br />
(Structure to be expanded in the future… see script.h and script.cpp and [[Script]] for more information)<br />
<br />
The TxOut structure consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 8 || value || int64_t || Transaction Value<br />
|-<br />
| 1+ || pk_script length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the pk_script<br />
|-<br />
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.<br />
|}<br />
<br />
Example ''tx'' message:<br />
<pre><br />
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........<br />
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..<br />
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.<br />
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...<br />
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...<br />
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:<br />
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....<br />
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...<br />
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....<br />
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...<br />
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...<br />
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...<br />
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....<br />
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....<br />
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........<br />
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..<br />
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...<br />
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......<br />
<br />
<br />
Message header:<br />
F9 BE B4 D9 - main network magic bytes<br />
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command<br />
02 01 00 00 - payload is 258 bytes long<br />
E2 93 CD BE - checksum of payload<br />
<br />
Transaction:<br />
01 00 00 00 - version<br />
<br />
Inputs:<br />
01 - number of transaction inputs<br />
<br />
Input 1:<br />
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)<br />
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29<br />
00 00 00 00<br />
<br />
8B - script is 139 bytes long<br />
<br />
48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)<br />
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23<br />
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41<br />
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD<br />
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E<br />
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD<br />
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02<br />
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04<br />
2F 46 61 4A 4C 70 C0 F1 4B EF F5<br />
<br />
FF FF FF FF - sequence<br />
<br />
Outputs:<br />
02 - 2 Output Transactions<br />
<br />
Output 1:<br />
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)<br />
19 - pk_script is 25 bytes long<br />
<br />
76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script<br />
A9 D9 EA 1A FB 22 5E 88 AC<br />
<br />
Output 2:<br />
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)<br />
19 - pk_script is 25 bytes long<br />
<br />
76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script<br />
FD A0 B7 8B 4E CC 52 88 AC<br />
<br />
Locktime:<br />
00 00 00 00 - lock time<br />
</pre><br />
<br />
=== block ===<br />
<br />
The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Block version information, based upon the software version creating this block<br />
|-<br />
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references<br />
|-<br />
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block<br />
|-<br />
| 4 || timestamp || uint32_t || A unix timestamp recording when this block was created (Currently limited to dates before the year 2106!)<br />
|-<br />
| 4 || bits || uint32_t || The calculated [[Difficulty|difficulty target]] being used for this block<br />
|-<br />
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes<br />
|-<br />
| ? || txn_count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of transaction entries<br />
|-<br />
| ? || txns || tx[] || Block transactions, in format of "tx" command<br />
|}<br />
<br />
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.<br />
See [[Block hashing algorithm]] for details and an example.<br />
<br />
=== headers ===<br />
<br />
The ''headers'' packet returns block headers in response to a ''getheaders'' packet. <br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of block headers<br />
|-<br />
| 81x? || headers || [[Protocol_specification#Block_Headers|block_header]][] || [[Protocol_specification#Block_Headers|Block headers]]<br />
|}<br />
<br />
Note that the block headers in this packet include a transaction count (a var_int, so there can be more than 81 bytes per header) as opposed to the block headers which are sent to miners.<br />
<br />
=== getaddr ===<br />
<br />
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.<br />
<br />
No additional data is transmitted with this message.<br />
<br />
=== checkorder ===<br />
<br />
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.<br />
<br />
It contains a CWalletTx object<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
|colspan="4"| Fields from CMerkleTx<br />
|-<br />
| ? || hashBlock<br />
|-<br />
| ? || vMerkleBranch<br />
|-<br />
| ? || nIndex<br />
|-<br />
|colspan="4"| Fields from CWalletTx<br />
|-<br />
| ? || vtxPrev<br />
|-<br />
| ? || mapValue<br />
|-<br />
| ? || vOrderForm<br />
|-<br />
| ? || fTimeReceivedIsTxTime<br />
|-<br />
| ? || nTimeReceived<br />
|-<br />
| ? || fFromMe<br />
|-<br />
| ? || fSpent<br />
|}<br />
<br />
=== submitorder ===<br />
<br />
Confirms an order has been submitted. <br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 32 || hash || char[32] || Hash of the transaction<br />
|-<br />
| ? || wallet_entry || CWalletTx || Same payload as checkorder<br />
|}<br />
<br />
=== reply ===<br />
<br />
Generic reply for [[IP Transactions]]<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || reply || uint32_t || reply code<br />
|}<br />
<br />
Possible values:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')<br />
|-<br />
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed<br />
|-<br />
| 2 || DENIED || IP Transactions are not accepted by this node<br />
|}<br />
<br />
=== ping ===<br />
<br />
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. In modern protocol versions, a ''pong'' response is generated using a nonce included in the ping.<br />
<br />
=== filterload, filteradd, filterclear, merkleblock ===<br />
<br />
These messages are related to Bloom filtering of connections and are defined in [[BIP 0037]].<br />
<br />
=== alert ===<br />
<br />
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.<br />
<br />
Alert format:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || payload || var_str || Serialized alert payload<br />
|-<br />
| ? || signature || var_str || An ECDSA signature of the message<br />
|}<br />
<br />
The developers of Satoshi's client use this public key for signing alerts:<br />
04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284<br />
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s<br />
<br />
The payload is serialized into a var_str to ensure that versions using incompatible alert formats can still relay alerts among one another. The current alert payload format is:<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || Version || int32_t || Alert format version<br />
|-<br />
| 8 || RelayUntil || int64_t || The timestamp beyond which nodes should stop relaying this alert<br />
|-<br />
| 8 || Expiration || int64_t || The timestamp beyond which this alert is no longer in effect and should be ignored<br />
|-<br />
| 4 || ID || int32_t || A unique ID number for this alert<br />
|-<br />
| 4 || Cancel || int32_t || All alerts with an ID number less than or equal to this number should be canceled: deleted and not accepted in the future<br />
|-<br />
| ? || setCancel || set<int> || All alert IDs contained in this set should be canceled as above<br />
|-<br />
| 4 || MinVer || int32_t || This alert only applies to versions greater than or equal to this version. Other versions should still relay it.<br />
|-<br />
| 4 || MaxVer || int32_t || This alert only applies to versions less than or equal to this version. Other versions should still relay it.<br />
|-<br />
| ? || setSubVer || set<string> || If this set contains any elements, then only nodes that have their subVer contained in this set are affected by the alert. Other versions should still relay it.<br />
|-<br />
| 4 || Priority || int32_t || Relative priority compared to other alerts<br />
|-<br />
| ? || Comment || string || A comment on the alert that is not displayed<br />
|-<br />
| ? || StatusBar || string || The alert message that is displayed to the user<br />
|-<br />
| ? || Reserved || string || Reserved<br />
|}<br />
<br />
Sample alert (no message header):<br />
73010000003766404f00000000b305434f00000000f2030000f1030000001027000048ee0000<br />
0064000000004653656520626974636f696e2e6f72672f666562323020696620796f75206861<br />
76652074726f75626c6520636f6e6e656374696e672061667465722032302046656272756172<br />
79004730450221008389df45f0703f39ec8c1cc42c13810ffcae14995bb648340219e353b63b<br />
53eb022009ec65e1c1aaeec1fd334c6b684bde2b3f573060d5b70c3a46723326e4e8a4f1<br />
<br />
Version: 1<br />
RelayUntil: 1329620535<br />
Expiration: 1329792435<br />
ID: 1010<br />
Cancel: 1009<br />
setCancel: <empty><br />
MinVer: 10000<br />
MaxVer: 61000<br />
setSubVer: <empty><br />
Priority: 100<br />
Comment: <empty><br />
StatusBar: "See bitcoin.org/feb20 if you have trouble connecting after 20 February"<br />
Reserved: <empty><br />
<br />
== Scripting ==<br />
<br />
See [[script]].<br />
<br />
== Wireshark dissector ==<br />
A dissector for wireshark is being developed at https://github.com/blueCommand/bitcoin-dissector<br />
<br />
==See Also==<br />
<br />
* [[Network]]<br />
* [[Protocol rules]]<br />
* [[Hardfork Wishlist]]<br />
<br />
==References==<br />
<references /><br />
<br />
[[zh-cn:协议说明]]<br />
[[Category:Technical]]<br />
[[Category:Developer]]</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Protocol_documentation&diff=38941Protocol documentation2013-06-27T17:31:32Z<p>Giszmo: /* Merkle Trees */ increased readability (only whitespaces affected)</p>
<hr />
<div>Sources:<br />
* [[Original Bitcoin client]] source<br />
<br />
Type names used in this documentation are from the C99 standard.<br />
<br />
For protocol used in mining, see [[Getwork]].<br />
<br />
==Common standards==<br />
<br />
=== Hashes ===<br />
<br />
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).<br />
<br />
Example of double-SHA-256 encoding of string "hello":<br />
<br />
hello<br />
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)<br />
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)<br />
<br />
For bitcoin addresses (RIPEMD-160) this would give:<br />
<br />
hello<br />
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round is sha-256)<br />
b6a9c8c230722b7c748331a8b450f05566dc7d0f (with ripemd-160)<br />
<br />
=== Merkle Trees ===<br />
<br />
Merkle trees are binary trees of hashes. Merkle trees in bitcoin use a '''double''' SHA-256, the SHA-256 hash of the SHA-256 hash of something.<br />
<br />
If, when forming a row in the tree (other than the root of the tree), it would have an odd number of elements, the final double-hash is duplicated to ensure that the row has an even number of hashes.<br />
<br />
First form the bottom row of the tree with the ordered double-SHA-256 hashes of the byte streams of the transactions in the block.<br />
<br />
Then the row above it consists of half that number of hashes. Each entry is the double-SHA-256 of the 64-byte concatenation of the corresponding two hashes below it in the tree.<br />
<br />
This procedure repeats recursively until we reach a row consisting of just a single double-hash. This is the '''merkle root''' of the tree.<br />
<br />
For example, imagine a block with three transactions ''a'', ''b'' and ''c''. The merkle tree is: <br />
<br />
d6=dhash(d4 concat d5)<br />
d4=dhash(d1 concat d2)<br />
d5=dhash(d3 concat d3)<br />
d1=dhash(a)<br />
d2=dhash(b)<br />
d3=dhash(c)<br />
d3=dhash(c)<br />
<br />
where<br />
<br />
dhash(a) = sha256(sha256(a))<br />
<br />
''d6'' is the merkle root of the 3 transactions in this block.<br />
<br />
Note: Hashes in Merkle Tree displayed in the [[Block Explorer]] are of little-endian notation. For some implementations and [http://www.fileformat.info/tool/hash.htm calculations], the bits need to be reversed before they are hashed, and again after the hashing operation.<br />
<br />
=== Signatures ===<br />
<br />
Bitcoin uses [http://en.wikipedia.org/wiki/Elliptic_curve_cryptography Elliptic Curve] [http://en.wikipedia.org/wiki/Digital_Signature_Algorithm Digital Signature Algorithm] ([http://en.wikipedia.org/wiki/Elliptic_Curve_DSA ECDSA]) to sign transactions. <br />
<br />
For ECDSA the secp256k1 curve from http://www.secg.org/collateral/sec2_final.pdf is used.<br />
<br />
Public keys (in scripts) are given as 04 <x> <y> where ''x'' and ''y'' are 32 byte big-endian integers representing the coordinates of a point on the curve or in compressed form given as <sign> <x> where <sign> is 0x02 if ''y'' is even and 0x03 if ''y'' is odd.<br />
<br />
Signatures use [http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER encoding] to pack the ''r'' and ''s'' components into a single byte stream (this is also what OpenSSL produces by default).<br />
<br />
=== Transaction Verification ===<br />
Transactions are cryptographically signed records that reassign ownership of Bitcoins to new addresses. Transactions have ''inputs'' - records which reference the funds from other previous transactions - and ''outputs'' - records which determine the new owner of the transferred Bitcoins, and which will be referenced as inputs in future transactions as those funds are respent.<br />
<br />
Each ''input'' must have a cryptographic digital signature that unlocks the funds from the prior transaction. Only the person possessing the appropriate [[private key]] is able to create a satisfactory signature; this in effect ensures that funds can only be spent by their owners.<br />
<br />
Each ''output'' determines which Bitcoin address (or other criteria, see [[Scripting]]) is the recipient of the funds.<br />
<br />
In a transaction, the sum of all inputs must be equal to or greater than the sum of all outputs. If the inputs exceed the outputs, the difference is considered a [[transaction fee]], and is redeemable by whoever first includes the transaction into the block chain.<br />
<br />
A special kind of transaction, called a [[coinbase transaction]], has no inputs. It is created by [[miners]], and there is one coinbase transaction per block. Because each block comes with a reward of newly created Bitcoins (e.g. 50 BTC for the first 210,000 blocks), the first transaction of a block is, with few exceptions, the transaction that grants those coins to their recipient (the miner). In addition to the newly created Bitcoins, the coinbase transaction is also used for assigning the recipient of any transaction fees that were paid within the other transactions being included in the same block. The coinbase transaction can assign the entire reward to a single Bitcoin address, or split it in portions among multiple addresses, just like any other transaction. Coinbase transactions always contain outputs totaling the sum of the block reward plus all transaction fees collected from the other transactions in the same block.<br />
<br />
The [[coinbase transaction]] in block zero cannot be spent. This is due to a quirk of the reference client implementation that would open the potential for a block chain fork if some nodes accepted the spend and others did not<ref>[http://bitcointalk.org/index.php?topic=119645.msg1288552#msg1288552 Block 0 Network Fork]</ref>.<br />
<br />
Most Bitcoin outputs encumber the newly transferred coins with a single ECDSA private key. The actual record saved with inputs and outputs isn't necessarily a key, but a ''script''. Bitcoin uses an interpreted scripting system to determine whether an output's criteria have been satisfied, with which more complex operations are possible, such as outputs that require two ECDSA signatures, or two-of-three-signature schemes. An output that references a single Bitcoin address is a ''typical'' output; an output actually contains this information in the form of a script that requires a single ECDSA signature (see [[OP_CHECKSIG]]). The output script specifies what must be provided to unlock the funds later, and when the time comes in the future to spend the transaction in another input, that input must provide all of the thing(s) that satisfy the requirements defined by the original output script.<br />
<br />
=== Addresses ===<br />
<br />
A bitcoin address is in fact the hash of a ECDSA public key, computed this way:<br />
<br />
Version = 1 byte of 0 (zero); on the test network, this is 1 byte of 111<br />
Key hash = Version concatenated with RIPEMD-160(SHA-256(public key))<br />
Checksum = 1st 4 bytes of SHA-256(SHA-256(Key hash))<br />
Bitcoin Address = Base58Encode(Key hash concatenated with Checksum)<br />
<br />
The Base58 encoding used is home made, and has some differences. Especially, leading zeroes are kept as single zeroes when conversion happens.<br />
<br />
== Common structures ==<br />
<br />
Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.<br />
<br />
=== Message structure ===<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || magic || uint32_t || Magic value indicating message origin network, and used to seek to next message when stream state is unknown<br />
|-<br />
| 12 || command || char[12] || ASCII string identifying the packet content, NULL padded (non-NULL padding results in packet rejected)<br />
|-<br />
| 4 || length || uint32_t || Length of payload in number of bytes<br />
|-<br />
| 4 || checksum || uint32_t || First 4 bytes of sha256(sha256(payload))<br />
|-<br />
| ? || payload || uchar[] || The actual data<br />
|}<br />
<br />
<br />
Known magic values:<br />
<br />
{|class="wikitable"<br />
! Network !! Magic value !! Sent over wire as<br />
|-<br />
| main || 0xD9B4BEF9 || F9 BE B4 D9<br />
|-<br />
| testnet || 0xDAB5BFFA || FA BF B5 DA<br />
|-<br />
| testnet3 || 0x0709110B || 0B 11 09 07<br />
|-<br />
| namecoin || 0xFEB4BEF9 || F9 BE B4 FE<br />
|}<br />
<br />
=== Variable length integer ===<br />
<br />
Integer can be encoded depending on the represented value to save space.<br />
Variable length integers always precede an array/vector of a type of data that may vary in length.<br />
Longer numbers are encoded in little endian.<br />
<br />
{|class="wikitable"<br />
! Value !! Storage length !! Format<br />
|-<br />
| < 0xfd || 1 || uint8_t<br />
|-<br />
| <= 0xffff || 3 || 0xfd followed by the length as uint16_t<br />
|-<br />
| <= 0xffffffff || 5 || 0xfe followed by the length as uint32_t<br />
|-<br />
| - || 9 || 0xff followed by the length as uint64_t<br />
|}<br />
<br />
Footnote - if you're reading the Satoshi client code it refers to this as a "CompactSize" - VarInt's are something entirely different to the Satoshi code.<br />
<br />
=== Variable length string ===<br />
<br />
Variable length string can be stored using a variable length integer followed by the string itself.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the string<br />
|-<br />
| ? || string || char[] || The string itself (can be empty)<br />
|}<br />
<br />
=== Network address ===<br />
<br />
When a network address is needed somewhere, this structure is used. This protocol and structure supports IPv6, '''but note that the original client currently only supports IPv4 networking'''. Network addresses are not prefixed with a timestamp in the version message.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || time || uint32 || the Time (version >= 31402)<br />
|-<br />
| 8 || services || uint64_t || same service(s) listed in [[#version|version]]<br />
|-<br />
| 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]<br />
(12 bytes ''00 00 00 00 00 00 00 00 00 00 FF FF'', followed by the 4 bytes of the IPv4 address).<br />
|-<br />
| 2 || port || uint16_t || port number, network byte order<br />
|}<br />
<br />
Hexdump example of Network address structure<br />
<br />
<pre><br />
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .<br />
<br />
Network address:<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK: see services listed under version command)<br />
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<br />
20 8D - Port 8333<br />
</pre><br />
<br />
=== Inventory Vectors ===<br />
<br />
Inventory vectors are used for notifying other nodes about objects they have or data which is being requested.<br />
<br />
Inventory vectors consist of the following data format:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || type || uint32_t || Identifies the object type linked to this inventory<br />
|-<br />
| 32 || hash || char[32] || Hash of the object<br />
|}<br />
<br />
<br />
The object type is currently defined as one of the following possibilities:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 0 || ERROR || Any data of with this number may be ignored<br />
|-<br />
| 1 || MSG_TX || Hash is related to a transaction<br />
|-<br />
| 2 || MSG_BLOCK || Hash is related to a data block<br />
|}<br />
<br />
Other Data Type values are considered reserved for future implementations.<br />
<br />
=== Block Headers ===<br />
<br />
Block headers are sent in a headers packet in response to a getheaders message.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Block version information, based upon the software version creating this block<br />
|-<br />
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references<br />
|-<br />
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block<br />
|-<br />
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)<br />
|-<br />
| 4 || bits || uint32_t || The calculated difficulty target being used for this block<br />
|-<br />
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes<br />
|-<br />
| 1 || txn_count || uint8_t || Number of transaction entries, this value is always 0<br />
|}<br />
<br />
== Message types ==<br />
<br />
=== version ===<br />
<br />
When a node creates an outgoing connection, it will immediately [[Version Handshake|advertise]] its version. The remote node will respond with its version. No futher communication is possible until both peers have exchanged their version.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || int32_t || Identifies protocol version being used by the node<br />
|-<br />
| 8 || services || uint64_t || bitfield of features to be enabled for this connection<br />
|-<br />
| 8 || timestamp || int64_t || standard UNIX timestamp in seconds<br />
|-<br />
| 26 || addr_recv || net_addr || The network address of the node receiving this message<br />
|-<br />
|colspan="4"| version >= 106<br />
|-<br />
| 26 || addr_from || net_addr || The network address of the node emitting this message<br />
|-<br />
| 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.<br />
|-<br />
| ? || user_agent || [[#Variable length string|var_str]] || [[BIP_0014|User Agent]] (0x00 if string is 0 bytes long)<br />
|-<br />
| 4 || start_height || int32_t || The last block received by the emitting node<br />
|-<br />
| 1 || relay || bool || Whether the remote peer should announce relayed transactions or not, see [[BIP 0037]], since version >= 70001<br />
|}<br />
<br />
A "verack" packet shall be sent if the version packet was accepted.<br />
<br />
The following services are currently assigned:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers.<br />
|}<br />
<br />
Hexdump example of version message (OBSOLETE EXAMPLE. This example lacks a checksum and user-agent):<br />
<pre><br />
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....<br />
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........<br />
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............<br />
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................<br />
0040 20 8D 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,<br />
0060 3A B4 57 13 00 55 81 01 00 :.W..U...<br />
<br />
Message header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command<br />
55 00 00 00 - Payload is 85 bytes long<br />
- No checksum in version message until 20 February 2012. See https://bitcointalk.org/index.php?topic=55852.0<br />
Version message:<br />
9C 7C 00 00 - 31900 (version 0.3.19)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)<br />
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 20 8D - Recipient address info - see Network Address<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - Sender address info - see Network Address<br />
DD 9D 20 2C 3A B4 57 13 - Node random unique ID<br />
00 - "" sub-version string (string is 0 bytes long)<br />
55 81 01 00 - Last block sending node has is block #98645<br />
</pre><br />
<br />
And here's a modern (60002) protocol version client advertising itself to a local peer...<br />
<br />
Newer protocol includes the checksum now, this is from a mainline (satoshi) client during <br />
an outgoing connection to another local client, notice that it does not fill out the <br />
address information at all when the source or destination is "unroutable".<br />
<br />
<pre><br />
<br />
0000 f9 be b4 d9 76 65 72 73 69 6f 6e 00 00 00 00 00 ....version.....<br />
0010 64 00 00 00 35 8d 49 32 62 ea 00 00 01 00 00 00 d...5.I2b.......<br />
0020 00 00 00 00 11 b2 d0 50 00 00 00 00 01 00 00 00 .......P........<br />
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ................<br />
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0050 00 00 00 00 00 00 00 00 ff ff 00 00 00 00 00 00 ................<br />
0060 3b 2e b3 5d 8c e6 17 65 0f 2f 53 61 74 6f 73 68 ;..]...e./Satosh<br />
0070 69 3a 30 2e 37 2e 32 2f c0 3e 03 00 i:0.7.2/.>..<br />
<br />
Message Header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command<br />
64 00 00 00 - Payload is 100 bytes long<br />
35 8D 49 32 - payload checksum<br />
<br />
Version message:<br />
62 EA 00 00 - 60002 (protocol version 60002)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)<br />
11 B2 D0 50 00 00 00 00 - Tue Dec 18 10:12:33 PST 2012<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Recipient address info - see Network Address<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Sender address info - see Network Address<br />
3B 2E B3 5D 8C E6 17 65 - Node ID<br />
0F 2F 53 61 74 6F 73 68 69 3A 30 2E 37 2E 32 2F - "/Satoshi:0.7.2/" sub-version string (string is 15 bytes long)<br />
C0 3E 03 00 - Last block sending node has is block #212672<br />
</pre><br />
<br />
=== verack ===<br />
<br />
The ''verack'' message is sent in reply to ''version''. This message consists of only a [[#Message structure|message header]] with the command string "verack".<br />
<br />
Hexdump of the verack message:<br />
<br />
<pre><br />
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......<br />
0010 00 00 00 00 5D F6 E0 E2 ........<br />
<br />
Message header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 61 63 6B 00 00 00 00 00 00 - "verack" command<br />
00 00 00 00 - Payload is 0 bytes long<br />
5D F6 E0 E2 - Checksum<br />
</pre><br />
<br />
=== addr ===<br />
<br />
Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours<br />
<br />
Payload:<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 1+ || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of address entries (max: 1000)<br />
|-<br />
| 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).<br />
|}<br />
<br />
'''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.<br />
<br />
Hexdump example of ''addr'' message:<br />
<pre><br />
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........<br />
0010 1F 00 00 00 ED 52 39 9B 01 E2 15 10 4D 01 00 00 .....R9.....M...<br />
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................<br />
0030 FF 0A 00 00 01 20 8D ..... .<br />
<br />
Message Header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"<br />
1F 00 00 00 - payload is 31 bytes long<br />
ED 52 39 9B - checksum of payload<br />
<br />
Payload:<br />
01 - 1 address in this message<br />
<br />
Address:<br />
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - see version message)<br />
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)<br />
20 8D - port 8333<br />
</pre><br />
<br />
=== inv ===<br />
<br />
Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to ''getblocks''.<br />
<br />
Payload (maximum payload length: 1.8 Megabytes or 50000 entries):<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries<br />
|-<br />
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br />
|}<br />
<br />
=== getdata ===<br />
<br />
getdata is used in response to inv, to retrieve the content of a specific object, and is usually sent after receiving an ''inv'' packet, after filtering known elements. It can be used to retrieve transactions, but only if they are in the memory pool or relay set - arbitrary access to transactions in the chain is not allowed to avoid having clients start to depend on nodes having full transaction indexes (which modern nodes do not).<br />
<br />
Payload (maximum payload length: 1.8 Megabytes or 50000 entries):<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries<br />
|-<br />
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br />
|}<br />
<br />
=== notfound ===<br />
<br />
notfound is a response to a getdata, sent if any requested data items could not be relayed, for example, because the requested transaction was not in the memory pool or relay set.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries<br />
|-<br />
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br />
|}<br />
<br />
=== getblocks ===<br />
<br />
Return an ''inv'' packet containing the list of blocks starting right after the last known hash in the block locator object, up to hash_stop or 500 blocks, whichever comes first. <br />
<br />
The locator hashes are processed by a node in the order as they appear in the message. If a block hash if found in the node's main chain, the list of it's children is returned back via the ''inv'' message and the remaining locators are ignored, no matter if the requested limit was reached, or not.<br />
<br />
To receive the next blocks hashes, one needs to issue getblocks again with a new block locator object. Keep in mind that some clients (specifically the Satoshi client) will gladly provide blocks which are invalid if the block locator object contains a hash on the invalid branch.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || the protocol version<br />
|-<br />
| 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries<br />
|-<br />
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)<br />
|-<br />
| 32 || hash_stop || char[32] || hash of the last desired block; set to zero to get as many blocks as possible (500)<br />
|}<br />
<br />
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:<br />
<br />
<pre><br />
// From libbitcoin which is under AGPL<br />
std::vector<size_t> block_locator_indices(int top_depth)<br />
{<br />
// Start at max_depth<br />
std::vector<size_t> indices;<br />
// Push last 10 indices first<br />
size_t step = 1, start = 0;<br />
for (int i = top_depth; i > 0; i -= step, ++start)<br />
{<br />
if (start >= 10)<br />
step *= 2;<br />
indices.push_back(i);<br />
}<br />
indices.push_back(0);<br />
return indices;<br />
}<br />
</pre><br />
<br />
Note that it is allowed to send in fewer known hashes down to a minimum of just one hash. However, the purpose of the block locator object is to detect a wrong branch in the caller's main chain. If the peer detects that you are off the main chain, it will send in block hashes which are earlier than your last known block. So if you just send in your last known hash and it is off the main chain, the peer starts over at block #1.<br />
<br />
=== getheaders ===<br />
<br />
Return a ''headers'' packet containing the headers of blocks starting right after the last known hash in the block locator object, up to hash_stop or 2000 blocks, whichever comes first. To receive the next block headers, one needs to issue getheaders again with a new block locator object. The ''getheaders'' command is used by thin clients to quickly download the blockchain where the contents of the transactions would be irrelevant (because they are not ours). Keep in mind that some clients (specifically the Satoshi client) will gladly provide headers of blocks which are invalid if the block locator object contains a hash on the invalid branch.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || the protocol version<br />
|-<br />
| 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries<br />
|-<br />
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)<br />
|-<br />
| 32 || hash_stop || char[32] || hash of the last desired block header; set to zero to get as many blocks as possible (2000)<br />
|}<br />
<br />
For the block locator object in this packet, the same rules apply as for the [[Protocol_specification#getblocks|getblocks]] packet.<br />
<br />
=== tx ===<br />
<br />
''tx'' describes a bitcoin transaction, in reply to ''getdata''<br />
<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Transaction data format version<br />
|-<br />
| 1+ || tx_in count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction inputs<br />
|-<br />
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins<br />
|-<br />
| 1+ || tx_out count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction outputs<br />
|-<br />
| 9+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins<br />
|-<br />
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked:<br />
{|class="wikitable"<br />
! Value !! Description<br />
|-<br />
| 0 || Always locked<br />
|-<br />
| < 500000000 || Block number at which this transaction is locked<br />
|-<br />
| >= 500000000 || UNIX timestamp at which this transaction is locked<br />
|}<br />
If all TxIn inputs have final (0xffffffff) sequence numbers then lock_time is irrelevant. Otherwise, the transaction may not be added to a block until after lock_time.<br />
<br />
|}<br />
<br />
TxIn consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure<br />
|-<br />
| 1+ || script length || [[Protocol_specification#Variable_length_integer|var_int]] || The length of the signature script<br />
|-<br />
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization<br />
|-<br />
| 4 || [http://bitcoin.stackexchange.com/q/2025/323 sequence] || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.<br />
|}<br />
<br />
The OutPoint structure consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 32 || hash || char[32] || The hash of the referenced transaction.<br />
|-<br />
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.<br />
|}<br />
<br />
The Script structure consists of a series of pieces of information and operations related to the value of the transaction.<br />
<br />
(Structure to be expanded in the future… see script.h and script.cpp and [[Script]] for more information)<br />
<br />
The TxOut structure consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 8 || value || int64_t || Transaction Value<br />
|-<br />
| 1+ || pk_script length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the pk_script<br />
|-<br />
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.<br />
|}<br />
<br />
Example ''tx'' message:<br />
<pre><br />
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........<br />
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..<br />
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.<br />
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...<br />
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...<br />
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:<br />
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....<br />
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...<br />
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....<br />
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...<br />
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...<br />
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...<br />
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....<br />
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....<br />
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........<br />
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..<br />
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...<br />
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......<br />
<br />
<br />
Message header:<br />
F9 BE B4 D9 - main network magic bytes<br />
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command<br />
02 01 00 00 - payload is 258 bytes long<br />
E2 93 CD BE - checksum of payload<br />
<br />
Transaction:<br />
01 00 00 00 - version<br />
<br />
Inputs:<br />
01 - number of transaction inputs<br />
<br />
Input 1:<br />
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)<br />
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29<br />
00 00 00 00<br />
<br />
8B - script is 139 bytes long<br />
<br />
48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)<br />
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23<br />
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41<br />
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD<br />
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E<br />
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD<br />
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02<br />
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04<br />
2F 46 61 4A 4C 70 C0 F1 4B EF F5<br />
<br />
FF FF FF FF - sequence<br />
<br />
Outputs:<br />
02 - 2 Output Transactions<br />
<br />
Output 1:<br />
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)<br />
19 - pk_script is 25 bytes long<br />
<br />
76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script<br />
A9 D9 EA 1A FB 22 5E 88 AC<br />
<br />
Output 2:<br />
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)<br />
19 - pk_script is 25 bytes long<br />
<br />
76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script<br />
FD A0 B7 8B 4E CC 52 88 AC<br />
<br />
Locktime:<br />
00 00 00 00 - lock time<br />
</pre><br />
<br />
=== block ===<br />
<br />
The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Block version information, based upon the software version creating this block<br />
|-<br />
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references<br />
|-<br />
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block<br />
|-<br />
| 4 || timestamp || uint32_t || A unix timestamp recording when this block was created (Currently limited to dates before the year 2106!)<br />
|-<br />
| 4 || bits || uint32_t || The calculated [[Difficulty|difficulty target]] being used for this block<br />
|-<br />
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes<br />
|-<br />
| ? || txn_count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of transaction entries<br />
|-<br />
| ? || txns || tx[] || Block transactions, in format of "tx" command<br />
|}<br />
<br />
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.<br />
See [[Block hashing algorithm]] for details and an example.<br />
<br />
=== headers ===<br />
<br />
The ''headers'' packet returns block headers in response to a ''getheaders'' packet. <br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of block headers<br />
|-<br />
| 81x? || headers || [[Protocol_specification#Block_Headers|block_header]][] || [[Protocol_specification#Block_Headers|Block headers]]<br />
|}<br />
<br />
Note that the block headers in this packet include a transaction count (a var_int, so there can be more than 81 bytes per header) as opposed to the block headers which are sent to miners.<br />
<br />
=== getaddr ===<br />
<br />
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.<br />
<br />
No additional data is transmitted with this message.<br />
<br />
=== checkorder ===<br />
<br />
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.<br />
<br />
It contains a CWalletTx object<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
|colspan="4"| Fields from CMerkleTx<br />
|-<br />
| ? || hashBlock<br />
|-<br />
| ? || vMerkleBranch<br />
|-<br />
| ? || nIndex<br />
|-<br />
|colspan="4"| Fields from CWalletTx<br />
|-<br />
| ? || vtxPrev<br />
|-<br />
| ? || mapValue<br />
|-<br />
| ? || vOrderForm<br />
|-<br />
| ? || fTimeReceivedIsTxTime<br />
|-<br />
| ? || nTimeReceived<br />
|-<br />
| ? || fFromMe<br />
|-<br />
| ? || fSpent<br />
|}<br />
<br />
=== submitorder ===<br />
<br />
Confirms an order has been submitted. <br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 32 || hash || char[32] || Hash of the transaction<br />
|-<br />
| ? || wallet_entry || CWalletTx || Same payload as checkorder<br />
|}<br />
<br />
=== reply ===<br />
<br />
Generic reply for [[IP Transactions]]<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || reply || uint32_t || reply code<br />
|}<br />
<br />
Possible values:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')<br />
|-<br />
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed<br />
|-<br />
| 2 || DENIED || IP Transactions are not accepted by this node<br />
|}<br />
<br />
=== ping ===<br />
<br />
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. In modern protocol versions, a ''pong'' response is generated using a nonce included in the ping.<br />
<br />
=== filterload, filteradd, filterclear, merkleblock ===<br />
<br />
These messages are related to Bloom filtering of connections and are defined in [[BIP 0037]].<br />
<br />
=== alert ===<br />
<br />
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.<br />
<br />
Alert format:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || payload || var_str || Serialized alert payload<br />
|-<br />
| ? || signature || var_str || An ECDSA signature of the message<br />
|}<br />
<br />
The developers of Satoshi's client use this public key for signing alerts:<br />
04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284<br />
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s<br />
<br />
The payload is serialized into a var_str to ensure that versions using incompatible alert formats can still relay alerts among one another. The current alert payload format is:<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || Version || int32_t || Alert format version<br />
|-<br />
| 8 || RelayUntil || int64_t || The timestamp beyond which nodes should stop relaying this alert<br />
|-<br />
| 8 || Expiration || int64_t || The timestamp beyond which this alert is no longer in effect and should be ignored<br />
|-<br />
| 4 || ID || int32_t || A unique ID number for this alert<br />
|-<br />
| 4 || Cancel || int32_t || All alerts with an ID number less than or equal to this number should be canceled: deleted and not accepted in the future<br />
|-<br />
| ? || setCancel || set<int> || All alert IDs contained in this set should be canceled as above<br />
|-<br />
| 4 || MinVer || int32_t || This alert only applies to versions greater than or equal to this version. Other versions should still relay it.<br />
|-<br />
| 4 || MaxVer || int32_t || This alert only applies to versions less than or equal to this version. Other versions should still relay it.<br />
|-<br />
| ? || setSubVer || set<string> || If this set contains any elements, then only nodes that have their subVer contained in this set are affected by the alert. Other versions should still relay it.<br />
|-<br />
| 4 || Priority || int32_t || Relative priority compared to other alerts<br />
|-<br />
| ? || Comment || string || A comment on the alert that is not displayed<br />
|-<br />
| ? || StatusBar || string || The alert message that is displayed to the user<br />
|-<br />
| ? || Reserved || string || Reserved<br />
|}<br />
<br />
Sample alert (no message header):<br />
73010000003766404f00000000b305434f00000000f2030000f1030000001027000048ee0000<br />
0064000000004653656520626974636f696e2e6f72672f666562323020696620796f75206861<br />
76652074726f75626c6520636f6e6e656374696e672061667465722032302046656272756172<br />
79004730450221008389df45f0703f39ec8c1cc42c13810ffcae14995bb648340219e353b63b<br />
53eb022009ec65e1c1aaeec1fd334c6b684bde2b3f573060d5b70c3a46723326e4e8a4f1<br />
<br />
Version: 1<br />
RelayUntil: 1329620535<br />
Expiration: 1329792435<br />
ID: 1010<br />
Cancel: 1009<br />
setCancel: <empty><br />
MinVer: 10000<br />
MaxVer: 61000<br />
setSubVer: <empty><br />
Priority: 100<br />
Comment: <empty><br />
StatusBar: "See bitcoin.org/feb20 if you have trouble connecting after 20 February"<br />
Reserved: <empty><br />
<br />
== Scripting ==<br />
<br />
See [[script]].<br />
<br />
== Wireshark dissector ==<br />
A dissector for wireshark is being developed at https://github.com/blueCommand/bitcoin-dissector<br />
<br />
==See Also==<br />
<br />
* [[Network]]<br />
* [[Protocol rules]]<br />
* [[Hardfork Wishlist]]<br />
<br />
==References==<br />
<references /><br />
<br />
[[zh-cn:协议说明]]<br />
[[Category:Technical]]<br />
[[Category:Developer]]</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=User_talk:Raize&diff=38045User talk:Raize2013-05-26T01:58:36Z<p>Giszmo: Created page with "== Welcome == Hi and welcome to the bitcoin wiki. You can sign and timestamp your comments using ~. *1 ~ *2 ~~ *3 ~~~ *4 ~~~~ Regards, --~~~~"</p>
<hr />
<div>== Welcome ==<br />
Hi and welcome to the bitcoin wiki. You can sign and timestamp your comments using ~.<br />
*1 ~<br />
*2 ~~<br />
*3 [[User:Giszmo|Giszmo]] ([[User talk:Giszmo|talk]])<br />
*4 [[User:Giszmo|Giszmo]] ([[User talk:Giszmo|talk]]) 01:58, 26 May 2013 (GMT)<br />
Regards,<br />
<br />
--[[User:Giszmo|Giszmo]] ([[User talk:Giszmo|talk]]) 01:58, 26 May 2013 (GMT)</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Talk:Tonal_Bitcoin&diff=38044Talk:Tonal Bitcoin2013-05-26T01:48:34Z<p>Giszmo: </p>
<hr />
<div>This is for discussion, not trolling. Note that this is not an encyclopedia, and does not have any "notability" requirements. If you don't want to use Tonal, don't. Trolling is not acceptable and will be deleted. Reasoned criticism is welcome in the "Criticism" section of the page.<br />
<br />
<br />
I have no legitimate stake in the matter, I made a few edits that I hope remove POV and still embrace the idea of Tonal Bitcoin. This is Raize, I am sorry I am not familiar enough with wiki editing to provide my signature. --[[User:Raize|Raize]]<br />
<br />
This page should be deleted until there is a working, supported, maintained Tonal Bitcoin client. Vaporware doesn't belong on this wiki, you'll get articles on CosbyCoin and UnicornCoin...<br />
[[User:Gavinandresen|Gavin Andresen]] ([[User talk:Gavinandresen|talk]]) 23:28, 25 May 2013 (GMT)<br />
:Oh, a new player entered the arena in Luke's religious war :) The heavyweigh champion Gavin Andresen! I'm impressed! --[[User:Giszmo|Giszmo]] ([[User talk:Giszmo|talk]]) 01:48, 26 May 2013 (GMT)</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Talk:Trade&diff=36597Talk:Trade2013-04-02T20:04:00Z<p>Giszmo: /* one page per "thing" with categories */ new section</p>
<hr />
<div>==Proposed Listing Standards==<br />
I propose the following standards be required for listing on the [Trade]. The listed site must<br />
# Be currently functional (downtime of less than 48 hours is acceptable)<br />
# Be currently accepting bitcoins<br />
# Have clear instructions for paying with bitcoins from the link given<br />
# Prices must be sane within an order of magnitude (non-sane prices indicate that the website has not been updated to match bitcoin deflation)<br />
The standards will help keep the list manageable and easy to use.<br />
<br />
<br />
This is a talk page, so please sign your contributions. I mostly agree, but the "sane prices" criterion seems a bit subjective ; there is a risk that we exclude goodwilling merchants, who would otherwise be willing to update their prices when contacted. [[User:ThomasV|ThomasV]] 10:43, 12 February 2011 (GMT)<br />
<br />
:Here is an example [http://bitcoin2cash.com/]. When I say "sane", I mean reasonable within an order of magnitude. I moved your other comment to a separate section for clarity [[User:Ptd|Ptd]] 12:59, 13 February 2011 (GMT)<br />
<br />
Sounds reasonable. --[[User:Sirius|Sirius]] 07:09, 23 February 2011 (GMT)<br />
Reasonable. What about defining a practice for ordering the list of sites? I've got one to add, so I'll just tack it at the bottom, but it's going to be an ugly list after awhile. Alphabetical? Chronologically ordered by add date?<br />
[[User:JulianTosh|JulianTosh]] 00:19, 10 May 2011 (GMT)<br />
<br />
I'd say somewhat unreasonable regarding the clear instructions. A lot of my customers are the types who would get confused if I listed my native currency and Bitcoin side by side. I want to offer Bitcoin for Bitcoin users, but not at the risk of confusing other potential customers and potentially losing sales as a result. As such, I make it possible for customers to switch to using Bitcoin during the checkout process. [[User:Orbixx|Orbixx]] 18:39, 02 June 2011 (GMT)<br />
<br />
Every link that does not go to a page that CLEARLY states they are accepting bitcoins should be removed. Try to go to the website Orbixx has added again, there is simply no way to check they accept bitcoins, and I believe they don't actually. I couldn't figure it out. So I think the rules should be that if the link does NOT arrive at a page that says the site is accepting bitcoins, it should be removed. Orbixx, companies can just create a separate page for it, and you link to that page, not simply to your homepage if you think it would be too confusing on the home page.<br />
[[User:Berend|Berend]] 21:21, 2 June 2011 (GMT)<br />
<br />
On Exoware.net payment methods are not stated at all until the checkout process; this is incredibly common. It should be evident that we accept Bitcoin because we are listed on this page and there should be no need to plaster it all over some landing page or on the site. As for your belief that "they don't actually [accept bitcoins]", you're welcome to try us - we do. The mere fact that you nonchalantly removed our listing in the first place for apparently not accepting Bitcoin without even getting in contact with us in the first place is ridiculous. Then to come on here after I email you with screenshots showing the page where you can change your currency to BTC and say that somehow you still maintain that we do not accept Bitcoin is preposterous. Do not remove any listings without first solidly verifying your inadequate assumptions. [[User:Orbixx|Orbixx]] 04:01, 03 June 2011 (GMT)<br />
<br />
It's not unreasonable to expect a merchant to have a bitcoin logo among the mastercard, visa, paypal, google checkout, etc. buttons that clutter a corner of nearly every website that takes money. If they accept bitcoin, they should add a bitcoin logo there. if they take money, they should have a section that fits the description. it's that simple. no reason not to be able to tell at a glance. [[User:aarcane|aarcane]] 04:54, 03 June 2011 (UTC)<br />
<br />
I suggest we vote on this. Vendors who have hidden the fact they accept bitcoin extremely well (try finding it on Orbixx's site) do not deserve to be listed here. We could create a separate page for them (i.e. unverifiable entries). [[User:Berend|Berend]] 22:24, 11 August 2011 (GMT)<br />
<br />
I agree that a site that accepts bitcoin must Clearly Say So on any page that mentions payment options, and their front/landing page. Any site that does not say so Up Front, should not be listed as Accepting Bitcoin. How do you verify that they accept bitcoin until you've already selected a product/service, and gone to the checkout page, and Finally see an option for using Bitcoin? This is a ridiculous thing to do. If I only have a Mastercard, and I'm on a site that only accepts Visa, I'd be pretty upset to not find that out until I'm already at the checkout page!! Every site I have EVER used to purchase Anything online says, Up Front, what kinds of payment methods they accept. No confusion. [[User:Krepta3000|Krepta3000]] 17:47, 25 August 2011 (MST) <br />
<br />
==Should we put addresses on the wiki?==<br />
We just had some bitcoin address spam. perhaps it would not have happened if we did not put bitcoin addresses on the wiki ? [[User:ThomasV|ThomasV]] 23:50, 12 February 2011 (GMT)<br />
: Page is now semi-protected. [[User:MagicalTux|MagicalTux]] 08:28, 16 February 2011 (GMT)<br />
<br />
Yea i suggest not to put the bitcoin addresses of donation-accepting orgs on the wiki. this opens it up to vandalism in hopes of getting misdirected bitcoins. just link to the relevant webpage of the donation-accepting organization, and that's all. that way also we don't have to worry about the addresses changing.--[[User:Nanotube|Nanotube]] 04:41, 24 February 2011 (GMT)<br />
<br />
==Hide Contents of Adult?==<br />
Should the contents of Adult be displayed by default, or might it be reasonable to expect that to be a hidden that requires an action for the contents of the category to be rendered? - [[User:sgornick]] 06:22, 23 February 2011 (GMT)<br />
<br />
Should be hidden or moved to another page. --[[User:Sirius|Sirius]] 07:05, 23 February 2011 (GMT)<br />
<br />
I'm all for censoring it as much as the community will tolerate. --[[User:Luke-jr|Luke-jr]] 13:27, 23 February 2011 (GMT)<br />
<br />
Why hide adult section? They are just links to sites, and section is clearly labeled "Adult". What's the big idea on the censorship? --[[User:Nanotube|Nanotube]] 04:39, 24 February 2011 (GMT)<br />
<br />
I suggest do not censor or hide. Consider for example genjix's calm reference to drugs in his presentation. Should he have been afraid and contemplative of censoring or preventing from communicating such things? Such is a kind of debate generally influenced by religi*** motivations. See [[Trade_R]] for adult content [[User:Mizerydearia|Mizerydearia]] 15:04, 27 April 2011 (GMT)<br />
<br />
Against censorship of site links. They should simply be labeled as adult oriented and the vagues possible genre references.<br />
[[User:JulianTosh|JulianTosh]] 00:21, 10 May 2011 (GMT)<br />
<br />
The problem with listing every site together with adults sites is that automatic scanning software might label your business in the same group. You don't want that to happen, else your legitimate businesses will very quickly disappear from this page<br />
[[User:Berend|Berend]] 21:18, 2 June 2011 (GMT)<br />
<br />
The header for the page claims 'Products or services illegal in US or Japan are not fit to be listed here - such links will be removed immediately. Any attempt to get those links up again will result in the account being blocked. This includes pornography and many mind-altering drugs'. As pornography is not actually illegal in Japan or in the US, it should be clarified whether the restriction is the result of an editor attempting to enforce their ideology, a requirement that all porn comply with Japanese censorship regulations (i.e. mosaic over certain body parts - which I suspect fairly few bitcoin-accepting sites actually comply with), or an administrative decision whose force stems from private property rights rather than from .us/.jp law. [[User:Deekoo|Deekoo]] 05:54, 15 August 2011 (GMT)<br />
<br />
== Drugs Section Empty ==<br />
<br />
The "psychoactives" section appears to consist entirely of dead links. [[User:Ironwolf|Ironwolf]] 03:54, 28 March 2011 (GMT)<br />
<br />
I deleted the Drugs section, since Bitcoin is still far too vulnerable to government actions against it -- there are many single points of failure. The most glaring to me is the DNS system -- the bitcoin.org domain could be taken down if the US government wishes to.<br />
<br />
:This is a terrible decision. My company was removed because of this decision, and it disgusts me. Not all drugs are illegal. My company operates a physical storefront in the US. We ONLY sell drugs that you can buy at the supermarket down the road. Just because it is a "drug" or "psychoactive" doesn't mean that the government is trying to shut it down. Nicotine is a drug, aspirin is a drug, alcohol is a drug. Lotus petals are psychoactive, and so is chamomile and kava - but you can go into Walmart or Walgreens/CVS and buy them. These are the only drugs for sale. Stop freaking out about it. People have swept our business off this list twice because of this ridiculous mindset. We're a hippy art store - not a head shop or drug market. --[[User:Metagnosis|Metagnosis]] 17:59, 22 June 2011 (GMT)<br />
<br />
I apologize to those merchants who may not get as many customers now, but really, it's probably better this way. Anyone who needs to can get a connection by asking around, I'm sure. My goal is only to reduce the "criminal" perception of Bitcoin. [[User:AaronM|AaronM]] 01:18, 27 April 2011 (GMT)<br />
<br />
We want a payment medium that resists the authority of the state. That is going to be "criminal". The real fix is providing adequate fallbacks and replacements for single points of failure [[User:STH|STH]] 01:04, 20 November 2011 (GMT)<br />
<br />
== What is a Notable Website ==<br />
<br />
I started accepting bitcoin at http://la.indymedia.org and a couple other sites on the slaptech.net site. What's the standard for adding this to the list of sites? [[User:Johnk|Johnk]] 16:30, 17 April 2011 (GMT)<br />
:Just go for it. Even MezeGrill has no verifiable info on their business accepting BTC. We need some level of organisation to sort things out and it is good practice to give all necessary information that makes it easy for others to verify your information but for now if you have an actual business that's better than the worst of those listed here already.<br />
:--[[User:Giszmo|Giszmo]] 13:24, 28 September 2011 (GMT)<br />
<br />
== New section for services that are not considered "Professional services"? ==<br />
<br />
I'm wondering whether it might be advisable to add a section for services that are not really "professional services" as that term is ordinarily used in vernacular English. <br />
<br />
For example, I just added a dump-truck haulage service to ''Professional services/Other''; but dump truck haulage is not generally considered a professional service. Ought we to consider adding a new section to the page? [[User:1ECVX6EAk53VER2NH5NKharUUGpfw8iUP6|1ECVX6EAk53VER2NH5NKharUUGpfw8iUP6]] 01:49, 4 May 2011 (GMT)<br />
<br />
:i'm a massage therapist wanting to trade bitcoin for massage. what section do i put my services in?<br />
:[[User:zenbunny|zenbunny]] 20:52, 25 May 2011 (GMT)<br />
<br />
== donation accepting organizations ==<br />
<br />
perhaps a separate page should be created for them ?<br />
I guess donations do not belong to "trade".<br />
[[User:ThomasV|ThomasV]] 23:17, 5 May 2011 (GMT)<br />
<br />
:Definitely. It's a bit sad that there is no place to list all Bitcoin-accepted organizations, particularly smaller non-profit ones since they don't sell anything and the organizations page has a notability requirement. I'll create one if no one objects and/or does it before me. [[User:Blues|Blues]] 20:36, 25 May 2011 (GMT)<br />
<br />
I've added RYT (Roll Your Tasks) under 'Productivity' again (has been deleted by user Luke-jr, probably because there is no force to pay for this service). Donations are accepted, but I'm not an organization of any kind. Moreover RYT is an app for enhancing productivity without political or similar intent, beside that I want to give others the opportunity to use it. I think it's good to also give non- or part-commercial efforts a chance to be listed here. If someone wants to have some specific (RYT) improvements, feel free to suggest a deal...<br />
<br />
Listing criteria above are fullfilled:<br />
Be currently functional (downtime of less than 48 hours is acceptable) -> fullfilled.<br />
Be currently accepting bitcoins -> Yes.<br />
Have clear instructions for paying with bitcoins from the link given -> Yes (bitcoin address).<br />
Prices must be sane within an order of magnitude (non-sane prices indicate that the website has not been updated to match bitcoin deflation) -> Very sane (free, if you don't want to donate).<br />
[[User:Hartrock|Hartrock]] 03:57, 25 September 2011 (GMT)<br />
<br />
== Alternative listings for bitcoin-related directory and merchant sites ==<br />
<br />
Because this wiki is censored and not allowing of certain contents or sites, I have set up http://bitcoinsites.witcoin.com/ to allow for all bitcoin-related sites to be posted. Feel free to also use this medium for commenting and reviewing sites as well. [[User:Mizerydearia|Mizerydearia]] 05:28, 25 May 2011 (GMT)<br />
<br />
* Since witcoin.com is subject to US and/or Canada law, I would expect it to be censored as well eventually. But perhaps not a bad idea to make an alternative site for the ratings/reviews idea anyway... I won't use it if it's based on witcoin though, since they require paying to comment/rate... --[[User:Luke-jr|Luke-jr]] 18:27, 25 May 2011 (GMT)<br />
<br />
Witcoin still down [[User:STH|STH]] 00:58, 20 November 2011 (GMT)<br />
<br />
[http://payco.in payco.in : bitcoin currency directory] - I've started a links list of my own (I admit I wanted to get my own site, [http://lorna-morgan.com Lorna Morgan], listed somewhere I wouldn't be removed!) I didn't like the design of witcoin ... and Bitcookies seems to be down at the moment. --[[User:Lorna Morgan|Lorna Morgan]] 05:36, 28 July 2011 (GMT)<br />
<br />
payco.in still up [[User:STH|STH]] 00:58, 20 November 2011 (GMT)<br />
<br />
<br />
[http://bitcookies.com Bitcookies] - A community resource to list businesses, events, and classifieds that are related to Bitcoin. The server is privately owned and therefore not subject to any controlling interests. The site does not, nor will it ever have censorship in terms of the types of businesses/traders/websites listed. The site is free to all community members and was developed with funds from my mining operations. [[User:Miner249er|Miner24934]] 16:25, 27 May 2011 (GMT)<br />
<br />
Bitcookies still down [[User:STH|STH]] 00:56, 20 November 2011 (GMT)<br />
<br />
== Bloomberg Esque Data Suite: Compiling Transaction info from merchants to measure demand ==<br />
<br />
I am included on the list of many who are very interested in seeing bitcoin succeed and want to be a part of that success, but there is one serious uncertainity that is keeping me from getting in: are people actually using their coins for more than just buying drugs and slim jims, and is all of the buying concentrated in one website or product and one consumer demographic? Demand for the coins is necessary for their success. This can be determined by consumption rates and habits. I have perused the website listing, but still feel that information is lacking. <br />
<br />
It would be nice to see an economic indicator that acquires data from merchants (and compensates them in bitcoin for their effort) on the dollar value (and perhaps sector) of the bitcoin transactions. We could then weigh a derivative of total dollar amount and number of transactions against the number of bitcoins mined to get a better understanding of the economic health of the currency.<br />
<br />
== Require description of changes ==<br />
<br />
It's impossible to read this pages's history, because most people seem to forget to:<br />
- use the "description" line when committing a change<br />
- use the "preview" button, and do several changes in a row just because they forgot the label on a link<br />
<br />
The first point is the most important, because of changes like [https://en.bitcoin.it/w/index.php?title=Trade&diff=prev&oldid=11246 that one], that suppresses and adds random links without even explaining why. Such changes should be immediately reverted, by policy. On the technical side, one small improvement could be to require the "description" field to be non-empty. People could still write random characters, but that would still be a different action. --[[User:Davux|Davux]] 23:15, 22 June 2011 (GMT)<br />
<br />
== Huge chunk of deletions reverted ==<br />
<br />
Hi,<br />
<br />
I've tracked down a huge set of deletions wich was probably done in error, [https://en.bitcoin.it/w/index.php?title=Trade&diff=next&oldid=11252 see link]. I've reverted each deletion individually because otherwise, new entries would have been deleted.<br />
<br />
It's probably necessary to watch out for that. --[[User:Joise|Joise]] 18:55, 29 June 2011 (GMT)<br />
<br />
== Vetting ==<br />
<br />
I realise this is probably a difficult issue &mdash; we don't realistically have the time or work to vet all listed sites &mdash; but should ones which are clearly scams be removed from the wiki page, or should each be discussed first before deletion (perhaps, by moderator staff)?<br />
<br />
For example: <blockquote>[https://sites.google.com/site/wwjdtd/ Time Warp interactive], is a fiction/nonfiction mmorpg that is in alpha and is selling the game only through bitcoins</blockquote>This, to me, is clearly a scam. Going through their Google Sites website (which is the new GeoCities), it becomes clear very quickly that this is not a product that it pretends to be, and is instead just some fly by night website setup by a couple of teenagers in hopes of some free cash from unsuspecting visitors.<br />
<br />
I doubt anybody would actually send any BTC their way anyway, but in my opinion having hoaxes like this damages the credibility and trustworthy of Bitcoin accepting merchants as a whole.<br />
<br />
Could we come up with some way of pruning false merchants like this?<br />
<br />
::I think that links which are very clearly scam should not be promoted. However I see two difficulties:<br />
::# It might be hard to see whether something is simply a low budget project or not serious. <br />
::# What is reputable and what not certainly will vary widely. If you want to promote a bank, I'd likely want another neighborhood than if you just try to sell psychodelically designed pizza containing extremely high concentrations of capsain.<br />
::# The more profound issue is that the not-to-reputable looking enterprises might be exactly the ones which bring the stongest kicks to innovation. I am thinking in the term "garage firm". And obviously grandparents will tell the kids some day that the whole bitcoin economy started with alpaca socks, online poker and fancy glass beads.<br />
<br />
::My proposal: Create a playground / dockland / bitcoinpunk section which can collect the fringe of the fringe. And let largely visitors decide what they are going to trust. --[[User:Joise|Joise]] 19:21, 4 July 2011 (GMT)<br />
<br />
== proposal ==<br />
<br />
Separated pages for trading, bitcoin accepting online stores, games, free coins etc.<br />
<br />
== Major clean-up ==<br />
Mediawiki has a perfect way to deal with collections. That's '''categories'''. It also has great tools to get a consistent look. That's '''templates'''.<br />
This cluttered list of non-verifiable (every child here knows [http://www.mezegrill.com/ meze grill] accepts bitcoins but there is no word indicating this is true if you follow the link), outdated (o-crep is on this list but the [http://o-crepes.com/bitcoin/# link] leads you to a one time offer) or even scam. Often there is not even a link to brick and mortar businesses but only a street address.<br />
<br />
I suggest everybody who wants to promote his business here makes a small [[myBitcoinBusiness site]] for it and makes strong use of categories and templates.<br />
--[[User:Giszmo|Giszmo]] 13:24, 28 September 2011 (GMT)<br />
:I'd like to bump this suggestion. Are there any objections to creating a separate page for every Business and put it into all relevant categories? --[[User:Giszmo|Giszmo]] ([[User talk:Giszmo|talk]]) 05:21, 26 August 2012 (GMT)<br />
<br />
== Please add us www.fnib.co ==<br />
<br />
First National Innovation Brokers has been accepting btc to fund forex and gold trading accounts since June, 2011.<br />
www.fnib.co Please add us on the Trade list and help get the word out.<br />
:It's a wiki. Add yourself. Wikipedia rules of no articles about yourself don't apply here. If you take yourself for relevant and others disagree, after an edit-war you might give up or become relevant ;) --[[User:Giszmo|Giszmo]] ([[User talk:Giszmo|talk]]) 05:22, 26 August 2012 (GMT)<br />
<br />
== Is bittit.info appropriate? ==<br />
<br />
bittit.info is a place for users to sell their photos. It's free to use (no fees) and it also has a NSFW section. I wonder if that last thing makes it inappropriate for this wiki. It's not a porn site, almost all the pictures are in the SFW section but I hesitate to add it here. If someone could advice me on that matter I would be grateful. --[[User:Tritonio|Tritonio]] 20:25, 6 November 2011 (GMT)<br />
<br />
== Geographical ==<br />
<br />
Perhaps as a start there should be something to deal with location. <br />
We could have a separate non-geographical section for things like online services and places that post globally. <br />
<br />
A plumber accepting BTC in USA probably isn't much interest to someone in Japan.<br />
<br />
== Duplication ==<br />
<br />
Pages [[Buying bitcoins]] and [[Selling bitcoins]] list exchanges as well. Perhaps separating this information is a good idea (into a page named like "List of Exchanges") to avoid duplication and "overcluttering" of Trade page?<br />
<br />
== Referral Links ==<br />
<br />
I am constantly finding referral links on this page and others. Whenever I see them, I change them back to regular links without the referral code.<br />
<br />
Is there some action we should be taking to block those users who keep adding their referral codes to links?<br />
: Admins can/should block their accounts. We could create a bot to detect these easy to detect links and revert them automatically. I never made a bot but saw many in action. Also I believe the pages should make clear that referral spam will not be tolerated and patrol the referrers and black list certain origins like this wiki for example and exclude those spammers for future referrals. --[[User:Giszmo|Giszmo]] ([[User talk:Giszmo|talk]]) 14:17, 22 July 2012 (GMT)<br />
<br />
== DailyBtc.com ==<br />
<br />
Daily bitcoin lottery paid out every day<br />
<br />
== Wikileaks ==<br />
<br />
Why isn't WikiLeaks listed? Under Political Activism?<br />
<br />
== Coinster Search Engine (no censorship) ==<br />
<br />
[http://coinster.info Coinster.info] has very open listing guidelines.<br />
<br />
== Pharmacy ==<br />
<br />
The listed sites are the same sites that probably send you your daily spam. The India one is listed twice (with different domains) and the Swiss one has no pharmacy license according to their homepage. Listing such sites here is kind of an endorsement and I would prefer not to list those sites here. I don't like censorship, but I don't see any reason to promote them either. --[[User:Http|Http]] ([[User talk:Http|talk]]) 12:52, 1 April 2013 (GMT)<br />
<br />
== one page per "thing" with categories ==<br />
<br />
Mediawiki is exceptionally good at organizing categories. You can use categories for many things. German pirate party even uses categories for an [http://wiki.piratenpartei.de/Kategorie:Benutzer_kann_PGP experts listing] resulting in users being in dozens of categories because the feel like sharing they know french sort of.<br />
I think we should use the same power here to get things sorted a bit. One business, one wiki page, many categories. The category pages can be unedited (they just group the businesses), be categorized themselves or contain general information about what belongs there and what not.<br />
We should use the power of mediawiki! (I know, just do it :( Would be cool if others could do it ;) )<br />
--[[User:Giszmo|Giszmo]] ([[User talk:Giszmo|talk]]) 20:03, 2 April 2013 (GMT)</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Category:History&diff=35831Category:History2013-03-01T01:12:34Z<p>Giszmo: /* 2013 */</p>
<hr />
<div>== Important milestones of the Bitcoin project ==<br />
=== 2008 ===<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | August 18<br />
|| Domain name "bitcoin.org" registered<ref>[https://bitcointalk.org/index.php?topic=103369.msg1135218#msg1135218 According to theymos], Satoshi registered bitcoin.org via https://www.anonymousspeech.com/ which allows to anonymously register domains.</ref>.<br />
|-<br />
! October 31<br />
|| [http://article.gmane.org/gmane.comp.encryption.general/12588/ Bitcoin design paper] published<br />
|-<br />
! November 09<br />
|| Bitcoin project registered at SourceForge.net<br />
|}<br />
<br />
=== 2009 ===<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | January 3<br />
|| [http://www.BlockExplorer.com/b/0 Genesis block] established at 18:15:05 GMT<br />
|-<br />
! January 11<br />
|| Bitcoin v0.1 released and announced on the [http://www.mail-archive.com/cryptography@metzdowd.com/msg10152.html cryptography mailing list]<br />
|-<br />
! January 12<br />
|| First Bitcoin transaction, [http://www.BlockExplorer.com/b/170 in block 170] - from [[Satoshi]] to Hal Finney<ref>[http://bitcointalk.org/index.php?topic=91806.msg1012234#msg1012234 Earliest Block With A Spend]</ref>.<br />
|-<br />
! October 5<br />
|| Exchange rates [http://newlibertystandard.wetpaint.com/page/2009+Exchange+Rate published] by New Liberty Standard. $1 = 1,309.03 BTC (and [[User:theymos|theymos]] thought NLS was overcharging<ref>[http://bitcointalk.org/index.php?topic=104287.msg1143955#msg1143955 Historical Price Data for 2009]</ref>)<br />
|-<br />
! December 16<br />
|| Bitcoin v0.2 released<br />
|-<br />
! December 30<br />
|| First difficulty increase at 06:11:04 GMT<br />
|}<br />
<br />
=== 2010 ===<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | February 6<br />
|| [[Bitcoin Market]] established<br />
|-<br />
! May 21<br />
|| laszlo first to buy pizza with Bitcoins agreeing upon paying 10,000 BTC for ~$25 worth of pizza courtesy of jercos<ref>[https://bitcointalk.org/index.php?topic=137.msg1195#msg1195 bitcointalk post] where laszlo confirmed having bought pizza</ref><br />
|-<br />
! July 7<br />
|| Bitcoin v0.3 released<br />
|-<br />
! July 11<br />
|| Bitcoin v0.3 release mentioned on slashdot<ref>[http://news.slashdot.org/story/10/07/11/1747245/Bitcoin-Releases-Version-03 slashdot] metiones Bitcoin</ref>, bringing a large influx of new bitcoin users.<br />
|-<br />
! July 12<br />
|| Beginning of a 10x increase in exchange value over a 5 day period, from about $0.008/BTC to $0.08/BTC<br />
|-<br />
! July 17<br />
|| [[MtGox]] established<br />
|-<br />
! July 18<br />
|| ArtForz generated his first block after establishing his personal OpenCL GPU hash farm<br />
|-<br />
! August 15<br />
|| 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]]).<br />
|-<br />
! September 14<br />
|| jgarzik [https://bitcointalk.org/index.php?topic=133.msg12921#msg12921 offered] 10,000 BTC (valued at ~$600-650) to puddinpop to open source their windows-based CUDA client<br />
|-<br />
! September 14<br />
|| Block [http://blockexplorer.com/b/79764 79,764] is first to be mined using split allocation of the generation reward.<br />
|-<br />
! September 18<br />
|| puddinpop [https://bitcointalk.org/index.php?topic=133.msg13135#msg13135 released] source to their windows-based CUDA client under MIT license<br />
|-<br />
! September 29<br />
|| kermit [https://bitcointalk.org/index.php?topic=1306.0 discovered] a microtransactions exploit which precipitated the Bitcoin v0.3.13 release<br />
|-<br />
! October 01<br />
|| First public OpenCL miner released<br />
|-<br />
! October 04<br />
|| Original Bitcoin History wiki page (this page) established (ooh so meta) on Bitcoin.org's wiki.<br />
|-<br />
! October 07<br />
|| Exchange rate started climbing up from $0.06/BTC after several flat months.<br />
|-<br />
! October 28<br />
|| 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.<br />
|-<br />
! November 6<br />
|| The [https://bitcointalk.org/index.php?topic=1672 Bitcoin economy passed US $1 million]. The MtGox price touched USD $0.50/BTC.<br />
|-<br />
! December 7<br />
|| 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.<br />
|-<br />
! December 9<br />
|| The generation difficulty passed 10,000.<br />
|-<br />
|<br />
|| First bitcoin call option contract sold, from nanotube to [[User:Sgornick|sgornick]], via the [[Bitcoin-otc|#bitcoin-otc]] market.<br />
|-<br />
! December 16<br />
|| [http://mining.bitcoin.cz/ Bitcoin Pooled Mining], operated by slush, found its first block<br />
|}<br />
<br />
=== 2011 ===<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | January 2<br />
|| [[Tonal Bitcoin]] units standardized.<br />
|-<br />
! January 8<br />
|| [[History of Bitcoin]] page (this page) created after replicating from original Bitcoin History page on Bitcoin.org.<br />
|-<br />
|<br />
|| Bitcoin Pooled Mining reached a total of 10,000 Mhash/s<br />
|-<br />
! January 27<br />
|| 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><br />
|-<br />
! January 28<br />
|| 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.<br />
|-<br />
! February 9<br />
|| Bitcoin reached parity with the US dollar, touching $1 per BTC at [[MtGox]].<br />
|-<br />
! February 10<br />
|| Bitcoin.org website struggles to handle [https://bitcointalk.org/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.<br />
|-<br />
! February 14<br />
|| A vehicle was, for the first time, offered in exchange for a certain number of bitcoins<ref>[https://bitcointalk.org/index.php?topic=3485.0 Car for Sale - Australia]</ref>.<br />
|-<br />
! March 6<br />
|| Total Bitcoin network computation speed for a short time reached a new 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]).<br />
|-<br />
! March 18<br />
|| 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.<br />
|-<br />
! March 25<br />
|| Difficulty decreased nearly 10%. A decrease has only occurred once before, and this decrease of nearly 10% was the largest.<br />
|-<br />
! March 27<br />
|| The first market for exchanging bitcoins to and from the British Pound Sterling BTC/GBP, [[Britcoin]], opens.<br />
|-<br />
! March 31<br />
|| The first market for exchanging bitcoins to and from Brazilian Reals, [[Bitcoin Brazil]], opens.<br />
|-<br />
! April 5<br />
|| The first market for exchanging bitcoins to and from the Polish złoty, [[BitMarket.eu]], opens.<br />
|-<br />
! April 12<br />
|| First bitcoin put option contract sold via the [[Bitcoin-otc|#bitcoin-otc]] market.<br />
|-<br />
! April 16<br />
|| TIME does [http://techland.time.com/2011/04/16/online-cash-bitcoin-could-challenge-governments/ an article on Bitcoin].<br />
|-<br />
! April 23<br />
|| BTC/USD exchange rate reaches and passes parity with the Euro (EUR) on [[MtGox]] exchange.<br />
|-<br />
|<br />
|| BTC/USD exchange rate reaches and passes parity with the British Sterling Pound (GBP) on [[MtGox]] exchange.<br />
|-<br />
|<br />
|| Value of the Bitcoin money stock at current exchange rate passes $10 million USD threshold.<br />
|-<br />
! April 27<br />
|| [[VirWoX]] opens first market to trade bitcoins against a virtual currency on BTC/SL (Second Life Lindens) exchange.<br />
|-<br />
! April 30<br />
|| The generation difficulty passed 100,000.<br />
|-<br />
! June 2<br />
|| The exchange rate at [[MtGox]] touched 10 USD per BTC.<br />
|-<br />
! June 3<br />
|| [[Tonal Bitcoin]] reached parity with the US cent, touching 1¢ per TBC at [[Bitcoin Market]].<br />
|-<br />
! June 8<br />
|| 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].<br />
|-<br />
! June 12<br />
|| The [[MtGox]] exchange rate briefly dropped to near 10 USD four days after the peak, in its largest percentage price retreat to date.<br />
|-<br />
! June 13<br />
|| 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).<br />
|-<br />
! June 19<br />
|| 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.<br />
|-<br />
! June 19<br />
|| 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).<br />
|-<br />
! June 19<br />
|| 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.<br />
|-<br />
! June 20<br />
|| The EFF announced that it was no longer accepting Bitcoin donations due to legal uncertainties.<br />
|-<br />
! June 24<br />
|| The generation difficulty passed 1,000,000 with Block [http://blockexplorer.com/b/133056 133056].<br />
|-<br />
! July 19<br />
|| "Let it go on record that at 4:05pm CET [19 July 2011], my manager Tadek was the first person in the world to receive [testnet] Bitcoins via NFC ;)" - Mike Hearn<br />
|-<br />
! July 22<br />
|| [[BitCoins Mobile]], the first Bitcoin application for iPad was released by [http://www.intervex.net Intervex Digital].<br />
|-<br />
! July 30<br />
|| [http://pastebin.com/raw.php?i=BUB3dygQ Tribute to Len Sassaman] included in the blockchain<ref>[http://bitcointalk.org/index.php?topic=33618.msg420597#msg420597 A Tribute to Len "rabbi" Sassama]</ref>. <br />
|-<br />
! August 20<br />
|| First Bitcoin Conference and World Expo held, in NYC.<ref>[http://bitcoinme.com/index.php/conference/ New York Conference 2011]</ref><br />
|-<br />
! August 23<br />
|| [[P2Pool]], the first P2P decentralized pool, mines its first Bitcoin mainnet block (Block [http://blockexplorer.com/b/142312 142,312]).<br />
|-<br />
! August 30<br />
|| Difficulty adjustment at block [http://blockexplorer.com/b/143136 143,136] marks the first back-to-back drop.<br />
|-<br />
! November 15<br />
|| First CVE (CVE-2011-4447) assigned to a Bitcoin client exploit.<br />
|-<br />
! November 25<br />
|| First European Bitcoin Conference in Prague, Czech Rep.<ref>[http://bitgroups.org/ Prague Conference 2011]</ref><br />
|-<br />
! December 12<br />
|| Largest amount of fees, to-date, in a single transaction, and most fees in a single block. A [http://blockexplorer.com/tx/1d7749c65c90c32f5e2c036217a2574f3f4403da39174626b246eefa620b58d9 transaction] paid 171 BTC in fees in [http://blockexplorer.com/b/157235 block 157235]<ref>[http://bitcointalk.org/index.php?topic=88423.msg973509#msg973509 Largest fee ever?]</ref>.<br />
|}<br />
<br />
=== 2012 ===<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | March 1<br />
|| Largest theft of bitcoins to-date occurred (near 50K BTC) after security breach at web host Linode.<br />
|-<br />
! width="8em" | April 1<br />
|| Pay-to-script-hash ([[P2SH]]) as defined through [[BIP 0016]] goes live.<br />
|-<br />
! May 08<br />
|| A single service, [[SatoshiDICE]] becomes responsible for over half the transaction volume on the Bitcoin blockchain.<br />
|-<br />
! June 3<br />
|| Largest block (most transactions), to-date (June 3), is [http://BlockExplorer.com/b/181919 block 181919] with 1322 transactions<ref>[http://bitcointalk.org/index.php?topic=85353.msg939859#msg939859 Largest block to date]</ref>.<br />
|-<br />
! July 22<br />
|| One millionth topic reply was posted on the unofficial [[Bitcoin Forum]] <ref>[https://bitcointalk.org/index.php?topic=94608.0 Topic about one millionth forum post]</ref>.<br />
|-<br />
! September 15-16<br />
|| Bitcoin Conference in London <ref>[http://bitcoin2012.com/ London Conference 2012]</ref>.<br />
|-<br />
! September 27<br />
|| Formation of the [[Bitcoin Foundation]].<br />
|-<br />
! November 28<br />
|| Halving day. [http://blockexplorer.com/b/210000 Block 210,000] is the first with a block reward subsidy of only 25 BTC.<br />
|-<br />
! December 6<br />
|| First Bitcoin exchange [https://bitcointalk.org/index.php?topic=129461.0 licensed "as a bank" in europe] (actually a PSP which is like a bank, without debt-money issuing).<br />
|}<br />
<br />
=== 2013 ===<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | February 19<br />
|| Bitcoin Client v0.8 released featuring improved download speed and [https://en.wikipedia.org/wiki/Bloom_filter Bloom Filtering]<br />
|-<br />
! February 28<br />
|| The [[MtGox]] exchange rate broke the June 8 2011 peak of 31.91 USD. The first all time high since 601 days<br />
|-<br />
|}<br />
<br />
==See Also==<br />
<br />
* [[Bitcoin Firsts]]<br />
<br />
==References==<br />
<references /></div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Category:History&diff=35830Category:History2013-03-01T01:10:25Z<p>Giszmo: /* 2013 */</p>
<hr />
<div>== Important milestones of the Bitcoin project ==<br />
=== 2008 ===<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | August 18<br />
|| Domain name "bitcoin.org" registered<ref>[https://bitcointalk.org/index.php?topic=103369.msg1135218#msg1135218 According to theymos], Satoshi registered bitcoin.org via https://www.anonymousspeech.com/ which allows to anonymously register domains.</ref>.<br />
|-<br />
! October 31<br />
|| [http://article.gmane.org/gmane.comp.encryption.general/12588/ Bitcoin design paper] published<br />
|-<br />
! November 09<br />
|| Bitcoin project registered at SourceForge.net<br />
|}<br />
<br />
=== 2009 ===<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | January 3<br />
|| [http://www.BlockExplorer.com/b/0 Genesis block] established at 18:15:05 GMT<br />
|-<br />
! January 11<br />
|| Bitcoin v0.1 released and announced on the [http://www.mail-archive.com/cryptography@metzdowd.com/msg10152.html cryptography mailing list]<br />
|-<br />
! January 12<br />
|| First Bitcoin transaction, [http://www.BlockExplorer.com/b/170 in block 170] - from [[Satoshi]] to Hal Finney<ref>[http://bitcointalk.org/index.php?topic=91806.msg1012234#msg1012234 Earliest Block With A Spend]</ref>.<br />
|-<br />
! October 5<br />
|| Exchange rates [http://newlibertystandard.wetpaint.com/page/2009+Exchange+Rate published] by New Liberty Standard. $1 = 1,309.03 BTC (and [[User:theymos|theymos]] thought NLS was overcharging<ref>[http://bitcointalk.org/index.php?topic=104287.msg1143955#msg1143955 Historical Price Data for 2009]</ref>)<br />
|-<br />
! December 16<br />
|| Bitcoin v0.2 released<br />
|-<br />
! December 30<br />
|| First difficulty increase at 06:11:04 GMT<br />
|}<br />
<br />
=== 2010 ===<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | February 6<br />
|| [[Bitcoin Market]] established<br />
|-<br />
! May 21<br />
|| laszlo first to buy pizza with Bitcoins agreeing upon paying 10,000 BTC for ~$25 worth of pizza courtesy of jercos<ref>[https://bitcointalk.org/index.php?topic=137.msg1195#msg1195 bitcointalk post] where laszlo confirmed having bought pizza</ref><br />
|-<br />
! July 7<br />
|| Bitcoin v0.3 released<br />
|-<br />
! July 11<br />
|| Bitcoin v0.3 release mentioned on slashdot<ref>[http://news.slashdot.org/story/10/07/11/1747245/Bitcoin-Releases-Version-03 slashdot] metiones Bitcoin</ref>, bringing a large influx of new bitcoin users.<br />
|-<br />
! July 12<br />
|| Beginning of a 10x increase in exchange value over a 5 day period, from about $0.008/BTC to $0.08/BTC<br />
|-<br />
! July 17<br />
|| [[MtGox]] established<br />
|-<br />
! July 18<br />
|| ArtForz generated his first block after establishing his personal OpenCL GPU hash farm<br />
|-<br />
! August 15<br />
|| 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]]).<br />
|-<br />
! September 14<br />
|| jgarzik [https://bitcointalk.org/index.php?topic=133.msg12921#msg12921 offered] 10,000 BTC (valued at ~$600-650) to puddinpop to open source their windows-based CUDA client<br />
|-<br />
! September 14<br />
|| Block [http://blockexplorer.com/b/79764 79,764] is first to be mined using split allocation of the generation reward.<br />
|-<br />
! September 18<br />
|| puddinpop [https://bitcointalk.org/index.php?topic=133.msg13135#msg13135 released] source to their windows-based CUDA client under MIT license<br />
|-<br />
! September 29<br />
|| kermit [https://bitcointalk.org/index.php?topic=1306.0 discovered] a microtransactions exploit which precipitated the Bitcoin v0.3.13 release<br />
|-<br />
! October 01<br />
|| First public OpenCL miner released<br />
|-<br />
! October 04<br />
|| Original Bitcoin History wiki page (this page) established (ooh so meta) on Bitcoin.org's wiki.<br />
|-<br />
! October 07<br />
|| Exchange rate started climbing up from $0.06/BTC after several flat months.<br />
|-<br />
! October 28<br />
|| 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.<br />
|-<br />
! November 6<br />
|| The [https://bitcointalk.org/index.php?topic=1672 Bitcoin economy passed US $1 million]. The MtGox price touched USD $0.50/BTC.<br />
|-<br />
! December 7<br />
|| 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.<br />
|-<br />
! December 9<br />
|| The generation difficulty passed 10,000.<br />
|-<br />
|<br />
|| First bitcoin call option contract sold, from nanotube to [[User:Sgornick|sgornick]], via the [[Bitcoin-otc|#bitcoin-otc]] market.<br />
|-<br />
! December 16<br />
|| [http://mining.bitcoin.cz/ Bitcoin Pooled Mining], operated by slush, found its first block<br />
|}<br />
<br />
=== 2011 ===<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | January 2<br />
|| [[Tonal Bitcoin]] units standardized.<br />
|-<br />
! January 8<br />
|| [[History of Bitcoin]] page (this page) created after replicating from original Bitcoin History page on Bitcoin.org.<br />
|-<br />
|<br />
|| Bitcoin Pooled Mining reached a total of 10,000 Mhash/s<br />
|-<br />
! January 27<br />
|| 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><br />
|-<br />
! January 28<br />
|| 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.<br />
|-<br />
! February 9<br />
|| Bitcoin reached parity with the US dollar, touching $1 per BTC at [[MtGox]].<br />
|-<br />
! February 10<br />
|| Bitcoin.org website struggles to handle [https://bitcointalk.org/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.<br />
|-<br />
! February 14<br />
|| A vehicle was, for the first time, offered in exchange for a certain number of bitcoins<ref>[https://bitcointalk.org/index.php?topic=3485.0 Car for Sale - Australia]</ref>.<br />
|-<br />
! March 6<br />
|| Total Bitcoin network computation speed for a short time reached a new 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]).<br />
|-<br />
! March 18<br />
|| 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.<br />
|-<br />
! March 25<br />
|| Difficulty decreased nearly 10%. A decrease has only occurred once before, and this decrease of nearly 10% was the largest.<br />
|-<br />
! March 27<br />
|| The first market for exchanging bitcoins to and from the British Pound Sterling BTC/GBP, [[Britcoin]], opens.<br />
|-<br />
! March 31<br />
|| The first market for exchanging bitcoins to and from Brazilian Reals, [[Bitcoin Brazil]], opens.<br />
|-<br />
! April 5<br />
|| The first market for exchanging bitcoins to and from the Polish złoty, [[BitMarket.eu]], opens.<br />
|-<br />
! April 12<br />
|| First bitcoin put option contract sold via the [[Bitcoin-otc|#bitcoin-otc]] market.<br />
|-<br />
! April 16<br />
|| TIME does [http://techland.time.com/2011/04/16/online-cash-bitcoin-could-challenge-governments/ an article on Bitcoin].<br />
|-<br />
! April 23<br />
|| BTC/USD exchange rate reaches and passes parity with the Euro (EUR) on [[MtGox]] exchange.<br />
|-<br />
|<br />
|| BTC/USD exchange rate reaches and passes parity with the British Sterling Pound (GBP) on [[MtGox]] exchange.<br />
|-<br />
|<br />
|| Value of the Bitcoin money stock at current exchange rate passes $10 million USD threshold.<br />
|-<br />
! April 27<br />
|| [[VirWoX]] opens first market to trade bitcoins against a virtual currency on BTC/SL (Second Life Lindens) exchange.<br />
|-<br />
! April 30<br />
|| The generation difficulty passed 100,000.<br />
|-<br />
! June 2<br />
|| The exchange rate at [[MtGox]] touched 10 USD per BTC.<br />
|-<br />
! June 3<br />
|| [[Tonal Bitcoin]] reached parity with the US cent, touching 1¢ per TBC at [[Bitcoin Market]].<br />
|-<br />
! June 8<br />
|| 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].<br />
|-<br />
! June 12<br />
|| The [[MtGox]] exchange rate briefly dropped to near 10 USD four days after the peak, in its largest percentage price retreat to date.<br />
|-<br />
! June 13<br />
|| 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).<br />
|-<br />
! June 19<br />
|| 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.<br />
|-<br />
! June 19<br />
|| 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).<br />
|-<br />
! June 19<br />
|| 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.<br />
|-<br />
! June 20<br />
|| The EFF announced that it was no longer accepting Bitcoin donations due to legal uncertainties.<br />
|-<br />
! June 24<br />
|| The generation difficulty passed 1,000,000 with Block [http://blockexplorer.com/b/133056 133056].<br />
|-<br />
! July 19<br />
|| "Let it go on record that at 4:05pm CET [19 July 2011], my manager Tadek was the first person in the world to receive [testnet] Bitcoins via NFC ;)" - Mike Hearn<br />
|-<br />
! July 22<br />
|| [[BitCoins Mobile]], the first Bitcoin application for iPad was released by [http://www.intervex.net Intervex Digital].<br />
|-<br />
! July 30<br />
|| [http://pastebin.com/raw.php?i=BUB3dygQ Tribute to Len Sassaman] included in the blockchain<ref>[http://bitcointalk.org/index.php?topic=33618.msg420597#msg420597 A Tribute to Len "rabbi" Sassama]</ref>. <br />
|-<br />
! August 20<br />
|| First Bitcoin Conference and World Expo held, in NYC.<ref>[http://bitcoinme.com/index.php/conference/ New York Conference 2011]</ref><br />
|-<br />
! August 23<br />
|| [[P2Pool]], the first P2P decentralized pool, mines its first Bitcoin mainnet block (Block [http://blockexplorer.com/b/142312 142,312]).<br />
|-<br />
! August 30<br />
|| Difficulty adjustment at block [http://blockexplorer.com/b/143136 143,136] marks the first back-to-back drop.<br />
|-<br />
! November 15<br />
|| First CVE (CVE-2011-4447) assigned to a Bitcoin client exploit.<br />
|-<br />
! November 25<br />
|| First European Bitcoin Conference in Prague, Czech Rep.<ref>[http://bitgroups.org/ Prague Conference 2011]</ref><br />
|-<br />
! December 12<br />
|| Largest amount of fees, to-date, in a single transaction, and most fees in a single block. A [http://blockexplorer.com/tx/1d7749c65c90c32f5e2c036217a2574f3f4403da39174626b246eefa620b58d9 transaction] paid 171 BTC in fees in [http://blockexplorer.com/b/157235 block 157235]<ref>[http://bitcointalk.org/index.php?topic=88423.msg973509#msg973509 Largest fee ever?]</ref>.<br />
|}<br />
<br />
=== 2012 ===<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | March 1<br />
|| Largest theft of bitcoins to-date occurred (near 50K BTC) after security breach at web host Linode.<br />
|-<br />
! width="8em" | April 1<br />
|| Pay-to-script-hash ([[P2SH]]) as defined through [[BIP 0016]] goes live.<br />
|-<br />
! May 08<br />
|| A single service, [[SatoshiDICE]] becomes responsible for over half the transaction volume on the Bitcoin blockchain.<br />
|-<br />
! June 3<br />
|| Largest block (most transactions), to-date (June 3), is [http://BlockExplorer.com/b/181919 block 181919] with 1322 transactions<ref>[http://bitcointalk.org/index.php?topic=85353.msg939859#msg939859 Largest block to date]</ref>.<br />
|-<br />
! July 22<br />
|| One millionth topic reply was posted on the unofficial [[Bitcoin Forum]] <ref>[https://bitcointalk.org/index.php?topic=94608.0 Topic about one millionth forum post]</ref>.<br />
|-<br />
! September 15-16<br />
|| Bitcoin Conference in London <ref>[http://bitcoin2012.com/ London Conference 2012]</ref>.<br />
|-<br />
! September 27<br />
|| Formation of the [[Bitcoin Foundation]].<br />
|-<br />
! November 28<br />
|| Halving day. [http://blockexplorer.com/b/210000 Block 210,000] is the first with a block reward subsidy of only 25 BTC.<br />
|-<br />
! December 6<br />
|| First Bitcoin exchange [https://bitcointalk.org/index.php?topic=129461.0 licensed "as a bank" in europe] (actually a PSP which is like a bank, without debt-money issuing).<br />
|}<br />
<br />
=== 2013 ===<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | February 19<br />
|| Bitcoin Client v0.8 (w/faster blockchain download) released<br />
|-<br />
! February 28<br />
|| The [[MtGox]] exchange rate broke the June 8 2011 peak of 31.91 USD. The first all time high since 601 days<br />
|-<br />
|}<br />
<br />
==See Also==<br />
<br />
* [[Bitcoin Firsts]]<br />
<br />
==References==<br />
<references /></div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Category:History&diff=35829Category:History2013-03-01T01:09:28Z<p>Giszmo: /* 2013 */</p>
<hr />
<div>== Important milestones of the Bitcoin project ==<br />
=== 2008 ===<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | August 18<br />
|| Domain name "bitcoin.org" registered<ref>[https://bitcointalk.org/index.php?topic=103369.msg1135218#msg1135218 According to theymos], Satoshi registered bitcoin.org via https://www.anonymousspeech.com/ which allows to anonymously register domains.</ref>.<br />
|-<br />
! October 31<br />
|| [http://article.gmane.org/gmane.comp.encryption.general/12588/ Bitcoin design paper] published<br />
|-<br />
! November 09<br />
|| Bitcoin project registered at SourceForge.net<br />
|}<br />
<br />
=== 2009 ===<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | January 3<br />
|| [http://www.BlockExplorer.com/b/0 Genesis block] established at 18:15:05 GMT<br />
|-<br />
! January 11<br />
|| Bitcoin v0.1 released and announced on the [http://www.mail-archive.com/cryptography@metzdowd.com/msg10152.html cryptography mailing list]<br />
|-<br />
! January 12<br />
|| First Bitcoin transaction, [http://www.BlockExplorer.com/b/170 in block 170] - from [[Satoshi]] to Hal Finney<ref>[http://bitcointalk.org/index.php?topic=91806.msg1012234#msg1012234 Earliest Block With A Spend]</ref>.<br />
|-<br />
! October 5<br />
|| Exchange rates [http://newlibertystandard.wetpaint.com/page/2009+Exchange+Rate published] by New Liberty Standard. $1 = 1,309.03 BTC (and [[User:theymos|theymos]] thought NLS was overcharging<ref>[http://bitcointalk.org/index.php?topic=104287.msg1143955#msg1143955 Historical Price Data for 2009]</ref>)<br />
|-<br />
! December 16<br />
|| Bitcoin v0.2 released<br />
|-<br />
! December 30<br />
|| First difficulty increase at 06:11:04 GMT<br />
|}<br />
<br />
=== 2010 ===<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | February 6<br />
|| [[Bitcoin Market]] established<br />
|-<br />
! May 21<br />
|| laszlo first to buy pizza with Bitcoins agreeing upon paying 10,000 BTC for ~$25 worth of pizza courtesy of jercos<ref>[https://bitcointalk.org/index.php?topic=137.msg1195#msg1195 bitcointalk post] where laszlo confirmed having bought pizza</ref><br />
|-<br />
! July 7<br />
|| Bitcoin v0.3 released<br />
|-<br />
! July 11<br />
|| Bitcoin v0.3 release mentioned on slashdot<ref>[http://news.slashdot.org/story/10/07/11/1747245/Bitcoin-Releases-Version-03 slashdot] metiones Bitcoin</ref>, bringing a large influx of new bitcoin users.<br />
|-<br />
! July 12<br />
|| Beginning of a 10x increase in exchange value over a 5 day period, from about $0.008/BTC to $0.08/BTC<br />
|-<br />
! July 17<br />
|| [[MtGox]] established<br />
|-<br />
! July 18<br />
|| ArtForz generated his first block after establishing his personal OpenCL GPU hash farm<br />
|-<br />
! August 15<br />
|| 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]]).<br />
|-<br />
! September 14<br />
|| jgarzik [https://bitcointalk.org/index.php?topic=133.msg12921#msg12921 offered] 10,000 BTC (valued at ~$600-650) to puddinpop to open source their windows-based CUDA client<br />
|-<br />
! September 14<br />
|| Block [http://blockexplorer.com/b/79764 79,764] is first to be mined using split allocation of the generation reward.<br />
|-<br />
! September 18<br />
|| puddinpop [https://bitcointalk.org/index.php?topic=133.msg13135#msg13135 released] source to their windows-based CUDA client under MIT license<br />
|-<br />
! September 29<br />
|| kermit [https://bitcointalk.org/index.php?topic=1306.0 discovered] a microtransactions exploit which precipitated the Bitcoin v0.3.13 release<br />
|-<br />
! October 01<br />
|| First public OpenCL miner released<br />
|-<br />
! October 04<br />
|| Original Bitcoin History wiki page (this page) established (ooh so meta) on Bitcoin.org's wiki.<br />
|-<br />
! October 07<br />
|| Exchange rate started climbing up from $0.06/BTC after several flat months.<br />
|-<br />
! October 28<br />
|| 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.<br />
|-<br />
! November 6<br />
|| The [https://bitcointalk.org/index.php?topic=1672 Bitcoin economy passed US $1 million]. The MtGox price touched USD $0.50/BTC.<br />
|-<br />
! December 7<br />
|| 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.<br />
|-<br />
! December 9<br />
|| The generation difficulty passed 10,000.<br />
|-<br />
|<br />
|| First bitcoin call option contract sold, from nanotube to [[User:Sgornick|sgornick]], via the [[Bitcoin-otc|#bitcoin-otc]] market.<br />
|-<br />
! December 16<br />
|| [http://mining.bitcoin.cz/ Bitcoin Pooled Mining], operated by slush, found its first block<br />
|}<br />
<br />
=== 2011 ===<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | January 2<br />
|| [[Tonal Bitcoin]] units standardized.<br />
|-<br />
! January 8<br />
|| [[History of Bitcoin]] page (this page) created after replicating from original Bitcoin History page on Bitcoin.org.<br />
|-<br />
|<br />
|| Bitcoin Pooled Mining reached a total of 10,000 Mhash/s<br />
|-<br />
! January 27<br />
|| 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><br />
|-<br />
! January 28<br />
|| 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.<br />
|-<br />
! February 9<br />
|| Bitcoin reached parity with the US dollar, touching $1 per BTC at [[MtGox]].<br />
|-<br />
! February 10<br />
|| Bitcoin.org website struggles to handle [https://bitcointalk.org/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.<br />
|-<br />
! February 14<br />
|| A vehicle was, for the first time, offered in exchange for a certain number of bitcoins<ref>[https://bitcointalk.org/index.php?topic=3485.0 Car for Sale - Australia]</ref>.<br />
|-<br />
! March 6<br />
|| Total Bitcoin network computation speed for a short time reached a new 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]).<br />
|-<br />
! March 18<br />
|| 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.<br />
|-<br />
! March 25<br />
|| Difficulty decreased nearly 10%. A decrease has only occurred once before, and this decrease of nearly 10% was the largest.<br />
|-<br />
! March 27<br />
|| The first market for exchanging bitcoins to and from the British Pound Sterling BTC/GBP, [[Britcoin]], opens.<br />
|-<br />
! March 31<br />
|| The first market for exchanging bitcoins to and from Brazilian Reals, [[Bitcoin Brazil]], opens.<br />
|-<br />
! April 5<br />
|| The first market for exchanging bitcoins to and from the Polish złoty, [[BitMarket.eu]], opens.<br />
|-<br />
! April 12<br />
|| First bitcoin put option contract sold via the [[Bitcoin-otc|#bitcoin-otc]] market.<br />
|-<br />
! April 16<br />
|| TIME does [http://techland.time.com/2011/04/16/online-cash-bitcoin-could-challenge-governments/ an article on Bitcoin].<br />
|-<br />
! April 23<br />
|| BTC/USD exchange rate reaches and passes parity with the Euro (EUR) on [[MtGox]] exchange.<br />
|-<br />
|<br />
|| BTC/USD exchange rate reaches and passes parity with the British Sterling Pound (GBP) on [[MtGox]] exchange.<br />
|-<br />
|<br />
|| Value of the Bitcoin money stock at current exchange rate passes $10 million USD threshold.<br />
|-<br />
! April 27<br />
|| [[VirWoX]] opens first market to trade bitcoins against a virtual currency on BTC/SL (Second Life Lindens) exchange.<br />
|-<br />
! April 30<br />
|| The generation difficulty passed 100,000.<br />
|-<br />
! June 2<br />
|| The exchange rate at [[MtGox]] touched 10 USD per BTC.<br />
|-<br />
! June 3<br />
|| [[Tonal Bitcoin]] reached parity with the US cent, touching 1¢ per TBC at [[Bitcoin Market]].<br />
|-<br />
! June 8<br />
|| 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].<br />
|-<br />
! June 12<br />
|| The [[MtGox]] exchange rate briefly dropped to near 10 USD four days after the peak, in its largest percentage price retreat to date.<br />
|-<br />
! June 13<br />
|| 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).<br />
|-<br />
! June 19<br />
|| 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.<br />
|-<br />
! June 19<br />
|| 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).<br />
|-<br />
! June 19<br />
|| 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.<br />
|-<br />
! June 20<br />
|| The EFF announced that it was no longer accepting Bitcoin donations due to legal uncertainties.<br />
|-<br />
! June 24<br />
|| The generation difficulty passed 1,000,000 with Block [http://blockexplorer.com/b/133056 133056].<br />
|-<br />
! July 19<br />
|| "Let it go on record that at 4:05pm CET [19 July 2011], my manager Tadek was the first person in the world to receive [testnet] Bitcoins via NFC ;)" - Mike Hearn<br />
|-<br />
! July 22<br />
|| [[BitCoins Mobile]], the first Bitcoin application for iPad was released by [http://www.intervex.net Intervex Digital].<br />
|-<br />
! July 30<br />
|| [http://pastebin.com/raw.php?i=BUB3dygQ Tribute to Len Sassaman] included in the blockchain<ref>[http://bitcointalk.org/index.php?topic=33618.msg420597#msg420597 A Tribute to Len "rabbi" Sassama]</ref>. <br />
|-<br />
! August 20<br />
|| First Bitcoin Conference and World Expo held, in NYC.<ref>[http://bitcoinme.com/index.php/conference/ New York Conference 2011]</ref><br />
|-<br />
! August 23<br />
|| [[P2Pool]], the first P2P decentralized pool, mines its first Bitcoin mainnet block (Block [http://blockexplorer.com/b/142312 142,312]).<br />
|-<br />
! August 30<br />
|| Difficulty adjustment at block [http://blockexplorer.com/b/143136 143,136] marks the first back-to-back drop.<br />
|-<br />
! November 15<br />
|| First CVE (CVE-2011-4447) assigned to a Bitcoin client exploit.<br />
|-<br />
! November 25<br />
|| First European Bitcoin Conference in Prague, Czech Rep.<ref>[http://bitgroups.org/ Prague Conference 2011]</ref><br />
|-<br />
! December 12<br />
|| Largest amount of fees, to-date, in a single transaction, and most fees in a single block. A [http://blockexplorer.com/tx/1d7749c65c90c32f5e2c036217a2574f3f4403da39174626b246eefa620b58d9 transaction] paid 171 BTC in fees in [http://blockexplorer.com/b/157235 block 157235]<ref>[http://bitcointalk.org/index.php?topic=88423.msg973509#msg973509 Largest fee ever?]</ref>.<br />
|}<br />
<br />
=== 2012 ===<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | March 1<br />
|| Largest theft of bitcoins to-date occurred (near 50K BTC) after security breach at web host Linode.<br />
|-<br />
! width="8em" | April 1<br />
|| Pay-to-script-hash ([[P2SH]]) as defined through [[BIP 0016]] goes live.<br />
|-<br />
! May 08<br />
|| A single service, [[SatoshiDICE]] becomes responsible for over half the transaction volume on the Bitcoin blockchain.<br />
|-<br />
! June 3<br />
|| Largest block (most transactions), to-date (June 3), is [http://BlockExplorer.com/b/181919 block 181919] with 1322 transactions<ref>[http://bitcointalk.org/index.php?topic=85353.msg939859#msg939859 Largest block to date]</ref>.<br />
|-<br />
! July 22<br />
|| One millionth topic reply was posted on the unofficial [[Bitcoin Forum]] <ref>[https://bitcointalk.org/index.php?topic=94608.0 Topic about one millionth forum post]</ref>.<br />
|-<br />
! September 15-16<br />
|| Bitcoin Conference in London <ref>[http://bitcoin2012.com/ London Conference 2012]</ref>.<br />
|-<br />
! September 27<br />
|| Formation of the [[Bitcoin Foundation]].<br />
|-<br />
! November 28<br />
|| Halving day. [http://blockexplorer.com/b/210000 Block 210,000] is the first with a block reward subsidy of only 25 BTC.<br />
|-<br />
! December 6<br />
|| First Bitcoin exchange [https://bitcointalk.org/index.php?topic=129461.0 licensed "as a bank" in europe] (actually a PSP which is like a bank, without debt-money issuing).<br />
|}<br />
<br />
=== 2013 ===<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | February 19<br />
|| Bitcoin Client v0.8 (w/faster blockchain download) released<br />
|-<br />
! Feb 28<br />
|| The [[MtGox]] exchange rate broke the Jun 8 2011 peak of 31.91 USD. The first all time high since 601 days<br />
|-<br />
|}<br />
<br />
==See Also==<br />
<br />
* [[Bitcoin Firsts]]<br />
<br />
==References==<br />
<references /></div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Talk:Satoshi_Dice&diff=34830Talk:Satoshi Dice2013-01-08T20:52:55Z<p>Giszmo: pro SD</p>
<hr />
<div>==== DDoS claims ====<br />
[[User:Luke-Jr]] added an edit to this article calling it a DDoS attack [https://en.bitcoin.it/w/index.php?title=SatoshiDice&oldid=32544 in this revision]. Since I found the edit opinionated and it had no citations to back the accusation, I edited it to a more neutral form [https://en.bitcoin.it/w/index.php?title=SatoshiDice&oldid=33157 in this revision]. He later reverted my edit [https://en.bitcoin.it/w/index.php?title=SatoshiDice&oldid=33337 in this revision] without revising the article. Since I have no intention of waging an edit war, I would like to hear Luke-Jr's opinion on the issue before making any further edits. Bitcoin doesn't need any more drama at this point. --[[User:Matoking|Matoking]] ([[User talk:Matoking|talk]]) 20:18, 5 December 2012 (GMT)<br />
<br />
As to why I *don't* think SatoshiDice is a DDoS attack:<br />
<br />
* SatoshiDice doesn't break any rules upheld by Bitcoin network since it pays transaction fees as seen in transactions such as [http://blockchain.info/tx/e774dbfad35e1bf5d9571f8d808b9a934130cc93c0ba2c6d70041c0fbb7f8fee this] and [http://blockchain.info/tx/d37cf4c63d6f4e1fc7fbce5f1f52447d514dc364bb13959aa6171be3635ae32f that one]. More over, the transaction fees meet or exceed the minimum amount as described [[Transaction_fees|in this article]]. How can you claim SatoshiDice to be a DDoS attack when almost all of the miners deliberately include the transactions in their respective mined blocks since they don't "break" any rules?<br />
* How SatoshiDice handles its bets and transactions is explained [http://satoshidice.com/bits.php here] and the purported "transaction spam" is only a consequence of how the system works and how popular it has become, where the fault is more of poor design than malicious intent. The gamblers have knowledge of how the system works and just because it has become very active in terms of transaction throughput doesn't mean it has suddenly become a "DDoS attack" against the network. The same thing could be claimed about mixing services, which try to hide the transaction inputs' origins by shuffling them through multiple transactions, but since their effect on the size of blockchain is minimal at best, nobody seriously considers that they are malicious attacks.<br />
* The reason why SatoshiDice works at the moment is because a lot of people legitimately use it for gambling and a lot of miners agree to include the created transactions in their blocks, since the inclusion of transaction fees make it viable. If most of people are okay with the service's existence, then why is it a DDoS attack? --[[User:Matoking|Matoking]] ([[User talk:Matoking|talk]]) 09:59, 6 December 2012 (GMT)<br />
<br />
<br />
::* SatoshiDice ''does'' break Bitcoin network rules: particularly the rule against flooding with spam transactions. By design, Bitcoin intended to counter such spam by requiring minimal transaction fees for spammy-looking transactions, so that eventually such a spammer would run out of funds. SatoshiDice, however, uses novel social engineering to exploit gamblers and force them to cover the cost of bypassing Bitcoin's anti-spam rules (SatoshiDice itself does not pay the transaction fees, they are always paid out of the gambler's pocket).<br />
::* SatoshiDice is abusing the good will of the miners by flooding 2 transactions for every action a user/gambler makes. This would be the equivalent of 2 transactions for every item you take off the shelf at Walmart (or any other store). Not even big networks like VISA could probably handle this kind of abuse, so it is absurd to suggest Bitcoin in its early stage should or could. While the total transaction volume might be within reason for what Bitcoin must handle some day, when that volume is a ''reasonable'' amount of transactions, there will also be far more users/peers, developers, etc, and Bitcoin will scale better than it does today.<br />
::* As implemented today, Bitcoin clients do an extremely ''poor'' job of passing around transactions and (especially) blocks. SatoshiDice's transaction spam has on multiple occasions been the direct cause of many miners ''losing'' their hard-earned Bitcoin blocks. This can be improved with development time and scaling, but it isn't a trivial overnight rewrite and involves a lot of complicated code to get it right.<br />
::* Despite knowing how it violates Bitcoin rules and disrupts the network, SatoshiDice continues to intentionally abuse the network. --[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 12:27, 6 December 2012 (GMT)<br />
<br />
<br />
:::* As I said, SatoshiDice does not hide the facts behind the system, such as how the transaction fees are paid and it is stated [http://satoshidice.com/bits.php on this page] that the site will subtract bitcoins from the bet if it's necessary to pay the transaction fee. This is the case with a lot of other Bitcoin services too. I hardly think that is social engineering.<br />
:::* Again, the "2 transactions" system is a design feature using which the gambler can know whether the bet was processed or not. The workings behind that is public information as stated on this [http://satoshidice.com/bits.php aforementioned page], so you can't claim that the users "don't know about it."<br />
:::* That's a problem with the Bitcoin client, not the service. It has been known for a long time that there is a lot of optimization that can be done with the Bitcoin client, something which had been largely ignored until the network started growing in terms of transaction throughput and blockchain in terms of file size. While it would be good if the Bitcoin network and the community could scale at the same pace, it isn't possible and instead of stomping out services just because they aren't ready for the prime-time yet, developers should focus on improving the current Bitcoin client.<br />
:::* How is it violating the network? As far as I know, there are no "official" guidelines or rules set in place which define how many transactions a certain service can use during a certain time period, besides the rules that have been defined in the current Bitcoin-Qt client. --[[User:Matoking|Matoking]] ([[User talk:Matoking|talk]]) 14:02, 6 December 2012 (GMT)<br />
<br />
::::* Oh, great, so I stumbled into the next Luke-jr edit war. Too bad. I promise I first removed stupidity and then read on the Talk page that I was in the wrong place again. Yeah, I hereby take side of SD not being a DDoS attack as the network should either not accept these transactions or it should deal with them. A P2P payment processor can't knowingly take transaction fees from a business and at the same time call it a DDoS attack. --[[User:Giszmo|Giszmo]] ([[User talk:Giszmo|talk]]) 20:52, 8 January 2013 (GMT)</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Satoshi_Dice&diff=34829Satoshi Dice2013-01-08T20:44:52Z<p>Giszmo: /* History */ Removed flooding, spam and legitimate from the history entry about the new transaction records hit by SD</p>
<hr />
<div>SatoshiDice is a "blockchain-based betting game."<br />
<br />
It is generally considered to be DDoS attack against the Bitcoin network since it is bypassing the built-in anti-DDoS features of Bitcoin (transaction fees). {{Citation needed}}<br />
<br />
Unlike traditional online gaming software, wagers with SatoshiDice can be sent without access to the website nor running any client software. To play, a Bitcoin transaction is made to one of the static addresses operated by the service, each having differing payouts. The service determines if the wager wins or loses and sends a transaction in response with the payout to a winning bet or it returns a tiny fraction of the house's gain to a losing bet.<br />
As a result, the game spams the p2p network and blockchain with useless data.<br />
SatoshiDice forces players to pay a transaction fee on each result so the spam will successfully flood both the p2p relay network and the blockchain.<br />
<br />
There has been the suggestion that the service might be also be used as a [[mixing service]], as the composition of a wallet can be materially changed after running wagers through SatoshiDice<ref>[http://bitcointalk.org/index.php?topic=79079.0 Blockchain-based betting services function as mixing services?]</ref>.<br />
Though this approach could change the makeup of the wallet, it does not sufficiently serve the mixing purpose as the coins returned in winning bets are tied to the coins from the wager transaction.<br />
<br />
There is no reason to believe that [[Satoshi Nakamoto]] has anything to do with this attack, other than the service choosing to include the noun Satoshi in the brand.<br />
It is known to be currently operated by [[Erik Voorhees]].<br />
<br />
==Random Number Generation==<br />
<br />
To determine if a wager is a winner or loser, the site uses a method to produce a number between 0 and 65,535, similar to how a random number generator (RNG) would be used. The service uses a combination of the transaction hash from the wager transaction from the blockchain and performs a 512-bit SHA2 hash for that transaction hash using a secret unknown to the player. The first four bytes of that hash become the lucky number in determining winner or loser.<br />
<br />
==Odds==<br />
<br />
Each wager address has different odds, and each gives the house an edge of 1.50% (i.e., payouts are 98.5% when including the payout to the losing bets)<ref>[http://bitcointalk.org/index.php?topic=77870.msg906438#msg906438 Some changes to the site]</ref>. The website shows the full list of wager addresses and odds.<br />
<br />
==Automated Betting==<br />
<br />
Some gamblers have built automated betting bot scripts employing the Martingale betting system and variants thereof<ref>[http://bitcointalk.org/index.php?topic=80245.0 PHP martingale bot for satoshiDICE]</ref>.<br />
<br />
==History==<br />
<br />
SatoshiDice was the brand given the service initially created by [[BitcoinTalk]] forum user FireDuck before selling the system to another operator<ref>[http://www.reddit.com/r/Bitcoin/comments/segz0/anyone_want_to_run_my_bitcoin_casino Anyone want to run my bitcoin casino]</ref>. The service was announced on April 24, 2012<ref>[http://bitcointalk.org/index.php?topic=77870.0 SatoshiDICE.com - Verified rolls, up to 65,000x winning]</ref>.<br />
Within weeks, the site became responsible for more Bitcoin transactions than all other uses of Bitcoin combined<ref>[http://bitcointalk.org/index.php?topic=79285.0 All-time transaction record was just hit]</ref>.<br />
<br />
Since August 20, 2012 SatoshiDice shares are publicly traded<ref>https://bitcointalk.org/index.php?topic=101902.0 IPO shares announcement</ref> at [[MPEx]] under S.DICE symbol and paying monthly dividends.<br />
<br />
==See Also==<br />
<br />
* [[Mixing service]]<br />
<br />
==External Links==<br />
<br />
* [http://www.SatoshiDice.com SatoshiDice.com] website<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Gambling]]</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Satoshi_Dice&diff=34828Satoshi Dice2013-01-08T20:41:47Z<p>Giszmo: /* History */ extra ] and g removed</p>
<hr />
<div>SatoshiDice is a "blockchain-based betting game."<br />
<br />
It is generally considered to be DDoS attack against the Bitcoin network since it is bypassing the built-in anti-DDoS features of Bitcoin (transaction fees). {{Citation needed}}<br />
<br />
Unlike traditional online gaming software, wagers with SatoshiDice can be sent without access to the website nor running any client software. To play, a Bitcoin transaction is made to one of the static addresses operated by the service, each having differing payouts. The service determines if the wager wins or loses and sends a transaction in response with the payout to a winning bet or it returns a tiny fraction of the house's gain to a losing bet.<br />
As a result, the game spams the p2p network and blockchain with useless data.<br />
SatoshiDice forces players to pay a transaction fee on each result so the spam will successfully flood both the p2p relay network and the blockchain.<br />
<br />
There has been the suggestion that the service might be also be used as a [[mixing service]], as the composition of a wallet can be materially changed after running wagers through SatoshiDice<ref>[http://bitcointalk.org/index.php?topic=79079.0 Blockchain-based betting services function as mixing services?]</ref>.<br />
Though this approach could change the makeup of the wallet, it does not sufficiently serve the mixing purpose as the coins returned in winning bets are tied to the coins from the wager transaction.<br />
<br />
There is no reason to believe that [[Satoshi Nakamoto]] has anything to do with this attack, other than the service choosing to include the noun Satoshi in the brand.<br />
It is known to be currently operated by [[Erik Voorhees]].<br />
<br />
==Random Number Generation==<br />
<br />
To determine if a wager is a winner or loser, the site uses a method to produce a number between 0 and 65,535, similar to how a random number generator (RNG) would be used. The service uses a combination of the transaction hash from the wager transaction from the blockchain and performs a 512-bit SHA2 hash for that transaction hash using a secret unknown to the player. The first four bytes of that hash become the lucky number in determining winner or loser.<br />
<br />
==Odds==<br />
<br />
Each wager address has different odds, and each gives the house an edge of 1.50% (i.e., payouts are 98.5% when including the payout to the losing bets)<ref>[http://bitcointalk.org/index.php?topic=77870.msg906438#msg906438 Some changes to the site]</ref>. The website shows the full list of wager addresses and odds.<br />
<br />
==Automated Betting==<br />
<br />
Some gamblers have built automated betting bot scripts employing the Martingale betting system and variants thereof<ref>[http://bitcointalk.org/index.php?topic=80245.0 PHP martingale bot for satoshiDICE]</ref>.<br />
<br />
==History==<br />
<br />
SatoshiDice was the brand given the service initially created by [[BitcoinTalk]] forum user FireDuck before selling the system to another operator<ref>[http://www.reddit.com/r/Bitcoin/comments/segz0/anyone_want_to_run_my_bitcoin_casino Anyone want to run my bitcoin casino]</ref>. The service was announced on April 24, 2012<ref>[http://bitcointalk.org/index.php?topic=77870.0 SatoshiDICE.com - Verified rolls, up to 65,000x winning]</ref>.<br />
Within weeks, the site became responsible for flooding more Bitcoin spam transactions than all legitimate uses of Bitcoin combined<ref>[http://bitcointalk.org/index.php?topic=79285.0 All-time transaction record was just hit]</ref>.<br />
<br />
Since August 20, 2012 SatoshiDice shares are publicly traded<ref>https://bitcointalk.org/index.php?topic=101902.0 IPO shares announcement</ref> at [[MPEx]] under S.DICE symbol and paying monthly dividends.<br />
<br />
==See Also==<br />
<br />
* [[Mixing service]]<br />
<br />
==External Links==<br />
<br />
* [http://www.SatoshiDice.com SatoshiDice.com] website<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Gambling]]</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=User_talk:Sgornick&diff=34827User talk:Sgornick2013-01-08T20:29:57Z<p>Giszmo: /* Tonal */</p>
<hr />
<div>__TOC__<br />
<br />
==06:22, 4 August 2011 (GMT)==<br />
Trade; 05:20 . . (-71) . . Sgornick (Talk | contribs) (→Getting started: Remove BTCBase, this is wiki is generally for english-only sites. There are separate wikis for other languages.)<br />
Yet Bitomat is not available in English... what's the difference here? --[[User:Luke-jr|Luke-jr]] 06:22, 4 August 2011 (GMT)<br />
<br />
Good point, Luke-jr. Unfortunately, they don't belong on the trade page for another reason -- they are info only, they have no trade. Otherwise I would add them back in somewhere.<br />
<br />
==13:13, 10 August 2011 (GMT)==<br />
Mr. Sgornick I thought this was a good idea. I don't understand how it hurts the community?!(I don't see the reasons in deleting them.) I made my contributions (Introduced 4-5 bitcoin-related sites and wrote some descriptions). The users don't have anything to loose and the BTC I make out of this I intend to spend on bitcoindeals.com (after I get an invitation). Isn't there a way I can leave those links there? We have the same rights on this wiki so I hope we can disscus this with respect and consideration.<br />
--[[User:Vladgiurgiubv|Vladgiurgiubv]] 13:13, 10 August 2011 (GMT)<br />
<br />
Vladgiurgiubv, It was an unwritten but generally accepted rule that no affiliate / referral links should be included in the wiki for a number of reasons. The [[BitcoinWiki:Rules|policy]] does now exist though.<br />
<br />
==22:58, 11 August 2011 (GMT)==<br />
<br />
Dear sgornick, I realize you recently removed my links to iscyspace on the mining guide, how bit coin works and irc claiming they were none existent, this is not the case, I'll agree to the irc one because well . . . my irc is pretty much empty >_< however my site most certainly does exist and in fact the guide is blatantly on the open page, as a sign of good will I have removed the linkbucks links and replaced them with direct links instead as i pay for my site through advertisements, although even I admit the linkbucks thing took it a bit to far, I've sent you an email explaining the situation and offering some further comments and I hope to hear back from you soon.<br />
<br />
It is blatant spam/advertising. Using a binary distribution site for open source software is uncool, and clearly shows you to be unqualified to contribute further on this wiki, in my opinion. I've referred this to the admins. - [[User:Sgornick|Sgornick]] 23:30, 11 August 2011 (GMT)<br />
<br />
It's not a binary distribution site first of all, it offers links to the official download pages for each piece of software man, its simlpy a guide to help people set up miners and solve any common problems, the only advertisements on the site is a top banner and a side box of which both are tiny and non distracting, there are no pop ups and no spam, we don't take emails from people so we cant spam them through that, I just don't understand how you see the site as spam advertisements, have you even looked at it =/ Seriously look, its just a set up guide and in fact has less advertisements on it than most other websites, I don't understand the rationality behind your argument, can you at least check my site and show me what spam advertisements you are referring to so i can fix this problem, because believe it or not the site does matter to me, as does its popularity with the bit coin community and the simple removal of my links yesterday literally vaporized my hit rate to practically non existent, you know the bit coin community lacks simple set up guides and that's all I offer, a guide, with links to what they need, nothing more, no spam advertisements like you claim. And finally as a testament to such, tell me EXACTLY what part of the site your unhappy with, and ill try my hardest to change it, im just proud of my little site and i don't want it being damaged, it makes no money and i'll show you, admins, and anyone else the ad sense logs to prove that.<br />
<br />
== placement of only ==<br />
<br />
Hi. I just edited the Network article to correct some sentences with the word "only" in the wrong part of the sentence, and noticed that one was a recent edit of yours, so thought I'd let you know. I realise that the word is often misplaced in sentences even by native English speakers, possibly even the majority, but as this is a technical document, and technically it does change the meaning by having it in the wrong place, I felt it better to correct these. --[[User:Rebroad|Rebroad]] 21:40, 23 February 2012 (GMT)<br />
<br />
== "affiliate" link of dtsleech.com link ==<br />
<br />
This isn't an affiliate link, it is a tracking link to measure the amount of users who click from this site to dtsleech.com and the amount of sale/conversions there are link specific. It is not a link associated with any user account at dtsleech.com or in any way an affiliate link. It is purely for market research, would appreciate if it was not removed.<br />
<br />
== Tonal ==<br />
<br />
May I ask why you take LukeJR's side in the edit war on Tonal Bitcoin? If you are the Stephen Gornick from the forum I would really appreciate your reasoning why the wiki should keep Tonal* around.<br />
--[[User:Giszmo|Giszmo]] ([[User talk:Giszmo|talk]]) 00:59, 28 December 2012 (GMT)<br />
<br />
Thanks Giszmo for inquiring. My beef is that waging an edit war causes me more work. I peruse the [[Special:RecentChanges|Recent changes]] to know what content has changed so that I can help remove spam, or learn what has changed. If daily I come across an edit and revert of a page, day after day, that is upsetting to me. The article isn't hurting anything. My opinion then is to just leave it be. And if there's an edit war I will attempt to show it is futile (unwinnable) because I will add my firepower (i.e., I can click "undo" too) on the "let it exist" side.<br />
- [[User:Sgornick|Sgornick]] ([[User talk:Sgornick|talk]]) 20:33, 28 December 2012 (GMT)<br />
<br />
I understand your motive but can't agree with your action. If you have more power than others then you should use it with care and not randomly just stop an edit war. Edit wars are hard work, too ;)<br />
You claim there is no harm done but you [https://en.bitcoin.it/w/index.php?title=Talk%3ATonal_Bitcoin&diff=34092&oldid=34043 don't allow a discussion about exactly that to take place]. I'm really disappointed. What next? Delete my account for annoying you here cause you need more time to keep up the good work?<br />
If the majority of editors understand and support a consensus, you have less work, as not only others do what you would have to do else, but yet others feel worse about doing what you have to revert later. As it stands I have no bad feelings to bring back the Tonal:Talk but if there is a good reason not to discuss this particular article and I find this good reason somewhere, I will refrain from doing so.<br />
--[[User:Giszmo|Giszmo]] ([[User talk:Giszmo|talk]]) 20:29, 8 January 2013 (GMT)</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Satoshi_Dice&diff=34306Satoshi Dice2013-01-01T23:03:39Z<p>Giszmo: Category:Gambling</p>
<hr />
<div>SatoshiDice is a "blockchain-based betting game."<br />
<br />
It is often thought to be DDoS attack against the Bitcoin network since it is bypassing the built-in anti-DDoS features of Bitcoin (transaction fees).<br />
<br />
Unlike traditional online gaming software, wagers with SatoshiDice can be sent without access to the website nor running any client software. To play, a Bitcoin transaction is made to one of the static addresses operated by the service, each having differing payouts. The service determines if the wager wins or loses and sends a transaction in response with the payout to a winning bet or it returns a tiny fraction of the house's gain to a losing bet.<br />
As a result, the game spams the p2p network and blockchain with useless data.<br />
SatoshiDice forces players to pay a transaction fee on each result so the spam will successfully flood both the p2p relay network and the blockchain.<br />
<br />
There has been the suggestion that the service might be also be used as a [[mixing service]], as the composition of a wallet can be materially changed after running wagers through SatoshiDice<ref>[http://bitcointalk.org/index.php?topic=79079.0 Blockchain-based betting services function as mixing services?]</ref>.<br />
Though this approach could change the makeup of the wallet, it does not sufficiently serve the mixing purpose as the coins returned in winning bets are tied to the coins from the wager transaction.<br />
<br />
There is no reason to believe that [[Satoshi Nakamoto]] has anything to do with this attack, other than the service choosing to include the noun Satoshi in the brand.<br />
It is known to be currently operated by [[Erik Voorhees]].<br />
<br />
==Random Number Generation==<br />
<br />
To determine if a wager is a winner or loser, the site uses a method to produce a number between 0 and 65,535, similar to how a random number generator (RNG) would be used. The service uses a combination of the transaction hash from the wager transaction from the blockchain and performs a 512-bit SHA2 hash for that transaction hash using a secret unknown to the player. The first four bytes of that hash become the lucky number in determining winner or loser.<br />
<br />
==Odds==<br />
<br />
Each wager address has different odds, and each gives the house an edge of 1.50% (i.e., payouts are 98.5% when including the payout to the losing bets)<ref>[http://bitcointalk.org/index.php?topic=77870.msg906438#msg906438 Some changes to the site]</ref>. The website shows the full list of wager addresses and odds.<br />
<br />
==Automated Betting==<br />
<br />
Some gamblers have built automated betting bot scripts employing the Martingale betting system and variants thereof<ref>[http://bitcointalk.org/index.php?topic=80245.0 PHP martingale bot for satoshiDICE]</ref>.<br />
<br />
==History==<br />
<br />
SatoshiDice was the brand given the service initially created by [[BitcoinTalk]] forum user FireDuck before selling the system to another operator<ref>[http://www.reddit.com/r/Bitcoin/comments/segz0/anyone_want_to_run_my_bitcoin_casino Anyone want to run my bitcoin casino]</ref>. The service was announced on April 24, 2012<ref>[http://bitcointalk.org/index.php?topic=77870.0 SatoshiDICE.com - Verified rolls, up to 65,000x winning]</ref>].<br />
Withing weeks, the site became responsible for flooding more Bitcoin spam transactions than all legitimate uses of Bitcoin combined<ref>[http://bitcointalk.org/index.php?topic=79285.0 All-time transaction record was just hit]</ref>.<br />
<br />
Since August 20, 2012 SatoshiDice shares are publicly traded<ref>https://bitcointalk.org/index.php?topic=101902.0 IPO shares announcement</ref> at [[MPEx]] under S.DICE symbol and paying monthly dividends.<br />
<br />
==See Also==<br />
<br />
* [[Mixing service]]<br />
<br />
==External Links==<br />
<br />
* [http://www.SatoshiDice.com SatoshiDice.com] website<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Gambling]]</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Talk:SatoshiTable&diff=34305Talk:SatoshiTable2013-01-01T23:02:26Z<p>Giszmo: delete request</p>
<hr />
<div>== Delete ==<br />
As stated on the website, this service does not exist anymore. --[[User:Giszmo|Giszmo]] ([[User talk:Giszmo|talk]]) 23:02, 1 January 2013 (GMT)</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=User_talk:Sgornick&diff=34169User talk:Sgornick2012-12-28T00:59:22Z<p>Giszmo: /* Tonal */ new section</p>
<hr />
<div>__TOC__<br />
<br />
==06:22, 4 August 2011 (GMT)==<br />
Trade; 05:20 . . (-71) . . Sgornick (Talk | contribs) (→Getting started: Remove BTCBase, this is wiki is generally for english-only sites. There are separate wikis for other languages.)<br />
Yet Bitomat is not available in English... what's the difference here? --[[User:Luke-jr|Luke-jr]] 06:22, 4 August 2011 (GMT)<br />
<br />
Good point, Luke-jr. Unfortunately, they don't belong on the trade page for another reason -- they are info only, they have no trade. Otherwise I would add them back in somewhere.<br />
<br />
==13:13, 10 August 2011 (GMT)==<br />
Mr. Sgornick I thought this was a good idea. I don't understand how it hurts the community?!(I don't see the reasons in deleting them.) I made my contributions (Introduced 4-5 bitcoin-related sites and wrote some descriptions). The users don't have anything to loose and the BTC I make out of this I intend to spend on bitcoindeals.com (after I get an invitation). Isn't there a way I can leave those links there? We have the same rights on this wiki so I hope we can disscus this with respect and consideration.<br />
--[[User:Vladgiurgiubv|Vladgiurgiubv]] 13:13, 10 August 2011 (GMT)<br />
<br />
Vladgiurgiubv, It was an unwritten but generally accepted rule that no affiliate / referral links should be included in the wiki for a number of reasons. The [[BitcoinWiki:Rules|policy]] does now exist though.<br />
<br />
==22:58, 11 August 2011 (GMT)==<br />
<br />
Dear sgornick, I realize you recently removed my links to iscyspace on the mining guide, how bit coin works and irc claiming they were none existent, this is not the case, I'll agree to the irc one because well . . . my irc is pretty much empty >_< however my site most certainly does exist and in fact the guide is blatantly on the open page, as a sign of good will I have removed the linkbucks links and replaced them with direct links instead as i pay for my site through advertisements, although even I admit the linkbucks thing took it a bit to far, I've sent you an email explaining the situation and offering some further comments and I hope to hear back from you soon.<br />
<br />
It is blatant spam/advertising. Using a binary distribution site for open source software is uncool, and clearly shows you to be unqualified to contribute further on this wiki, in my opinion. I've referred this to the admins. - [[User:Sgornick|Sgornick]] 23:30, 11 August 2011 (GMT)<br />
<br />
It's not a binary distribution site first of all, it offers links to the official download pages for each piece of software man, its simlpy a guide to help people set up miners and solve any common problems, the only advertisements on the site is a top banner and a side box of which both are tiny and non distracting, there are no pop ups and no spam, we don't take emails from people so we cant spam them through that, I just don't understand how you see the site as spam advertisements, have you even looked at it =/ Seriously look, its just a set up guide and in fact has less advertisements on it than most other websites, I don't understand the rationality behind your argument, can you at least check my site and show me what spam advertisements you are referring to so i can fix this problem, because believe it or not the site does matter to me, as does its popularity with the bit coin community and the simple removal of my links yesterday literally vaporized my hit rate to practically non existent, you know the bit coin community lacks simple set up guides and that's all I offer, a guide, with links to what they need, nothing more, no spam advertisements like you claim. And finally as a testament to such, tell me EXACTLY what part of the site your unhappy with, and ill try my hardest to change it, im just proud of my little site and i don't want it being damaged, it makes no money and i'll show you, admins, and anyone else the ad sense logs to prove that.<br />
<br />
== placement of only ==<br />
<br />
Hi. I just edited the Network article to correct some sentences with the word "only" in the wrong part of the sentence, and noticed that one was a recent edit of yours, so thought I'd let you know. I realise that the word is often misplaced in sentences even by native English speakers, possibly even the majority, but as this is a technical document, and technically it does change the meaning by having it in the wrong place, I felt it better to correct these. --[[User:Rebroad|Rebroad]] 21:40, 23 February 2012 (GMT)<br />
<br />
== "affiliate" link of dtsleech.com link ==<br />
<br />
This isn't an affiliate link, it is a tracking link to measure the amount of users who click from this site to dtsleech.com and the amount of sale/conversions there are link specific. It is not a link associated with any user account at dtsleech.com or in any way an affiliate link. It is purely for market research, would appreciate if it was not removed.<br />
<br />
== Tonal ==<br />
<br />
May I ask why you take LukeJR's side in the edit war on Tonal Bitcoin? If you are the Stephen Gornick from the forum I would really appreciate your reasoning why the wiki should keep Tonal* around.<br />
--[[User:Giszmo|Giszmo]] ([[User talk:Giszmo|talk]]) 00:59, 28 December 2012 (GMT)</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Talk:Bitcoin_Firsts&diff=32669Talk:Bitcoin Firsts2012-11-16T05:27:54Z<p>Giszmo: /* Format */ new section</p>
<hr />
<div>Any reason the 'bitcoin first' page is separate from the older History page?<br />
<br />
Ya, probably so that the History page was more specific to bitcoin, but firsts was for trivia and only true firsts.<br />
<br />
Like maybe going to v0.6 release is enough to make it into the History, but not something that would go into firsts.<br />
At the same time, the first food truck to start using bitcoin might be something suitable for the Firsts page but would be extraneous in the Bitcoin History page.<br />
<br />
== Adult entertainers video ==<br />
<br />
Video has been removed from Youtube due to TOS violation. I change the link to the original subreddit where it all began and entertainers in general started accepting Bitcoin.<br />
<br />
== Many, if not most things missing ==<br />
Many ideas and actions deserve being mentioned and the first to do it deserves to be mentioned here I think. There would be room for mentioning others as super tiny references like <ref>alternative 1</ref><ref>alternative 2</ref><ref>alternative 3</ref>. 5 minutes of brain storming:<br />
* first implementation of an exchange (otc?)<br />
* first floating exchange (MtGox?)<br />
* first free bitcoins site (faucet?)<br />
* first facebook wallet<br />
* first margin trading<br />
* first betting site<br />
* first auction site<br />
* first firstbits site<br />
* first live monitor of an exchange<br />
* first day with more than x transactions<br />
* first day with trade volume > x USD<br />
* first mobile wallet<br />
* first iPhone/android/blackberry/... wallet<br />
* first hosted wallet<br />
* first hosted wallet without registration (instawallet?)<br />
* first brain wallet site<br />
* …<br />
<references /><br />
--[[User:Giszmo|Giszmo]] ([[User talk:Giszmo|talk]]) 15:16, 27 August 2012 (GMT)<br />
<br />
== Format ==<br />
<br />
Some "Firsts" are actually no "Firsts". I suggest to reword all to "First …" and remove those that fail to fit into this. "First trading day of blablabla exchange" is not a Bitcoin first for example. If the exchange is the most relevant one, there is definitely room for some "first exchange to trad $XXX in one day/week/month".<br />
--[[User:Giszmo|Giszmo]] ([[User talk:Giszmo|talk]]) 05:27, 16 November 2012 (GMT)</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Bitcoin_Firsts&diff=32668Bitcoin Firsts2012-11-16T05:23:47Z<p>Giszmo: mentioned wordpress directly in the list</p>
<hr />
<div><br />
First examples of bitcoins being accepted for various goods and services and other notable first occurances. See discussion for more regarding what is suitable here.<br />
<br />
{| class="wikitable"<br />
! &nbsp;Event&nbsp;Date&nbsp;<br />
! Event<br />
|- <br />
| 2009-01-12<br />
| First bitcoin transaction<ref>[http://blockexplorer.com/b/170 Block 170 with the first transaction ever]</ref> on the network. From Satoshi to Hal Finney<ref>[https://bitcointalk.org/index.php?topic=91806.msg1012234#msg1012234 Earliest Block With A Spend]</ref>.<br />
|- <br />
| 2010-05-17<br />
| First recorded purchase of a good (pizza). Cost 10,000 BTC.<ref>[http://www.bitcointalk.org/index.php?topic=137.0 Pizza]</ref><br />
|-<br />
|2011-03-21<br />
| First travel using only Bitcoin to survive<ref>[http://www.bitcointalk.org/index.php?topic=4752.0 Plato's road trip]</ref><br />
|-<br />
| 2011-01-06<br />
| Guy pays random guy for work performed (holding a sign on a busy intersection)<ref>[http://www.bitcoinblogger.com/2011/01/power-of-bitcoins.html Mobile marketing gig]</ref><br />
|-<br />
| 2011-05-09<br />
| First physical bitcoins<ref>[[Bitbills]]</ref><br />
|-<br />
|2011-05-12<br />
|First room for rent for Bitcoin<ref>[http://www.bitcointalk.org/index.php?topic=8174.msg119235#msg119235 Room for rent]</ref><br />
|-<br />
|2011-05-17<br />
|First stripper being tipped bitcoin<ref>[http://therealplato.com/post/5568777157 Tipped a stripper Bitcoins] </ref><br />
|-<br />
|2011-05-27<br />
|Buying aircraft for BTC<ref>[http://www.bitcointalk.org/index.php?topic=10210.0 Buying aircraft for BTC]</ref><br />
|-<br />
|2011-06-01<br />
|SF Chiropractor accepts BTC for office visits<ref>[http://www.bitcointalk.org/index.php?topic=11178.0 SF Chiropractor accepts BTC for office visits]</ref><br />
|-<br />
|2011-06-04<br />
|First real estate offered for Bitcoin. A beach condo<ref>[http://www.bitcointalk.org/index.php?topic=12185.0 Beach Condo]</ref> and a house<ref>[http://forum.bitcoin.org/index.php?topic=12466.0 House]</ref> were offered within hours of each other<br />
|-<br />
|2011-10-30<br />
|First Bitcoin mining on an in-flight airplane using wifi. Unknown if any Bitcoins were actually created in flight<ref>[http://bitcointalk.org/index.php?topic=50379.0 Mining at 18,000 feet]</ref><br />
|-<br />
|2011-12-19<br />
|First TV story based on Bitcoin<ref>[http://www.cbspressexpress.com/cbs-entertainment/releases/view?id=30177 CBS' "THE GOOD WIFE" episode]</ref><br />
|-<br />
|2012-02-16<br />
|Auto title loan for bitcoins requested<ref>[http://bitcointalk.org/index.php?topic=64199 Auto title loan for bitcoins requested]</ref><br />
|-<br />
|2012-03-24<br />
|First property management accepts bitcons for rent<ref>[http://bitcointalk.org/index.php?topic=73712.0 Property management accept bitcons for rent]</ref>. Over 100 commercial and residential properties<br />
|-<br />
|2012-03-27<br />
|First printed Bitcoin magazine is announced and then followed by photos<ref>[https://bitcointalk.org/index.php?topic=74346.0 first photos of Coineer]</ref><ref>[https://coineer.com Coineer - The Bitcoin Magazine available in print]</ref><br />
|-<br />
|2012-03-28<br />
|Amateur Adult Entertainers use Bitcoin for tips<ref>[http://reddit.com/r/GirlsGoneBitcoin Amateur Adult Entertainers use Bitcoin for tips]</ref><br />
|-<br />
|2012-03-29<br />
|Bitcoin-only Credit Default Swap (CDS)<ref>[http://bitcointalk.org/index.php?topic=74552.0 Bitcoin-only Credit Default Swap (CDS)] </ref><br />
|-<br />
|2012-04-19<br />
|US Based exchange gets Federally licensed as a MSB<ref>[http://payglo.be/2012/04/19/bitinstant-federally-licensed-bitcoin-exchange/ US Based exchange gets Federally licensed as a MSB]</ref><ref>[https://bitcointalk.org/index.php?topic=77194.msg857699#msg857699 US Based exchange gets Federally licensed as a MSB 2]</ref><br />
|-<br />
|2012-04-20<br />
|Bitcoinica.com gets licensed as a MSB<ref>[http://bitcoinmedia.com/first-licensed-advanced-trading-platform-for-bitcoin/ Bitcoinica.com gets licensed as a MSB]</ref><br />
|-<br />
|2012-04-25<br />
|First Music album sold for bitcoins exclusively – Before being sold on iTunes<ref>[https://www.coindl.com/page/item/127 Music album sold for bitcoins exclusively]</ref><br />
|-<br />
|2012-04-26<br />
|First WebCam site to accept Bitcoins<ref>[http://ptvheaven.com WebCam site to accept Bitcoins]</ref>. Bitcoins accepted as an alternative payment. Entertainer payouts are not in Bitcoin.<br />
|-<br />
|2012-04-29<br />
|First Bitcoin only live webcam site<ref>[http://www.cam4btc.co.cc/ Bitcoin only live webcam site]</ref>. Bitcoin tips go directly to entertainers. Site operates on tips.<br />
|-<br />
|2012-05-01<br />
|Bitcoin Magazine<ref>[[Bitcoin Magazine]]</ref><ref>[http://bitcoinmagazine.net/bitcoin-magazine-press-release/ Press release] as first issue goes to print</ref><br />
|-<br />
|2012-05-01<br />
|Race horse named after Satoshi<ref>[http://www.satoshisdaemon.com/ Race horse named after Satoshi]</ref><ref>http://www.thebitcointrader.com/2012/04/bitcoin-horse-to-run-first-race-on-may.html</ref><br />
|-<br />
| 2012-05-09<br />
| First formal risk assessment by a government agency<ref>[http://bitcointalk.org/index.php?topic=80173.0 Discussion of Leaked FBI Report on Bitcoin- April 2012]</ref><br />
|-<br />
| 2012-05-09<br />
|Sold San Francisco Bridge<ref>[https://bitcointalk.org/index.php?topic=80485.msg890710#msg890710 Sold San Francisco Bridge]</ref>. Another traditional first for a new currency. (likely not authentic)<br />
|-<br />
| 2012-05-18<br />
|First Bitcoin class in a public school<ref>[https://bitcointalk.org/index.php?topic=82046.msg908451#msg908451 Bitcoin taught in a public school]</ref>. It was a 4th grade class<br />
|-<br />
| 2012-06-06<br />
|First Bitcoin donations to contribute to a successful anti-corrupt local government political campaign<ref>[https://bitcointalk.org/index.php?topic=74219.msg945392#msg945392 Bitcoin donations contribute to successful anti-corrupt local government political campaign]</ref>. Travis Kiger, running against a Fullerton City counsel that turned a blind eye to the death of Kelly Thomas at the hands of their local police department, promoted the use of Bitcoin to fund his campaign and won the councel seat for his district.<br />
|-<br />
| 2012-07-23<br />
| First car producers offer their vehicle for Bitcoin<ref>[https://bitcointalk.org/index.php?topic=94820.msg1048706#msg1048706 Automaker offers their vehicle for Bitcoin]</ref>. WikiSpeed is a Seattle based corporation that manufactures open source modular cars that get 100 MPG and accept Bitcoin as payment<br />
|-<br />
| 2012-08-06<br />
| First Bitcoin lawsuit<ref>[https://docs.google.com/file/d/0B_ECG6JRZs-7dTZ5QS0xcUkxQjQ/edit?pli=1# Bitcoin lawsuit]</ref>. Brian Cartmell filed a lawsuit against [[Bitcoinica]], a former Bitcoin margin trading platform that got hacked and hasen't returned customers' funds.<br />
|-<br />
| 2012-08-24<br />
| First private medical practice accepts Bitcoin<ref>[http://meidanklinikka.fi Private medical practice accepts Bitcoin]</ref>. It's a dentist in Finland.<br />
|-<br />
| 2012-09-14<br />
| First warrant to seize Bitcoins<ref>[http://www.americanbanker.com/bankthink/plot-thickens-in-bizarre-bitcoin-blackmail-caper-1054312-1.html First warrant to seize Bitcoin]</ref>. U.S. Secret Service seizing Michael M. Brown's bitcoins in the Romney Taxes For Ransom case.<br />
|-<br />
| 2012-09-26<br />
| First Taxi service accepts Bitcoin<ref>[http://www.taxizen.co.uk Taxi service accepts Bitcoin]</ref> (in Herefordshire, UK.)<br />
|-<br />
| 2012-11-15<br />
| First big<ref>[http://www.alexa.com/siteinfo/wordpress.com Wordpress.com at Alexa.com]</ref> website<ref>[http://en.blog.wordpress.com/2012/11/15/pay-another-way-bitcoin/ Wordpress accepts Bitcoin]</ref> accepts Bitcoin. It's [http://www.wordpress.com wordpress.com]<br />
|}<br />
<br />
==See Also==<br />
<br />
* [[History]]<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Introduction]]</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Bitcoin_Firsts&diff=32667Bitcoin Firsts2012-11-16T05:20:58Z<p>Giszmo: Made this list much nicer to read. Please review all that does not start with "First". I only reworded when I felt like this actually belongs here.</p>
<hr />
<div><br />
First examples of bitcoins being accepted for various goods and services and other notable first occurances. See discussion for more regarding what is suitable here.<br />
<br />
{| class="wikitable"<br />
! &nbsp;Event&nbsp;Date&nbsp;<br />
! Event<br />
|- <br />
| 2009-01-12<br />
| First bitcoin transaction<ref>[http://blockexplorer.com/b/170 Block 170 with the first transaction ever]</ref> on the network. From Satoshi to Hal Finney<ref>[https://bitcointalk.org/index.php?topic=91806.msg1012234#msg1012234 Earliest Block With A Spend]</ref>.<br />
|- <br />
| 2010-05-17<br />
| First recorded purchase of a good (pizza). Cost 10,000 BTC.<ref>[http://www.bitcointalk.org/index.php?topic=137.0 Pizza]</ref><br />
|-<br />
|2011-03-21<br />
| First travel using only Bitcoin to survive<ref>[http://www.bitcointalk.org/index.php?topic=4752.0 Plato's road trip]</ref><br />
|-<br />
| 2011-01-06<br />
| Guy pays random guy for work performed (holding a sign on a busy intersection)<ref>[http://www.bitcoinblogger.com/2011/01/power-of-bitcoins.html Mobile marketing gig]</ref><br />
|-<br />
| 2011-05-09<br />
| First physical bitcoins<ref>[[Bitbills]]</ref><br />
|-<br />
|2011-05-12<br />
|First room for rent for Bitcoin<ref>[http://www.bitcointalk.org/index.php?topic=8174.msg119235#msg119235 Room for rent]</ref><br />
|-<br />
|2011-05-17<br />
|First stripper being tipped bitcoin<ref>[http://therealplato.com/post/5568777157 Tipped a stripper Bitcoins] </ref><br />
|-<br />
|2011-05-27<br />
|Buying aircraft for BTC<ref>[http://www.bitcointalk.org/index.php?topic=10210.0 Buying aircraft for BTC]</ref><br />
|-<br />
|2011-06-01<br />
|SF Chiropractor accepts BTC for office visits<ref>[http://www.bitcointalk.org/index.php?topic=11178.0 SF Chiropractor accepts BTC for office visits]</ref><br />
|-<br />
|2011-06-04<br />
|First real estate offered for Bitcoin. A beach condo<ref>[http://www.bitcointalk.org/index.php?topic=12185.0 Beach Condo]</ref> and a house<ref>[http://forum.bitcoin.org/index.php?topic=12466.0 House]</ref> were offered within hours of each other<br />
|-<br />
|2011-10-30<br />
|First Bitcoin mining on an in-flight airplane using wifi. Unknown if any Bitcoins were actually created in flight<ref>[http://bitcointalk.org/index.php?topic=50379.0 Mining at 18,000 feet]</ref><br />
|-<br />
|2011-12-19<br />
|First TV story based on Bitcoin<ref>[http://www.cbspressexpress.com/cbs-entertainment/releases/view?id=30177 CBS' "THE GOOD WIFE" episode]</ref><br />
|-<br />
|2012-02-16<br />
|Auto title loan for bitcoins requested<ref>[http://bitcointalk.org/index.php?topic=64199 Auto title loan for bitcoins requested]</ref><br />
|-<br />
|2012-03-24<br />
|First property management accepts bitcons for rent<ref>[http://bitcointalk.org/index.php?topic=73712.0 Property management accept bitcons for rent]</ref>. Over 100 commercial and residential properties<br />
|-<br />
|2012-03-27<br />
|First printed Bitcoin magazine is announced and then followed by photos<ref>[https://bitcointalk.org/index.php?topic=74346.0 first photos of Coineer]</ref><ref>[https://coineer.com Coineer - The Bitcoin Magazine available in print]</ref><br />
|-<br />
|2012-03-28<br />
|Amateur Adult Entertainers use Bitcoin for tips<ref>[http://reddit.com/r/GirlsGoneBitcoin Amateur Adult Entertainers use Bitcoin for tips]</ref><br />
|-<br />
|2012-03-29<br />
|Bitcoin-only Credit Default Swap (CDS)<ref>[http://bitcointalk.org/index.php?topic=74552.0 Bitcoin-only Credit Default Swap (CDS)] </ref><br />
|-<br />
|2012-04-19<br />
|US Based exchange gets Federally licensed as a MSB<ref>[http://payglo.be/2012/04/19/bitinstant-federally-licensed-bitcoin-exchange/ US Based exchange gets Federally licensed as a MSB]</ref><ref>[https://bitcointalk.org/index.php?topic=77194.msg857699#msg857699 US Based exchange gets Federally licensed as a MSB 2]</ref><br />
|-<br />
|2012-04-20<br />
|Bitcoinica.com gets licensed as a MSB<ref>[http://bitcoinmedia.com/first-licensed-advanced-trading-platform-for-bitcoin/ Bitcoinica.com gets licensed as a MSB]</ref><br />
|-<br />
|2012-04-25<br />
|First Music album sold for bitcoins exclusively – Before being sold on iTunes<ref>[https://www.coindl.com/page/item/127 Music album sold for bitcoins exclusively]</ref><br />
|-<br />
|2012-04-26<br />
|First WebCam site to accept Bitcoins<ref>[http://ptvheaven.com WebCam site to accept Bitcoins]</ref>. Bitcoins accepted as an alternative payment. Entertainer payouts are not in Bitcoin.<br />
|-<br />
|2012-04-29<br />
|First Bitcoin only live webcam site<ref>[http://www.cam4btc.co.cc/ Bitcoin only live webcam site]</ref>. Bitcoin tips go directly to entertainers. Site operates on tips.<br />
|-<br />
|2012-05-01<br />
|Bitcoin Magazine<ref>[[Bitcoin Magazine]]</ref><ref>[http://bitcoinmagazine.net/bitcoin-magazine-press-release/ Press release] as first issue goes to print</ref><br />
|-<br />
|2012-05-01<br />
|Race horse named after Satoshi<ref>[http://www.satoshisdaemon.com/ Race horse named after Satoshi]</ref><ref>http://www.thebitcointrader.com/2012/04/bitcoin-horse-to-run-first-race-on-may.html</ref><br />
|-<br />
| 2012-05-09<br />
| First formal risk assessment by a government agency<ref>[http://bitcointalk.org/index.php?topic=80173.0 Discussion of Leaked FBI Report on Bitcoin- April 2012]</ref><br />
|-<br />
| 2012-05-09<br />
|Sold San Francisco Bridge<ref>[https://bitcointalk.org/index.php?topic=80485.msg890710#msg890710 Sold San Francisco Bridge]</ref>. Another traditional first for a new currency. (likely not authentic)<br />
|-<br />
| 2012-05-18<br />
|First Bitcoin class in a public school<ref>[https://bitcointalk.org/index.php?topic=82046.msg908451#msg908451 Bitcoin taught in a public school]</ref>. It was a 4th grade class<br />
|-<br />
| 2012-06-06<br />
|First Bitcoin donations to contribute to a successful anti-corrupt local government political campaign<ref>[https://bitcointalk.org/index.php?topic=74219.msg945392#msg945392 Bitcoin donations contribute to successful anti-corrupt local government political campaign]</ref>. Travis Kiger, running against a Fullerton City counsel that turned a blind eye to the death of Kelly Thomas at the hands of their local police department, promoted the use of Bitcoin to fund his campaign and won the councel seat for his district.<br />
|-<br />
| 2012-07-23<br />
| First car producers offer their vehicle for Bitcoin<ref>[https://bitcointalk.org/index.php?topic=94820.msg1048706#msg1048706 Automaker offers their vehicle for Bitcoin]</ref>. WikiSpeed is a Seattle based corporation that manufactures open source modular cars that get 100 MPG and accept Bitcoin as payment<br />
|-<br />
| 2012-08-06<br />
| First Bitcoin lawsuit<ref>[https://docs.google.com/file/d/0B_ECG6JRZs-7dTZ5QS0xcUkxQjQ/edit?pli=1# Bitcoin lawsuit]</ref>. Brian Cartmell filed a lawsuit against [[Bitcoinica]], a former Bitcoin margin trading platform that got hacked and hasen't returned customers' funds.<br />
|-<br />
| 2012-08-24<br />
| First private medical practice accepts Bitcoin<ref>[http://meidanklinikka.fi Private medical practice accepts Bitcoin]</ref>. It's a dentist in Finland.<br />
|-<br />
| 2012-09-14<br />
| First warrant to seize Bitcoins<ref>[http://www.americanbanker.com/bankthink/plot-thickens-in-bizarre-bitcoin-blackmail-caper-1054312-1.html First warrant to seize Bitcoin]</ref>. U.S. Secret Service seizing Michael M. Brown's bitcoins in the Romney Taxes For Ransom case.<br />
|-<br />
| 2012-09-26<br />
| First Taxi service accepts Bitcoin<ref>[http://www.taxizen.co.uk Taxi service accepts Bitcoin]</ref> (in Herefordshire, UK.)<br />
|-<br />
| 2012-11-15<br />
| First big<ref>[http://www.alexa.com/siteinfo/wordpress.com Wordpress.com at Alexa.com]</ref> website<ref>[http://en.blog.wordpress.com/2012/11/15/pay-another-way-bitcoin/ Wordpress accepts Bitcoin]</ref> accepts Bitcoin<br />
|}<br />
<br />
==See Also==<br />
<br />
* [[History]]<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Introduction]]</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Bitcoin_Firsts&diff=32666Bitcoin Firsts2012-11-16T04:41:46Z<p>Giszmo: Added Wordpress accepting Bitcoin</p>
<hr />
<div>First examples of bitcoins being accepted for various goods and services and other notable first occurances. See discussion for more regarding what is suitable here.<br />
<br />
{| class="wikitable"<br />
! &nbsp;Event&nbsp;Date&nbsp;<br />
! Link <br />
! Notes<br />
|- <br />
| 2009-01-12<br />
| [http://blockexplorer.com/b/170 Block 170]<br />
| First bitcoin transaction on the network. From Satoshi to Hal Finney<ref>[https://bitcointalk.org/index.php?topic=91806.msg1012234#msg1012234 Earliest Block With A Spend]</ref>.<br />
|- <br />
| 2010-05-17<br />
| [http://www.bitcointalk.org/index.php?topic=137.0 Pizza]<br />
| First recorded purchase of a good (pizza). Cost 10,000 BTC.<br />
|-<br />
|2011-03-21<br />
| [http://www.bitcointalk.org/index.php?topic=4752.0 Road trip]<br />
| Plato travels using only Bitcoin to survive.<br />
|-<br />
| 2011-01-06<br />
| [http://www.bitcoinblogger.com/2011/01/power-of-bitcoins.html Mobile marketing gig]<br />
| Guy pays random guy for work performed (holding a sign on a busy intersection).<br />
|-<br />
| 2011-05-09<br />
| [[Bitbills]] <br />
| Physical incarnation of bitcoins. <br />
|-<br />
|2011-05-12<br />
|[http://www.bitcointalk.org/index.php?topic=8174.msg119235#msg119235 Room for rent] <br />
|<br />
|-<br />
|2011-05-17<br />
|[http://therealplato.com/post/5568777157 Tipped a stripper Bitcoins] <br />
|<br />
|-<br />
|2011-05-27<br />
| [http://www.bitcointalk.org/index.php?topic=10210.0 Buying aircraft for BTC] <br />
|<br />
|-<br />
|2011-06-01<br />
| [http://www.bitcointalk.org/index.php?topic=11178.0 SF Chiropractor accepts BTC for office visits] <br />
|<br />
|-<br />
|2011-06-04<br />
|[http://www.bitcointalk.org/index.php?topic=12185.0 Beach Condo] and [http://forum.bitcoin.org/index.php?topic=12466.0 House] <br />
|Offered within hours of each other.<br />
|-<br />
|2011-10-30<br />
|[http://bitcointalk.org/index.php?topic=50379.0 Mining at 18,000 feet]<br />
| Guy mines Bitcoin on an in-flight airplane using wifi. Unknown if any Bitcoins were actually created in flight.<br />
|-<br />
|2011-12-19<br />
|[http://www.cbspressexpress.com/cbs-entertainment/releases/view?id=30177 CBS' "THE GOOD WIFE" episode] <br />
|TV story based on Bitcoin<br />
|-<br />
|2012-02-16<br />
|[http://bitcointalk.org/index.php?topic=64199 Auto title loan for bitcoins requested] <br />
|<br />
|-<br />
|2012-03-24<br />
|[http://bitcointalk.org/index.php?topic=73712.0 Property management accept bitcons for rent] <br />
| Over 100 commercial and residential properties<br />
|-<br />
|2012-03-27<br />
|[https://coineer.com Coineer - The Bitcoin Magazine available in print]<br />
|The World's first printed Bitcoin magazine is announced and then [https://bitcointalk.org/index.php?topic=74346.0 followed by photos]<br />
|-<br />
|2012-03-28<br />
|[http://reddit.com/r/GirlsGoneBitcoin Amateur Adult Entertainers use Bitcoin for tips] <br />
|<br />
|-<br />
|2012-03-29<br />
|[http://bitcointalk.org/index.php?topic=74552.0 Bitcoin-only Credit Default Swap (CDS)] <br />
|<br />
|-<br />
|2012-04-19<br />
|[http://payglo.be/2012/04/19/bitinstant-federally-licensed-bitcoin-exchange/ US Based exchange gets Federally licensed as a MSB]<br />
|[https://bitcointalk.org/index.php?topic=77194.msg857699#msg857699 source]<br />
|-<br />
|2012-04-20<br />
|[http://bitcoinmedia.com/first-licensed-advanced-trading-platform-for-bitcoin/ Bitcoinica.com gets licensed as a MSB] <br />
|<br />
|-<br />
|2012-04-25<br />
|[https://www.coindl.com/page/item/127 Music album sold for bitcoins exclusively] <br />
|Before sold on iTunes<br />
|-<br />
|2012-04-26<br />
|[http://ptvheaven.com WebCam site to accept Bitcoins]<br />
|Bitcoins accepted as an alternative payment. Entertainer payouts are not in Bitcoin.<br />
|-<br />
|2012-04-29<br />
|[http://www.cam4btc.co.cc/ Bitcoin only live webcam site] <br />
|Bitcoin tips go directly to entertainers. Site operates on tips. Only accepts bitcoin.<br />
|-<br />
|2012-05-01<br />
|[[Bitcoin Magazine]]<br />
|[http://bitcoinmagazine.net/bitcoin-magazine-press-release/ Press release] as first issue goes to print<br />
|-<br />
|2012-05-01<br />
|[http://www.satoshisdaemon.com/ Race horse named after Satoshi]<br />
|http://www.thebitcointrader.com/2012/04/bitcoin-horse-to-run-first-race-on-may.html<br />
|-<br />
| 2012-05-09<br />
|[http://bitcointalk.org/index.php?topic=80173.0 Discussion of Leaked FBI Report on Bitcoin- April 2012] <br />
|Formal risk assessment by a government agency.<br />
|-<br />
| 2012-05-09<br />
|[https://bitcointalk.org/index.php?topic=80485.msg890710#msg890710 Sold San Francisco Bridge]<br />
|Another traditional first for a new currency. (likely not authentic)<br />
|-<br />
| 2012-05-18<br />
| [https://bitcointalk.org/index.php?topic=82046.msg908451#msg908451 Bitcoin taught in a public school]<br />
|4th grade class<br />
|-<br />
| 2012-06-06<br />
| [https://bitcointalk.org/index.php?topic=74219.msg945392#msg945392 Bitcoin donations contribute to successful anti-corrupt local government political campaign.]<br />
| Travis Kiger, running against a Fullerton City counsel that turned a blind eye to the death of Kelly Thomas at the hands of their local police department, promoted the use of Bitcoin to fund his campaign and won the councel seat for his district.<br />
|-<br />
| 2012-07-23<br />
| [https://bitcointalk.org/index.php?topic=94820.msg1048706#msg1048706 Automaker offers their vehicle for Bitcoin]<br />
| WikiSpeed is a Seattle based corporation that manufactures open source modular cars that get 100 MPG and accept Bitcoin as payment.<br />
|-<br />
| 2012-08-06<br />
| [https://docs.google.com/file/d/0B_ECG6JRZs-7dTZ5QS0xcUkxQjQ/edit?pli=1# Bitcoin lawsuit]<br />
| Brian Cartmell filed a lawsuit against [[Bitcoinica]], a former Bitcoin marging trading platform that got hacked and haven't returned customers' funds.<br />
|-<br />
| 2012-08-24<br />
| [http://meidanklinikka.fi Private medical practice accepts Bitcoin]<br />
| Dentist in Finland.<br />
|-<br />
| 2012-09-14<br />
| [http://www.americanbanker.com/bankthink/plot-thickens-in-bizarre-bitcoin-blackmail-caper-1054312-1.html First warrant to seize Bitcoin]<br />
| U.S. Secret Service seizing Michael M. Brown's bitcoins in the Romney Taxes For Ransom case.<br />
|-<br />
| 2012-09-26<br />
| [http://www.taxizen.co.uk Taxi service accepts Bitcoin]<br />
| Herefordshire, UK.<br />
|-<br />
| 2012-11-15<br />
| First big<ref>[http://www.alexa.com/siteinfo/wordpress.com Wordpress.com at Alexa.com]</ref> website<ref>[http://en.blog.wordpress.com/2012/11/15/pay-another-way-bitcoin/ Wordpress accepts Bitcoin]</ref> accepts Bitcoin<br />
|<br />
|}<br />
<br />
==See Also==<br />
<br />
* [[History]]<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Introduction]]</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Bitcoin_Firsts&diff=32665Bitcoin Firsts2012-11-16T04:33:55Z<p>Giszmo: At least on my system the dates were split up to two lines without these changes. Also Event Date is nicer than ISO Date</p>
<hr />
<div>First examples of bitcoins being accepted for various goods and services and other notable first occurances. See discussion for more regarding what is suitable here.<br />
<br />
{| class="wikitable"<br />
! &nbsp;Event&nbsp;Date&nbsp;<br />
! Link <br />
! Notes<br />
|- <br />
| 2009-01-12<br />
| [http://blockexplorer.com/b/170 Block 170]<br />
| First bitcoin transaction on the network. From Satoshi to Hal Finney<ref>[https://bitcointalk.org/index.php?topic=91806.msg1012234#msg1012234 Earliest Block With A Spend]</ref>.<br />
|- <br />
| 2010-05-17<br />
| [http://www.bitcointalk.org/index.php?topic=137.0 Pizza]<br />
| First recorded purchase of a good (pizza). Cost 10,000 BTC.<br />
|-<br />
|2011-03-21<br />
| [http://www.bitcointalk.org/index.php?topic=4752.0 Road trip]<br />
| Plato travels using only Bitcoin to survive.<br />
|-<br />
| 2011-01-06<br />
| [http://www.bitcoinblogger.com/2011/01/power-of-bitcoins.html Mobile marketing gig]<br />
| Guy pays random guy for work performed (holding a sign on a busy intersection).<br />
|-<br />
| 2011-05-09<br />
| [[Bitbills]] <br />
| Physical incarnation of bitcoins. <br />
|-<br />
|2011-05-12<br />
|[http://www.bitcointalk.org/index.php?topic=8174.msg119235#msg119235 Room for rent] <br />
|<br />
|-<br />
|2011-05-17<br />
|[http://therealplato.com/post/5568777157 Tipped a stripper Bitcoins] <br />
|<br />
|-<br />
|2011-05-27<br />
| [http://www.bitcointalk.org/index.php?topic=10210.0 Buying aircraft for BTC] <br />
|<br />
|-<br />
|2011-06-01<br />
| [http://www.bitcointalk.org/index.php?topic=11178.0 SF Chiropractor accepts BTC for office visits] <br />
|<br />
|-<br />
|2011-06-04<br />
|[http://www.bitcointalk.org/index.php?topic=12185.0 Beach Condo] and [http://forum.bitcoin.org/index.php?topic=12466.0 House] <br />
|Offered within hours of each other.<br />
|-<br />
|2011-10-30<br />
|[http://bitcointalk.org/index.php?topic=50379.0 Mining at 18,000 feet]<br />
| Guy mines Bitcoin on an in-flight airplane using wifi. Unknown if any Bitcoins were actually created in flight.<br />
|-<br />
|2011-12-19<br />
|[http://www.cbspressexpress.com/cbs-entertainment/releases/view?id=30177 CBS' "THE GOOD WIFE" episode] <br />
|TV story based on Bitcoin<br />
|-<br />
|2012-02-16<br />
|[http://bitcointalk.org/index.php?topic=64199 Auto title loan for bitcoins requested] <br />
|<br />
|-<br />
|2012-03-24<br />
|[http://bitcointalk.org/index.php?topic=73712.0 Property management accept bitcons for rent] <br />
| Over 100 commercial and residential properties<br />
|-<br />
|2012-03-27<br />
|[https://coineer.com Coineer - The Bitcoin Magazine available in print]<br />
|The World's first printed Bitcoin magazine is announced and then [https://bitcointalk.org/index.php?topic=74346.0 followed by photos]<br />
|-<br />
|2012-03-28<br />
|[http://reddit.com/r/GirlsGoneBitcoin Amateur Adult Entertainers use Bitcoin for tips] <br />
|<br />
|-<br />
|2012-03-29<br />
|[http://bitcointalk.org/index.php?topic=74552.0 Bitcoin-only Credit Default Swap (CDS)] <br />
|<br />
|-<br />
|2012-04-19<br />
|[http://payglo.be/2012/04/19/bitinstant-federally-licensed-bitcoin-exchange/ US Based exchange gets Federally licensed as a MSB]<br />
|[https://bitcointalk.org/index.php?topic=77194.msg857699#msg857699 source]<br />
|-<br />
|2012-04-20<br />
|[http://bitcoinmedia.com/first-licensed-advanced-trading-platform-for-bitcoin/ Bitcoinica.com gets licensed as a MSB] <br />
|<br />
|-<br />
|2012-04-25<br />
|[https://www.coindl.com/page/item/127 Music album sold for bitcoins exclusively] <br />
|Before sold on iTunes<br />
|-<br />
|2012-04-26<br />
|[http://ptvheaven.com WebCam site to accept Bitcoins]<br />
|Bitcoins accepted as an alternative payment. Entertainer payouts are not in Bitcoin.<br />
|-<br />
|2012-04-29<br />
|[http://www.cam4btc.co.cc/ Bitcoin only live webcam site] <br />
|Bitcoin tips go directly to entertainers. Site operates on tips. Only accepts bitcoin.<br />
|-<br />
|2012-05-01<br />
|[[Bitcoin Magazine]]<br />
|[http://bitcoinmagazine.net/bitcoin-magazine-press-release/ Press release] as first issue goes to print<br />
|-<br />
|2012-05-01<br />
|[http://www.satoshisdaemon.com/ Race horse named after Satoshi]<br />
|http://www.thebitcointrader.com/2012/04/bitcoin-horse-to-run-first-race-on-may.html<br />
|-<br />
| 2012-05-09<br />
|[http://bitcointalk.org/index.php?topic=80173.0 Discussion of Leaked FBI Report on Bitcoin- April 2012] <br />
|Formal risk assessment by a government agency.<br />
|-<br />
| 2012-05-09<br />
|[https://bitcointalk.org/index.php?topic=80485.msg890710#msg890710 Sold San Francisco Bridge]<br />
|Another traditional first for a new currency. (likely not authentic)<br />
|-<br />
| 2012-05-18<br />
| [https://bitcointalk.org/index.php?topic=82046.msg908451#msg908451 Bitcoin taught in a public school]<br />
|4th grade class<br />
|-<br />
| 2012-06-06<br />
| [https://bitcointalk.org/index.php?topic=74219.msg945392#msg945392 Bitcoin donations contribute to successful anti-corrupt local government political campaign.]<br />
| Travis Kiger, running against a Fullerton City counsel that turned a blind eye to the death of Kelly Thomas at the hands of their local police department, promoted the use of Bitcoin to fund his campaign and won the councel seat for his district.<br />
|-<br />
| 2012-07-23<br />
| [https://bitcointalk.org/index.php?topic=94820.msg1048706#msg1048706 Automaker offers their vehicle for Bitcoin]<br />
| WikiSpeed is a Seattle based corporation that manufactures open source modular cars that get 100 MPG and accept Bitcoin as payment.<br />
|-<br />
| 2012-08-06<br />
| [https://docs.google.com/file/d/0B_ECG6JRZs-7dTZ5QS0xcUkxQjQ/edit?pli=1# Bitcoin lawsuit]<br />
| Brian Cartmell filed a lawsuit against [[Bitcoinica]], a former Bitcoin marging trading platform that got hacked and haven't returned customers' funds.<br />
|-<br />
| 2012-08-24<br />
| [http://meidanklinikka.fi Private medical practice accepts Bitcoin]<br />
| Dentist in Finland.<br />
|-<br />
| 2012-09-14<br />
| [http://www.americanbanker.com/bankthink/plot-thickens-in-bizarre-bitcoin-blackmail-caper-1054312-1.html First warrant to seize Bitcoin]<br />
| U.S. Secret Service seizing Michael M. Brown's bitcoins in the Romney Taxes For Ransom case.<br />
|-<br />
| 2012-09-26<br />
| [http://www.taxizen.co.uk Taxi service accepts Bitcoin]<br />
| Herefordshire, UK.<br />
|-<br />
| 2012-11-09<br />
| [http://www.BitcoinFriday.com First Bitcoin Friday]<br />
| First organized promotion involving over sixty Bitcoin merchants.<br />
|}<br />
<br />
==See Also==<br />
<br />
* [[History]]<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Introduction]]</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Help_talk:Introduction&diff=32622Help talk:Introduction2012-11-14T15:53:55Z<p>Giszmo: /* What's an EFT? */</p>
<hr />
<div>I would like to create this page, describing bitcoin in an easy manner.<br />
---<br />
<br />
"These bitcoins are valuable because they require the spending of real resources (CPU time and electricity) to produce,"<br />
<br />
this seems to me the cost-theory of value, which is a fallacy. Digging holes in the ground requires spending of resources too.<br />
<br />
--<br />
<br />
Good page, but I was expecting a more concise introduction. Perhaps give it a more punchy, concise start?<br />
<br />
--[[User:Mcnalu|Mcnalu]] 14:43, 15 May 2011 (GMT)<br />
<br />
The idea for the "resources" talk was that people who spend CPU time and electricity to mine bitcoins will not want to simply give it away for free. The people who buy it from them later in exchange for something valuable also won't want to give it away cheaper, and so on. I think this kind of talk makes sense if you wish to promote Bitcoin because if you talk to people about it, basing its "worth" on how many people are already using it (how "useful" it is), you are conceding to Bitcoin's being subject to network effects, which, if it is, it is not going to survive. I hate to see great ideas like this going down because of stupid chicken-and-egg problems.<br />
<br />
I suppose it's easy to present this all as useless electricity wasting, but at least it's based on something real. You spend this much electricity/CPU time, you get this many bitcoins. The alternative is the "good" old papers+guns system. What is that based on?<br />
<br />
I haven't been following the arguments about the "gold standard" and whether it's "good" or "bad", and things like that. Haven't been in the forum much lately. Perhaps we could argue indefinitely about this. IMO, it's better for Bitcoin if the introduction talks about tangible things (maybe electricity isn't "tangible" but at least it's not dependent on people).<br />
<br />
I'm going to change the phrase to talk about both the "usefulness" and the resources.<br />
<br />
--[[User:Prcarter|Prcarter]] 06:29, 8 September 2011 (GMT)<br />
<br />
This introduction shows Bitcoin's place and how it relates to the traditional banking system. It's to make people conscious of what is really going on and of the level of trust they are already placing on banks and those printed pieces of paper we base our survival on. I would hate a "buy bitcoins, they are cool"-type "promo".<br />
<br />
--[[User:Prcarter|Prcarter]] 06:40, 8 September 2011 (GMT)<br />
<br />
Yes, "maintaining account balances" tones it down a little.<br />
<br />
--[[User:Prcarter|Prcarter]] 06:44, 8 September 2011 (GMT)<br />
<br />
I had to change this back. Bitcoins do not have value because they take labor or electricity to create. See http://en.wikipedia.org/wiki/Labor_theory_of_value#The_relation_between_values_and_prices<br />
While it is true that the value will tend to the cost of production, that is incidental. <br />
--[[User:Atheros|Atheros]] 02:59, 25 October 2011 (GMT)<br />
<br />
== it.bitcoin.it ==<br />
<br />
I've started filling-in a few sections of the Italian version it.bitcoin.it. If you don't mind, I am using this page as the basis. So, I'm translating it and tightening it up at the same time. Would it be OK? I've also added a summary, using the bitcoin entry in wikipedia.<br />
<br />
ciao<br />
<br />
[[User:Gianco|Gianco]] 19:50, 16 June 2011 (GMT)<br />
<br />
==Banking and Money, in general==<br />
<br />
I am not sure about all the users of this site who are interested in and trying to understand BitCoin (as I am), but personally, I found myself, even quite recently, without an understanding about how banking and money works at all. The Khan Academy video series on banking and money was very helpful, I thought perhaps you might want to include a link in the Introduction and Basic Concepts. http://www.khanacademy.org/#banking-and-money<br />
I think the more regular people can understand these basic things, the more they will be interested and engaged.<br />
<br />
Thanks and great work so far it seems<br />
<br />
[[User:Cruiser moves|Cruiser moves]] 12:44, 23 June 2011 (GMT)<br />
<br />
== Confusion : how the Money is valued ==<br />
<br />
The introduction is not upfront enough as to how Bitcoins get their value and why people are prepared to except them as money.ie We need on overview of the introduction to explain this without the explainations as to how they are created and cannot be duplicated. I gather what happens is that as long as there are enough people with things to sell and willing buyers then the money then gets its value due to its expanding usage.That is someone who has sold something can then turn around and buy something else with a bitcoin. Is that right?<br />
And since the coins themselves are made scare by the design of their creation(time and energy) and their intrinsic unforgability (due to the mathematics) they then can be traded with confidence.Yes?<br />
<br />
== What's an EFT? ==<br />
--[[User:Jepo|Jepo]] ([[User talk:Jepo|talk]]) 04:17, 25 October 2012 (GMT)<br />
: Good question. My guess would be it's either [https://en.wikipedia.org/wiki/Electronic_funds_transfer Electronic Funds Transfer] or [https://en.wikipedia.org/wiki/Emotional_Freedom_Technique Emotional Freedom Technique]<br />
: [[User:Giszmo|Giszmo]] ([[User talk:Giszmo|talk]]) 15:53, 14 November 2012 (GMT)</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Help:Introduction&diff=32621Help:Introduction2012-11-14T15:51:26Z<p>Giszmo: /* Banks */ linked EFT to electronic funds transfer on wikipedia</p>
<hr />
<div>The purpose of this page is to provide a general overview of the Bitcoin system and economy.<br />
<br />
==Basic Concepts==<br />
<br />
===Currency===<br />
<br />
Alice wants to buy the [http://www.grasshillalpacas.com/alpacaproductsforbitcoinoffer.html Alpaca socks] which Bob has for sale. In return, she is to provide something of equal value to Bob. The most efficient way to do this is by using a medium of exchange that Bob accepts which would be classified as currency. Currency makes trade easier by eliminating the need for [http://en.wikipedia.org/wiki/Coincidence_of_wants coincidence of wants] required in other systems of trade such as barter. Currency adoption and acceptance can be global, national, or in some cases local or community-based.<br />
<br />
===Banks===<br />
<br />
Alice needs not provide currency to Bob in-person. She may instead transfer this value by first entrusting her currency to a bank who promises to store and protect Alice's currency notes. The bank gives Alice a written promise (called a "bank statement") that entitles her to withdraw the same number of currency bills that she deposited. Since the money is still Alice's, she is entitled to do with it whatever she pleases, and the bank (like most banks), for a small fee, will do Alice the service of passing on the currency bills to Bob on her behalf. This is done by Alice's bank by giving the dollar bills to Bob's bank and informing them that the money is for Bob, who will then see the amount the next time he checks his balance or receives his bank statement.<br />
<br />
Since banks have many customers, and bank employees require money for doing the job of talking to people and signing documents, banks in recent times have been using machines such as ATMs and web servers that do the job of interacting with customers instead of paid bank employees. The task of these machines is to learn what each customer wants to do with their money and, to the extent that it is possible, act on what the customer wants (for example, ATMs can hand out cash). Customers can always know how much money they have in their accounts, and they are confident that the numbers they see in their bank statements and on their computer screens accurately reflect the number of dollars that they can get from the bank on demand. They can be so sure of this that they can accept those numbers in the same way they accept paper banknotes (this is similar to the way people started accepting paper dollars when they had been accepting gold or silver).<br />
<br />
Such a system has several disadvantages:<br />
* It is costly. [https://en.wikipedia.org/wiki/Electronic_funds_transfer EFTs] in Europe can cost 25 euros. Credit transactions can cost several percent of the transaction.<br />
* It is slow. Checking and low cost wire services take days to complete.<br />
* In most cases, it cannot be anonymous.<br />
* Accounts can be frozen. <br />
* Banks and other payment processors like PayPal, Visa, and Mastercard may refuse to process payments for legal entities. <br />
<br />
<br />
Bitcoin is a system of owning and voluntarily transferring amounts of so-called ''bitcoins'', in a manner similar to an on-line banking, but pseudonymously and without reliance on a central authority to maintain account balances. If bitcoins are valuable, it is because they are useful and limited in supply.<br />
<br />
==Bitcoin Basics==<br />
<br />
===Creation of coins===<br />
The creation of coins must be limited for the currency to have any value. <br />
<br />
New coins are slowly [[Mining|mined]] into existence by following a mutually agreed-upon set of rules. A user [[Mining|mining]] bitcoins is running a software program that searches tirelessly for a solution to a very difficult math problem whose difficulty is precisely known. The difficulty is automatically adjusted regularly so that the number of solutions found globally, by everyone, is constant: an average of 6 per hour. When a solution is found, the user may tell everyone of the existence of this newly found solution, along with other information, packaged together in what is called a "[[Block|block]]". <br />
<br />
Blocks contain 50 bitcoins at present. This amount, known as the block reward, is an incentive for people to perform the computation work required for generating blocks. Roughly every 4 years, the number of bitcoins that can be "mined" in a block reduces by 50%. Any block that is created by a malicious user that does not follow this rule (or any other rules) will be rejected by everyone else. In the end, no more than 21 million bitcoins will ever exist. <br />
<br />
Because the block reward will decrease over the long term, miners will some day instead pay for their hardware and electricity costs by collecting [[Transaction_fee|transaction fees]]. The sender of money may voluntarily pay a small transaction fee which will be kept by whomever finds the next block. Paying this fee will encourage miners to include the transaction in a block more quickly.<br />
<br />
===Sending payments===<br />
To guarantee that a third-party, let's call her Eve, cannot spend other people's bitcoins by creating transactions in their names, Bitcoin uses [[Wikipedia:Public-key_cryptography|public key cryptography]] to make and verify digital signatures. In this system, each person, such as Alice or Bob, has one or more addresses each with an associated pair of public and private keys that they may hold in a [[Wallet|wallet]]. Only the user with the private key can sign a transaction to give some of their bitcoins to somebody else, but anyone can validate the signature using that user’s public key.<br />
<br />
Suppose Alice wants to send a bitcoin to Bob.<br />
* Bob sends his address (from which the public key can be derived) to Alice.<br />
* Alice adds Bob’s public key and the amount of bitcoins to transfer to a message: a 'transaction' message.<br />
* Alice signs the transaction with her private key.<br />
* Alice broadcasts the transaction on the Bitcoin network for all to see.<br />
<br />
(Only the first two steps require human action. The rest is done by the Bitcoin client software.)<br />
<br />
Looking at this transaction from the outside, anyone who knows that these addresses belong to Alice and Bob can see that Alice has agreed to transfer the amount to Bob, because nobody else has Alice's private key. Alice would be foolish to give her private key to other people, as this would allow them to sign transactions in her name, removing funds from her control.<br />
<br />
Later on, when Bob wishes to transfer the same bitcoins to Charley, he will do the same thing:<br />
* Charlie sends Bob his address.<br />
* Bob adds Charlie's public key and the amount of bitcoins to transfer to a message: a 'transaction' message.<br />
* Bob signs the transaction with his private key.<br />
* Bob broadcasts the transaction on the Bitcoin network for all to see. <br />
<br />
Only Bob can do this because only he has the private key that can create a valid signature for the transaction.<br />
<br />
Eve cannot change whose coins these are by replacing Bob’s public key with her public key, because Alice signed the transfer to Bob using her own private key, which is kept secret from Eve, and instructing that the coins which were hers now belong to Bob. So if Charlie accepts that the original coin was in the hands of Alice, he will also accept the fact that this coin was later passed to Bob, and now Bob is passing this same coin to him.<br />
<br />
===Preventing [[double-spending]]===<br />
The process described above does not prevent Alice from using the same bitcoins in more than one transaction. The following process does; this is the primary innovation behind Bitcoin.<br />
<br />
* Details about the [[Transactions|transaction]] are [[Network|sent and forwarded]] to all or as many other computers as possible.<br />
* A constantly growing chain of [[Blocks|blocks]] that contains a record of all transactions is collectively maintained by all computers (each has a full copy).<br />
* To be accepted in the chain, transaction blocks must be valid and must include [[proof of work]] (one block generated by the network every 10 minutes).<br />
* Blocks are chained in a way so that, if any one is modified, all following blocks will have to be recomputed.<br />
* When multiple valid continuations to this chain appear, only the longest such branch is accepted and it is then extended further.<br />
<br />
When Bob sees that his transaction has been included in a block, which has been made part of the single longest and fastest-growing block chain (extended with significant computational effort), he can be confident that the transaction by Alice has been accepted by the computers in the network and is permanently recorded, preventing Alice from creating a second transaction with the same coin. In order for Alice to thwart this system and double-spend her coins, she would need to muster more computing power than all other Bitcoin users combined.<br />
<br />
===Anonymity===<br />
When it comes to the Bitcoin network itself, there are no "accounts" to set up, and no e-mail addresses, user-names or passwords are required to hold or spend bitcoins. Each balance is simply associated with an address and its public-private key pair. The money "belongs" to anyone who has the private key and can sign transactions with it. Moreover, those keys do not have to be registered anywhere in advance, as they are only used when required for a transaction. Transacting parties do not need to know each other's identity in much the same way that a store owner does not know a cash-paying customer's name.<br />
<br />
A [[Address|Bitcoin address]] mathematically corresponds to a public key and looks like this:<br />
<br />
:1PC9aZC4hNX2rmmrt7uHTfYAS3hRbph4UN<br />
<br />
Each person can have many such addresses, each with its own balance, which makes it very difficult to know which person owns what amount. In order to protect his [[Anonymity|privacy]], Bob can generate a new public-private key pair for each individual receiving transaction and the Bitcoin software encourages this behavior by default. Continuing the example from above, when Charlie receives the bitcoins from Bob, Charlie will not be able to identify who owned the bitcoins before Bob without further information.<br />
<br />
===Capitalization / Nomenclature===<br />
Since Bitcoin is both a currency and a protocol, capitalization of Bitcoin can be confusing. Generally accepted practice is to use Bitcoin (singular, with upper case letter b) to describe the protocol, network, and software, and bitcoin(s) (singular or plural, with lower case letter b) to describe actual bitcoins, as generated by computers. For example, you may have some bitcoins but when you run the program you are using Bitcoin.<br />
<br />
==Where to see and explore==<br />
You can directly explore the system in action by visiting [http://blockchain.info/ Blockchain.info] or [http://blockexplorer.com/ Bitcoin Block Explorer].<br />
The site shows you the latest blocks in the block chain. The [[Block_chain|block chain]] contains the agreed history of all transactions that took place in the system.<br />
Note how many blocks were generated in the last hour, which on average will be 6. Also notice the number of transactions and the total amount transferred in the last hour (last time I checked it was about 64 and 15K).<br />
This should give you an indication of how active the system is.<br />
<br />
Next, navigate to one of these blocks.<br />
The block's [[hash]] begins with a run of zeros. This is what made creating the block so difficult; a hash that begins with many zeros is much more difficult to find than a hash with few or no zeros. The computer that generated this block had to try many ''Nonce'' values (also listed on the block's page) until it found one that generated this run of zeros.<br />
Next, see the line titled ''Previous block''. Each block contains the hash of the block that came before it. This is what forms the chain of blocks.<br />
Now take a look at all the transactions the block contains. The first transaction is the income earned by the computer that generated this block. It includes a fixed amount of coins created out of "thin air" and possibly a fee collected from other transactions in the same block.<br />
<br />
Drill down into any of the transactions and you will see how it is made up of one or more amounts coming in and out.<br />
Having more than one incoming and outgoing amount in a transaction enables the system to join and break amounts in any possible way, allowing for any fractional amount needed. Each incoming amount is a past transaction (which you can also view) from someone's address, and each outgoing amount is addressed to someone and will be part of a future transaction (which you can also navigate down into if it has already taken place.)<br />
<br />
Finally you can follow any of the [[Address|addresses]] links and see what public information is available for them.<br />
<br />
To get an impression of the amount of activity on the Bitcoin network, you might like to visit the monitoring websites [[Bitcoin Monitor]] and [[Bitcoin Watch]]. The first shows a real-time visualization of events on the Bitcoin network, and the second lists general statistics on the amount and size of recent transactions.<br />
<br />
===How many people use Bitcoin?===<br />
<br />
This is quite a difficult question to answer accurately. One approach is to count how many bitcoin clients connected to the network in the last 24 hours. We can do this because some clients transmit their addresses to the other members of the network periodically. In September 2011 this method suggested that there were about {{formatnum:60000}} users.<br />
<br />
==See Also==<br />
<br />
* [http://www.youtube.com/watch?v=Um63OQz3bjo What is Bitcoin?] video introduction<br />
* Installing Bitcoin [[getting started]] <br />
* [[How bitcoin works]]<br />
* [[Using Bitcoin]]<br />
* A gentle introduction to Bitcoin - [[BitcoinMe]]<br />
* [http://coinlab.com/2011/12/bitcoin-primer Bitcoin Primer] from CoinLab<br />
* Another introduction, ''The Rebooting Of Money'' podcast is found at [[Bitcoin Money]]<br />
* A beginner's step-by-step guide to using Bitcoin, use of alternative wallets, and generally keeping your money and computer secure - [http://BitcoinIntro.com BitcoinIntro.com]<br />
* [http://howtobitcoin.info howtobitcoin.info] Directory of bitcoin links for beginners<br />
* Amazon Kindle Book [http://www.amazon.com/Bitcoin-Step-by-ebook/dp/B00A1CUQQU Bitcoin Step by Step] $3.99 (USD). The author walks you step by step through getting started.<br />
<br />
[[zh-cn:简介]]<br />
<br />
[[de:Einführung]]</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Pooled_mining&diff=32620Pooled mining2012-11-14T15:45:00Z<p>Giszmo: /* External links */ removed a link spam (most likely others of the external link lis thave little to do with the article neither)</p>
<hr />
<div>'''Pooled mining''' is a [[Mining|mining]] approach where multiple generating clients contribute to the generation of a block, and then split the block reward according the contributed processing power. Pooled mining effectively reduces the granularity of the block generation reward, spreading it out more smoothly over time.<br />
<br />
==Introduction==<br />
<br />
With increasing generation difficulty, mining with lower-performance devices can take a very long time before block generation, on average. For example, with a mining speed of 1000 Khps, at a difficulty of 14484 (which was in effect at the end of December, 2010), the average time to generate a block is almost 2 years. <br />
<br />
To provide a more smooth incentive to lower-performance miners, several pooled miners, using different approaches, have been created. With a mining pool, a lot of different people contribute to generating a block, and the reward is then split among them according to their processing contribution. This way, instead of waiting for years to generate 50btc in a block, a smaller miner may get a fraction of a bitcoin on a more regular basis.<br />
<br />
A '''share''' is awarded by the mining pool to the clients who present a valid [[proof of work]] of the same type as the proof of work that is used for creating [[block|blocks]], but of lesser difficulty, so that it requires less time on average to generate.<br />
<br />
==Pooled mining approaches==<br />
<br />
The problem with pooled mining is that steps must be taken to prevent cheating by the clients and the server. Currently there are several different approaches used.<br />
<br />
===The slush approach===<br />
<br />
[[Bitcoin Pooled Mining]] (BPM), sometimes referred to as "slush's pool", follows a score-based method. Older shares (from beginning of the round) have lower weight than more recent shares, which reduces the motivation to cheat by switching between pools within a round.<br />
<br />
===The puddinpop approach===<br />
<br />
(As of February, 2011, there are no puddinpop pools running.)<br />
<br />
Another approach is the 'metahash' technique, used by puddinpop's [[remote miner]]. Clients generate hashes, and also submit 'metahashes', which are hashes of a large chunk of generated hashes. The server checks that the metahashes are correct (in a round-robin fashion, picking up a metahash from a client that hasn't been checked on the longest), thus preventing clients from simply claiming that they have done work without actually doing it. The withholding of good blocks by the clients is prevented by the server's possession of the private key, just as in the previous approach. Rewards are distributed based on the number of metahashes submitted by the clients.<br />
<br />
The generated blocks contain multiple keys in the generation transaction, giving fractional bitcoin amounts to each key in proportion to their hashing contribution for that block.<br />
<br />
===The Pay-per-Share approach===<br />
<br />
The Pay-per-Share (PPS) approach, first described by [[BitPenny]], is to offer an instant flat payout for each share that is solved. The payout is offered from the pool's existing balance and can therefore be withdrawn immediately, without waiting for a block to be solved or confirmed. The possibility of cheating the miners by the pool operator and by timing attacks is thus completely eliminated. <br />
<br />
This method results in the least possible variance for miners while transferring all risk to the pool operator. The resulting possibility of loss for the server is offset by setting a payout lower than the full expected value.<br />
<br />
===Luke-Jr's approach ("[[Eligius]]")===<br />
[[User:Luke-Jr|Luke]] came up with a third approach borrowing strengths from the earlier two.<br />
Like slush's approach, miners submit proofs-of-work to earn shares.<br />
Like puddinpop's approach, the pool pays out immediately via block generation.<br />
When distributing block rewards, it is divided equally among all shares since the last valid block.<br />
Unlike any preexisting pool approach, this means that the shares contributed toward orphaned blocks are recycled into the next block's shares.<br />
In order to spare participating miners from transaction fees, rewards are only paid out if a miner has earned at least 0.67108864 BTC (400 [[Tonal Bitcoin|TBC]]). If the amount owed is less, it will be added to the earnings of a later block (which may then total over the threshold amount).<br />
If a miner does not submit a share for over a week, the pool sends any balance remaining, regardless of its size.<br />
<br />
===The Triplemining approach===<br />
The [[Triplemining]] approach is to bring together a medium-sized pool with no fees and clever redistribution of 1% of every found block to allow your share to grow more rapidly than on any other bitcoin mining pool. <br />
<br />
For every found block, Triplemining redistributes 1% of the profits to all minipool owners (people with 1 or more friends mining with them). The redistribution is connected to the shares found by the members of the minipool. So if the hash rate of the minipool members equals or is bigger than yours, the part in the redistribution will be equally bigger.<br />
<br />
===P2Pool approach===<br />
<br />
[[P2Pool]] mining nodes work on a chain of shares similar to Bitcoin’s blockchain. When a block is found, the reward is divided among the most recent shares in this share-blockchain. Like the puddinpop and Luke-Jr approaches, p2pool pays via generation.<br />
<br />
===Comparison===<br />
<br />
The cooperative mining approach (slush and Luke-Jr) uses a lot less resources on the pool server, since rather than continuously checking metahashes, all that has to be checked is the validity of submitted shares. The number of shares sent can be adjusted by adjusting the artificial difficulty level.<br />
<br />
Further, the cooperative mining approach allows the clients to use existing miners without any modification, while the puddinpop approach requires the custom pool miner, which are as of now not as efficient on GPU mining as the existing GPU miners.<br />
[[File:Smallgeneration.png|thumb|Puddinpop miners receive coins directly.]]<br />
<br />
Additionally, the puddinpop and Luke-Jr approaches of distributing the earnings by way of including precise sub-cent amounts in the generation transaction for the participants, results in the presence of sub-cent bitcoin amounts in your wallet, which are liable to disappear (as unnecessary fees) later due to a bug in old (before 0.3.21) bitcoin nodes. (E.g., if you have a transaction with 0.052 in your wallet, and you later send .05 to someone, your .002 will disappear.).<br />
<br />
Puddinpop and Luke-Jr miners receive coins directly, which eliminates the delay in receiving earnings that is required on slush-based mining servers. However, using some [[eWallet]] services like MyBitcoin for generated coin will cause those coins to be lost.<br />
<br />
==See Also==<br />
<br />
* [[:Category:Miners|Miners]]<br />
* [[Poolservers]]<br />
* [[Comparison of mining pools]]<br />
* [[:Category:Pool Operators|Pool Operators]]<br />
* [[Why a GPU mines faster than a CPU]]<br />
* [[Why pooled mining]]<br />
* [[Mining pool reward FAQ]]<br />
<br />
==External links==<br />
* [http://btcserv.net BTCSERV.net - Bitcoin Pool]<br />
* [http://21bitcoin.com/pool/ 21bitcoin mining pool, Chinese Interface]<br />
* [http://mining.bitcoin.cz slush's mining pool]<br />
* [http://www.bitcash.cz bitcash.cz - czech mining pool]<br />
* [http://www.bitcoin.org/smf/index.php?topic=1458.0 puddinpop's mining pool thread]<br />
* [http://blockexplorer.com/block/00000000000233334b157d901714baf59e5b9236227b2878844e52244da4195e example puddinpop block]<br />
* [http://bitclockers.com bitclockers mining pool]<br />
* [https://pool.itzod.ru pool.itzod.ru mining pool] <br />
* [https://50btc.com 50btc.com mining pool] <br />
* [http://forum.bitcoin.org/index.php?topic=18313 P2Pool forum]<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Mining]]</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Talk:Tonal_Bitcoin&diff=31184Talk:Tonal Bitcoin2012-09-24T02:40:49Z<p>Giszmo: Undo revision 31117 by Luke-jr (talk) as usual undid Luke's censorship of the discussion</p>
<hr />
<div>The point of Bitcoin is that it is a decentralized peer to peer currency. <br />
That is the novelty about Bitcoin; the novelty is NOT that it comes along with a funky new way of counting things.<br />
So please stop using Bitcoin to promote your own agenda ; this is just going to confuse people.<br />
If you want to introduce a new method for counting currency, I suggest you go talk to the FED and propose the Tonal Dollar, or whatever.<br />
[[User:ThomasV|ThomasV]] 14:33, 20 February 2011 (GMT)<br />
* If Bitcoin has only one purpose, then it will never succeed. There are about as many people that care about a "decentralized peer to peer currency" as there are that care about Tonal. If you want BitCoin to succeed, you should support as many (legal) reasons to use it as possible. Also, whether it's ever enforced or not, vandalism and trolling should be bannable offenses. --[[User:Luke-jr|Luke-jr]] 04:43, 21 February 2011 (GMT)<br />
<br />
This page should be deleted.<br />
Nothing against Tonal, if there was a Hexadecimal Bitcoin or an Octal Bitcoin I would suggest those get deleted, too.<br />
* Seconded. Tonal is not a key part of bitcoin, and currently not used in any form. If there is a reasonable number of users using tonal, then I would have no objections against this page. [[User:Mqrius|Mqrius]] 05:11, 2 February 2012 (GMT)<br />
<br />
This is silly. I thought you'd removed this already, but it's seeping across to other pages despite me never seeing it in the wild. It serves only to confuse [[User:Gigitrix|Gigitrix]] 01:41, 13 June 2011 (GMT)<br />
<br />
I agree with Gavin that this page should be deleted. Regardless of my personal opinion or the technical merits of tonal v. decimal, it's fair to say that tonal attracts scorn and ridicule from the vast majority of the population if they hear about it. Bitcoin's reputation suffers from the association. [[User:ByteCoin|ByteCoin]] 24 June 2011 (GMT)<br />
* It's not fair to say that, no. --[[User:Luke-jr|Luke-jr]] 00:45, 25 June 2011 (GMT)<br />
<br />
I have no legitimate stake in the matter, I made a few edits that I hope remove POV and still embrace the idea of Tonal Bitcoin. This is Raize, I am sorry I am not familiar enough with wiki editing to provide my signature. --[[User:Raize|Raize]]<br />
<br />
<br />
<br />
I think this page needs a much clearer explanation of what is being documented and would be better if it had a more descriptive name.<br />
<br />
The page could be renamed somthing like "describing and writing amounts of BTC using Tonal numbers"<br />
<br />
How about replacing the first couple of sentances with<br />
<br />
"Currently most people who use bitcoin use decimal numbers to represent amounts of money. That means numbers using the digits 0 to 9. All known bitcoin software displays amounts of currency to user with decimal numbers.<br />
<br />
Luke-jr thinks that there are people out there use a base 16 number system, he is probably right in the sense that it is correct to say that some people speak Latin because there are a few hundred people on the planet who speak Latin fluently.<br />
<br />
This page is a proposal for a way that people who use a base 16 number system called the 'tonal system' could talk about or write down amounts of BTC.<br />
<br />
This is about as useful as a book about making chocolate teapots written in esperanto. There is no evidence that anyone other than Luke-jr has ever used non-decimal numbers for bitcoin."<br />
<br />
--[[User:Ziv|Ziv]]<br />
<br />
==Voting about deleting page==<br />
<br />
I also think this page should be deleted. There are at least three people suggesting this now, so I will re-add the delete tag to the page. So far there seems to be only one objection to the delete. I will initiate voting on this talk page. --[[User:Rebroad|Rebroad]] 22:48, 20 March 2012 (GMT)<br />
* '''Delete''' - I believe this tonal suggestion will only do harm to the bitcoin project, and so far the only person advocating it is luke-jr, who rarely gives any rational reasons that I nor anyone else AFAIK can understand. Sorry luke-jr, but I'm doing my best to get you to explain the benefits. --[[User:Rebroad|Rebroad]] 22:52, 20 March 2012 (GMT)<br />
*'''Delete''' - I've been lurking for a while, but I registered after seeing this nonsense here. Clearly if luke-jr is simply (and rather immaturely) blanking the discussion rather than responding to the specific points he has few arguments to marshal in his favor. --[[User:Zyzygy|Zyzygy]] ([[User talk:Zyzygy|talk]]) 05:14, 26 August 2012 (GMT)<br />
*'''Delete''' along with all other references to this bullshit one man show in history, firsts and maybe other places. It serves no other thing than to Luke's ego. Why should the wiki as a whole support this? Apparently he realized that he can't win with arguments as he just deleted this very discussion. --[[User:Giszmo|Giszmo]] ([[User talk:Giszmo|talk]]) 15:41, 27 August 2012 (GMT)<br />
*'''Delete''' because:<br />
# nobody knows it - it seems that all sources are from one person [[User:Luke-jr|Luke-jr]] and from 150 years old (!) book. There is no notability. Nobody after cares about it. There are no "tonal system community" or "people that are using tonal system" - tonal system uses just 1 person and he is trying to misappropriate Bitcoin for this<br />
# Tonal system is not at any way related to Bitcoin. Tonal system is related to numbers representation, not to monetary system. Please keep this page in general Wikipedia or some numeric Wikipedia, not in Bitcoin Wikipedia<br />
# Tonal units are very confusing - from technically point of view (font, writing it) and mainly there is very similar to decimal numbers - there are many cases in which is not clear which system is used. Also TBC is common typing error of BTC<br />
:'''Also I propose remove all notation about tonal from other wiki pages''', for example [[Units]] (very confusing), [[History]], [[Wallet protocol]] or [[Vocabulary]], and prevent them from reverting back (as happened several times). At least until Luke-jr (or someone else) find notable cites to keeping it here. [[User:Aleš Janda|Aleš Janda]] ([[User talk:Aleš Janda|talk]]) 19:44, 27 August 2012 (GMT)<br />
<br />
<br />
Luke-jr comment to voting: This is for discussion, not trolling. Note that this is not an encyclopedia, and does not have any "notability" requirements. If you don't want to use Tonal, don't. Trolling is not acceptable and will be deleted. Reasoned criticism is welcome in the "Criticism" section of the page.<br />
<br />
:What exactly from this discussion is "trolling"? I think you regard as trolling ANY critism. Don't clear discussion. Also, "Criticism" section is not good place to talk. [[User:Aleš Janda|Aleš Janda]] ([[User talk:Aleš Janda|talk]]) 09:16, 19 September 2012 (GMT)</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Talk:Tonal_Bitcoin&diff=30808Talk:Tonal Bitcoin2012-09-14T18:08:51Z<p>Giszmo: Undo revision 30779 by Luke-jr (talk)</p>
<hr />
<div>The point of Bitcoin is that it is a decentralized peer to peer currency. <br />
That is the novelty about Bitcoin; the novelty is NOT that it comes along with a funky new way of counting things.<br />
So please stop using Bitcoin to promote your own agenda ; this is just going to confuse people.<br />
If you want to introduce a new method for counting currency, I suggest you go talk to the FED and propose the Tonal Dollar, or whatever.<br />
[[User:ThomasV|ThomasV]] 14:33, 20 February 2011 (GMT)<br />
* If Bitcoin has only one purpose, then it will never succeed. There are about as many people that care about a "decentralized peer to peer currency" as there are that care about Tonal. If you want BitCoin to succeed, you should support as many (legal) reasons to use it as possible. Also, whether it's ever enforced or not, vandalism and trolling should be bannable offenses. --[[User:Luke-jr|Luke-jr]] 04:43, 21 February 2011 (GMT)<br />
<br />
This page should be deleted.<br />
Nothing against Tonal, if there was a Hexadecimal Bitcoin or an Octal Bitcoin I would suggest those get deleted, too.<br />
* Seconded. Tonal is not a key part of bitcoin, and currently not used in any form. If there is a reasonable number of users using tonal, then I would have no objections against this page. [[User:Mqrius|Mqrius]] 05:11, 2 February 2012 (GMT)<br />
<br />
This is silly. I thought you'd removed this already, but it's seeping across to other pages despite me never seeing it in the wild. It serves only to confuse [[User:Gigitrix|Gigitrix]] 01:41, 13 June 2011 (GMT)<br />
<br />
I agree with Gavin that this page should be deleted. Regardless of my personal opinion or the technical merits of tonal v. decimal, it's fair to say that tonal attracts scorn and ridicule from the vast majority of the population if they hear about it. Bitcoin's reputation suffers from the association. [[User:ByteCoin|ByteCoin]] 24 June 2011 (GMT)<br />
* It's not fair to say that, no. --[[User:Luke-jr|Luke-jr]] 00:45, 25 June 2011 (GMT)<br />
<br />
==Voting about deleting page==<br />
<br />
I also think this page should be deleted. There are at least three people suggesting this now, so I will re-add the delete tag to the page. So far there seems to be only one objection to the delete. I will initiate voting on this talk page. --[[User:Rebroad|Rebroad]] 22:48, 20 March 2012 (GMT)<br />
* '''Delete''' - I believe this tonal suggestion will only do harm to the bitcoin project, and so far the only person advocating it is luke-jr, who rarely gives any rational reasons that I nor anyone else AFAIK can understand. Sorry luke-jr, but I'm doing my best to get you to explain the benefits. --[[User:Rebroad|Rebroad]] 22:52, 20 March 2012 (GMT)<br />
*'''Delete''' - I've been lurking for a while, but I registered after seeing this nonsense here. Clearly if luke-jr is simply (and rather immaturely) blanking the discussion rather than responding to the specific points he has few arguments to marshal in his favor. --[[User:Zyzygy|Zyzygy]] ([[User talk:Zyzygy|talk]]) 05:14, 26 August 2012 (GMT)<br />
*'''Delete''' along with all other references to this bullshit one man show in history, firsts and maybe other places. It serves no other thing than to Luke's ego. Why should the wiki as a whole support this? Apparently he realized that he can't win with arguments as he just deleted this very discussion. --[[User:Giszmo|Giszmo]] ([[User talk:Giszmo|talk]]) 15:41, 27 August 2012 (GMT)<br />
*'''Delete''' because:<br />
# nobody knows it - it seems that all sources are from one person [[User:Luke-jr|Luke-jr]] and from 150 years old (!) book. There is no notability. Nobody after cares about it. There are no "tonal system community" or "people that are using tonal system" - tonal system uses just 1 person and he is trying to misappropriate Bitcoin for this<br />
# Tonal system is not at any way related to Bitcoin. Tonal system is related to numbers representation, not to monetary system. Please keep this page in general Wikipedia or some numeric Wikipedia, not in Bitcoin Wikipedia<br />
# Tonal units are very confusing - from technically point of view (font, writing it) and mainly there is very similar to decimal numbers - there are many cases in which is not clear which system is used. Also TBC is common typing error of BTC<br />
:'''Also I propose remove all notation about tonal from other wiki pages''', for example [[Units]] (very confusing), [[History]], [[Wallet protocol]] or [[Vocabulary]], and prevent them from reverting back (as happened several times). At least until Luke-jr (or someone else) find notable cites to keeping it here. [[User:Aleš Janda|Aleš Janda]] ([[User talk:Aleš Janda|talk]]) 19:44, 27 August 2012 (GMT)<br />
<br />
<br />
Luke-jr comment to voting: This is for discussion, not trolling. This is not an encyclopedia, and does not have any "notability" requirements. If you don't want to use Tonal, don't. Trolling is not acceptable.</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=People&diff=30161People2012-08-27T20:13:16Z<p>Giszmo: fixed a broken redirect</p>
<hr />
<div>A list of active contributors to Bitcoin, ordered by first name.<br />
<br />
[[Andreas Schildbach]] ([https://profiles.google.com/andreas.schildbach Profile]) - original developer of [https://market.android.com/details?id=de.schildbach.wallet Bitcoin Wallet for Android] ([http://code.google.com/p/bitcoin-wallet/ Google Code Project]).<br />
<br />
[[Amir Taaki]] aka genjix- creator of the [[Britcoin]] and [[Intersango]] exchanges, [[libbitcoin]] library for Bitcoin, [[Spesmilo]], [[Bitcoin Consultancy]], [[Vibanko]], [[GLBSE]] client, Bitcoin poker client, [https://gitorious.org/freecoin/freecoin Python bindings] for Bitcoin, [[Pastecoin]] and others.<br />
<br />
[[ArtForz|Art Forz]]- developed the first GUI miner and at one time his GPU mining farm (the ArtFarm) was mining over a third of all blocks.<br />
<br />
[[Gary Rowe]] [https://plus.google.com/u/0/115295932487523951663/about (Profile)] - Contributor to the [[MultiBit]] (http://multibit.org) and [[BitCoinJ]] (http://code.google.com/p/bitcoinj/) projects. Working on various Bitcoin based businesses.<br />
<br />
[[Gavin Andresen]]- [https://profiles.google.com/u/0/gavinandresen/about (Profile)] [[Satoshi client]] maintainer. He previously worked at Silicon Graphics and now runs his own company.<br />
<br />
[[Hal Finney]]- one of the creators of [http://en.wikipedia.org/wiki/Pretty_Good_Privacy PGP] and one of the earliest contributors to the Bitcoin project. First to identify a type of double-spending attack that now bears his name -- the [[Double-spending#Finney_attack|Finney attack]].<br />
<br />
James McCarthy aka Nefario- creator of the first bitcoin stock exchange [[GLBSE]]<br />
<br />
[[Jed McCaleb]], original developer of MtGox. Previously created eDonkey2000.<br />
<br />
[[Jeff Garzik]]- [http://en.wikipedia.org/wiki/Jeff_Garzik (Wikipedia Entry)] [[Satoshi client]] core developer, GPU poold software and the founder of [[Bitcoin Watch]]. Works as a Linux kernel developer at Red Hat,<br />
<br />
[[Luke Dashjr]] aka Luke-Jr- [[Eligius]] owner/admin and [[Spesmilo]] core developer<br />
<br />
[[Mark Karpeles]] aka MagicalTux- Owner of the largest Bitcoin exchange, [[MtGox]], this Bitcoin Wiki, and [https://www.kalyhost.com/ Kalyhost]<br />
<br />
[[Sirius|Martti Malmi]] aka Sirius- Operates the host for bitcoin.org and is an administrator of the [[Bitcoin Forum]].<br />
<br />
[[Matt Corallo]] aka BlueMatt- [[Satoshi client]] developer.<br />
<br />
[[Michael Hendrix]] aka mndrix- creator of the now defunct CoinPal and CoinCard services<br />
<br />
[[Michael Marquardt]] aka theymos- creator of the widely used blockexplorer.com site, and BitcoinTalk Forum<br />
<br />
[[Mike Hearn]] [https://profiles.google.com/mh.in.england/about (Profile)]- Google engineer who works on Gmail and developed [[BitCoinJ]] (http://code.google.com/p/bitcoinj/)<br />
<br />
[[User:Tcatm|Nils Schneider]] aka tcatm - Bitcoin developer, owner of BitcoinWatch, creator and owner of BitcoinCharts, GPU mining software and JS web interface.<br />
<br />
[[Patrick McFarland]] aka Diablo-D3 - DiabloMiner author, and BitcoinTalk forum moderator.<br />
<br />
[[Patrick Strateman]] aka phantomcircuit - Bitcoin developer, creator of [[Intersango]], member of [[Bitcoin Consultancy]] and creator of Python Bitcoin implementation.<br />
<br />
[[Pieter Wuille]] aka sipa- [[Satoshi client]] developer and maintainer of the network graphs http://bitcoin.sipa.be<br />
<br />
[[Stefan Thomas]] aka justmoon- creator of the WeUseCoins.com site/video and WebCoin.<br />
<br />
[[Vladimir Marchenko]]- [https://profiles.google.com/u/0/vmartchenko/about?hl=en Profile], runs [[Marchenko Ltd]] which sells mining contracts, previously developed the figator.org search engine.<br />
<br />
<br />
==See Also==<br />
* [[Original client developers]]<br />
* [[Developers]]<br />
* Wiki list of [[:Special:ListUsers|users]]<br />
* [[Bitcoin:Community_portal|Community portal]]<br />
* [[:Category:People]]</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Tonal_Bitcoin&diff=30146Tonal Bitcoin2012-08-27T15:42:02Z<p>Giszmo: </p>
<hr />
<div>{{Delete}}<br />
<br />
Tonal Bitcoin is a representation of the Bitcoin network aimed toward the minority of people who use the Tonal number system.<br />
This is an alternative to decimal and the metric system, which improves usability drastically by allowing for infinite binary division (note that Bitcoin protocol support is still finite).<br />
For more information on the Tonal system in general, please see [http://www.lulu.com/product/file-download/tonal-system/10991091 the book].<br />
<br />
Please note, that all numbers of TBC and its divisions/multipliers are written in [http://en.wikipedia.org/wiki/Tonal_System Tonal], not decimal.<br />
This means that instead of counting 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10-- you count: 0, 1, 2, 3, 4, 5, 6, 7, 8, , 9, , , , , , 10. Some higher-value digits may require installing a [http://luke.dashjr.org/education/tonal/glyphs/fonts/ font].<br />
<br />
{| border="1" style="text-align:right;font-family:Console, Luxi Mono, fixed"<br />
|- style="background-color:silver"<br />
! Abbreviation<br />
! Pronunciation<br />
! [[Tonal Bitcoin|Tonal (TBC)]]<br />
! Decimal (BTC)<br />
|-<br />
| <br />
| Tam-Bitcoin<br />
| 1 0000 0000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 2 814 749.767 106 56<br />
|-<br />
| ᵇTBC<br />
| Bong-Bitcoin<br />
| 1 0000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 42.949 672 96<br />
|-<br />
| ᵐTBC<br />
| Mill-Bitcoin<br />
| 1000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 2.684 354 56<br />
|-<br />
| ˢTBC<br />
| San-Bitcoin<br />
| 100&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 0.167 772 16<br />
|-<br />
| ᵗTBC<br />
| Ton-Bitcoin<br />
| 10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 0.010 485 76<br />
|-<br />
| TBC<br />
| Bitcoin*<br />
| 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 0.000 655 36<br />
|-<br />
| TBCᵗ<br />
| Bitcoin-ton<br />
| 0.1&nbsp;&nbsp;&nbsp;<br />
| 0.000 040 96<br />
|-<br />
| TBCˢ<br />
| Bitcoin-san<br />
| 0.01&nbsp;&nbsp;<br />
| 0.000 002 56<br />
|-<br />
| TBCᵐ<br />
| Bitcoin-mill<br />
| 0.001&nbsp;<br />
| 0.000 000 16<br />
|-<br />
| TBCᵇ<br />
| Bitcoin-bong<br />
| 0.0001<br />
| 0.000 000 01<br />
|}<br />
<br />
<small>* Tonal Bitcoin and Decimal Bitcoin can be differentiated by the pronunciation of the numbers. "One bitcoin", "two bitcoin", etc is decimal, but "an bitcoin", "de bitcoin" is tonal.</small><br />
<br />
The total number of Tonal Bitcoins ever (analogous to the 21mil BTC) is just over 7.75059 tam-bitcoin.<br />
<br />
== Compatible Clients ==<br />
<br />
While all Bitcoin clients will correctly approximate values in decimal bitcoin, actual Tonal compatibility is sparse.<br />
<br />
* [[Spesmilo]], despite its name, can be configured to display TBC<br />
<br />
== Guessing TBC or BTC ==<br />
<br />
Given variable 'value' in base units (uBTCents/TBCᵇ), one can guess whether it is properly Decimal Bitcoin or Tonal Bitcoin with the following pseudo-code:<br />
<br />
if ( ! ( this % 0x10000 ) )<br />
Choose Tonal Bitcoin<br />
if ( ! ( this % 1000000 ) )<br />
Choose Decimal Bitcoin<br />
if ( ! ( this % 0x100 ) )<br />
Choose Tonal Bitcoin<br />
<br />
=== Python ===<br />
<br />
<pre>import math<br />
<br />
def formatBTC(n, addSign = False):<br />
s = "%0.2f BTC" % (math.ceil(n * 100) / 100.,)<br />
if addSign and n >= 0:<br />
s = "+" + s<br />
return s<br />
<br />
def Bitcoin2BTC(n):<br />
return n / 100000000.<br />
<br />
toTonalDict = dict(((57, u'\ue9d9'), (65, u'\ue9da'), (66, u'\ue9db'), (67, u'\ue9dc'), (68, u'\ue9dd'), (69, u'\ue9de'), (70, u'\ue9df'), (97, u'\ue9da'), (98, u'\ue9db'), (99, u'\ue9dc'), (100, u'\ue9dd'), (101, u'\ue9de'), (102, u'\ue9df')))<br />
<br />
def formatTBC(n, addSign = False):<br />
s = "%x" % n<br />
n %= 1<br />
if n:<br />
s += '.'<br />
while n:<br />
n *= 16<br />
s += "%x" % n<br />
n %= 1<br />
s = unicode(s).translate(toTonalDict)<br />
s += " TBC"<br />
if addSign and n >= 0:<br />
s = "+" + s<br />
return s<br />
<br />
def Bitcoin2TBC(n):<br />
return n / 65536.<br />
<br />
def formatBitcoin(n, addSign = False):<br />
if not n % 0x10000:<br />
return formatTBC(Bitcoin2TBC(n), addSign);<br />
if not n % 1000000:<br />
return formatBTC(Bitcoin2BTC(n), addSign);<br />
if not n % 0x100:<br />
return formatTBC(Bitcoin2TBC(n), addSign);<br />
s = "%d uBTCents" % (n,);<br />
if addSign and n > 0:<br />
s = "+" + s;<br />
return s;</pre><br />
<br />
== Criticism ==<br />
<br />
* [[User:Davout|Davout]] has to google this page each time someone mentions an amount in tonal bitcoin<br />
<br />
=== Can be done without funny characters ===<br />
<br />
The tonal notation requires extra fonts. Within the programming community there is a widely accepted convention for hexadecimal notation: use A-F for the higher order digits. Thus, one counts 0,1,2,3, ... , 9,A,B,C,D,E,F,10,11 .... There are even two conventions, (which are lacking in tonal) for distinguishing a base-16 number from a decimal. The C convention prefixes 0x and the Motorola convention suffixes h. So, the number san, 256 (decimal) would be written 0x100 or 100h. In tonal notation, it would only be written 100, and thus potentially confused with decimal 100 which is 0x64.<br />
<br />
Thus programming notation accomplishes the same goals as tonal notation with no requirement for changing fonts, thus is more suited to wide usage. Further the prefix and suffix conventions lead to less ambiguity.</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Talk:Tonal_Bitcoin&diff=30145Talk:Tonal Bitcoin2012-08-27T15:41:25Z<p>Giszmo: voted for deletion</p>
<hr />
<div>The point of Bitcoin is that it is a decentralized peer to peer currency. <br />
That is the novelty about Bitcoin; the novelty is NOT that it comes along with a funky new way of counting things.<br />
So please stop using Bitcoin to promote your own agenda ; this is just going to confuse people.<br />
If you want to introduce a new method for counting currency, I suggest you go talk to the FED and propose the Tonal Dollar, or whatever.<br />
[[User:ThomasV|ThomasV]] 14:33, 20 February 2011 (GMT)<br />
* If Bitcoin has only one purpose, then it will never succeed. There are about as many people that care about a "decentralized peer to peer currency" as there are that care about Tonal. If you want BitCoin to succeed, you should support as many (legal) reasons to use it as possible. Also, whether it's ever enforced or not, vandalism and trolling should be bannable offenses. --[[User:Luke-jr|Luke-jr]] 04:43, 21 February 2011 (GMT)<br />
<br />
This page should be deleted.<br />
Nothing against Tonal, if there was a Hexadecimal Bitcoin or an Octal Bitcoin I would suggest those get deleted, too.<br />
* Seconded. Tonal is not a key part of bitcoin, and currently not used in any form. If there is a reasonable number of users using tonal, then I would have no objections against this page. [[User:Mqrius|Mqrius]] 05:11, 2 February 2012 (GMT)<br />
<br />
This is silly. I thought you'd removed this already, but it's seeping across to other pages despite me never seeing it in the wild. It serves only to confuse [[User:Gigitrix|Gigitrix]] 01:41, 13 June 2011 (GMT)<br />
<br />
I agree with Gavin that this page should be deleted. Regardless of my personal opinion or the technical merits of tonal v. decimal, it's fair to say that tonal attracts scorn and ridicule from the vast majority of the population if they hear about it. Bitcoin's reputation suffers from the association. [[User:ByteCoin|ByteCoin]] 24 June 2011 (GMT)<br />
* It's not fair to say that, no. --[[User:Luke-jr|Luke-jr]] 00:45, 25 June 2011 (GMT)<br />
<br />
I also think this page should be deleted. There are at least three people suggesting this now, so I will re-add the delete tag to the page. So far there seems to be only one objection to the delete. I will initiate voting on this talk page. --[[User:Rebroad|Rebroad]] 22:48, 20 March 2012 (GMT)<br />
* '''Delete''' - I believe this tonal suggestion will only do harm to the bitcoin project, and so far the only person advocating it is luke-jr, who rarely gives any rational reasons that I nor anyone else AFAIK can understand. Sorry luke-jr, but I'm doing my best to get you to explain the benefits. --[[User:Rebroad|Rebroad]] 22:52, 20 March 2012 (GMT)<br />
*'''Delete''' - I've been lurking for a while, but I registered after seeing this nonsense here. Clearly if luke-jr is simply (and rather immaturely) blanking the discussion rather than responding to the specific points he has few arguments to marshal in his favor. --[[User:Zyzygy|Zyzygy]] ([[User talk:Zyzygy|talk]]) 05:14, 26 August 2012 (GMT)<br />
*'''Delete''' along with all other references to this bullshit one man show in history, firsts and maybe other places. It serves no other thing than to Luke's ego. Why should the wiki as a whole support this? Apparently he realized that he can't win with arguments as he just deleted this very discussion. --[[User:Giszmo|Giszmo]] ([[User talk:Giszmo|talk]]) 15:41, 27 August 2012 (GMT)</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Talk:Tonal_Bitcoin&diff=30144Talk:Tonal Bitcoin2012-08-27T15:38:23Z<p>Giszmo: Undo revision 30130 by Luke-jr (talk)</p>
<hr />
<div>The point of Bitcoin is that it is a decentralized peer to peer currency. <br />
That is the novelty about Bitcoin; the novelty is NOT that it comes along with a funky new way of counting things.<br />
So please stop using Bitcoin to promote your own agenda ; this is just going to confuse people.<br />
If you want to introduce a new method for counting currency, I suggest you go talk to the FED and propose the Tonal Dollar, or whatever.<br />
[[User:ThomasV|ThomasV]] 14:33, 20 February 2011 (GMT)<br />
* If Bitcoin has only one purpose, then it will never succeed. There are about as many people that care about a "decentralized peer to peer currency" as there are that care about Tonal. If you want BitCoin to succeed, you should support as many (legal) reasons to use it as possible. Also, whether it's ever enforced or not, vandalism and trolling should be bannable offenses. --[[User:Luke-jr|Luke-jr]] 04:43, 21 February 2011 (GMT)<br />
<br />
This page should be deleted.<br />
Nothing against Tonal, if there was a Hexadecimal Bitcoin or an Octal Bitcoin I would suggest those get deleted, too.<br />
* Seconded. Tonal is not a key part of bitcoin, and currently not used in any form. If there is a reasonable number of users using tonal, then I would have no objections against this page. [[User:Mqrius|Mqrius]] 05:11, 2 February 2012 (GMT)<br />
<br />
This is silly. I thought you'd removed this already, but it's seeping across to other pages despite me never seeing it in the wild. It serves only to confuse [[User:Gigitrix|Gigitrix]] 01:41, 13 June 2011 (GMT)<br />
<br />
I agree with Gavin that this page should be deleted. Regardless of my personal opinion or the technical merits of tonal v. decimal, it's fair to say that tonal attracts scorn and ridicule from the vast majority of the population if they hear about it. Bitcoin's reputation suffers from the association. [[User:ByteCoin|ByteCoin]] 24 June 2011 (GMT)<br />
* It's not fair to say that, no. --[[User:Luke-jr|Luke-jr]] 00:45, 25 June 2011 (GMT)<br />
<br />
I also think this page should be deleted. There are at least three people suggesting this now, so I will re-add the delete tag to the page. So far there seems to be only one objection to the delete. I will initiate voting on this talk page. --[[User:Rebroad|Rebroad]] 22:48, 20 March 2012 (GMT)<br />
* '''Delete''' - I believe this tonal suggestion will only do harm to the bitcoin project, and so far the only person advocating it is luke-jr, who rarely gives any rational reasons that I nor anyone else AFAIK can understand. Sorry luke-jr, but I'm doing my best to get you to explain the benefits. --[[User:Rebroad|Rebroad]] 22:52, 20 March 2012 (GMT)<br />
*'''Delete''' - I've been lurking for a while, but I registered after seeing this nonsense here. Clearly if luke-jr is simply (and rather immaturely) blanking the discussion rather than responding to the specific points he has few arguments to marshal in his favor. --[[User:Zyzygy|Zyzygy]] ([[User talk:Zyzygy|talk]]) 05:14, 26 August 2012 (GMT)</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Talk:Bitcoin_Firsts&diff=30143Talk:Bitcoin Firsts2012-08-27T15:16:48Z<p>Giszmo: Suggested to add many more things. Please discuss.</p>
<hr />
<div>Any reason the 'bitcoin first' page is separate from the older History page?<br />
<br />
Ya, probably so that the History page was more specific to bitcoin, but firsts was for trivia and only true firsts.<br />
<br />
Like maybe going to v0.6 release is enough to make it into the History, but not something that would go into firsts.<br />
At the same time, the first food truck to start using bitcoin might be something suitable for the Firsts page but would be extraneous in the Bitcoin History page.<br />
<br />
== Adult entertainers video ==<br />
<br />
Video has been removed from Youtube due to TOS violation. I change the link to the original subreddit where it all began and entertainers in general started accepting Bitcoin.<br />
<br />
== Many, if not most things missing ==<br />
Many ideas and actions deserve being mentioned and the first to do it deserves to be mentioned here I think. There would be room for mentioning others as super tiny references like <ref>alternative 1</ref><ref>alternative 2</ref><ref>alternative 3</ref>. 5 minutes of brain storming:<br />
* first implementation of an exchange (otc?)<br />
* first floating exchange (MtGox?)<br />
* first free bitcoins site (faucet?)<br />
* first facebook wallet<br />
* first margin trading<br />
* first betting site<br />
* first auction site<br />
* first firstbits site<br />
* first live monitor of an exchange<br />
* first day with more than x transactions<br />
* first day with trade volume > x USD<br />
* first mobile wallet<br />
* first iPhone/android/blackberry/... wallet<br />
* first hosted wallet<br />
* first hosted wallet without registration (instawallet?)<br />
* first brain wallet site<br />
* …<br />
<references /><br />
--[[User:Giszmo|Giszmo]] ([[User talk:Giszmo|talk]]) 15:16, 27 August 2012 (GMT)</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Category:History&diff=30137Category:History2012-08-27T05:12:45Z<p>Giszmo: updated headline levels</p>
<hr />
<div>== Important milestones of the Bitcoin project ==<br />
=== 2008 ===<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | August 18<br />
|| Domain name "bitcoin.org" registered<ref>[https://bitcointalk.org/index.php?topic=103369.msg1135218#msg1135218 According to theymos], Satoshi registered bitcoin.org via https://www.anonymousspeech.com/ which allows to anonymously register domains.</ref>.<br />
|-<br />
! October 31<br />
|| [http://article.gmane.org/gmane.comp.encryption.general/12588/ Bitcoin design paper] published<br />
|-<br />
! November 09<br />
|| Bitcoin project registered at SourceForge.net<br />
|}<br />
<br />
=== 2009 ===<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | January 3<br />
|| [http://www.BlockExplorer.com/b/0 Genesis block] established at 18:15:05 GMT<br />
|-<br />
! January 11<br />
|| Bitcoin v0.1 released and announced on the [http://www.mail-archive.com/cryptography@metzdowd.com/msg10152.html cryptography mailing list]<br />
|-<br />
! January 12<br />
|| First Bitcoin transaction, [http://www.BlockExplorer.com/b/170 in block 170] - from [[Satoshi]] to Hal Finney<ref>[http://bitcointalk.org/index.php?topic=91806.msg1012234#msg1012234 Earliest Block With A Spend]</ref>.<br />
|-<br />
! December 16<br />
|| Bitcoin v0.2 released<br />
|-<br />
! December 30<br />
|| First difficulty increase at 06:11:04 GMT<br />
|}<br />
=== 2010 ===<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | February 6<br />
|| [[Bitcoin Market]] established<br />
|-<br />
! May 22<br />
|| laszlo first to buy pizza with Bitcoins agreeing upon paying 10,000 BTC for ~$25 worth of pizza courtesy of jercos<ref>[https://bitcointalk.org/index.php?topic=137.msg1195#msg1195 bitcointalk post] where laszlo confirmed having bought pizza</ref><br />
|-<br />
! July 7<br />
|| Bitcoin v0.3 released<br />
|-<br />
! July 11<br />
|| Bitcoin v0.3 release mentioned on slashdot<ref>[http://news.slashdot.org/story/10/07/11/1747245/Bitcoin-Releases-Version-03 slashdot] metiones Bitcoin</ref>, bringing a large influx of new bitcoin users.<br />
|-<br />
! July 12<br />
|| Beginning of a 10x increase in exchange value over a 5 day period, from about $0.008/BTC to $0.08/BTC<br />
|-<br />
! July 17<br />
|| [[MtGox]] established<br />
|-<br />
! July 18<br />
|| ArtForz generated his first block after establishing his personal OpenCL GPU hash farm<br />
|-<br />
! August 15<br />
|| 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]]).<br />
|-<br />
! September 14<br />
|| jgarzik [https://bitcointalk.org/index.php?topic=133.msg12921#msg12921 offered] 10,000 BTC (valued at ~$600-650) to puddinpop to open source their windows-based CUDA client<br />
|-<br />
! September 18<br />
|| puddinpop [https://bitcointalk.org/index.php?topic=133.msg13135#msg13135 released] source to their windows-based CUDA client under MIT license<br />
|-<br />
! September 29<br />
|| kermit [https://bitcointalk.org/index.php?topic=1306.0 discovered] a microtransactions exploit which precipitated the Bitcoin v0.3.13 release<br />
|-<br />
! October 01<br />
|| First public OpenCL miner released<br />
|-<br />
! October 04<br />
|| Original Bitcoin History wiki page (this page) established (ooh so meta) on Bitcoin.org's wiki.<br />
|-<br />
! October 07<br />
|| Exchange rate started climbing up from $0.06/BTC after several flat months.<br />
|-<br />
! October 28<br />
|| 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.<br />
|-<br />
! November 6<br />
|| The [https://bitcointalk.org/index.php?topic=1672 Bitcoin economy passed US $1 million]. The MtGox price touched USD $0.50/BTC.<br />
|-<br />
! December 7<br />
|| 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.<br />
|-<br />
! December 9<br />
|| The generation difficulty passed 10,000.<br />
|-<br />
|<br />
|| First bitcoin call option contract sold, from nanotube to [[User:Sgornick|sgornick]], via the [[Bitcoin-otc|#bitcoin-otc]] market.<br />
|-<br />
! December 16<br />
|| [http://mining.bitcoin.cz/ Bitcoin Pooled Mining], operated by slush, found its first block<br />
|}<br />
<br />
=== 2011 ===<br />
{| style="text-align: left"<br />
|-<br />
! January 2<br />
|| [[Tonal Bitcoin]] units standardized.<br />
|-<br />
! width="8em" | January 8<br />
|| [[History of Bitcoin]] page (this page) created after replicating from original Bitcoin History page on Bitcoin.org.<br />
|-<br />
|<br />
|| Bitcoin Pooled Mining reached a total of 10,000 Mhash/s<br />
|-<br />
! January 27<br />
|| 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><br />
|-<br />
! January 28<br />
|| 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.<br />
|-<br />
! February 9<br />
|| Bitcoin reached parity with the US dollar, touching $1 per BTC at [[MtGox]].<br />
|-<br />
! February 10<br />
|| Bitcoin.org website struggles to handle [https://bitcointalk.org/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.<br />
|-<br />
! February 14<br />
|| A vehicle was, for the first time, offered in exchange for a certain number of bitcoins<ref>[https://bitcointalk.org/index.php?topic=3485.0 Car for Sale - Australia]</ref>.<br />
|-<br />
! March 6<br />
|| Total Bitcoin network computation speed for a short time reached a new 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]).<br />
|-<br />
! March 18<br />
|| 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.<br />
|-<br />
! March 25<br />
|| Difficulty decreased nearly 10%. A decrease has only occurred once before, and this decrease of nearly 10% was the largest.<br />
|-<br />
! March 27<br />
|| The first market for exchanging bitcoins to and from the British Pound Sterling BTC/GBP, [[Britcoin]], opens.<br />
|-<br />
! March 31<br />
|| The first market for exchanging bitcoins to and from Brazilian Reals, [[Bitcoin Brazil]], opens.<br />
|-<br />
! April 5<br />
|| The first market for exchanging bitcoins to and from the Polish złoty, [[BitMarket.eu]], opens.<br />
|-<br />
! April 12<br />
|| First bitcoin put option contract sold via the [[Bitcoin-otc|#bitcoin-otc]] market.<br />
|-<br />
! April 16<br />
|| TIME does [http://techland.time.com/2011/04/16/online-cash-bitcoin-could-challenge-governments/ an article on Bitcoin].<br />
|-<br />
! April 23<br />
|| BTC/USD exchange rate reaches and passes parity with the Euro (EUR) on [[MtGox]] exchange.<br />
|-<br />
|<br />
|| BTC/USD exchange rate reaches and passes parity with the British Sterling Pound (GBP) on [[MtGox]] exchange.<br />
|-<br />
|<br />
|| Value of the Bitcoin money stock at current exchange rate passes $10 million USD threshold.<br />
|-<br />
! April 27<br />
|| [[VirWoX]] opens first market to trade bitcoins against a virtual currency on BTC/SL (Second Life Lindens) exchange.<br />
|-<br />
! April 28<br />
|| Block [http://blockexplorer.com/b/120630 120,630] is first to be mined using split allocation of the generation reward.<br />
|-<br />
! April 30<br />
|| The generation difficulty passed 100,000.<br />
|-<br />
! June 2<br />
|| The exchange rate at [[MtGox]] touched 10 USD per BTC.<br />
|-<br />
! June 8<br />
|| 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].<br />
|-<br />
! June 12<br />
|| The [[MtGox]] exchange rate briefly dropped to near 10 USD four days after the peak, in its largest percentage price retreat to date.<br />
|-<br />
! June 13<br />
|| 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).<br />
|-<br />
! June 19<br />
|| 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.<br />
|-<br />
! June 19<br />
|| 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).<br />
|-<br />
! June 19<br />
|| 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.<br />
|-<br />
! June 20<br />
|| The EFF announced that it was no longer accepting Bitcoin donations due to legal uncertainties.<br />
|-<br />
! June 24<br />
|| The generation difficulty passed 1,000,000 with Block [http://blockexplorer.com/b/133056 133056].<br />
|-<br />
! July 22<br />
|| [[BitCoins Mobile]], the first Bitcoin application for iPad was released by [http://www.intervex.net Intervex Digital].<br />
|-<br />
! August 20<br />
|| First Bitcoin Conference and World Expo held, in NYC.<br />
|-<br />
! August 23<br />
|| [[P2Pool]], the first P2P decentralized pool, mines its first Bitcoin mainnet block (Block [http://blockexplorer.com/b/142312 142,312]).<br />
|-<br />
! August 30<br />
|| Difficulty adjustment at block [http://blockexplorer.com/b/143136 143,136] marks the first back-to-back drop.<br />
|-<br />
! November 15<br />
|| First CVE (CVE-2011-4447) assigned to a Bitcoin client exploit.<br />
|-<br />
! November 25<br />
|| First European Bitcoin Conference in Prague, Czech Rep.<br />
|-<br />
! December 12<br />
|| Largest amount of fees, to-date, in a single transaction, and most fees in a single block. A [http://blockexplorer.com/tx/1d7749c65c90c32f5e2c036217a2574f3f4403da39174626b246eefa620b58d9 transaction] paid 171 BTC in fees in [http://blockexplorer.com/b/157235 block 157235]<ref>[http://bitcointalk.org/index.php?topic=88423.msg973509#msg973509 Largest fee ever?]</ref>.<br />
|}<br />
=== 2012 ===<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | March 1<br />
|| Largest theft of bitcoins to-date occurred (near 50K BTC) after security breach at web host Linode.<br />
|-<br />
! May 08<br />
|| A single service, [[SatoshiDICE]] becomes responsible for over half the transaction volume on the Bitcoin blockchain.<br />
|-<br />
! June 3<br />
|| Largest block (most transactions), to-date (June 3), is [http://BlockExplorer.com/b/181919 block 181919] with 1322 transactions<ref>[http://bitcointalk.org/index.php?topic=85353.msg939859#msg939859 Largest block to date]</ref>.<br />
|-<br />
! July 22<br />
|| One millionth topic reply was posted on the unofficial [[Bitcoin Forum]] <ref>[https://bitcointalk.org/index.php?topic=94608.0 Topic about one millionth forum post]</ref>.<br />
|}<br />
<br />
==See Also==<br />
<br />
* [[Bitcoin Firsts]]<br />
<br />
==References==<br />
<references /></div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Category_talk:History&diff=30136Category talk:History2012-08-27T05:09:57Z<p>Giszmo: wikify</p>
<hr />
<div>Any reason the 'bitcoin first' page is separate from the older History page?<br />
<br />
:Ya, probably so that the History page was more specific to bitcoin, but firsts was for trivia and only true firsts.<br />
:Like maybe going to v0.6 release is enough to make it into the History, but not something that would go into firsts. At the same time, the first food truck to start using bitcoin might be something suitable for the Firsts page but would be extraneous in the Bitcoin History page.</div>Giszmohttps://tests.bitcoin.it/w/index.php?title=Category:History&diff=30135Category:History2012-08-27T05:08:08Z<p>Giszmo: /* 2008 */</p>
<hr />
<div>= Important milestones of the Bitcoin project =<br />
== 2008 ==<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | August 18<br />
|| Domain name "bitcoin.org" registered<ref>[https://bitcointalk.org/index.php?topic=103369.msg1135218#msg1135218 According to theymos], Satoshi registered bitcoin.org via https://www.anonymousspeech.com/ which allows to anonymously register domains.</ref>.<br />
|-<br />
! October 31<br />
|| [http://article.gmane.org/gmane.comp.encryption.general/12588/ Bitcoin design paper] published<br />
|-<br />
! November 09<br />
|| Bitcoin project registered at SourceForge.net<br />
|}<br />
<br />
== 2009 ==<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | January 3<br />
|| [http://www.BlockExplorer.com/b/0 Genesis block] established at 18:15:05 GMT<br />
|-<br />
! January 11<br />
|| Bitcoin v0.1 released and announced on the [http://www.mail-archive.com/cryptography@metzdowd.com/msg10152.html cryptography mailing list]<br />
|-<br />
! January 12<br />
|| First Bitcoin transaction, [http://www.BlockExplorer.com/b/170 in block 170] - from [[Satoshi]] to Hal Finney<ref>[http://bitcointalk.org/index.php?topic=91806.msg1012234#msg1012234 Earliest Block With A Spend]</ref>.<br />
|-<br />
! December 16<br />
|| Bitcoin v0.2 released<br />
|-<br />
! December 30<br />
|| First difficulty increase at 06:11:04 GMT<br />
|}<br />
== 2010 ==<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | February 6<br />
|| [[Bitcoin Market]] established<br />
|-<br />
! May 22<br />
|| laszlo first to buy pizza with Bitcoins agreeing upon paying 10,000 BTC for ~$25 worth of pizza courtesy of jercos<ref>[https://bitcointalk.org/index.php?topic=137.msg1195#msg1195 bitcointalk post] where laszlo confirmed having bought pizza</ref><br />
|-<br />
! July 7<br />
|| Bitcoin v0.3 released<br />
|-<br />
! July 11<br />
|| Bitcoin v0.3 release mentioned on slashdot<ref>[http://news.slashdot.org/story/10/07/11/1747245/Bitcoin-Releases-Version-03 slashdot] metiones Bitcoin</ref>, bringing a large influx of new bitcoin users.<br />
|-<br />
! July 12<br />
|| Beginning of a 10x increase in exchange value over a 5 day period, from about $0.008/BTC to $0.08/BTC<br />
|-<br />
! July 17<br />
|| [[MtGox]] established<br />
|-<br />
! July 18<br />
|| ArtForz generated his first block after establishing his personal OpenCL GPU hash farm<br />
|-<br />
! August 15<br />
|| 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]]).<br />
|-<br />
! September 14<br />
|| jgarzik [https://bitcointalk.org/index.php?topic=133.msg12921#msg12921 offered] 10,000 BTC (valued at ~$600-650) to puddinpop to open source their windows-based CUDA client<br />
|-<br />
! September 18<br />
|| puddinpop [https://bitcointalk.org/index.php?topic=133.msg13135#msg13135 released] source to their windows-based CUDA client under MIT license<br />
|-<br />
! September 29<br />
|| kermit [https://bitcointalk.org/index.php?topic=1306.0 discovered] a microtransactions exploit which precipitated the Bitcoin v0.3.13 release<br />
|-<br />
! October 01<br />
|| First public OpenCL miner released<br />
|-<br />
! October 04<br />
|| Original Bitcoin History wiki page (this page) established (ooh so meta) on Bitcoin.org's wiki.<br />
|-<br />
! October 07<br />
|| Exchange rate started climbing up from $0.06/BTC after several flat months.<br />
|-<br />
! October 28<br />
|| 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.<br />
|-<br />
! November 6<br />
|| The [https://bitcointalk.org/index.php?topic=1672 Bitcoin economy passed US $1 million]. The MtGox price touched USD $0.50/BTC.<br />
|-<br />
! December 7<br />
|| 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.<br />
|-<br />
! December 9<br />
|| The generation difficulty passed 10,000.<br />
|-<br />
|<br />
|| First bitcoin call option contract sold, from nanotube to [[User:Sgornick|sgornick]], via the [[Bitcoin-otc|#bitcoin-otc]] market.<br />
|-<br />
! December 16<br />
|| [http://mining.bitcoin.cz/ Bitcoin Pooled Mining], operated by slush, found its first block<br />
|}<br />
<br />
== 2011 ==<br />
{| style="text-align: left"<br />
|-<br />
! January 2<br />
|| [[Tonal Bitcoin]] units standardized.<br />
|-<br />
! width="8em" | January 8<br />
|| [[History of Bitcoin]] page (this page) created after replicating from original Bitcoin History page on Bitcoin.org.<br />
|-<br />
|<br />
|| Bitcoin Pooled Mining reached a total of 10,000 Mhash/s<br />
|-<br />
! January 27<br />
|| 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><br />
|-<br />
! January 28<br />
|| 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.<br />
|-<br />
! February 9<br />
|| Bitcoin reached parity with the US dollar, touching $1 per BTC at [[MtGox]].<br />
|-<br />
! February 10<br />
|| Bitcoin.org website struggles to handle [https://bitcointalk.org/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.<br />
|-<br />
! February 14<br />
|| A vehicle was, for the first time, offered in exchange for a certain number of bitcoins<ref>[https://bitcointalk.org/index.php?topic=3485.0 Car for Sale - Australia]</ref>.<br />
|-<br />
! March 6<br />
|| Total Bitcoin network computation speed for a short time reached a new 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]).<br />
|-<br />
! March 18<br />
|| 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.<br />
|-<br />
! March 25<br />
|| Difficulty decreased nearly 10%. A decrease has only occurred once before, and this decrease of nearly 10% was the largest.<br />
|-<br />
! March 27<br />
|| The first market for exchanging bitcoins to and from the British Pound Sterling BTC/GBP, [[Britcoin]], opens.<br />
|-<br />
! March 31<br />
|| The first market for exchanging bitcoins to and from Brazilian Reals, [[Bitcoin Brazil]], opens.<br />
|-<br />
! April 5<br />
|| The first market for exchanging bitcoins to and from the Polish złoty, [[BitMarket.eu]], opens.<br />
|-<br />
! April 12<br />
|| First bitcoin put option contract sold via the [[Bitcoin-otc|#bitcoin-otc]] market.<br />
|-<br />
! April 16<br />
|| TIME does [http://techland.time.com/2011/04/16/online-cash-bitcoin-could-challenge-governments/ an article on Bitcoin].<br />
|-<br />
! April 23<br />
|| BTC/USD exchange rate reaches and passes parity with the Euro (EUR) on [[MtGox]] exchange.<br />
|-<br />
|<br />
|| BTC/USD exchange rate reaches and passes parity with the British Sterling Pound (GBP) on [[MtGox]] exchange.<br />
|-<br />
|<br />
|| Value of the Bitcoin money stock at current exchange rate passes $10 million USD threshold.<br />
|-<br />
! April 27<br />
|| [[VirWoX]] opens first market to trade bitcoins against a virtual currency on BTC/SL (Second Life Lindens) exchange.<br />
|-<br />
! April 28<br />
|| Block [http://blockexplorer.com/b/120630 120,630] is first to be mined using split allocation of the generation reward.<br />
|-<br />
! April 30<br />
|| The generation difficulty passed 100,000.<br />
|-<br />
! June 2<br />
|| The exchange rate at [[MtGox]] touched 10 USD per BTC.<br />
|-<br />
! June 8<br />
|| 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].<br />
|-<br />
! June 12<br />
|| The [[MtGox]] exchange rate briefly dropped to near 10 USD four days after the peak, in its largest percentage price retreat to date.<br />
|-<br />
! June 13<br />
|| 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).<br />
|-<br />
! June 19<br />
|| 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.<br />
|-<br />
! June 19<br />
|| 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).<br />
|-<br />
! June 19<br />
|| 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.<br />
|-<br />
! June 20<br />
|| The EFF announced that it was no longer accepting Bitcoin donations due to legal uncertainties.<br />
|-<br />
! June 24<br />
|| The generation difficulty passed 1,000,000 with Block [http://blockexplorer.com/b/133056 133056].<br />
|-<br />
! July 22<br />
|| [[BitCoins Mobile]], the first Bitcoin application for iPad was released by [http://www.intervex.net Intervex Digital].<br />
|-<br />
! August 20<br />
|| First Bitcoin Conference and World Expo held, in NYC.<br />
|-<br />
! August 23<br />
|| [[P2Pool]], the first P2P decentralized pool, mines its first Bitcoin mainnet block (Block [http://blockexplorer.com/b/142312 142,312]).<br />
|-<br />
! August 30<br />
|| Difficulty adjustment at block [http://blockexplorer.com/b/143136 143,136] marks the first back-to-back drop.<br />
|-<br />
! November 15<br />
|| First CVE (CVE-2011-4447) assigned to a Bitcoin client exploit.<br />
|-<br />
! November 25<br />
|| First European Bitcoin Conference in Prague, Czech Rep.<br />
|-<br />
! December 12<br />
|| Largest amount of fees, to-date, in a single transaction, and most fees in a single block. A [http://blockexplorer.com/tx/1d7749c65c90c32f5e2c036217a2574f3f4403da39174626b246eefa620b58d9 transaction] paid 171 BTC in fees in [http://blockexplorer.com/b/157235 block 157235]<ref>[http://bitcointalk.org/index.php?topic=88423.msg973509#msg973509 Largest fee ever?]</ref>.<br />
|}<br />
== 2012 ==<br />
{| style="text-align: left"<br />
|-<br />
! width="8em" | March 1<br />
|| Largest theft of bitcoins to-date occurred (near 50K BTC) after security breach at web host Linode.<br />
|-<br />
! May 08<br />
|| A single service, [[SatoshiDICE]] becomes responsible for over half the transaction volume on the Bitcoin blockchain.<br />
|-<br />
! June 3<br />
|| Largest block (most transactions), to-date (June 3), is [http://BlockExplorer.com/b/181919 block 181919] with 1322 transactions<ref>[http://bitcointalk.org/index.php?topic=85353.msg939859#msg939859 Largest block to date]</ref>.<br />
|-<br />
! July 22<br />
|| One millionth topic reply was posted on the unofficial [[Bitcoin Forum]] <ref>[https://bitcointalk.org/index.php?topic=94608.0 Topic about one millionth forum post]</ref>.<br />
|}<br />
<br />
==See Also==<br />
<br />
* [[Bitcoin Firsts]]<br />
<br />
==References==<br />
<references /></div>Giszmo