https://tests.bitcoin.it/w/api.php?action=feedcontributions&user=Superb&feedformat=atomBitcoin Wiki - User contributions [en]2024-03-28T14:02:33ZUser contributionsMediaWiki 1.30.0https://tests.bitcoin.it/w/index.php?title=Help:Introduction&diff=49287Help:Introduction2014-08-01T13:37:41Z<p>Superb: </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 must 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 need 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, or their balance partially or wholly confiscated.<br />
* Banks and other payment processors like PayPal, Visa, and Mastercard may refuse to process payments for certain 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 />
<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, for a given unit of time 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 create 25 new 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%. Originally the block reward was 50 bitcoins; it halved in November 2012. 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 whoever finds the next block. Paying this fee will encourage miners to include the transaction in a block more quickly.<br />
<br />
===Sending payments===<br />
<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 to Alice.<br />
* Alice adds Bob’s address and the amount of bitcoins to transfer to a message: a 'transaction' message.<br />
* Alice signs the transaction with her private key, and announces her public key for signature verification.<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 address and the amount of bitcoins to transfer to a message: a 'transaction' message.<br />
* Bob signs the transaction with his private key, and announces his public key for signature verification.<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 address with her address, 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 />
<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 & Security]]===<br />
<br />
Bitcoin could be interpreted as a ‘pseudo-anonymous’ network. It is anonymous in the sense that you can hold a Bitcoin address without revealing anything about your identity in that address. One person could hold multiple addresses, and in theory, there would be nothing to link those addresses together, or to indicate that the person owned them.<br />
<br />
A [[Address|Bitcoin address]] mathematically corresponds to a public key and looks like this:<br />
<br />
:1PHYrmdJ22MKbJevpb3MBNpVckjZHt89hz<br />
<br />
There is another side to Bitcoin. Everything that happens in the Bitcoin world is trackable. Thanks to the way that the algorithm is structured, every Bitcoin-based transaction is logged in the blockchain.<br />
<br />
All exchanges require the user to scan ID documents, and large transactions must be reported to the proper governmental authority. When you use Bitcoin to pay for goods and services, you will of course need to provide your name and address to the seller for delivery purposes.<br />
<br />
This means that a third party with an interest in tracking your activities can use your visible balance and ID information as a basis from which to track your future transactions or to study previous activity. In short, you have compromised your [[security]] and [[privacy]].<br />
<br />
===Capitalization / Nomenclature===<br />
<br />
Since Bitcoin is both a currency and a protocol, capitalization can be confusing. Accepted practice is to use ''Bitcoin'' (singular with an upper case letter B) to label the protocol, software, and community, and ''bitcoins'' (with a lower case b) to label units of the currency.<br />
<br />
==Where to see and explore==<br />
<br />
You can directly explore the system in action by visiting [https://www.biteasy.com/ Biteasy.com], [http://blockchain.info/ Blockchain.info], [http://btc.blockr.io/ Blokr.io Bitcoin Block Explorer] 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 />
* [[Anonymity & Security]]<br />
* [http://bitcoinhelp.net Bitcoin Help] &mdash; the simple guide to Bitcoin.<br />
* Learn the entire history of Bitcoin in the interactive timeline at [http://historyofbitcoin.org History of Bitcoin].<br />
* Get started buying bitcoins at [http://coinbase.com/ Coinbase].<br />
* [http://bitcoinX.io BitcoinX.io] Website Dedicated to Providing Users with the Best Information on Where to Buy, Sell and Trade Bitcoins. Covers all of the Major Exchanges.<br />
* [[File:MCS_200by200_logo-01.png|20px|link=http://www.mycoinsolution.com]][http://www.mycoinsolution.com My Coin Solution] - For business that want to learn more about Bitcoin<br />
* [https://www.trybtc.com/ TryBTC] easiest way to get started using bitcoin. Gives you free coins to create a bitcoin wallet and start spending.<br />
* [http://www.youtube.com/watch?v=Um63OQz3bjo What is Bitcoin?] video introduction<br />
* Installing Bitcoin [[getting started]] <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 />
* [http://dpassport.com/free-reports/Free-Bitcoin-Report.pdf Free Bitcoin report] by Brad Gosse and Jennifer Wozniak<br />
<br />
[[zh-cn:简介]]<br />
<br />
[[de:Einführung]]<br />
[[fr:Introduction]]</div>Superbhttps://tests.bitcoin.it/w/index.php?title=Earning_bitcoins&diff=49286Earning bitcoins2014-08-01T13:34:22Z<p>Superb: </p>
<hr />
<div>These websites have bonus programs that allow you to earn bitcoins by doing things like taking surveys, answering questions, trying apps, viewing advertisements, referring others to the website, and making purchases at other websites. Some of these have many of the same offers (but they give different payouts for participating in those offers).<br />
<br />
== Offer Programs ==<br />
<br />
* [http://www.bitcoinreward.net Bitcoinreward] Earn Bitcoins by completing simple tasks such as watching videos, checking search engine results and small surveys. Payouts range from 250 to 1,000,000 Satoshi (0.01 BTC) and users are paid every 24 hours for balances of 10,000 or more Satoshi. No signup is required, you get 1,000 Satoshi just for entering your Bitcoin address. They also offer a 50% referal scheme for life.<br />
<br />
* [http://www.freedigitalmoney.com/Bitcoins Free Digital Money] Earn bitcoins by participating in sponsored offers. There are approximately 1000 offers available. Some offers are free and some require a purchase. Bitcoins are sent to you immediately after you participate in each offer. No account is needed to participate in offers.<br />
<br />
* [http://www.iwantfreebitcoins.com iWantFreeBitCoins] Earn bitcoins by participating in sponsored offers. There are approximately 700 offers available. Some offers are free and some require a purchase. You receive a currency called BitPoints added to your balance immediately after you participate in each offer. Your BitPoints can be converted to bitcoins when you request a payout, which will be processed the following Wednesday or Sunday. The referral program pays 25% of everything earned by each user you refer. An account is needed to participate in offers.<br />
<br />
* [http://www.rugatu.com/ Rugatu Q&A] Get bitcoins by answering questions that other members have posted. A great way to do some freelancing job if you have an area of expertise and help support the bitcoin community. Sometimes higher value bounties are posted for programmers or media artists. You can login with your existing google, facebook, yahoo or openid account.<br />
<br />
* [http://www.bitcoinget.com BitcoinGet] Earn bitcoins for watching videos, completing tasks, and completing offers. No signup required. Just enter your Bitcoin address to start earning. No minimum payout. Payments are made daily to reduce transaction fees.<br />
<br />
* [http://bitbucks.com/ BitBucks] Earn bitcoins by filling out surveys and participating in promotional offers. Roughly 2000+ offers available worldwide: most are free but some require minor deposits (however the bitcoin-payout is usually comparatively larger than the deposit). Some offers require Facebook authentication [no personal information is collected]. The referral system pays 10% commissions on all earnings made by users who use your referral-link. No account is needed and you can earn bitcoins from any computer, phone or tablet.<br />
<br />
* [https://www.trybtc.com/ TryBTC] Features interactive tutorials in which users are given a small amount of Bitcoin to send to charitable causes and share with friends. In the process they are taught about concepts such as wallets, addresses, transactions, and the Bitcoin Blockchain. You get to keep up to 5 cents in BTC at the end.<br />
<br />
* [http://btcnews.nl/_bonus/bonus_programmas.php BtcNews.nl] Similar to BitcoinGet. Earn bitcoins by filling out surveys and participating in promotional offers. Roughly 2000+ offers available worldwide: all are free. The referral system pays 10% commissions on all earnings made by users who use your referral-link. No account is needed and you can earn bitcoins from any computer, phone or tablet. At the moment the language is only in Dutch, but all worldwide users can participate when understanding the structure of the page.<br />
<br />
* [http://www.Bitalo.com/ Bitalo.com - Secure online wallet and exchange] Earn 5 USD of free bitcoins simply by signing up and get a verified account or by referring new users.<br />
<br />
== Additional Resources ==<br />
<br />
* [http://bonusbitcoin.weebly.com/ BonusBitcoin List] A list of bitcoin bonus offers. Updated almost every day.<br />
<br />
==See Also==<br />
<br />
* [[Anonymity & Security]]<br />
* [[Getting_started|Getting Started]]<br />
* [[Bitcoin_Affiliate_Programs|Affiliate Programs]]<br />
* [[Trade|Bitcoin Businesses]]</div>Superbhttps://tests.bitcoin.it/w/index.php?title=How_to_use_a_Bitcoin_wallet_(for_newbies)&diff=49284How to use a Bitcoin wallet (for newbies)2014-08-01T13:32:46Z<p>Superb: </p>
<hr />
<div>This page aims to be the best resource for new users to understand how Bitcoin wallets work, and how to use them.<br />
<br />
== Introduction ==<br />
<br />
To use Bitcoin, some sort of wallet is needed. There are [http://bitcoin.org/clients.html several wallet programs] from you to choose from, as well as a web wallet called [http://blockchain.info/wallet/ My Wallet].<br />
<br />
== Security ==<br />
Before proceeding, you should [[Securing_your_wallet#Making_a_secure_workspace|make sure your computer system is secure]].<br />
<br />
== How to use My Wallet ==<br />
The following demonstrates how to use My Wallet, but most of it applies to any other client you choose.<br />
<br />
# [http://blockchain.info/wallet/ Open an account]<br />
# [[Securing_your_wallet#Password_Strength|Choose a strong password]]<br />
## '''Note''' - there is no "reset your password" feature. You must not lose your password.<br />
# Recommended: Associate an email address with the account, for backup purposes.<br />
# You now have a [[Address|Bitcoin Address]], which you can use to receive payments - just email your address to another person, and he can send money directly to this address.<br />
## '''Note''' - anyone who knows your address might be able to analyze your transactions and estimate how much Bitcoins you own. [http://bitcoin.stackexchange.com/questions/52/how-anonymous-are-bitcoin-transactions Understand that Bitcoin is pseudonymous], not anonymous.<br />
# Understand that your wallet can contain numerous bitcoin addresses. It is a good practice to generate a new receiving address for each incoming transaction, to increase [[Anonymity & Security|anonymity]].<br />
# You can now [[How to get free Bitcoins?|get some Bitcoins ... for free]]. Make sure to test it, try sending a few (milli)bitcoins to someone and get the hang of it.<br />
# If you want to own some more Bitcoins, proceed to [[Buying Bitcoins (the newbie version)]]<br />
<br />
== How to use another client ==<br />
The other clients are similar in principle to My Wallet, but there are a few important differences:<br />
<br />
# You need to download a software to your computer to use them (make sure to only download form a trusted source ... if unsure, ask)<br />
# You have to take care to [[Backup#Backup|make a secure backup of your wallet]].<br />
<br />
<br />
[[Category:Introduction]]</div>Superbhttps://tests.bitcoin.it/w/index.php?title=Acceptance_policies&diff=49283Acceptance policies2014-08-01T13:32:21Z<p>Superb: </p>
<hr />
<div>Many businesses accept Bitcoins in exchange for their goods and services. Their policies vary depending on what they sell and their flexibility in pricing their goods. Here are some of the most common policies.<br />
<br />
==Cheaper In Bitcoins (CASH)==<br />
Goods and services are available for traditional currency, but are priced at a discount when purchased with Bitcoins because the merchant, for philosophical reasons, cost savings, or otherwise, prefers to receive Bitcoins as payment. Merchants may offer goods and services for a discount in Bitcoins for any of the same reasons they might offer a discount in person for immediate payment in cash.<br />
<br />
This policy is most favorable to the consumer using Bitcoins and is the most likely to attract business from the Bitcoin community.<br />
<br />
==Fixed Bitcoin price (FBP)==<br />
Goods and services are priced in BTC. Price changes, when necessary, are considered manually. This is common for goods and services that are sold exclusively in Bitcoins.<br />
<br />
==Fixed Bitcoin price with reserve (FBPR)==<br />
Same as Fixed price in BTC, but the merchant reserves the right, during periods of high price volatility, to temporarily suspend acceptance of BTC, or to charge a price that leaves the customer bearing most of the risk.<br />
<br />
==Liquidation Price (LIQ)==<br />
Goods and services are priced in traditional currency (dollars/euro), and Bitcoins are credited strictly for the traditional currency that can be obtained on the exchanges by selling the Bitcoins immediately at the time the trade is made. In many cases, this is exactly what happens, and the credit is equal to the proceeds of the trade.<br />
<br />
This pricing is least favorable to the consumer using Bitcoins, but also presents the lowest risk to traditional businesses who have opted to accept Bitcoins as payment. It tends to make payment by traditional currency more favorable, and usually only attracts Bitcoin business in cases where use of traditional payment is undesirable (e.g. buyer wants [[Anonymity & Security|anonymity]], or Bitcoin is the only payment method accepted, or where seller requires a non-recourse transaction as a condition of doing business)<br />
<br />
The merchant reserves the right to temporarily suspend acceptance of Bitcoins if liquidation is impractical or impossible (such as due to unavailability of the exchanges).<br />
<br />
==Proportional price (PP)==<br />
Goods and services are priced as a percentage of some other factor. For example, the MtGox trading fee is priced as a percentage of the trading volume. Adjustments due to exchange rates are unnecessary or rare under this policy, often because they are balanced out by some other factor (such as trading volume).<br />
<br />
==Last Trade Price (LAST)==<br />
Goods and services are priced in traditional currency (dollars/euro). Bitcoins are used as a substitute for traditional currency. A price believed to reflect the most recent trade on the exchanges is used. A merchant reserves the right to apply this policy only to "typical" size transactions for that merchant. A price may be locked for up to several minutes to ensure the transaction can be started and completed at a single price. During times of high volatility, price locking will be unavailable.<br />
<br />
Websites may present LAST pricing in the form of external images that are automatically updated by a web service to compute a BTC price from the exchange rates in real time.<br />
<br />
==Last Trade Price with Reserve (LASTR)==<br />
This policy is like LAST, where the merchant prefers to use the last trade price for simplicity, except that the merchant further reserves the right to use it only during times of stable trading activity where the bid/ask spread is minimal.<br />
<br />
Merchants reserve the right to use an alternate policy (e.g. MID, BB) whenever there is a significant bid/ask spread on the exchanges, and to use LIQ or to suspend acceptance of Bitcoins during times of very high volatility.<br />
<br />
==Best Bid (BB)==<br />
Goods and services are priced in traditional currency (dollars/euro). Bitcoins are used as a substitute for traditional currency. The highest unsatisfied bid price shown on the exchanges is used as an exchange rate. A merchant reserves the right to apply this policy only to "typical" size transactions for that merchant, defaulting to Liquidation Price (LIQ) for abnormally large transactions. A price may be locked for up to several minutes to ensure the transaction can be started and completed at a single price. A merchant may suspend price locking or acceptance of Bitcoins during high volatility.<br />
<br />
Websites may present BB pricing in the form of external images that are automatically updated by a web service to compute a BTC price from the exchange rates in real time.<br />
<br />
==Midpoint between Best Bid and Best Ask (MID)==<br />
Goods and services are priced in traditional currency (dollars/euro). Bitcoins are used as a substitute for traditional currency. The midpoint between the highest unsatisfied bid price and the lowest unsatisfied ask price shown on the exchanges is used as an exchange rate. A merchant reserves the right to apply this policy only to "typical" size transactions for that merchant, defaulting to Liquidation Price (LIQ) for abnormally large transactions. A price may be locked for up to several minutes to ensure the transaction can be started and completed at a single price. A merchant may suspend price locking or acceptance of Bitcoins during high volatility.<br />
<br />
Websites may present BB pricing in the form of external images that are automatically updated by a web service to compute a BTC price from the exchange rates in real time.<br />
<br />
==Recent Weighted Trade Price (RWTP)==<br />
Goods and services are priced in traditional currency (dollars/euro). Bitcoins are used as a substitute for traditional currency. A price believed to reflect a weighted average of recent trades on the exchanges is used. The actual formula is not defined by the policy, but typically tracks trading activity over the past few hours, and is often calculated by the exchanges.<br />
<br />
A merchant reserves the right to apply this policy only to "typical" size transactions, defaulting to Liquidation Price (LIQ) for abnormally large transactions, and to suspend acceptance of Bitcoins during periods of high volatility.<br />
<br />
Websites may present RWTP pricing in the form of external images that are automatically updated by a web service to compute a BTC price from the exchange rates in real time.</div>Superbhttps://tests.bitcoin.it/w/index.php?title=Hashcash&diff=49280Hashcash2014-08-01T13:29:18Z<p>Superb: </p>
<hr />
<div>This page explains hashcash and how bitcoin uses it.<br />
<br />
==Hashcash==<br />
<br />
Bitcoin uses the [http://en.wikipedia.org/wiki/Hashcash hashcash] [[Proof_of_work]] function as the mining core. All bitcoin miners whether CPU, GPU, FPGA or ASICs are expending their effort creating hashcash proofs-of-work which act as a vote in the blockchain evolution and validate the blockchain transaction log.<br />
<br />
Like many cryptographic algorithms hashcash uses a hash function as a building block, in the same way that HMAC, or RSA signatures are defined on a pluggable hash-function (commonly denoted by the naming convention of algorithm-hash: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, RSA-SHA1, etc), hashcash can be instantiated with different functions, hashcash-SHA1 (original), hashcash-SHA256^2 (bitcoin), hashcash-Scrypt(iter=1) (litecoin).<br />
<br />
===History===<br />
<br />
The hashcash proof-of-work function was invented in 1997 by [http://en.wikipedia.org/wiki/Adam_Back Adam Back], and proposed for anti-DoS uses including preventing: anonymous remailer and mail2news gateway abuse, nym name squatting on nymservers (replyable pseudonymous remailer severs), as well as general email anti-spam and general network abuse throttling. Before bitcoin, hashcash was used by SpamAssasin, and (with an incompatible format) by Microsoft (with the name "email postmark") in hotmail, exchange, outlook etc and by i2p anonymity network, mixmaster anonymous remailer components and other systems. Hashcash was also used by [http://en.wikipedia.org/wiki/Hal_Finney_(cypherpunk) Hal Finney]'s bitcoin precursor RPOW as a way to mine coins. Wei Dai's [[B-money Proposal]], and Nick Szabo's similar [[Bit_Gold_proposal]] bitcoin precursors, also were proposed in the context of hashcash mining.<br />
<br />
===Hash function choices===<br />
<br />
In the original 1997 algorithm hashcash used SHA1 because at that time, this was the defacto and NIST recommended hash, and the previous defacto hash MD5 had recently started to show signs of weakness. Bitcoin being specified/released in 2008/2009 uses SHA256. There is actually no strong reason SHA1 would not have worked also, hashcash relies only on the hash partial preimage resistance property (security up to hash-size, 160-bit with SHA1) and not birthday collision hardness (security up to 80-bit), so the SHA1 hash is big enough. Bitcoin is anyway built to 128-bit security because 256-bit ECDSA is used, which also offers 128-bit security. Never the less SHA256 is the correct and more conservative choice because even SHA1 has started to show some weakenesses, though only in birthday collision, not in 2nd-preimage.<br />
<br />
===Double Hash===<br />
<br />
Bitcoin is using two hash iterations (denoted SHA256^2 ie "SHA256 function squared") and the reason for this relates to a partial attack on the smaller but related SHA1 hash. SHA1's resistance to birthday attacks has been partially broken as of 2005 in O(2^64) vs the design O(2^80). While hashcash relies on pre-image resistance and so is not vulnerable to birthday attacks, a generic method of hardening SHA1 against the birthday collision attack is to iterate it twice. A comparable attack on SHA256 does not exist so far, however as the design of SHA256 is similar to SHA1 it is probably defensive for applications to use double SHA256. And this is what bitcoin does, it is not necessary given hashcash reliance on preimage security, but it is a defensive step against future cryptanalytic developments. The attack on SHA1 and in principle other hashes of similar design like SHA256, was also the motivation for the NIST SHA3 design competition which is still ongoing.<br />
<br />
===Future Hash===<br />
<br />
Once the NIST SHA3 contest has finalised, bitcoin might in the future consider adopting hashcash-SHA3 as a security upgrade (eg a single invocation of SHA3 vs a double invocation of SHA256). It seems clear from the SHA1 break, and SHA256 is a similar design, that there was previously a misunderstanding about the security of hash functions against birthday collisions, and SHA3 finalists all aim to fix that issue. One aspect of relevance for hashcash-SHA3 is that there is some debate within the NIST comments process on the proposal of weakening SHA3's resistance to pre-image attacks down to 128-bit (vs the full hash size as with previous hashes). The motivation is a small performance gain, with the rationale that some hash-pluggable algorithms do not rely on full-length pre-image resistance. The proposal has met with significant negative feedback due to it creating a non-standard security assumption (compared to all previous hashes), and therefore it creates risk and all hash-pluggable algorithms (like HMAC, RSA, DSA, hashcash etc) would need to be re-examined on a case by case basis to see if SHA3 is safe to use with them; from the balance of the feedback it seems probable that NIST will accept the feedback and SHA3 will retain the full 256-bit pre-image resistance. <br />
<br />
===Cryptanalytic Risks===<br />
<br />
A practical issue with switching to hashcash-SHA3 is that it would invalidate all existing ASIC mining hardware, and so is a change that would unlikely to be made except in the face of security risk; there is no indication that SHA1 or SHA256, or SHA256^2 are vulnerable to pre-image attack so the motivation is missing absent new cryptanalytic developments. In addition even if SHA256^2 became easier due to cryptanalytic attack, and miners started using whatever the new algorithmic approach was, it does not necessarily matter as difficulty would just adapt to it. One likely side-effect however would be that it would introduce more memory or pre-computation tradeoffs which could make ASICs unprofitable, or give advantages to people with large resources to do the pre-computations. Pre-computation advantages would perhaps be enough motivation to replace the hash with SHA3. Anyway this is all speculation if and until any pre-image affecting cryptanalytic attacks are found on SHA256.<br />
<br />
==Hashcash function==<br />
<br />
The hashcash algorithm is relatively simple to understand. The idea builds on a security property of cryptographic hashes, that they are designed to be hard to invert (so-called one-way or pre-image resistant property). You can compute y from x cheaply y=H(x) but it's very hard to find x given only y. A full hash inversion has a known computationally infeasible brute-force running time, being O(2^k) where k is the hash size eg SHA256, k=256, and if a pre-image was found anyone could very efficiently verify it by computing one hash, so there is a huge asymmetry in full pre-image mining (computationally infeasible) vs verification (a single hash invocation).<br />
<br />
A second hash pre-image means given one-preimage x of hash y where y=H(x), the task is to find another pre-image of hash y: x' so that y=H(x'). This is not to be confused with a birthday collision which is to find two values x, x' so that H(x)=H(x'), this can be done in much lower work O(sqrt(2^k))=O(2^(k/2)) because you can proceed by computing many H(x) values and storing them until you find a matching pair. It takes a lot of memory, but there are memory-time tradeoffs.<br />
<br />
Version 0 of hashcash protocol (1997) used a partial 2nd pre-image, however the later version 1 (2002) uses partial pre-images of a fairly chosen string, rather than digits of pi or something arbitrary, 0^k (ie all 0 string) is used for convenience, so the work is to find x such that H(x)=0. This is also equally fair and only requires one hash invocation to verify vs two with 2nd partial-pre-images. (This optimisation was proposed by Hal Finney & independently by Thomas Boschloo). To make the work easier the definition of a partial-pre-image is to find x such that H(x)/2^(n-k) = 0 where / is the integer quotient from division, n is the size of the hash output (n=256-bits for SHA256) and k is the work factor, ie, the first k bits of the hash output are 0 . So for example k=20 requires average 1 million tries. It is actually the output that partially matches, not the pre-image, so could perhaps more accurately called a pre-image with a partial output match, however partial pre-image effectively a short-hand for that.<br />
<br />
===Adding purpose===<br />
<br />
If the partial-pre-image x from y=H(x) is random it is just a disconnected proof-of-work to no purpose, everyone can see you did do the work, but they don't know why, so users could reuse the same work for different services. To make the proof-of-work be bound to a service, or purpose, the hash must include s, a service string so the work becomes to find H(s,c)/2^(n-k)=0. The miner varies counter c until this is true. The service string could be a web server domain name, a recipients email address, or in bitcoin a block of the bitcoin blockchain ledger.<br />
<br />
One additional problem is that if multiple people are mining, using the same service string, they must not start with the same x or they may end up with the same proof, and anyone looking at it will not honor a duplicated copy of the same work as it could have been copied without work, the first to present it will be rewarded, and others will find their work rejected. To avoid risking wasting work in this way, there needs to be a random starting point, and so the work becomes to find H(s,x,c)/2^(n-k) = 0 where x is random (eg 128-bits to make it statistically infeasible for two users to maliciously or accidentally start at the same point), and c is the counter being varied, and s is the service string.<br />
<br />
This is what hashcash version 1 and bitcoin does. In fact in bitcoin the service string is the coinbase and the coinbase includes the recipients reward address, as well as the transactions to validate in the block. Bitcoin actually does not include a random start point x, reusing the reward address as the randomization factor to avoid collisions for this random start point purpose, which saves 16-bytes of space in the coinbase. For privacy bitcoin expect the miner to use a different reward address on each successful block.<br />
<br />
===More Precise Work===<br />
<br />
Hashcash as originally proposed has work 2^k where k is an integer, this means difficulty can only be scaled in powers of 2, this is slightly simpler as you can see and fully measure the difficulty just by counting 0s in hex/binary and was adequate for prior uses. (A lot of hashcash design choices are motivated by simplicity).<br />
<br />
But because bitcoin needs more precise and dynamic control of work (to target 10-minute block interval accurately), it changes k to be a fractional (floating-point) so the work becomes to find H(s,x,c) < 2^(n-k) which is equivalent if k is an integer. Bitcoin defines target = 2^(n-k), so the work can be more simply written to find H(s,x,c) < target. Of course because of luck the block time actually has quite high variance, but the average is still more accurately targeted by the introduction of fractional k.<br />
<br />
===Work, difficulty & cryptographic security===<br />
<br />
Hashcash expresses security margin in the standard cryptographic security terms O(2^k) where for comparison DES offers k=56-bits of security, ECDSA-256 offers k=128-bits of security, and because its widely used this log2 way of expressing work and security can also be useful for making security comparisons.<br />
<br />
Bitcoin rate of work is called the [https://blockchain.info/q/hashrate network hashrate] in GH/sec. As the target block interval is 10 minutes that can be converted to cryptographic security as log2(hashrate*600), so that of Nov 2013 hashrate is 4 petahash/sec and bitcoin's hashcash-256^2 proofs-of-works are 62-bits (including +1 for double hash).<br />
<br />
Bitcoin also defines a new notion of (relative) difficulty which is the work required so that at current network hashrate a block is expected to be found every 10 minutes. It is expressed relative to a minimum work unit of 2^32 iterations (approximately, technically minimum work is 0xFFFF000 due to bitcoin implementation level details). Bitcoin difficulty is simple to approximately convert to log2 cryptographic security: k=log2(difficulty)+32 (or for high accuracy log2(difficulty*0xFFFF0000)). Difficulty is related to the target simply as difficulty = target / 0xFFFF000.<br />
<br />
It is perhaps easier to deal with high difficulties in log2 scale (a petahash/second is a 16 decimal digit number of hashes per second), and makes them comparable to other cryptographic security statements. For example the EFF "deepcrack" [https://en.wikipedia.org/wiki/EFF_DES_cracker DES cracker] project built a hardware brute force machine capable of breaking a DES key in 56 hours to make a political point that 56-bit DES was too weak in 1998 at a cost of $250,000 (plus volunteer design time). By comparison bitcoin network does 62-bits (including +1 for double hash) every 10-minutes and is 537,000 times more powerful than deepcrack, or could if it were focused on DES rather than SHA256 crack a DES key in 9 seconds to deepcracks 56 hours.<br />
<br />
===Miner privacy===<br />
<br />
In principle a miner should therefore for privacy use a different reward-address for each block (and reset the counter to 0). Why Satoshi's early mined bitcoins were potentially linked, was because while he changed the reward-addresss, he forgot to reset the counter after each successful mine, which is a bitcoin mining privacy bug. In fact with bitcoin the counter also should be obscured otherwise you would reveal your effort level, and if you have a lot of mining power that may imply who the coin belongs to. Bitcoin does this via the nonce and extra-nonce. Nonce starts at 0, but extra nonce is random. Together these form a randomized counter hiding the amount of effort that went into the proof, so no one can tell if it was a powerful but unlucky miner who worked hard, or a weak miner who was very lucky.<br />
<br />
Additionally with the introduction of mining pools, if the miner uses the same reward address for all users, which is what the current mining protocols do, then there is risk that users may redo work. To avoid users redoing work, miners hand out defined work for the users to do. However this creates an unnecessary communication round trip and in early protocol versions perhaps was a factor in the decision to have the pool send the actual block to mine, which means the miners are not validating their own blocks, which delegates validation authority, though not work, to the pool operator, reducing the security of the bitcoin network. The more recent mining protocol version allows the user to add their own block definition, but still unnecessarily incur round trips for handing out work allocation. Because the new pooled-mining protocol has a miner chosen extraNonce this acts as a random start factor so there is actually no need to talk to the pool for work allocation, a pool could have a static published address, and miners could just do work of whatever size they chose, and submit it to the pool as a UDP packet. (If privacy is required by the miner, it could use the public derivation method from BIP 32 to allow the node to tell the miner via an encrypted message with the mining work, which factor to multiply the static public key by.)<br />
<br />
===Scrypt proof-of-work===<br />
<br />
It is a misunderstanding to talk about the Scrypt proof-of-work.<br />
Scrypt is not intended as a proof-of-work function, but a stretched key-derivation function, and while it is by design expensive to compute with high iterations, it can not be used to make an efficiently publicly auditable proof-of-work, as verifying costs the same as creating.<br />
<br />
Hashcash with the internal hash function of Scrypt may be denoted hashcash-Scrypt(1). Scrypt, by Colin Percival, is a key-derivation function for converting user chosen passphrases into keys. It is salted (to prevent pre-computation/rainbow table attacks), and the hash is iterated many times to slow down passphrase grinding. Scrypt is similar in purpose to the defacto standard passphrase key-derivation function PBKDF2 (which uses HMAC-SHA1 internally). The differentiator and why people might choose Scrypt rather than PBDF2 is that Scrypt's inner hash uses more memory so the GPU (or theoretical Scrypt ASIC/FPGA) advantage in password grinding is reduced compared to CPUs.<br />
<br />
This does not use the key-stretching feature of Scrypt so mining is not actually using Scrypt directly, but only the inner Scrypt hash (accessed by setting the iteration parameter to one iteration). So Scrypt's key-stretching function is not being used at all to contribute to the hardness, unlike its normal use for key protection eg in deriving the encryption key from user passphrase to encrypt bitcoin wallets. The reason Scrypt's key-stretching can not be used for mining is because that simultaneously makes it more expensive to verify by the same factor. This hashcash variant can be denoted hashcash-Scrypt(iter=1,mem=128KB) or shortened to hashcash-Scrypt(1). The other major scrypt parameter denotes the amount of memory used (usually 128kB).<br />
<br />
===Decentralization: hashcash-Scrypt vs hashcash-SHA256===<br />
<br />
The 128kB Scrypt memory footprint makes litecoin arguably less vulnerable to centralization of mining power arising from limited access to or ownership of ASIC equipment by users. It's arguable and unclear, because there are counter arguments: that hashcash-SHA256^2 is very simple, so a skilled individual with his personal savings or a small Kickstarter project could design and put in an order with a chip-fabricator. This simplicity ensures that many people will do it and ASICs should become available. Conversely it is somewhat more difficult in comparison to make an hashcash-Scrypt(1) ASIC so perhaps litecoin will prove in the mid-term actually worse for centralization, if a well funded commercial entity corners the market by having faster, but proprietary, not available on the market, hashcash-Scrypt(1) ASICs that render litecoin GPU mining unprofitable. <br />
<br />
Note also a mitigating factor is that it is considered that hashcash-Scrypt(1) should offer less speed up from ASIC implementation vs GPUs than hashcash-SHA256^2. This is claimed because of the argument that the die area taken up by 128kB of RAM, which it might be thought must be dedicated to each Scrypt(1) core, would reduce the number of Scrypt(1) cores that fit per chip. Note however that Scrypt(1) is not actually securely memory-hard in that it makes no attempt to prevent time-memory tradeoffs, so it is actually possible to repeat the computation of internal rounds to reduce the memory requirement. In theory therefore it would be possible though more computation expensive to implement Scrypt(iter=1, mem=128kB) with minimal memory, just with more work. In hardware the time-memory tradeoff would be optimized to find the optimal amount of memory to use, and it is quite possible the optimal amount would be less than 128kB.<br />
<br />
Hashcash-Scrypt(1) also has a disadvantage relative to hashcash-SHA256^2 in that it is significantly slower to verify, as the verification cost of one iteration of Scrypt(mem=128kB) is far higher than a two SHA256 hashes. This makes validating the litecoin blockchain more CPU and memory intensive for all full nodes. Note however that the dominating CPU work of validation is the verification of the per transaction ECDSA signatures of the multiple transactions in a block. Even one ECDSA signature is slower than one Scrypt(1) verification which is done once per block, and there are many transactions (and so ECDSA signature verifications) to verify within a block.<br />
<br />
== See Also ==<br />
<br />
* [[Anonymity & Security]]</div>Superbhttps://tests.bitcoin.it/w/index.php?title=Blind_Bitcoin_Transfers&diff=49279Blind Bitcoin Transfers2014-08-01T13:28:10Z<p>Superb: </p>
<hr />
<div>A [[mixing service]] which is an implementation of David Chaum's blind digital cash scheme.<br />
<br />
Client-side cryptography is done in the browser. <br />
<br />
==History==<br />
<br />
This service was first seen in June, 2011. In August, 2011 the site displayed the message:<br />
Closed for the foreseeable future<br />
Somebody found an exploit in the code on this site. I am working on finding it, but, in the meantime, I have decided to get out of this business.<br />
<br />
==Fees==<br />
<br />
When transferring funds to the service, a fee is added. Though there was no fee schedule found on the site various amounts were used and the fee appears to be a flat 0.02 BTC per transfer.<br />
<br />
==See Also==<br />
<br />
* [[Anonymity & Security|anonymity]]<br />
* [http://www.bitcoin.org/smf/index.php?topic=2893.0 RFC: Bitcoin Mixnet]<br />
* [[Mixing service]]<br />
<br />
==External Links==<br />
<br />
* [http://blindbitcoin.com Blind Bitcoin Transfers] website<br />
<br />
==References==<br />
<references /></div>Superbhttps://tests.bitcoin.it/w/index.php?title=Public_relations&diff=49278Public relations2014-08-01T13:26:33Z<p>Superb: </p>
<hr />
<div>'''Public relations''' is about how Bitcoin is presented to the world. The mathematical foundations of Bitcoin minimize the level of trust necessary to use it, but for anyone who isn't interested in cryptography the strength of the Bitcoin brand is more important.<br />
<br />
This page lists some community-developed talking points, so if you'd like to promote Bitcoin consider using them.<br />
<br />
==Terminology==<br />
<br />
Bitcoin is a ''crypto-currency'', that is, a currency based on cryptography. However the crypto- prefix has another meaning, "something whose nature is obfuscated", as in cryptic messages. In that sense the term may not intuitively reflect the open source and community-based nature of the project. Also, cryptography is correctly perceived by many as a difficult and highly academic form of mathematics, which makes the term crypto-currency sound intimidating.<br />
<br />
There are various alternatives, but many don't translate well into other languages or have other undesirable connotations.<br />
<br />
'''Do say'''<br />
* Bitcoin is an [[digital currency|internet currency.]] This is an accurate description and combines two everyday concepts people are familiar with.<br />
* Bitcoin is a decentralized currency. This emphasizes the primary difference to regular, state backed currencies.<br />
* Bitcoin is a predictable currency, stressing the open nature of the algorithms and number there will be<br />
* Bitcoin is open source, demonstrating the community feeling of the currency<br />
* Bitcoin is getting stronger every day. Try and mention news stories and the current [[MtGox]] rates.<br />
<br />
'''Don't say'''<br />
* Bitcoin is a crypto-currency, grassroots currency, "currency of the people" etc. All these are loaded terms that may color peoples perceptions or translate badly into other languages. <br />
<br />
==Benefits==<br />
<br />
Bitcoin has many benefits over more traditional payment systems. Many of them can be summed up in one word: flexibility. Everyone likes flexibility, as long as it isn't too hard to deal with.<br />
<br />
'''Do say'''<br />
* Bitcoins can be stored with a bank or financial institution just like existing currencies if you want, but you're free to explore alternatives right up to and including entirely bank-free operation. After the financial crisis, disillusionment with banks is widespread and this aspect may appeal to some (not all).<br />
* Bitcoin can reduce the costs of everyday goods, by making the financial markets more competitive and eliminating the risk premium that credit card transactions entail.<br />
* Bitcoin is fair: it's as easy for you to sell things as buy them. Contrast with most existing payment systems in which accepting payments is much harder than making them.<br />
* Bitcoin has strong privacy: you should be able to choose who knows about your financial transactions. There are no statements mailed to you detailing your every financial move.<br />
* Bitcoin makes it easier to sell things over the internet. Most people aren't familiar with the myriad difficulties in this seemingly simple task.<br />
<br />
'''Don't say'''<br />
* Bitcoin transactions are free. They usually are today, but there are a few cases where a small fee is required. And in future fees will play a larger role. It's hard to predict what level fees will end up at, as they are paying for something entirely different to existing systems. There are good reasons to believe Bitcoin transactions will always be cheaper than most financial transactions are today, but the arguments on this topic are complex.<br />
* Bitcoin can't be taxed. Tax collectors were around before electronic payments and they'll be around after Bitcoin.<br />
* Bitcoin is anonymous. [[Anonymity & Security|Anonymity]] and Bitcoin is a complex topic, and anonymity means something slightly different to privacy.<br />
<br />
==Politics and the law==<br />
<br />
Bitcoin appeals to many libertarians, a political movement that emphasizes minimal government and individualism. If you are such a person, it's tempting to frame Bitcoin as some kind of anti-government force. But right or wrong many people are turned off by politics, and many others don't have an anti-government world view. This is especially true in Europe.<br />
<br />
'''Do say'''<br />
* Bitcoin is a chance to revolutionize the financial system, making it fairer and more democratic.<br />
* Bitcoin offers a strong level of privacy, but the people you trade with still know who you are. If the police turn up with the right warrants, they will probably learn who owns particular addresses. This means lawbreakers can still be tracked down with sufficient effort. As an analogy you can use the internet itself - whilst the average person and even large corporations can't find out the real identity behind an IP address, the law can make everyone work together to identify the owner.<br />
* Bitcoin allows anyone to pay anyone else. The authority to spend bitcoins belongs solely to the owner of the bitcoins. They decide and are responsible for the legality and morality of their actions, not a central authority. <br />
<br />
'''Don't say'''<br />
* Bitcoin is a way to topple or restrict the power of governments.<br />
* Bitcoin is impossible to regulate or control. There are schemes in which by regulating miners, Bitcoins can be frozen much as assets are sometimes frozen today. It's hard to know if they will ever be implemented, but it's not the case that Bitcoin cannot be regulated.<br />
* Bitcoin cannot be outlawed. There aren't any laws that would make Bitcoin obviously illegal, however, financial regulation is an extremely complex topic and it's possible that individual companies, exchanges etc, may at some point be found to not be in compliance. This happens to large, well-respected financial institutions so it's unreasonable to expect it will never happen to something Bitcoin related.<br />
<br />
==Expectations==<br />
<br />
Starting around the middle of 2010, Bitcoin has experienced dramatic growth in both the size of its community and exchange rates. People who are naturally optimistic or enthusiastic about Bitcoin sometimes try to promote it as a kind of get-rich-quick scheme.<br />
<br />
'''Do say'''<br />
* Bitcoin is an experiment that has grown rapidly as interest in the idea spreads.<br />
* There are many people trading real goods and services with Bitcoins.<br />
* Whilst the fundamental idea of Bitcoin is sound, pricing it is hard because nobody really knows the future potential. As a result the value swings wildly back and forth.<br />
* Although speculation of Bitcoins' value is possible and many are doing it, hoarding coins is an extremely risky investment strategy. Like many risky investments, it has potentially high returns but losses could be severe.<br />
* Whilst Bitcoin might fail, the concept of internet currencies is here to stay.<br />
<br />
'''Don't say'''<br />
* Bitcoins value has only gone up. Whilst the long term trend has been up, exchange rates are highly volatile and go down frequently.<br />
* Get in now before it's too late. This makes Bitcoin sound like a scam.<br />
* Bitcoin will take over the world unless <foo>. There are many potential end-games for Bitcoin of which "taking over the world" or "absolute failure" are only two. It could just as easily end up stuck in a niche, becoming an established competitor in the internet payments space but not going beyond that, etc.<br />
<br />
==Economics==<br />
<br />
Bitcoin uses a simple and easy to understand economic model, that is quite different to the one used by regular state-backed currencies today. Many people who just want to use the currency won't be interested in this aspect of the system. If they are:<br />
<br />
'''Do say'''<br />
* Bitcoin is intended to have a stable quantity of coins in existence in the long run.<br />
* Bitcoin inflates rapidly at present because the system is young. Over many decades, inflation will slow and eventually stop.<br />
* Assuming the (Bitcoin using) economy grows, that means that after some decades of operation, the value of a single Bitcoin will increase at roughly the same rate as the economy itself.<br />
* A growing economy with a static currency behaves, to the end user, much like a growing economy in which you put your money into an interest-bearing account. The value increases slowly over time, but you can usually earn more by investing in higher-risk ventures.<br />
* If it comes up, the usual formulation of the deflationary spiral argument (people won't spend money because it's always worth more tomorrow) is over-simplified. Consider consumer electronics, in which waiting a few months practically guarantees you something better for the same money. The actual economic argument, which is valid, has to do with the way existing currencies are expanded via the issuance of debt. Bitcoins are not issued via loans so the argument doesn't apply in the same way.<br />
<br />
'''Don't say'''<br />
* Bitcoin is deflationary. This implies the total amount of currency is intended to shrink. After inflation eventually shuts down, the currency will shrink at a very slow rate due to natural erosion, ie, people losing their wallet files due to failed hardware and missing backups (or simply losing interest and exiting the system). But this is better described as unavoidable than intentional.<br />
* There are 21 million coins. The Bitcoin definition of a coin is very unintuitive: it's a unit that can be divided into 100,000,000 pieces. If you want to discuss the exact limit, be sure to clarify that whilst we talk about "bitcoins", the placement of the decimal point is arbitrary and was chosen for convenience.<br />
<br />
==Notes and Addenda==<br />
<br />
It should be noted that the way you present the currency greatly depends on your audience. If the person you are speaking to is not an anarchist or anyone too much into anonymity, don't mention these aspects of the community. Tailor the way you present the currency to the interests of the audience.<br />
<br />
''e.g. Do not mention that you can buy all sorts of drugs untraceably at a geriatric knitting convention''<br />
<br />
==See Also==<br />
<br />
* [[Anonymity & Security]]<br />
* [[:Category:Marketing|Marketing]]<br />
<br />
[[Category:Marketing|Marketing]]</div>Superbhttps://tests.bitcoin.it/w/index.php?title=Research&diff=49277Research2014-08-01T13:25:55Z<p>Superb: </p>
<hr />
<div>Publications including research and analysis of Bitcoin or related areas.<br />
<br />
{| class="wikitable sortable"<br />
! Title<br />
! Author<br />
! Type<br />
! Year<br />
! Links<br />
|-<br />
| Bitcoin: A Peer-to-Peer Electronic Cash System<br />
| Satoshi Nakamoto<br />
| Research paper<br />
| 2009<br />
| [http://bitcoin.org/bitcoin.pdf Download] [[Bitcoin_paper |wiki page]]<br />
|-<br />
| Cyberlaundering: Anonymous Digital Cash and Money Laundering<br />
| R. Mark Bortner<br />
| Research paper<br />
| 1996<br />
| [http://osaka.law.miami.edu/~froomkin/seminar/papers/bortner.htm Download]<br />
|-<br />
| Triple Entry Accounting<br />
| Ian Grigg<br />
| Research paper<br />
| 2005<br />
| [http://iang.org/papers/triple_entry.html Download]<br />
|-<br />
| Shadowy Figures: Tracking Illicit Financial Transactions in the Murky World of Digital Currencies, Peer–to–Peer Networks, and Mobile Device Payments<br />
| John Villasenor, Cody Monk, Christopher Bronk<br />
| Research paper<br />
| 2011<br />
| [http://www.bakerinstitute.org/publications/ITP-pub-FinancialTransactions-082911.pdf Download]<br />
|-<br />
| An Analysis of Anonymity in the Bitcoin System<br />
| Fergal Reid, Martin Harrigan<br />
| Research paper<br />
| 2011<br />
| [http://arxiv.org/abs/1107.4524 Download], [http://bitcointalk.org/index.php?topic=31539.0 discussion]<br />
|-<br />
| Bitcoin: An Innovative Alternative Digital Currency<br />
| Reuben Grinberg<br />
| Research paper<br />
| 2011<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1817857 Download], [http://www.bitcointalk.org/index.php?topic=6247.0 discussion]<br />
|-<br />
| Bitcoin NFC<br />
| David Allen Bronleewe<br />
| Master's report<br />
| 2011<br />
| [http://repositories.lib.utexas.edu/bitstream/handle/2152/ETD-UT-2011-08-4150/BRONLEEWE-MASTERS-REPORT.pdf?sequence=1 Download], [http://code.google.com/p/bitcoin-nfc source code]<br />
|-<br />
| Optimal pool abuse strategy<br />
| Raulo<br />
| Research paper<br />
| 2011<br />
| [http://bitcoin.atspace.com/poolcheating.pdf Download], [http://www.bitcointalk.org/index.php?topic=3165.0 discussion]<br />
|-<br />
| Abusing Bitcoin cooperative mining pools: strategies for egoistical but honest miners<br />
| Nakamoto Ryo<br />
| Research paper<br />
| 2011<br />
| [http://www.bitcoinservice.co.uk/files/111 Download], [http://www.bitcointalk.org/index.php?topic=2941.0 discussion]<br />
|-<br />
| Analysis of Bitcoin Pooled Mining Reward Systems<br />
| Meni Rosenfeld<br />
| Research paper<br />
| 2011<br />
| [https://bitcoil.co.il/pool_analysis.pdf Download], [http://bitcointalk.org/index.php?topic=32814.0 discussion]<br />
|-<br />
| Bitcoin Exchange system<br />
| Tomáš Jiříček<br />
| Research paper<br />
| 2012<br />
| [https://dip.felk.cvut.cz/browse/pdfcache/jiricto2_2012bach.pdf Download]<br />
|-<br />
| On Bitcoin and Red Balloons<br />
| Moshe Babaioff, Shahar Dobzinski, Sigal Oren, Aviv Zohar<br />
| Publication article<br />
| 2012<br />
| [http://research.microsoft.com/pubs/156072/bitcoin.pdf Download]<br />
|-<br />
| 2011 Observations on the Digital Currency Industry<br />
| Mark Herpel<br />
| Publication article<br />
| 2011<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1721076 Download]<br />
|-<br />
| MAVE, New Lightweight Digital Signature Protocols for Massive Verifications<br />
| Sergio Demian Lerner<br />
| Research paper<br />
| 2012 (preliminary)<br />
| [http://bitslog.files.wordpress.com/2012/04/mave1.pdf Download]<br />
|-<br />
| MAVEPAY, a New Lightweight Payment Scheme for Peer to Peer Currency Networks<br />
| Sergio Demian Lerner<br />
| Research paper<br />
| 2012 (preliminary)<br />
| [http://bitslog.files.wordpress.com/2012/04/mavepay1.pdf Download]<br />
|-<br />
| Bitcoin: Eine erste Einordnung (an initial classification)<br />
| Christoph Sorge, Artus Krohn-Grimberghe<br />
| Research paper<br />
| 2012<br />
| [http://www.springerlink.com/content/cw1v762571tr4462/ Download], [http://bitcointalk.org/index.php?topic=90233.0 discussion]<br />
|-<br />
| Bitcoin - an introduction to the workings and a preliminary analysis and understanding of potential legal issues<br />
| Jean-Daniel Schmid, Alexander Schmid<br />
| Article<br />
| 2012<br />
| [http://ef-r.ch/images/publications/1338882576_Bitcoin.pdf Download]<br />
|-<br />
| Secure multiparty Bitcoin anonymization<br />
| Edward Z. Yang<br />
| Article<br />
| 2012<br />
| [http://blog.ezyang.com/2012/07/secure-multiparty-bitcoin-anonymization/ Download], [http://www.reddit.com/r/Bitcoin/comments/wvm2w/secure_multiparty_bitcoin_anonymization/ discussion]<br />
|-<br />
| Bitcoin & Gresham's Law - the economic inevitability of Collapse<br />
| Philipp Güring, Ian Grigg<br />
| Article<br />
| 2011<br />
| [http://iang.org/papers/BitcoinBreachesGreshamsLaw.pdf Download]<br />
|-<br />
| Today Techies, Tomorrow the World? Bitcoin.<br />
| Reuben Grinberg<br />
| Article<br />
| 2012<br />
| [http://www.milkeninstitute.org/publications/review/2012_1/22-31MR53.pdf Download]<br />
|-<br />
| Traveling the Silk Road: A measurement analysis of a large anonymous online marketplace<br />
| Nicolas Christin<br />
| Research paper<br />
| 2012<br />
| [http://www.cylab.cmu.edu/files/pdfs/tech_reports/CMUCyLab12018.pdf Download]<br />
|-<br />
| CommitCoin: Carbon Dating Commitments with Bitcoin<br />
| Jeremy Clark and Aleksander Essex<br />
| Research paper<br />
| 2012<br />
| [http://people.scs.carleton.ca/~clark/papers/2012_fc.pdf Download extended abstract]<br />[http://eprint.iacr.org/2011/677.pdf Download technical report]<br />
|-<br />
| Quantitative Analysis of the Full Bitcoin Transaction Graph<br />
| Dorit Ron and Adi Shamir<br />
| Research paper<br />
| 2012<br />
| [http://eprint.iacr.org/2012/584.pdf Download]<br />
|-<br />
| Design and security analysis of Bitcoin infrastructure using application deployed on Google Apps Engine<br />
| Piotr "ThePiachu" Piasecki<br />
| Master's thesis<br />
| 2012<br />
| [https://dl.dropbox.com/u/3658181/PiotrPiasecki-BitcoinMasterThesis.pdf Download], [https://bitcointalk.org/index.php?topic=88149.0 discussion]<br />
|-<br />
| The Production of Freedom: Value Production in the US- dominated Financial System, and Possible Alternatives<br />
| Jeremy Kirshbaum<br />
| Master's thesis<br />
| 2012 (preliminary)<br />
| [https://docs.google.com/document/d/1JIyMWIibqH8x20vGBTMBZ2yqM7Xbp54UpWBh0o2H7WI/edit?pli=1 Download], [https://bitcointalk.org/index.php?topic=87404.0 discussion]<br />
|-<br />
| COIN: a distributed accounting system for peer to peer networks<br />
| Fabio Varesano<br />
| Bachelor's thesis<br />
| 2012<br />
| [http://www.varesano.net/contents/projects/coin%20distributed%20accounting%20system%20peer%20peer%20networks Download]<br />
|-<br />
| BITCOIN CLIENTS<br />
| Rostislav Skudnov<br />
| Bachelor's thesis<br />
| 2012<br />
| [http://publications.theseus.fi/bitstream/handle/10024/47166/Skudnov_Rostislav.pdf?sequence=1 Download]<br />
|-<br />
| Bitter to Better—How to Make Bitcoin a Better Currency<br />
| Simon Barber, Xavier Boyen, Elaine Shi, Ersin Uzun<br />
| Research paper<br />
| 2012<br />
| [http://crypto.stanford.edu/~xb/fc12/bitcoin.pdf Download]<br />
|-<br />
| NooShare: A decentralized ledger of shared computational resources<br />
| Alex Coventry<br />
| Research paper<br />
| 2012<br />
| [http://mit.edu/alex_c/www/nooshare.pdf Download]<br />
|-<br />
| Bits and Bets. Information, Price Volatility, and Demand for Bitcoin<br />
| Martis Buchholz, Jess Delaney, Joseph Warren<br />
| Final project<br />
| 2012<br />
| [http://academic.reed.edu/economics/parker/s12/312/finalproj/Bitcoin.pdf Download], [http://www.reddit.com/r/Bitcoin/comments/x7kop/economic_analysis_of_the_demand_for_bitcoin discussion], [https://bitcointalk.org/index.php?topic=96003.0 discussion]<br />
|-<br />
| Two Bitcoins at the Price of One? Double Spending attacks on Fast Payments in Bitcoin<br />
| Ghassan O. Karame, Elli Androulaki, Srdjan Cap-kun <br />
| Research paper<br />
| 2012<br />
| [http://eprint.iacr.org/2012/248 Download]<br />
|-<br />
| Nerdy Money: Bitcoin, the Private Digital Currency, and the Case Against Its Regulation<br />
| Nikolei M. Kaplanov<br />
| Research paper<br />
| 2012<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2115203 Abstract]<br />
|-<br />
| Analysis of hashrate-based double-spending<br />
| Meni Rosenfeld<br />
| Research paper<br />
| 2012<br />
| [https://bitcoil.co.il/Doublespend.pdf Download]<br />
|-<br />
| Homomorphic Payment Addresses and the Pay-to-Contract Protocol<br />
| Ilja Gerhardt, Timo Hanke<br />
| Research Paper<br />
| 2012<br />
| [http://arxiv.org/pdf/1212.3257v1 Download] ([http://docs.google.com/viewer?url=http%3A%2F%2Farxiv.org%2Fpdf%2F1212.325qq7v1 via web viewer])<br />
|-<br />
| Quasi-Commodity Money (February 6, 2012). "This paper considers reform possibilities posed by a type of base money that has heretofore been overlooked in the literature on monetary economics."<br />
| George Selgin<br />
| Working Papers Series<br />
| 2012<br />
| [http://ssrn.com/abstract=2000118 Download]<br />
|-<br />
| Virtual currency schemes - "This report is a first attempt to provide the basis for a discussion on virtual currency schemes."<br />
| European Central Bank<br />
| Paper<br />
| 2012<br />
| [http://www.ecb.europa.eu/pub/pdf/other/virtualcurrencyschemes201210en.pdf Download]<br />
|-<br />
| Evaluating User Privacy in Bitcoin<br />
| Elli Androulaki, Ghassan Karame, Marc Roeschlin, Tobias Scherer and Srdjan Capkun <br />
| Paper<br />
| 2013<br />
| [http://fc13.ifca.ai/proc/1-3.pdf Download] ([http://fc13.ifca.ai/slide/1-3.pdf Slides]) <br />
|-<br />
| Beware the Middleman: Empirical Analysis of Bitcoin-Exchange Risk<br />
| Tyler Moore and Nicolas Christin <br />
| Short Paper<br />
| 2013<br />
| [http://fc13.ifca.ai/proc/1-2.pdf Download] ([http://fc13.ifca.ai/slide/1-2.pdf Slides]) <br />
|-<br />
| Bitcoin, Regulating Fraud In The E-Conomy Of Hacker-Cash<br />
| Derek A. Dion<br />
| Paper<br />
| 2013<br />
| [http://illinoisjltp.com/journal/wp-content/uploads/2013/05/Dion.pdf Download]<br />
|-<br />
| The practical materiality of Bitcoin<br />
| Bill Maurera, Taylor C. Nelmsa & Lana Swartz <br />
| Paper<br />
| 2013<br />
| [http://www.tandfonline.com/doi/full/10.1080/10350330.2013.777594#.UbbTVaD_6b4 Download]<br />
|-<br />
| Regulating Digital Currencies: Bringing Bitcoin within the Reach of the IMF<br />
| Nicholas Plassaras <br />
| Paper<br />
| 2013<br />
| [https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2248419 Download]<br />
|-<br />
| Bitcoin is Memory<br />
| William J. Luther, Josiah Olson <br />
| Paper<br />
| 2013<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2275730 Download]<br />
|-<br />
| The Economics of Bitcoin Mining or, Bitcoin in the Presence of Adversaries<br />
| Joshua A. Kroll, Ian C. Davey, and Edward W. Felten <br />
| Paper<br />
| 2013<br />
| [http://www.weis2013.econinfosec.org/papers/KrollDaveyFeltenWEIS2013.pdf Download]<br />
|-<br />
| Bitcoin: A Primer for Policymakers<br />
| Jerry Brito, Andrea Castillo<br />
| Research paper<br />
| 2013<br />
| [http://mercatus.org/publication/bitcoin-primer-policymakers Abstract] [http://mercatus.org/sites/default/files/Brito_BitcoinPrimer.pdf Download]<br />
|-<br />
| Whack-a-Mole: Prosecuting Digital Currency Exchanges<br />
| Catherine Martin Christopher <br />
| Research paper<br />
| 2013<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2312787 Abstract]<br />
[http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2312787_code1372021.pdf?abstractid=2312787&mirid=2 Download]<br />
|-<br />
| Are Cryptocurrencies 'Super' Tax Havens?<br />
| Omri Y. Marian<br />
| Research paper<br />
| 2013<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2305863 Abstract]<br />
[http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2316499_code592645.pdf?abstractid=2305863&mirid=1 Download]<br />
|-<br />
| Collective Emergent Institutional Entrepreneurship Through Bitcoin<br />
| Robin Teigland, Zeynep Yetis and Tomas Olov Larsson <br />
| Research paper<br />
| 2013<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2263707 Abstract]<br />
[http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2263707_code2053543.pdf?abstractid=2263707&mirid=1 Download]<br />
|-<br />
| Anonymity of Bitcoin Transactions<br />
| Malte Möser<br />
| Research paper<br />
| 2013<br />
| [https://www.wi.uni-muenster.de/sites/default/files/public/department/itsecurity/mbc13/mbc13-moeser-paper.pdf Download]<br />
|-<br />
| On the origins of Bitcoin: Stages of monetary evolution<br />
| Konrad S. Graf <br />
| Research paper<br />
| 2013<br />
| [http://konradsgraf.com/blog1/2013/10/23/on-the-origins-of-bitcoin-my-new-work-on-bitcoin-and-monetar.html Abstract]<br />
[http://konradsgraf.com/storage/On%20the%20Origins%20of%20Bitcoin%20Graf%2023.10.13.pdf Download]<br />
|-<br />
| Majority is not Enough: Bitcoin Mining is Vulnerable<br />
| Ittay Eyal and Emin Gun Sirer<br />
| Research paper<br />
| 2013<br />
| [http://arxiv.org/abs/1311.0243 Abstract]<br />
[http://arxiv.org/pdf/1311.0243v1 Download]<br />
|-<br />
| Bitcoin, the end of the Taboo on Money<br />
| Denis Roio aka Jaromil<br />
| Humanities article<br />
| 2013<br />
| [http://www.dyndy.net/2013/04/bitcoin-ends-the-taboo-on-money/ Abstract]<br />
[https://files.dyne.org/readers/Bitcoin_end_of_taboo_on_money.pdf Download]<br />
|-<br />
| Secure Multiparty Computations on BitCoin<br />
| Marcin Andrychowicz, Stefan Dziembowski, Daniel Malinowski and Łukasz Mazurek University of Warsaw <br />
| Research paper<br />
| 2013<br />
| [http://eprint.iacr.org/2013/784 Abstract]<br />
[http://eprint.iacr.org/eprint-bin/cite.pl?entry=2013/784 BibTeX]<br />
[http://eprint.iacr.org/2013/784.pdf Download]<br />
|-<br />
| A Fistful of Bitcoins: Characterizing Payments Among Men with No Names<br />
| Sarah Meiklejohn, Marjori Pomarole, Grant Jordan, Kirill Levchenko, Damon McCoy, Geoffrey M. Voelker, Stefan Savage<br />
| Research paper<br />
| 2013<br />
| <br />
[http://www.cs.gmu.edu/~mccoy/papers/imc13.pdf Download]<br />
|-<br />
| Information Propagation in the Bitcoin Network<br />
| Christian Decker (ETH Zurich, Switzerland), Roger Wattenhofer (Microsoft Research)<br />
| Research paper<br />
| 2013<br />
| <br />
[http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf Download]<br />
|-<br />
| The Economics of Private Digital Currency<br />
| Gerald P Dwyer<br />
| Research paper<br />
| 2014<br />
| [http://mpra.ub.uni-muenchen.de/55824/ Abstract]<br />
[http://mpra.ub.uni-muenchen.de/55824/1/MPRA_paper_55824.pdf Download]<br />
|-<br />
| The Origin, Classification and Utility of Bitcoin<br />
| Peter Šurda <br />
| Research Paper<br />
| 2014<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2436823 Abstract]<br />
|-<br />
| Deanonymisation of clients in Bitcoin P2P network<br />
| Alex Biryukov, Dmitry Khovratovich and Ivan Pustogarov<br />
| Research Paper<br />
| 2014<br />
| [http://arxiv.org/abs/1405.7418 Abstract] [http://arxiv.org/pdf/1405.7418v2.pdf Download]<br />
|-<br />
| Bitcoin Financial Regulation: Securities, Derivatives, Prediction Markets, & Gambling<br />
| Jerry Brito, Houman B. Shadab, Andrea Castillo<br />
| Research Paper<br />
| 2014<br />
| [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2423461 Abstract] [http://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2426195_code510873.pdf?abstractid=2423461&mirid=1 Download]<br />
|-<br />
| What are the main drivers of the Bitcoin price?<br />
| Ladislav Kristoufek<br />
| Research Paper<br />
| 2014<br />
| [http://arxiv.org/pdf/1406.0268v1.pdf Download]<br />
|-<br />
| The Economics of Bitcoin<br />
| Andre Herman<br />
| Bachelor's thesis<br />
| 2014<br />
| [http://www.scribd.com/doc/231964435/The-Economics-of-Bitcoin Download]<br />
|-<br />
| Near Zero Bitcoin Transaction Fees Cannot Last Forever<br />
| Kerem Kaşkaloğlu<br />
| Research Paper<br />
| 2014<br />
| [http://sdiwc.net/digital-library/near-zero-bitcoin-transaction-fees-cannot-last-forever.html Abstract] [http://sdiwc.net/digital-library/request.php?article=96cd6f6067fcbaf5e3947d071aa688fb Download]<br />
|-<br />
| Is Bitcoin Money?<br />
| Ísak Andri Ólafsson<br />
| Thesis Paper<br />
| 2014<br />
| [http://skemman.is/en/item/view/1946/18234 Abstract] [http://skemman.is/en/stream/get/1946/18234/42843/1/MS_%C3%8Dsak_Andri_%C3%93lafsson.pdf Download]<br />
|}<br />
<br />
==See Also==<br />
<br />
* [[Anonymity & Security]]<br />
* [http://people.scs.carleton.ca/~clark/biblio.html Jeremy Clark's Bitcoin Bibliography]<br />
* [[:Category:Economics|Economic]]<br />
* [[:Category:Technical|Technical]]<br />
* [[Press]]<br />
<br />
[[Category:Research]]</div>Superbhttps://tests.bitcoin.it/w/index.php?title=Open_Transactions&diff=49276Open Transactions2014-08-01T13:23:56Z<p>Superb: </p>
<hr />
<div>A financial crypto and digital cash software library. The software's author likens it to "PGP for money".<br />
<br />
Open Transactions (a centralized transaction system) is complementary to Bitcoin in that it provides some features that Bitcoin cannot, such as untraceable [[Anonymity & Security|anonymous]] (versus pseudonymous) transactions, no latency (instant finality of settlement / no risk of [[double spending]]) and more.<br />
<br />
Featuring: <br />
* Untraceable Digital Cash (real blinded tokens)<br />
* Anyone An Issuer (Ricardian-style Contracts) <br />
* Bearer-only, Fully-Anonymous (when used cash-only)<br />
* Pseudonymous User Accounts (user account == PGP key)<br />
* No Account History (asset account == the last receipt)<br />
* Many Financial Instruments (cheques, cash, vouchers, invoices...)<br />
* Basket Currencies (10 "baskets" == 5 gold, 3 silver)<br />
* Markets with Trades (stop, fill-or-kill, limit orders...)<br />
* Payment Plans<br />
<br />
Includes an API, server and client.<br />
<br />
The author of this software also released [[Moneychanger]], a reference implementation of a currency accounting application that accesses the Open Transactions API and integrates with Bitcoin.<br />
<br />
==See Also==<br />
<br />
* [[Anonymity & Security]]<br />
* [[Moneychanger]]<br />
* [[Mixing service]]<br />
* [[Anonymity]]<br />
* [[In-store Transactions]]<br />
<br />
==External Links==<br />
<br />
* [http://github.com/FellowTraveler/Open-Transactions Open Transactions] project on GitHub<br />
* [http://github.com/FellowTraveler/Open-Transactions#readme Readme]<br />
<br />
[[Category:Open Source]]</div>Superbhttps://tests.bitcoin.it/w/index.php?title=Browser-based_wallet&diff=49275Browser-based wallet2014-08-01T13:23:24Z<p>Superb: </p>
<hr />
<div>A '''browser-based wallet''' or '''wallet service''' is an online account with an external provider where bitcoins can be stored. Examples include accounts on currency exchange [[:Category:Markets|Markets]], online [[:Category:Services|Services]] and with ecommerce transaction processors. This definition also includes [[Browser-based_wallet#Hybrid_e-wallets|Hybrid e-wallets]].<br />
<br />
<span style="color:red">Warning: When storing your bitcoins with a browser-based wallet on a third-party website, you are trusting that the operator will not abscond with your bitcoins, and that operator maintains secure systems that protect against theft, internal or external. It is recommended that you obtain the real-world identity of the website operator, ensure that sufficient recourse is available and avoid services that do not use an offline wallet ([[cold storage]]) for bitcoins that are not needed for daily transactions. Storing significant quantities of bitcoins on third party websites is not recommended.</span> (Note: some [[Browser-based_wallet#Hybrid_e-wallets|Hybrid e-wallets]] might be exempt from this warning, and adequately safe for storing large amount of Bitcoins. In any case, do your own homework and learn how each site operates).<br />
<br />
==Benefits==<br />
* Use of a browser-based wallet provider may help improve [[Anonymity & Security|anonymity]] against third-parties who watch your IP address use.<br />
* An account with a wallet service can generally be established in just minutes.<br />
* Some bitcoin users store some or all of their bitcoins in a browser-based wallet to avoid having to worry about keeping a local wallet [[Securing_your_wallet|secure]].<br />
* Since withdrawals can be made to any Bitcoin address, simply using the withdrawal feature to withdraw to an address that is not yours is functionally equivalent to sending a Bitcoin payment when running the Bitcoin client locally.<br />
* Some services offer instant, internal transfers. This allows transactions to complete without having to wait for block confirmations.<br />
<br />
==Things to be aware of==<br />
<br />
When bitcoins are stored online, the provider retains full control of those amounts. You are trusting a third party to maintain your Bitcoin balance on your behalf. You would also need to trust the software implementation of the service, as well as your own browser. In comparison, if you run the Bitcoin software yourself, you are in full control of your coins so long as the wallet file stored on your computer is kept secret and secure.<br />
<br />
Other relevant things:<br />
<br />
* You typically have less anonymity with respect to those who run the online wallet site.<br />
* If a payment is made from an online wallet, the last-sent-to [[address]] (often [https://iwilcox.me.uk/2014/no-from-address incorrectly called a 'from' address]) is an address for the wallet provider and not an address reserved specifically for the sender. This is because the wallet service provider may service the payment from any coins in its possession - your balance is not associated with any particular coins, any more than your balance at your local bank is associated with any specific bills. Thus if the recipient were to "return" any bitcoins to the last-sent-to address, the sender would not receive those bitcoins &mdash; but last-sent-to addresses are [https://iwilcox.me.uk/2014/no-from-address#assumptions completely unsuitable for that anyway].<br />
<br />
* Not all wallet providers reserve a bitcoin address for the account holder indefinitely. Bitcoin addresses generally work best when one is assigned for each use. There is the risk of showing an address from a wallet provider in a directory or on a web page (for donations, as an example) as there is the possibility that at the future date when those bitcoins are sent that the intended recipient still has the wallet account. The same concern applies should the wallet provider cease operations.<br />
<br />
* While there are ways for the wallet provider to [https://iwilcox.me.uk/2014/proving-bitcoin-reserves demonstrate that they operate with full reserves], the practice is not widespread and doesn't protect against security breaches or the owner suddenly absconding with all funds.<br />
<br />
* Transactions to a Bitcoin address from the same wallet provider are usually completed internally and, if so, will not be processed on the Bitcoin P2P network. Auditing tools such as the [[Block Explorer]] will not show any activity for this transaction.<br />
** Some wallet providers allow amounts below 0.01 BTC to be sent if the transaction is to another account holder on the same service. This allows an inexpensive and immediate method to detect if the recipient is using the same wallet provider. <br />
<br />
* The wallet service provider's wallet may be vulnerable to security breaches, loss, or theft. Because Bitcoin transactions are irreversible, there may be limited or no recovery if a provider's master wallet is compromised. Wallet providers who implement preventative controls - such as keeping their reserves in an [[offline wallet]] - are likely to be safer.<br />
<br />
==Hybrid e-wallets==<br />
<br />
After several online bitcoin wallets were hacked, a second wave of online Bitcoin wallets entered the market. Hybrid wallets generally use Javascript in the user's browser to manage private keys and create payments.<br />
<br />
These wallets differed from traditional online wallet services because the user actually owns the private keys inside their wallet. This approach has several advantages:<br />
<br />
* The user can look up their account balance in the blockchain and which guarantees their account balance is correct.<br />
* Users can easily export their private keys out of a wallet to use with another bitcoin client or wallet provider; if they take backups of the code and wallet data, this may even be possible if the provider disappears.<br />
* The users' keys are stored encrypted on the server, offering some protection for security breaches if strongly encrypted.<br />
* As each address has only one user, it's less likely that [https://iwilcox.me.uk/2014/no-from-address misguided attempts to "return" coins] to their last-sent-to address will result in loss of coins.<br />
<br />
However, there are limits on what this model can achieve:<br />
<br />
* A single server compromise or abuse of trust can still result in losses for many users if the site serves maliciously modified Javascript.<br />
* Unless users make use of the backup/export facility, they're no less exposed to wallet data loss or confiscation by the provider.<br />
* The user's browser still presents a relatively large attack surface for exploits.<br />
* Facilities for obtaining entropy in the browser of a grade suitable for strong cryptography are currently poor, and custom entropy code almost never undergoes qualified review, so any keys or nonces created at the browser end may be weak.<br />
<br />
==See Also==<br />
<br />
* [[Anonymity & Security]]<br />
* [[Buying bitcoins]]<br />
* [[Selling bitcoins]]<br />
* [[Bitcoin faucet]]<br />
* List of [[:Category:HybridEWallets|HybridEWallets]]<br />
* List of [[:Category:eWallets|eWallets]]</div>Superbhttps://tests.bitcoin.it/w/index.php?title=PHP_developer_intro&diff=49274PHP developer intro2014-08-01T13:23:03Z<p>Superb: </p>
<hr />
<div>'''L'''inux '''A'''pache '''M'''ySQL '''P'''HP + Bitcoin tutorial.<br />
<br />
For this introduction we assume that you have GNU/Linux server with Apache and PHP and that you wish to interact with the Bitcoin network from a web application. We assume some knowledge of Bitcoin and experience in PHP.<br />
<br />
While this is written for PHP, the same principles apply for other languages. See the associated [[API reference (JSON-RPC)|API reference]] pages for info on other languages.<br />
<br />
The easiest way to get started is to run Bitcoin in daemon mode with which PHP communicates via local HTTP requests. A library called [http://jsonrpcphp.org/ JSON-RPC] is used to call the various functions of bitcoind, which will respond back with a [http://en.wikipedia.org/wiki/Json JSON object].<br />
<br />
== Setting up Bitcoin ==<br />
<br />
You can download the Bitcoin daemon from the [[Main_Page|homepage]] and run one of the included binaries or compile your own from the included source code. See [[Running Bitcoin]] for details on configuring bitcoind.<br />
<br />
Before running bitcoind you will need to create a configuration file in the Bitcoin data directory (~/.bitcoin/bitcoin.conf on Linux):<br />
<source lang="bash"><br />
rpcuser=user<br />
rpcpassword={you MUST pick a unique password to be secure}<br />
</source><br />
If you miss this step, bitcoind will remind you.<br />
<br />
Now run bitcoind:<br />
<source lang="bash"><br />
$ ./bitcoind<br />
# wait a few seconds for it to start up<br />
$ ./bitcoind getinfo<br />
# various information will be shown. If you get an error, try again until you see some useful output.<br />
$ ./bitcoind help<br />
# get help on commands, note no dash before help<br />
</source><br />
<br />
Bitcoin will begin synchronizing with the network and downloading a complete copy of the block chain. As of August 2012, more than 2gb of data must be downloaded and verified during this process. It may take two or more hours to complete. You will know when it's done when the block count reaches the [http://blockexplorer.com/q/getblockcount current count].<br />
<br />
== Getinfo (Bitcoind's version of Hello World) ==<br />
<br />
Assuming Bitcoin has finished the initialisation process; download the file jsonRPCClient.php from [http://jsonrpcphp.org/ JSON-RPC PHP] and place it in a web-accessible location.<br />
<br />
Second, create a PHP file with the following and visit it with your browser to test.<br />
<br />
<source lang="php"><br />
require_once 'jsonRPCClient.php';<br />
<br />
$bitcoin = new jsonRPCClient('http://user:password@127.0.0.1:8332/');<br />
<br />
echo "<pre>\n";<br />
print_r($bitcoin->getinfo());<br />
echo "</pre>";<br />
</source><br />
<br />
'''Note:''' The jsonRPCClient library uses fopen() and will throw an exception saying "Unable to connect" if it receives a 404 or 500 error from bitcoind. This prevents you from being able to see error messages generated by bitcoind (as they are sent with status 404 or 500). The [https://github.com/aceat64/EasyBitcoin-PHP EasyBitcoin-PHP library] is similar in function to JSON-RPC PHP but does not have this issue.<br />
<br />
== Precision ==<br />
<br />
Bitcoin amounts can range from 1 Satoshi (0.00000001 BTC) to nearly 2,100,000,000,000,000 (21,000,000 BTC). To avoid rounding errors, you must make sure your PHP implementation supports the full range of Bitcoin values without losing precision. Most PHP implementations use IEEE 64-bit double-precision floating point numbers with 53 bits of precision, which is enough to correctly represent the full range of bitcoin values.<br />
<br />
See [[Proper Money Handling (JSON-RPC)]] for more information.<br />
<br />
If your PHP implementation does not support 64-bit numbers (again, this is very rare), you must use a version of bitcoind that sends values as strings (genjix maintains a fork at http://github.com/genjix/bitcoin) and use the [http://php.net/manual/en/ref.gmp.php GMP] and [http://php.net/manual/en/ref.bc.php BC Math] libraries for all calculations involving bitcoin amounts.<br />
<br />
== Accounts ==<br />
<br />
In Bitcoin, money is sent to addresses and many addresses can be held by one wallet. The balance shown by default in bitcoind is the sum of the bitcoins in all the addresses in the wallet.<br />
<br />
Bitcoin goes another step. You can have [[Accounts explained|accounts]]. Each account holds multiple addresses and acts like a mini-bitcoind. <br />
<br />
<source lang="bash"><br />
$ ./bitcoind listaccounts<br />
# show list of accounts and various info for each one<br />
$ ./bitcoind getaccountaddress user889<br />
# get an address to receive money to that is unique for the account user889<br />
$ ./bitcoind getbalance user889<br />
# get the sum of all the money in the addresses owned by the account user889<br />
</source><br />
<br />
In your application, each user should have a unique username. You may then query bitcoind for a unique address using $bitcoin->getaccountaddress("user889"); [gets the first address for user889] or $bitcoin->getnewaddress("user889"); [creates a new address for user889].<br />
<br />
The customer then deposits to this address.<br />
<br />
You can check the funds for that customer by doing $bitcoin->getbalance("user889", 4);. The 4 indicates the minimum number of confirmations we will accept before assuming this payment is valid.<br />
<br />
If you will be using accounts for multiple deposits and withdrawals long-term, you may want to consider tracking user balances in your own database. This simplifies transfers between your application's accounts and decouples your accounts from the Bitcoin wallet.<br />
<br />
=== getnewaddress vs getaccountaddress ===<br />
<br />
Using getnewaddress helps increase maintain [[Anonymity & Security|anonymity]] of your users by making it hard for a malicious agent to track payments flowing through your application. Running getnewaddress too often, however, will cause your wallet to become filled with many empty addresses.<br />
<br />
It is therefore recommended to in some way limit the number of unfunded addresses each user can request. Here is an example using sessions:<br />
<source lang="php"><br />
<?php<br />
require_once('jsonRPCClient.php');<br />
$bitcoin = new jsonRPCClient('http://root:root@127.0.0.1:8332/'); <br />
# now check for appropriate funds in user account<br />
try {<br />
$username = ...<br />
if(isset($_SESSION['sendaddress']))<br />
$sendaddress = $_SESSION['sendaddress'];<br />
else {<br />
$sendaddress = $bitcoin->getnewaddress($username);<br />
$_SESSION['sendaddress'] = $sendaddress;<br />
}<br />
$balance = $bitcoin->getbalance($username);<br />
}<br />
catch (Exception $e) {<br />
die("<p>Server error! Please contact the admin.</p>");<br />
}<br />
?><br />
</source><br />
<br />
This creates a new address at the beginning of every new session, and stores it in the session variable.<br />
<br />
==See Also==<br />
<br />
* [[Anonymity & Security]]<br />
* [[API reference (JSON-RPC)]]<br />
* [[Lazy_API]]<br />
* [[Merchant Howto]]<br />
<br />
[[es:Introducción para desarrolladores de PHP]]<br />
[[de:Einführung_für_PHP-Entwickler]]<br />
<br />
[[Category:Developer]]</div>Superbhttps://tests.bitcoin.it/w/index.php?title=Weaknesses&diff=49272Weaknesses2014-08-01T13:20:30Z<p>Superb: </p>
<hr />
<div>== Might be a problem ==<br />
=== Wallet Vulnerable To Theft ===<br />
<br />
The [[wallet]] is stored unencrypted, by default, and thus becomes a valuable target for theft. Recent releases of the Bitcoin client now supports encryption to protect the wallet data, though the user must opt-in.<br />
<br />
==== New wallets vulnerable with old passwords via backups ====<br />
<br />
An old copy of a wallet with its old password is often easily retrievable via an existing backup facility (particularly Apple Time-Machine): draining that old wallet, with its old password, drains the current wallet with the current password -- this is contrary to most non-technical users expectation of what 'change the password on your wallet' should mean following password compromise.<br />
<br />
An initial solution is to mandate (either in code or as expressed policy) that changing a wallet's password causes (or asks the user to cause) the creation of a new wallet with new addresses, and the sending of existing sums to them. Backed-up copies of the original wallet with the original password would then be empty, should they be compromised. On the downside, the password-changing process would potentially take much longer, cost a transaction fee or more, and - intially at least - the new wallet is no longer backed up. On the upside, non-technical users won't find their wallets drained from security compromises they believed they had closed, nor be required to locate existing backups of a wallet in order to destroy them.<br />
<br />
=== Tracing a coin's history ===<br />
Tracing a coin's history can be used to connect identities to addresses. [[Anonymity & Security|More info]]|.<br />
<br />
=== Sybil attack ===<br />
An attacker can attempt to fill the network with clients controlled by him, you would then be very likely to connect only to attacker nodes. Although Bitcoin never uses a count of nodes for anything completely isolating a node from the honest network can be helpful in the execution of other attacks.<br />
<br />
This state can be exploited in (at least) the following ways:<br />
<br />
* The attacker can refuse to relay blocks and transactions from everyone, disconnecting you from the network.<br />
* The attacker can relay only blocks that he creates, putting you on a separate network. You're then open to [[double-spending]] attacks.<br />
* If you rely on transactions with 0 confirmations, the attacker can just filter out certain transactions to execute a double-spending attack.<br />
* Low-latency encryption/anonymization of Bitcoin's transmissions (With Tor, JAP, etc.) can be defeated relatively easy with a timing attack if you're connected to several of the attacker's nodes and the attacker is watching your transmissions at your ISP.<br />
<br />
Bitcoin makes these attacks more difficult by only making an outbound connection to one IP address per /16 (x.y.0.0). Incoming connections are unlimited and unregulated, but this is generally only a problem in the anonymity case, where you're probably already unable to accept incoming connections.<br />
<br />
Looking for suspiciously low network hash-rates may help prevent the second one.<br />
<br />
=== Packet sniffing ===<br />
Someone who can see all of your Internet traffic can easily see when you send a transaction that you didn't receive (which suggests you originated it). Bitcoin-QT has good Tor integration which closes this attack vector if used.<br />
<br />
=== Denial of Service (DoS) attacks ===<br />
Sending lots of data to a node may make it so busy it cannot process normal Bitcoin transactions. Bitcoin has some denial-of-service prevention built-in, but is likely still vulnerable to more sophisticated denial-of-service attacks.<br />
<br />
These are the current Bitcoin Satoshi client protections to deter DoS attacks, as of version 0.7.0:<br />
<br />
# Does not forward orphan transactions/blocks<br />
# Does not forward double-spend transactions<br />
# Does not forward the same block, transaction or alert twice to the same peer.<br />
# Continuous rate-limit of free transactions to mitigate 'penny-flooding'<br />
# Keeps a DoS score of each connected peer and disconnects from a peer that send messages that fail to comply with the rules.<br />
# Bans IP addresses that misbehave for a time lapse (24 hours default)<br />
# Limits the number of stored orphan transactions (10000 by default)<br />
# Uses a signature cache to prevent attacks that try to continuously trigger the re-verification of stored orphan transactions (protects from https://bitcointalk.org/index.php?topic=136422.0 attack)<br />
# Limits the number of stored signatures in the signature cache (50000 signatures by default)<br />
# Tries to catch all possible errors in transactions before the signature verifications take place, to avoid DoS attacks on CPU usage.<br />
# Penalizes peers that send lots of duplicate/expired/invalid-signature/whatever alerts, so they eventually get banned.<br />
# In orphan/signature caches, when removing an item, evicts a random entry.<br />
# Data structures are specially chosen to avoid loops in which the number of iterations can be controlled by an attacker that result in exponential complexity.<br />
# Ignores big orphan transactions, to avoid a send-big-orphans memory exhaustion attack.<br />
# In RPC: Only sends a HTTP 403 response if it's not using SSL to prevent a DoS during the SSL handshake.<br />
# In RPC: Sleeps some time if authorization fails to deter brute-forcing short passwords.<br />
# In GUI: Limits URI length to prevent a DoS against the QR-Code dialog<br />
# Considers non-standard signature scripts with size greater than 500 bytes.<br />
# Considers non-standard signature scripts that contain operations that are not PUSHs.<br />
# Does not forward nor process non-standard transactions<br />
<br />
These are protocol rules built to prevent DoS:<br />
<br />
# Restricts the block size to 1 megabyte.<br />
# Restricts the maximum number of signature checks a transaction input may request<br />
# Limits the size of each script (up to 10000 bytes)<br />
# Limits the size of each value pushed while evaluating a a script (up to 520 bytes)<br />
# Limits the number of expensive operations in a script (up to 201 operations). All but pushs are considered expensive. Also each key argument of signature checking in multi-signature checking (OP_CHECKMULTISIG) is considered an additional operation.<br />
# Limits the number of key arguments OP_CHECKMULTISIG can use (up to 20 keys)<br />
# Limits the number of the stack elements that can be stored simultaneously (up to 1000 elements, in standard and alt stacks together)<br />
# Limits the number of signature checks a block may request (up to 20000 checks)<br />
<br />
These are the Satoshi client protections added in version 0.8.0: <br />
<br />
# Transactions greater than 100 Kbytes are considered non-standard (protects from variations of the https://bitcointalk.org/index.php?topic=140078.0 attack).<br />
# Only the UXTO (Unspent Transaction Output Set) is stored in memory, the remaining data is stored on disk.<br />
# When processing a transaction, before fetching transaction inputs from disk to memory, the client checks that all the inputs are unspent (protects from the Continuous Hard Disk Seek/Read Activity (https://bitcointalk.org/index.php?topic=144122.0) DoS attack)<br />
<br />
<br />
Satoshi client does not directly limit peer bandwidth nor CPU usage.<br />
<br />
=== Forcing clock drift against a target node ===<br />
<br />
See [http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html Timejacking] for a description of this attack. It can be fixed by changing how nodes calculate the current time.<br />
<br />
=== Illegal content in the block chain ===<br />
It is illegal in some countries to possess/distribute certain kinds of data. Since arbitrary data can be included in Bitcoin transactions, and full Bitcoin nodes must normally have a copy of all unspent transactions, this could cause legal problems. However, Local node policy generally doesn't permit arbitrary data (transactions attempting to embed data re non-standard), but steganographic embedding can still be used though this generally limits storage to small amounts. Various ideas have [http://sourceforge.net/mailarchive/message.php?msg_id=30705609 been proposed] to further limit datastorage in the UTXO set but are not currently being seriously considered for deployment.<br />
<br />
=== Security Vulnerabilities and bugs ===<br />
It's possible but unlikely that a newly discovered bug or security vulnerability in the standard client could lead to a block chain split, or the need for every node to upgrade in a short time period. For example, a single malformed message tailored to exploit a specific vulnerability, when spread from node to node, could cause the whole network to shutdown in a few hours. Bugs that break user anonymity, on the contrary, have been found, since the pseudo-anonymity property of Bitcoin has been analyzed less.<br />
Starting from version 0.7.0, Bitcoin client can be considered a mature project. The security critical sections of the source code are updated less and less frequently and those parts have been reviewed by many computer security experts. Also Bitcoin Satoshi client has passed the test of being on-line for more than 3 years, without a single vulnerability being exploited ''in the wild''. <br />
See [[Common Vulnerabilities and Exposures]] for a detailed list of vulnerabilities detected and fixed.<br />
<br />
=== Energy Consumption ===<br />
Energy consumption for mining has a high correlation with bitcoin value (exchange rate). Because variable costs of [[mining]] are dominated by electricity price, the economic equilibrium for the mining rate is reached when global electricity costs for mining approximate the value of [[mining]] reward plus [[transaction_fee | transaction fees]]. <br />
<br />
So the higher the value of one bitcoin, the higher the value of mining rewards and transaction fees, the higher the energy consumption of the bitcoin network in the long run.<br />
<br />
* more efficient mining gear does not reduce energy use of the bitcoin network. It will only raise the network [[difficulty]]<br />
* cheaper energy linearly increases mining energy use of the bitcoin network<br />
* the same conclusions apply to all [[proof of work]] based currencies.<br />
<br />
== Probably not a problem ==<br />
<br />
===Breaking the cryptography===<br />
SHA-256 and ECDSA are considered very strong currently, but they might be broken in the far future. If that happens, BitCoin can shift to a stronger algorithm. [https://bitcointalk.org/index.php?topic=191.msg1585#msg1585 More info].<br />
<br />
===Scalability===<br />
BitCoin can easily scale beyond the level of traffic VISA sees globally today. See the discussion on the [[scalability]] page for more information.<br />
<br />
===Segmentation===<br />
If there is even a "trickle" of a connection between two sides of a segmented network, things should still work perfectly. When block chains are combined, all of the non-generation transactions in the shorter chain are re-added to the transaction pool -- they'll start over at 0/unconfirmed, but they'll still be valid. No mature transactions will be lost unless the segmentation persists for longer than ~120 blocks. Then generations will start to mature, and any transactions based on those generations will become invalid when recombined with the longer chain. [https://bitcointalk.org/index.php?topic=241.msg2071#msg2071 More info].<br />
<br />
=== Attacking all users ===<br />
The IP addresses of most users are totally public. You can use Tor to hide this, but the network won't work if everyone does this. BitCoin requires that ''some'' country is still free.<br />
<br />
=== Dropping transactions ===<br />
Nodes that generate blocks can choose not to include a transaction in their blocks. When this happens, the transaction remains "active" and can be included in a later block. Two things discourage this:<br />
* Nodes only hash a fixed-size ''header'', so there is no speed advantage to dropping transactions.<br />
* [[Satoshi]] has [https://bitcointalk.org/index.php?topic=165.msg1595#msg1595 communicated] that he will write code to stop this kind of thing if it becomes a problem.<br />
<br />
=== Attacker has a lot of computing power ===<br />
An attacker that controls more than 50% of the network's computing power can, for the time that he is in control, exclude and modify the ordering of transactions. This allows him to:<br />
* Reverse transactions that he sends while he's in control. This has the potential to [[Double-spending#51.25_attack|double-spend transactions]] that previously had already been seen in the block chain.<br />
* Prevent some or all transactions from gaining any confirmations<br />
* Prevent some or all other miners from mining any valid blocks<br />
The attacker ''can't'':<br />
* Reverse other people's transactions<br />
* Prevent transactions from being sent at all (they'll show as 0/unconfirmed)<br />
* Change the number of coins generated per block<br />
* Create coins out of thin air<br />
* Send coins that never belonged to him<br />
<br />
With less than 50%, the same kind of attacks are possible, but with less than 100% rate of success.<br />
For example, someone with only 40% of the network computing power can overcome a 6-deep confirmed transaction with a 50% success rate.<br />
<br />
It's much more difficult to change historical blocks, and it becomes exponentially more difficult the further back you go. As above, changing historical blocks only allows you to exclude and change the ordering of transactions. It's impossible to change blocks created before the last checkpoint.<br />
<br />
Since this attack doesn't permit all that much power over the network, it is expected that no one will attempt it. A profit-seeking person will always gain more by just following the rules, and even someone trying to destroy the system will probably find other attacks more attractive. However, if this attack is successfully executed, it will be difficult or impossible to "untangle" the mess created -- any changes the attacker makes might become permanent.<br />
<br />
=== Spamming transactions ===<br />
<br />
It is easy to send transactions to yourself repeatedly. If these transactions fill blocks to the maximum size (1MB), other transactions would be delayed until the next block.<br />
<br />
This is made expensive by the [[transaction fee|fees]] that would be required after the 50KB of free transactions per block are exhausted. An attacker will eventually eliminate free transactions, but Bitcoin fees will always be low because raising fees above 0.01 BTC per KB would require spending transaction fees. An attacker will eventually run out of money. Even if an attacker wants to waste money, transactions are further prioritized by the time since the coins were last spent, so attacks spending the same coins repeatedly are less effective.<br />
<br />
=== The [[Double-spending#Finney_attack|Finney attack]] ===<br />
Named for Hal Finney, who first described this variation of a double-spend attack involving accepting [http://www.bitcointalk.org/index.php?topic=3441.msg48384#msg48384 0-confirmation transactions]. Accepting 0-confirmation large-value transactions is problematic; accepting them for low-value transactions (after waiting several seconds to detect an ordinary double-spend attempt) is probably safe.<br />
<br />
===Rival/malicious client code===<br />
Any rival client must follow Bitcoin's rules or else all current BitCoin clients will ignore it. You'd have to actually get people to ''use'' your client. A better client that pretends to follow the same rules, but with an exception known only to the author (possibly by making it closed source), might conceivably be able to gain widespread adoption. At that point, its author could use his exception and go largely unnoticed.<br />
<br />
== Definitely not a problem ==<br />
<br />
===Coin destruction===<br />
Bitcoin has 2.1 quadrillion raw units, making up 8 decimals of BTC precision, so the entire network could potentially operate on much less than the full quantity of Bitcoins. If deflation gets to the point where transactions of more than 10 BTC are unheard of, clients can just switch to another unit so that, for example, it shows 10 mBTC rather than 0.01 BTC.<br />
<br />
The maximum number of raw units might not be enough if the ''entire world'' starts using BTC, but it would not be too difficult to increase precision in that case. The transaction format and version number would be scheduled to change at some particular block number after a year or two, and everyone would have to update by then.<br />
<br />
===Generating tons of addresses===<br />
Generating an address doesn't touch the network at all. You'd only be wasting your CPU resources and disk space.<br />
<br />
Also, a collision is highly unlikely.<br />
<br />
Keys are 256 bit in length and are hashed in a 160 bit address.(2^160th power)<br />
Divide it by the world population and you have about 215,000,000,000,000,000,000,000,000,000,000,000,000 addresses per capita.(2.15 x 10^38)[http://www.wolframalpha.com/input/?i=2^160+%2F+world+population]<br />
<br />
===Everyone calculates at the same rate===<br />
If everyone began with identical blocks and started their nonce at 1 and incremented, the fastest machine would always win. However, each block contains a new, random public key known only to you in the list of transactions. The 256-bit "Merkle tree" hash of this is part of the block header.<br />
<br />
So everyone begins with slightly different blocks and everyone truly has a random chance of winning (modified by CPU power).<br />
<br />
===Generate "valid" blocks with a lower difficulty than normal===<br />
Using unmodified Bitcoin code, an attacker could segment himself from the main network and generate a long block chain with a lower difficulty than the real network. These blocks would be totally valid for his network. However, it would be impossible to combine the two networks (and the "false" chain would be destroyed in the process).<br />
<br />
"Block chain length" is calculated from the combined difficulty of all the blocks, not just the number of blocks in the chain. The one that represents the most computation will win.<br />
<br />
==See Also==<br />
<br />
* [[Anonymity & Security]]<br />
* [[Double-spending]]<br />
* [http://bitcoin.stackexchange.com/questions/10025/where-can-i-find-well-written-criticism-about-bitcoin Stack Exchange]<br />
<br />
[[Category:Technical]]</div>Superbhttps://tests.bitcoin.it/w/index.php?title=Myths&diff=49271Myths2014-08-01T13:19:38Z<p>Superb: </p>
<hr />
<div>Let's clear up some common Bitcoin misconceptions.<br />
<br />
== Bitcoin is just like all other digital currencies; nothing new ==<br />
<br />
Nearly all other digital currencies are centrally controlled. This means that:<br />
* They can be printed at the subjective whims of the controllers<br />
* They can be destroyed by attacking the central point of control<br />
* Arbitrary rules can be imposed upon their users by the controllers<br />
<br />
Being decentralized, Bitcoin solves all of these problems.<br />
<br />
== Bitcoins don't solve any problems that fiat currency and/or gold doesn't solve ==<br />
<br />
Unlike gold, bitcoins are:<br />
* Easy to transfer<br />
* Easy to secure<br />
* Easy to verify<br />
* Easy to granulate<br />
<br />
Unlike fiat currencies, bitcoins are:<br />
* Predictable and limited in [[Controlled_Currency_Supply|supply]]<br />
* Not controlled by a central authority (such as [http://en.wikipedia.org/wiki/Federal_Reserve The United States Federal Reserve])<br />
* Not debt-based<br />
<br />
Unlike electronic fiat currency systems, bitcoins are:<br />
* Potentially [[Anonymity & Security|anonymous]]<br />
* Freeze-proof<br />
* Faster to transfer<br />
* Cheaper to transfer<br />
<br />
== Bitcoin is backed by processing power ==<br />
<br />
It is not correct to say that Bitcoin is "backed by" processing power. A currency being "backed" means that it is pegged to something else via a central party at a certain exchange rate yet you cannot exchange bitcoins for the computing power that was used to create them. Bitcoin is in this sense not backed by anything. It is a currency in its own right. Just as gold is not backed by anything, the same applies to Bitcoin. <br />
<br />
The Bitcoin currency is ''created'' via processing power, and the integrity of the block chain is ''protected'' by the existence of a network of powerful computing nodes from certain [[Weaknesses#Attacker_has_a_lot_of_computing_power|attacks]].<br />
<br />
== Bitcoins are worthless because they aren't backed by anything ==<br />
<br />
One could argue that gold isn't backed by anything either. Bitcoins have properties resulting from the system's design that allows them to be subjectively valued by individuals. This valuation is demonstrated when individuals freely exchange for or with bitcoins. Please refer to the [http://en.wikipedia.org/wiki/Subjective_theory_of_value Subjective Theory of Value].<br />
<br />
See also: the "[[#Bitcoin_is_backed_by_processing_power|Bitcoin is backed by processing power]]" myth.<br />
<br />
== The value of bitcoins are based on how much electricity and computing power it takes to mine them ==<br />
<br />
This statement is an attempt to apply to Bitcoin the [http://en.wikipedia.org/wiki/Labor_theory_of_value labor theory of value], which is generally accepted as false. Just because something takes X resources to create does not mean that the resulting product will be worth X. It can be worth more, or less, depending on the utility thereof to its users.<br />
<br />
In fact the causality is the reverse of that (this applies to the labor theory of value in general). The cost to mine bitcoins is based on how much they are worth. If bitcoins go up in value, more people will mine (because [[Mining|mining]] is profitable), thus [[difficulty]] will go up, thus the cost of mining will go up. The inverse happens if bitcoins go down in value. These effects balance out to cause mining to always cost an amount proportional to the value of bitcoins it produces.<br />
<br />
== Bitcoins have no intrinsic value (unlike some other things) ==<br />
<br />
This is simply not true. Each bitcoin gives the holder the ability to embed a large number of short in-transaction messages in a globally distributed and timestamped permanent data store, namely the bitcoin blockchain. There is no other similar datastore which is so widely distributed. There is a tradeoff between the exact number of messages and how quickly they can be embedded. But as of December 2013, it's fair to say that one bitcoin allows around 1000 such messages to be embedded, each within about 10 minutes of being sent, since a fee of 0.001 BTC is enough to get transactions confirmed quickly. This message embedding certainly has intrinsic value since it can be used to prove ownership of a document at a certain time, by including a one-way hash of that document in a transaction. Considering that electronic notarization services charge something like $10/document, this would give an intrinsic value of around $10,000 per bitcoin.<br />
<br />
While some other tangible commodities do have intrinsic value, that value is generally much less than its trading price. Consider for example that gold, if it were not used as an inflation-proof store of value, but rather only for its industrial uses, would certainly not be worth what it is today, since the industrial requirements for gold are far smaller than the available supply thereof.<br />
<br />
In any event, while historically intrinsic value, as well as other attributes like divisibility, fungibility, scarcity, durability, helped establish certain commodities as mediums of exchange, it is certainly not a prerequisite. While bitcoins are accused of lacking 'intrinsic value' in this sense, they make up for it in spades by possessing the other qualities necessary to make it a good medium of exchange, equal to or better than [http://en.wikipedia.org/wiki/Commodity_money commodity money].<br />
<br />
Another way to think about this is to consider the value of bitcoin the global network, rather than each bitcoin in isolation. The value of an individual telephone is derived from the network it is connected to. If there was no phone network, a telephone would be useless. Similarly the value of an individual bitcoin derives from the global network of bitcoin-enabled merchants, exchanges, wallets, etc... Just like a phone is necessary to transmit vocal information through the network, a bitcoin is necessary to transmit economic information through the network.<br />
<br />
Value is ultimately determined by what people are willing to trade for - by supply and demand.<br />
<br />
== Bitcoins are illegal because they're not legal tender ==<br />
In March 2013, the U.S. [http://en.wikipedia.org/wiki/Financial_Crimes_Enforcement_Network Financial Crimes Enforcement Network] issues a new set of guidelines on "de-centralized virtual currency", clearly targeting Bitcoin. Under the new guidelines, "a user of virtual currency is not a Money Services Businesses (MSB) under FinCEN's regulations and therefore is not subject to MSB registration, reporting, and record keeping regulations." <ref>[http://arstechnica.com/tech-policy/2013/03/us-regulator-bitcoin-exchanges-must-comply-with-money-laundering-laws/ US regulator: Bitcoin exchanges must comply with money-laundering laws | Ars Technica]</ref> [[Mining|Miners]], when mining bitcoins for their own personal use, aren't required to register as a MSB or Money Transmitter. <ref>[http://fincen.gov/news_room/rp/rulings/html/FIN-2014-R001.html Application of FinCEN’s Regulations to Virtual Currency Mining Operations | Fincen]</ref><br />
<br />
In general, there are a [http://en.wikipedia.org/wiki/Local_currency number of currencies] in existence that are not official government-backed currencies. A currency is, after all, nothing more than a convenient unit of account. While national laws may vary from country to country, and you should certainly check the laws of your jurisdiction, in general trading in any commodity, including digital currency like Bitcoin, [http://en.wikipedia.org/wiki/BerkShares BerkShares], game currencies like WoW gold, or Linden dollars, is not illegal.<br />
<br />
== Bitcoin is a form of domestic terrorism because it only harms the economic stability of the USA and its currency ==<br />
<br />
According to [http://en.wikipedia.org/wiki/Definitions_of_terrorism#United_States the definition of terrorism in the United States], you need to do violent activities to be considered a terrorist for legal purposes. Recent off-the-cuff remarks by politicians have no basis in law or fact.<br />
<br />
Also, Bitcoin isn't domestic to the US or any other country. It's a worldwide community, as can be seen in this [https://bitcointalk.org/?topic=2346.0 map of Bitcoin nodes].<br />
<br />
== Bitcoin will only enable tax evaders which will lead to the eventual downfall of civilization ==<br />
<br />
Cash transactions hold the same level of anonymity but are still taxed successfully. It is up to you to follow the applicable state laws in your home country, or face the consequences.<br />
<br />
While it may be easy to transfer bitcoins anonymously, ''spending'' them anonymously on tangibles is just as hard as spending any other kind of money anonymously. Tax evaders are often caught because their lifestyle and assets are inconsistent with their reported income, and not necessarily because government is able to follow their money.<br />
<br />
== Bitcoins can be printed/minted by anyone and are therefore worthless ==<br />
<br />
Bitcoins are not printed/minted. Instead, [[Blocks]] are computed by miners and for their efforts they are awarded a specific amount of bitcoins and transaction fees paid by others. See [[Mining]] for more information on how this process works.<br />
<br />
== Bitcoins are worthless because they're based on unproven cryptography ==<br />
<br />
SHA256 and ECDSA which are used in Bitcoin are well-known industry standard algorithms. SHA256 is endorsed and used by the US Government and is standardized (FIPS180-3 Secure Hash Standard). If you believe that these algorithms are untrustworthy then you should not trust Bitcoin, credit card transactions or any type of electronic bank transfer. Bitcoin has a sound basis in well understood cryptography.<br />
<br />
== Early adopters are unfairly rewarded ==<br />
<br />
Early adopters are rewarded for taking the higher risk with their time and money. The capital invested in bitcoin at each stage of its life invigorated the community and helped the currency to reach subsequent milestones. Arguing that early adopters do not deserve to profit from this is akin to saying that early investors in a company, or people who buy stock at a company IPO (Initial Public Offering), are unfairly rewarded.<br />
<br />
This argument also depends on bitcoin early adopters using bitcoins to store rather than transfer value. The daily trade on the exchanges (as of Jan 2012) indicates that smaller transactions are becoming the norm, indicating trade rather than investment. In more pragmatic terms, "fairness" is an arbitrary concept that is improbable to be agreed upon by a large population. Establishing "fairness" is no goal of Bitcoin, as this would be impossible.<br />
<br />
Looking forwards, considering the amount of publicity bitcoin received as of April 2013, there can be no reasonable grounds for complaint for people who did not invest at that time, and then see the value (possibly) rising drastically higher.<br />
<br />
By starting to mine or acquire bitcoins today, you too can become an early adopter.<br />
<br />
== 21 million coins isn't enough; doesn't scale ==<br />
<br />
One Bitcoin is divisible down to eight decimal places. There are really 2,099,999,997,690,000 (just over 2 quadrillion) maximum possible atomic units in the bitcoin system.<br />
<br />
The value of "1 BTC" represents 100,000,000 of these. In other words, each is divisible by up to 10^8. <br />
<br />
As the value of the unit of 1 BTC grows too large to be useful for day to day transactions, people can start dealing in smaller [[Units|units]], such as milli-bitcoins (mBTC) or micro-bitcoins (μBTC).<br />
<br />
== Bitcoins are stored in wallet files, just copy the wallet file to get more coins! ==<br />
<br />
No, your wallet contains your secret keys, giving you the rights to spend your bitcoins. Think of it like having bank details stored in a file. If you give your bank details (or bitcoin wallet) to someone else, that doesn't double the amount of money in your account. You can spend your money or they can spend your money, but not both.<br />
<br />
== Lost coins can't be replaced and this is bad ==<br />
<br />
Bitcoins are divisible to 0.00000001, so there being fewer bitcoins remaining is not a problem for the currency itself. If you lose your coins, all other coins will go up in value a little. Consider it a donation to all other bitcoin users.<br />
<br />
A related question is: Why don't we have a mechanism to replace lost coins? The answer is that it is impossible to distinguish between a 'lost' coin and one that is simply sitting unused in someone's wallet.<br />
<br />
== It's a giant ponzi scheme ==<br />
In a Ponzi Scheme, the founders persuade investors that they’ll profit. Bitcoin does not make such a guarantee. There is no central entity, just individuals building an economy.<br />
<br />
A ponzi scheme is a zero sum game. In a ponzi scheme, early adopters can only profit at the expense of late adopters, and the late adopters always lose. Bitcoin has an expected win-win outcome. Early and present adopters profit from the rise in value as Bitcoins become better understood and in turn demanded by the public at large. All adopters benefit from the usefulness of a reliable and widely-accepted decentralized peer-to-peer currency.<br />
<br />
== Finite coins plus lost coins means deflationary spiral ==<br />
As deflationary forces may apply, economic factors such as hoarding are offset by human factors that may lessen the chances that a [[Deflationary spiral]] will occur.<br />
<br />
== Bitcoin can't work because there is no way to control inflation ==<br />
<br />
Inflation is simply a rise of prices over time, which is generally the result of the devaluing of a currency. This is a function of supply and demand. Given the fact that the supply of bitcoins is fixed at a certain amount, unlike fiat money, the only way for inflation to get out of control is for demand to disappear. Temporary inflation is possible with a rapid adoption of Fractional Reserve Banking but will stabilize once a substantial number of the 21 million "hard" bitcoins are stored as reserves by banks.<br />
<br />
Given the fact that Bitcoin is a distributed system of currency, if demand were to decrease to almost nothing, the currency would be doomed anyway.<br />
<br />
The key point here is that Bitcoin as a currency can't be inflated by any single person or entity, like a government, as there's no way to increase supply past a certain amount.<br />
<br />
Indeed, the most likely scenario, as Bitcoin becomes more popular and demand increases, is for the currency to increase in value, or deflate, until demand stabilizes.<br />
<br />
== The Bitcoin community consists of anarchist/conspiracy theorist/gold standard 'weenies' ==<br />
<br />
The members of the community vary in their ideological stances. While it may have been started by ideological enthusiasts, Bitcoin now speaks to a large number of regular pragmatic folk, who simply see its potential for reducing the costs and friction of global e-commerce.<br />
<br />
== Anyone with enough computing power can take over the network ==<br />
<br />
CONFIRMED, see [[Weaknesses]].<br />
<br />
That said, as the network grows, it becomes harder and harder for a single entity to do so. Already the Bitcoin network's computing power is quite ahead of the world's fastest supercomputers, together.<br />
<br />
What an attacker can do once the network is taken over is quite limited. Under no circumstances could an attacker create counterfeit coins, fake transactions, or take anybody else's money. An attacker's capabilities are limited to taking back their own money that they very recently spent, and preventing other people's transactions from receiving confirmations. Such an attack would be very costly in resources, and for such meager benefits there is little rational economic incentive to do such a thing.<br />
<br />
Furthermore, this attack scenario would only be feasible for as long as it was actively underway. As soon as the attack stopped, the network would resume normal operation.<br />
<br />
== Bitcoin violates governmental regulations ==<br />
<br />
There is no known governmental regulation which disallows the use of Bitcoin.<br />
<br />
See also: the "[[#Bitcoins_are_illegal_because_they.27re_not_legal_tender|Bitcoins are illegal because they're not legal tender]]" myth.<br />
<br />
== Fractional reserve banking is not possible ==<br />
<br />
It is possible. See the main article, [[Fractional Reserve Banking and Bitcoin]]<br />
<br />
== After 21 million coins are mined, no one will generate new blocks ==<br />
<br />
When operating costs can't be covered by the block creation bounty, which will happen some time before the total amount of BTC is reached, miners will earn some profit from [[transaction fees]]. However unlike the block reward, there is [http://bitcoin.stackexchange.com/questions/876/how-much-will-transaction-fees-eventually-be/895#895 no coupling between transaction fees and the need for security], so there is less of a guarantee that the amount of [[Mining|mining]] being performed will be sufficient to maintain the network's security.<br />
<br />
== Bitcoin has no built-in chargeback mechanism, and this isn't good ==<br />
<br />
'''Why some people think this is bad''': Chargebacks are useful for limiting fraud. The person handling your money has a responsibility to prevent fraud. If you buy something on eBay and the seller never ships it, PayPal takes funds from the seller's account and gives you back the money. This strengthens the eBay economy, because people recognize that their risk is limited and are more willing to purchase items from risky sellers.<br />
<br />
'''Why it's actually a good thing''': Bitcoin is designed such that your money is yours and yours alone. Allowing chargebacks implies that it is possible for another entity to take your money from you. You can have either total ownership rights of your money, or fraud protection, but not both. That said, nothing inherent in the dollar or euro or any other currency is necessary for chargebacks to be possible, and likewise, nothing prevents the creation of PayPal-like services denominated in Bitcoin that provide chargebacks or fraud protection.<br />
<br />
The statement "The person handling your money has a responsibility to prevent fraud" is still true; the power has been shifted into your own hands. Fraud will always exist. It's up to you to only send bitcoins to trusted entities. It is possible to trust an online identity without ever knowing their physical identity; see the [http://wiki.bitcoin-otc.com/wiki/OTC_Rating_System OTC Web of Trust].<br />
<br />
== Quantum computers would break Bitcoin's security ==<br />
<br />
While ECDSA is indeed not secure under quantum computing, quantum computers don't yet exist and probably won't for a while.<br />
The DWAVE system often written about in the press is, even if all their claims are true, not a quantum computer of a kind that could be used for cryptography.<br />
Bitcoin's security, when used properly with a new address on each transaction, depends on more than just ECDSA: Cryptographic hashes are much stronger than ECDSA under QC.<br />
Bitcoin's security was designed to be upgraded in a forward compatible way and could be [http://en.wikipedia.org/wiki/Post-quantum_cryptography upgraded] if this were considered an imminent threat.<br />
<br />
See the implications of quantum computers on public key cryptography here http://en.wikipedia.org/wiki/Quantum_computer#Potential<br />
<br />
The ''risk'' of quantum computers is also there for financial institutions, like banks, because they heavily rely on cryptography when doing transactions.<br />
<br />
== Bitcoin makes self-sufficient artificial intelligence possible, which will in turn become self-aware and decide to exterminate humanity ==<br />
An artificial intelligence powerful enough to be threatening to mankind wouldn't depend on mankind to make Bitcoin, it would just invent something like Bitcoin itself and design it to be so attractive to us that we couldn't resist using it.<br />
<br />
== [[Mining|Bitcoin mining]] is a waste of energy and harmful for ecology ==<br />
No more so than the wastefulness of mining gold out of the ground, melting it down and shaping it into bars, and then putting it back underground again. Not to mention the building of big fancy buildings, the waste of energy printing and minting all the various fiat currencies, the transportation thereof in armored cars by no less than two security guards for each who could probably be doing something more productive, etc. <br />
<br />
As far as mediums of exchange go, Bitcoin is actually quite economical of resources, compared to others.<br />
<br />
'''Economic Argument 1'''<br />
<br />
[[Mining|Bitcoin mining]] is a highly competitive, dynamic, almost [http://en.wikipedia.org/wiki/Perfect_market perfect], market. Mining rigs can be set up and dismantled almost anywhere in the world with relative ease. Thus, market forces are constantly pushing mining activity to ''places'' and ''times'' where the marginal price of electricity is low or zero. These electricity products are cheap for a reason. Often it’s because the electricity is difficult (and wasteful) to transport, difficult to store, or because there is low demand and high supply. Using electricity in this way is a lot less wasteful than simply plugging a mining rig into the mains indiscriminately. <br />
<br />
For example, Iceland produces an excess of cheap electricity from renewable sources, but it has no way of exporting electricity because of its remote location. It is conceivable that at some point in future Bitcoin mining will only be profitable in places like Iceland, and unprofitable in places like central Europe, where electricity comes mostly from nuclear and fossil sources. <br />
<br />
Market forces could even push mining into innovative solutions that have an effective electricity consumption of ''zero''. Mining always produces heat equivalent to the energy consumed - for example, 1000 watts of mining equipment produces the same amount of heat as a 1000 watt heating element used in an electric space heater, hot tub, water heater, or similar appliance. Someone already in a willing position to incur the cost of electricity for its heat value alone could run mining equipment specially designed to mine bitcoins while capturing and utilizing the heat produced, without incurring any energy costs beyond what they already intended to spend on heating.<br />
<br />
(Note that this is just an example; mining will not always produce heat equivalent to the energy consumed because some energy is inevitably released as electromagnetic radiation, among others.)<br />
<br />
'''Economic Argument 2'''<br />
<br />
When the environmental costs of mining are considered, they need to be weighed up against the benefits. If you question Bitcoin on the grounds that it consumes electricity, then you should also ask questions like this: Will Bitcoin promote economic growth by freeing up trade? Will this speed up the rate of technological innovation? Will this lead to faster development of green technologies? Will Bitcoin enable new, border crossing [http://en.wikipedia.org/wiki/Smart_grid smart grid] technologies? …<br />
<br />
Dismissal of Bitcoin because of its costs, while ignoring its benefits, is a dishonest argument. In fact, any environmental argument of this type is dishonest, not just pertaining to Bitcoin. Along similar lines, it could be argued that wind turbines are bad for the environment because making the steel structure consumes energy.<br />
<br />
'''Ratio of Capital Costs versus Electrical Costs'''<br />
<br />
The BFL Jalapeno hashes at 5.5 Gh/s using 30W. That device consumes about $40 per year in electricity (using U.S. residential average of about $0.15 per kWh.) But the device costs over $300 including shipping. Thus just about a quarter of all costs over a two-year useful life goes to electricity. This compares to GPUs where more than 90% of costs over a two-year life went to electricity. Even more efficient designs can be expected in the future.<br />
<br />
== Shopkeepers can't seriously set prices in bitcoins because of the volatile exchange rate ==<br />
<br />
The assumption is that bitcoins must be sold immediately to cover operating expenses. If the shopkeeper's back-end expenses were transacted in bitcoins as well, then the exchange rate would be irrelevant. Larger adoption of Bitcoin would make prices [http://en.wikipedia.org/wiki/Sticky_%28economics%29 sticky]. Future volatility is expected to decrease, as the size and depth of the market grows. <br />
<br />
In the meantime, many merchants simply regularly pull the latest market rates from the exchanges and automatically update the prices on their websites. Also you might be able to buy a put option in order to sell at a fixed rate for a given amount of time. This would protect you from drops in price and simplify your operations for that time period.<br />
<br />
== Like Flooz and e-gold, bitcoins serve as opportunities for criminals and will be shut down ==<br />
<br />
* Visa, MasterCard, PayPal, and cash all serve as opportunities for criminals as well, but society keeps them around due to their recognized net benefit.<br />
* Hopefully Bitcoin will grow to the point where no single organization can disrupt the network, or would be better served by helping it.<br />
* Terrorists fly aircraft into buildings, but the governments have not yet abolished consumer air travel. Obviously the public good outweighs the possible bad in their opinion.<br />
* Criminal law differs between jurisdictions.<br />
<br />
== Bitcoins will be shut down by the government just like Liberty Dollars were ==<br />
<br />
Liberty Dollars started as a commercial venture to establish an alternative US currency, including physical banknotes and coins, backed by precious metals. This, in and of itself, is not illegal. They were prosecuted under counterfeiting laws because the silver coins allegedly resembled US currency.<br />
<br />
Bitcoins do not resemble the currency of the US or of any other nation in any way, shape, or form. The word "dollar" is not attached to them in any way. The "$" symbol is not used in any way.<br />
<br />
Bitcoins have no representational similarity whatsoever to US dollars. <br />
<br />
Of course, actually 'shutting down' Liberty Dollars was as easy as arresting the head of the company and seizing the offices and the precious metals used as backing. The decentralized Bitcoin, with no leader, no servers, no office, and no tangible asset backing, does not have the same vulnerability.<br />
<br />
== Bitcoin is not decentralized because the developers can dictate the software's behavior ==<br />
<br />
The Bitcoin protocol was originally defined by Bitcoin's inventor, [[Satoshi Nakamoto]], and this protocol has now been widely accepted as the standard by the community of miners and users. <br />
<br />
Though the developers of the original Bitcoin client still exert influence over the Bitcoin community, their power to arbitrarily modify the protocol is very limited. Since the release of Bitcoin v0.3, changes to the protocol have been minor and always in agreement with community consensus.<br />
<br />
Protocol modifications, such as increasing the block award from 25 to 50 BTC, are not compatible with clients already running in the network. If the developers were to release a new client that the majority of miners perceives as corrupt, or in violation of the project’s aims, that client would simply not catch on, and the few users who do try to use it would find that their transactions get rejected by the network.<br />
<br />
There are also other [[:Category:Clients|Bitcoin clients made by other developers]] that adhere to the Bitcoin protocol. As more developers create alternative clients, less power will lie with the developers of the original Bitcoin client. <br />
<br />
== Bitcoin is a pyramid scheme ==<br />
<br />
Bitcoin is nearly opposite of a pyramid scheme in a mathematical sense. Because Bitcoins are algorithmically made scarce, no exponential benefit is derived from introducing new users to use of it. There is a quantitative benefit in having additional interest or demand, but this is in no way exponential.<br />
<br />
== Bitcoin was hacked ==<br />
<br />
In the history of Bitcoin, there has never been an attack on the [[block chain]] that resulted in stolen money from a confirmed output. Neither has there ever been a reported theft resulting directly from a vulnerability in the [[Original Bitcoin client|original Bitcoin client]], or a vulnerability in the protocol. Bitcoin is secured by standard cryptographic functions. These functions have been peer reviewed by cryptography experts and are considered unlikely to be breakable in the foreseeable future.<br />
<br />
It is safe to say that the currency itself has never been 'hacked'. However, several major ''websites'' using the currency have been hacked, often resulting in high profile Bitcoin heists. These heists are misreported in some media as hacks on Bitcoin itself. An analogy: Just because someone stole US dollars from a supermarket till, doesn’t mean that the US dollar as a currency has been 'hacked'.<br />
<br />
Most bitcoin thefts are the result of inadequate [[Securing your wallet|wallet security]]. In response to the wave of thefts in 2011 and 2012, the community has developed risk-mitigating measures such as [[Wallet_encryption|wallet encryption]], support for [[BIP_0011|multiple signatures]], [[How_to_set_up_a_secure_offline_savings_wallet|offline wallets]], [[Paper_wallet|paper wallets]], and [[Hardware_wallet|hardware wallets]]. As these measures gain adoption by merchants and users, it is expected that the number of thefts will drop.<br />
<br />
==References==<br />
<references/><br />
<br />
[[de:Mythen]]<br />
[[ru:Мифы о биткоине]]</div>Superbhttps://tests.bitcoin.it/w/index.php?title=Using_Bitcoin&diff=49270Using Bitcoin2014-08-01T13:19:03Z<p>Superb: </p>
<hr />
<div><div style="background:#dddddd;border:solid gray 1px;width:70%;margin:auto;"><br />
Current releases of the bitcoin client have a different user interface than the versions used in this article.<br />
<br />
This article could use an update. See the discussion for this article for more.<br />
</div><br />
<br />
This page is a detailed tutorial to help new users understand and using bitcoin. After you read this page, you'll know the basics of what bitcoin is and how it is structured, how to get and install the bitcoin client, where to get coins, and how to use the client to send and receive transactions.<br />
<br />
If you want to ignore all the details of how the system works, and just want to start using it, see the [[Getting started]] page instead.<br />
<br />
=What is Bitcoin=<br />
<br />
Bitcoin is a distributed [[digital currency]] based on strong cryptographic principles. Each coin is assigned to the owner's public key, and is transferrable via cryptographically signed messages.<br />
<br />
=Getting started=<br />
<br />
In this section, you'll learn where to get the client, how to install it on different operating systems, and download the [[block chain]]. <br />
<br />
==Download and install the client==<br />
<br />
First, download the bitcoin client from http://bitcoin.org/. Choose the appropriate link depending on your operating system, and install in the usual manner. For Windows, easiest is probably the executable installer. For Linux, note that the tar.gz contains the binary build, in addition to the source, so if you run a recent distribution, you should be able to just run the binary without compiling yourself.<br />
<br />
===Issues with Linux package repositories===<br />
Be warned that the version of Bitcoin Core in some package repositories are severely out of date and may be harmful to use. For Debian, users should use [https://packages.debian.org/source/unstable/bitcoin the package from the 'unstable' repository]. For Ubuntu and derivatives, please use the PPA link [https://bitcoin.org/en/download on bitcoin.org]. Please see [https://launchpad.net/+help-soyuz/ppa-sources-list.html this guide] for details on how to use the PPA. You can also choose to use the static binary or to compile from source (both are in the 'tgz' file on the bitcoin.org download page), although updates will not be automated. Please refer to [https://bitcoin.org/en/download this page] for the latest version number.<br />
<br />
==Starting the client and connecting to the network==<br />
<br />
[[File:First time run fin.png|400px|thumb|right|Bitcoin is initializing by establishing a connection to other clients and downloading the blocks.]]<br />
Bitcoin comes with a GUI client called "bitcoin", and a CLI (text-mode) client called "bitcoind". It is probably more user-friendly to start with the GUI, so launch the bitcoin client. <br />
<br />
When you start for the first time, your bitcoin wallet will be created automatically, and the client will attempt to establish connections to other nodes on the network and start downloading the bitcoin [[block chain]]. You must get all of the blocks in the chain before sending/receiving transactions. [http://blockexplorer.com/q/getblockcount Click here] to see the current number of blocks in the chain. This download may take as long as several hours.<br />
<br />
==Client features==<br />
<br />
Your starting bitcoin address (you can have as many as you want - we'll talk about [[#Bitcoin addresses|addresses]] later) shows in a text box at the top. Right below it is your total bitcoin balance, which, of course, to start with will be zero. There is a list box below it showing all your transactions, which can be variously filtered with tabs, which again will be empty to start with.<br />
<br />
The status bar at the bottom will display some important information. If you have [[#Generating bitcoins|bitcoin generation (block hashing)]] turned on, on the left the client will display your hash rate. To the right of that, you will see the number of bitcoin nodes your client is connected to, then, the number of blocks your client has in its chain, and finally, the number of transactions you have in your wallet.<br />
<br />
=Using bitcoin=<br />
<br />
In this section you will learn about bitcoin addresses, sending and receiving transactions, the block chain and transaction confirmations, where to get your first bitcoins (faucet), generation. Tips on keeping wallet safe.<br />
<br />
==Getting your first bitcoins==<br />
<br />
There are few things more exciting than getting your first bitcoins! So once you have all the blocks downloaded, head on over to the [https://freebitcoins.appspot.com/ bitcoin faucet], fill out the form and put in your bitcoin address, and receive some free bitcoin! (You can do this before finishing the block chain download, but you won't see the coins in your wallet until you finish downloading the blocks... which would put a damper on the whole excitement bit.) <br />
<br />
See [http://en.bitcoin.it/wiki/Trade#Samples_and_Marketing_Offers Samples and Marketing Offers] for other free bitcoins and marketing offers.<br />
<br />
Once you submit the form successfully, you should see a new transaction in your client within seconds. But it will be grayed out, and have 0/unconfirmed status:<br />
[[File:First btc recv.png|frame|none]]<br />
<br />
Once your transaction makes it into the block chain, the confirmation count will grow in step with the number of blocks in the chain. By default, the client stops showing "unconfirmed" after the transaction is 6 blocks deep in the chain:<br />
[[File:Six confirms bitcoin client.png|frame|none]]<br />
<br />
==Bitcoin addresses==<br />
<br />
You can create as many new addresses as you like. Using a different address each time helps to preserve your [[Anonymity & Security|anonymity]].<br />
<br />
You cannot send BTC to an invalid address. Client will refuse to send payment to a misspecified address. (Though with care you can craft a valid but nonexistent address.)<br />
<br />
<!-- talk more about addresses here --><br />
<!-- No, link to the addresses page... --><br />
<br />
==Generating bitcoins==<br />
<br />
In order to generate bitcoins, you will need to perform bitcoin [[mining]]. As of 2013, the competition for bitcoin mining has become intense, so you are unlikely to achieve much without specialized hardware.<br />
<br />
=See also=<br />
<br />
* [[Anonymity & Security]]<br />
* [[Getting started]] A brief tutorial for the impatient<br />
* [http://bitcoinX.io BitcoinX.io] View where to buy and store your bitcoins on the only Bitcoin peer-to-peer review site, BitcoinX<br />
<br />
[[Category:Introduction]]</div>Superbhttps://tests.bitcoin.it/w/index.php?title=Technical_background_of_version_1_Bitcoin_addresses&diff=49269Technical background of version 1 Bitcoin addresses2014-08-01T13:18:36Z<p>Superb: </p>
<hr />
<div>[[File:PubKeyToAddr.png|thumb|right|Conversion from ECDSA public key to Bitcoin Address]]<br />
This article may be too technical for some users. The more basic article on [[Address|Bitcoin Addresses]] may be more appropriate.<br />
<br />
A [[Bitcoin address]] is a 160-bit hash of the public portion of a public/private [[Wikipedia:Elliptic_Curve_DSA|ECDSA]] keypair. Using [[Wikipedia:Public-key_cryptography|public-key cryptography]], you can "sign" data with your [[private key]] and anyone who knows your public key can verify that the signature is valid.<br />
<br />
A new keypair is generated for each receiving address. Bitcoin addresses (the public keys) and their associated private keys are stored in the [[wallet]] data file. This is the only file you need to [[backup|back up]]. A "send" transaction to a specific Bitcoin address requires that the corresponding private key exist in the recipient's wallet. This has the implication that if you create a receiving address and receive coins to that address, then restore the wallet from an earlier backup, before the address was generated, then the coins associated with that address are lost. Addresses are added to an address [[key pool]] prior to being used for receiving coins. If you lose your wallet entirely, all of your coins are lost and can never be recovered.<br />
<br />
Bitcoin allows you to create as many addresses as you want, and each one is completely separate. There is no "master address": the "Your Bitcoin address" area in the Bitcoin UI has no special importance. It's only there for your convenience, and it will change automatically from time to time to enhance your [[Anonymity & Security|anonymity]]. All of your other addresses will continue to work forever. They're listed in the "your receiving addresses" section. Each address takes up only about 500 bytes, so having a large number of addresses in your wallet is generally not a problem.<br />
<br />
Bitcoin addresses contain a built-in check code, so it's generally not possible to send Bitcoins to a mistyped address. However, if the address is well-formed but no one owns it (or the owner lost their wallet.dat), any coins sent to that address will be lost forever.<br />
<br />
Hash values and the checksum data are converted to an alpha-numeric representation using a custom scheme: the [[Base58Check encoding]] scheme. Under Base58Check, addresses can contain all alphanumeric characters except 0, O, I, and l. Normal addresses currently always start with 1 (addresses from script hashes use 3), though this might change in a future version. Testnet addresses usually start with ''m'' or ''n''. Mainline addresses can be 25-34 characters in length, and testnet addresses can be 26-34 characters in length. Most addresses are 33 or 34 characters long.<br />
<br />
It is also possible to send Bitcoins directly to an [[IP address]] but this method is never recommended as a man-in-the-middle attacks makes redirecting coins trivial.<br />
<br />
Since Bitcoin addresses are basically random numbers, it is possible, although extremely unlikely, for two people to independently generate the same address. This is called a [[Wikipedia:Collision_(computer_science)|collision]]. If this happens, then both the original owner of the address and the colliding owner could spend money sent to that address. It would not be possible for the colliding person to spend the original owner's entire wallet (or vice versa). If you were to intentionally try to make a collision, it would currently take 2^107 times longer to generate a colliding Bitcoin address than to generate a block. As long as the signing and hashing algorithms remain cryptographically strong, it will likely always be more profitable to collect generations and [[transaction fee|transaction fees]] than to try to create collisions.<br />
<br />
==How to create Bitcoin Address==<br />
0 - Having a private [[ECDSA]] key<br />
18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725<br />
1 - Take the corresponding public key generated with it (65 bytes, 1 byte 0x04, 32 bytes corresponding to X coordinate, 32 bytes corresponding to Y coordinate)<br />
0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6<br />
2 - Perform SHA-256 hashing on the public key<br />
600FFE422B4E00731A59557A5CCA46CC183944191006324A447BDB2D98D4B408<br />
3 - Perform RIPEMD-160 hashing on the result of SHA-256<br />
010966776006953D5567439E5E39F86A0D273BEE<br />
4 - Add version byte in front of RIPEMD-160 hash (0x00 for Main Network)<br />
00010966776006953D5567439E5E39F86A0D273BEE<br />
5 - Perform SHA-256 hash on the extended RIPEMD-160 result<br />
445C7A8007A93D8733188288BB320A8FE2DEBD2AE1B47F0F50BC10BAE845C094<br />
6 - Perform SHA-256 hash on the result of the previous SHA-256 hash<br />
D61967F63C7DD183914A4AE452C9F6AD5D462CE3D277798075B107615C1A8A30<br />
7 - Take the first 4 bytes of the second SHA-256 hash. This is the address checksum<br />
D61967F6<br />
8 - Add the 4 checksum bytes from stage 7 at the end of extended RIPEMD-160 hash from stage 4. This is the 25-byte binary Bitcoin Address.<br />
00010966776006953D5567439E5E39F86A0D273BEED61967F6<br />
9 - Convert the result from a byte string into a base58 string using [[Base58Check encoding]]. This is the most commonly used Bitcoin Address format<br />
16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM<br />
<br />
==See Also==<br />
* [[Address]]<br />
* [http://gobittest.appspot.com/Address Address testing suite]<br />
* [[Anonymity & Security]]<br />
[[Category:Technical]]</div>Superbhttps://tests.bitcoin.it/w/index.php?title=Protocol_documentation&diff=49268Protocol documentation2014-08-01T13:17:42Z<p>Superb: </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 [[getblocktemplate]].<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 [[Script]]) 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 totalling 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 />
If you're reading the Satoshi client code (BitcoinQT) it refers to this as a "CompactSize". Modern BitcoinQT has also CVarInt class which implements even more compact integer for the purpose of local storage (which is incompatible with "CompactSize" described here). CVarInt is not a part of the protocol.<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:a00: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 (Will overflow in 2106<ref>http://en.wikipedia.org/wiki/Unix_time#Notable.C2.A0events.C2.A0in.C2.A0Unix.C2.A0time</ref>)<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 || [[Protocol_specification#Variable_length_integer|var_int]] || 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 further 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]] || [https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki 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 [https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki 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 />
3B 64 8D 5A - 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 is found in the node's main chain, the list of its children is returned back via the ''inv'' message and the remaining locators are ignored, no matter if the requested limit was reached, or not.<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 block chain 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 (see [[NLockTime]]).<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 finding potential nodes in the network. The response to receiving this message is to transmit one or more addr messages with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.<br />
<br />
No additional data is transmitted with this message.<br />
<br />
=== mempool ===<br />
<br />
The mempool message sends a request to a node asking for information about transactions it has verified but which have not yet confirmed. The response to receiving this message is an inv message containing the transaction hashes for all the transactions in the node's mempool.<br />
<br />
No additional data is transmitted with this message.<br />
<br />
It is specified in [https://github.com/bitcoin/bips/blob/master/bip-0035.mediawiki BIP 35]. Since [https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki BIP 37], only transactions matching the filter are replied.<br />
<br />
=== checkorder ===<br />
<br />
This message was used for [[IP Transactions]]. As IP transactions have been deprecated, it is no longer used.<br />
<br />
=== submitorder ===<br />
<br />
This message was used for [[IP Transactions]]. As IP transactions have been deprecated, it is no longer used.<br />
<br />
=== reply ===<br />
<br />
This message was used for [[IP Transactions]]. As IP transactions have been deprecated, it is no longer used.<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.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 8 || nonce || uint64_t || random nonce<br />
|}<br />
<br />
=== pong ===<br />
<br />
The ''pong'' message is sent in response to a ''ping'' message. In modern protocol versions, a ''pong'' response is generated using a nonce included in the ping.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 8 || nonce || uint64_t || nonce from ping<br />
|}<br />
<br />
<br />
=== reject===<br />
<br />
The ''reject'' message is sent when messages are rejected.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 1+ || message || var_str || type of message rejected<br />
|-<br />
| 1 || ccode || char || code relating to rejected message<br />
|-<br />
| 1+ || reason || var_str || text version of reason for rejection<br />
|}<br />
<br />
CCodes<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 0x01 || REJECT_MALFORMED|| <br />
|-<br />
| 0x10 || REJECT_INVALID ||<br />
|-<br />
| 0x11 || REJECT_OBSOLETE ||<br />
|-<br />
| 0x12 || REJECT_DUPLICATE ||<br />
|-<br />
| 0x40 || REJECT_NONSTANDARD ||<br />
|-<br />
| 0x41 || REJECT_DUST ||<br />
|-<br />
| 0x42 || REJECT_INSUFFICIENTFEE ||<br />
|-<br />
| 0x43 || REJECT_CHECKPOINT ||<br />
|}<br />
<br />
<br />
=== filterload, filteradd, filterclear, merkleblock ===<br />
<br />
These messages are related to Bloom filtering of connections and are defined in [https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki BIP 0037].<br />
<br />
<br />
The <code>filterload</code> command is defined as follows:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || filter || uint8_t[] || The filter itself is simply a bit field of arbitrary byte-aligned size. The maximum size is 36,000 bytes.<br />
|-<br />
| 4 || nHashFuncs || uint32_t || The number of hash functions to use in this filter. The maximum value allowed in this field is 50.<br />
|-<br />
| 4 || nTweak || uint32_t || A random value to add to the seed value in the hash function used by the bloom filter.<br />
|-<br />
| 1 || nFlags || uint8_t || A set of flags that control how matched items are added to the filter.<br />
|}<br />
<br />
See below for a description of the Bloom filter algorithm and how to select nHashFuncs and filter size for a desired false positive rate.<br />
<br />
Upon receiving a <code>filterload</code> command, the remote peer will immediately restrict the broadcast transactions it announces (in inv packets) to transactions matching the filter, where the matching algorithm is specified below. The flags control the update behaviour of the matching algorithm.<br />
<br />
The <code>filteradd</code> command is defined as follows:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || data || uint8_t[] || The data element to add to the current filter.<br />
|}<br />
<br />
The data field must be smaller than or equal to 520 bytes in size (the maximum size of any potentially matched object).<br />
<br />
The given data element will be added to the Bloom filter. A filter must have been previously provided using <code>filterload</code>. This command is useful if a new key or script is added to a clients wallet whilst it has connections to the network open, it avoids the need to re-calculate and send an entirely new filter to every peer (though doing so is usually advisable to maintain [[Anonymity & Security|anonymity]]).<br />
<br />
The <code>filterclear</code> command has no arguments at all.<br />
<br />
After a filter has been set, nodes don't merely stop announcing non-matching transactions, they can also serve filtered blocks. A filtered block is defined by the <code>merkleblock</code> message and is defined like this:<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 />
| 4 || total_transactions || uint32_t || Number of transactions in the block (including unmatched ones)<br />
|-<br />
| ? || hashes || uint256[] || hashes in depth-first order (including standard varint size prefix)<br />
|-<br />
| ? || flags || byte[] || flag bits, packed per 8 in a byte, least significant bit first (including standard varint size prefix)<br />
|}<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 || uchar[] || Serialized alert payload<br />
|-<br />
| ? || signature || uchar[] || 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 uchar[] 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 cancelled: deleted and not accepted in the future<br />
|-<br />
| ? || setCancel || set<int32_t> || All alert IDs contained in this set should be cancelled 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 />
Note: '''set<''type''>''' in the table above is a [[#Variable length integer | variable length integer]] followed by the number of fields of the given ''type'' (either int32_t or [[#Variable length string | variable length string]])<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 />
==See Also==<br />
<br />
* [[Network]]<br />
* [[Protocol rules]]<br />
* [[Hardfork Wishlist]]<br />
* [https://bitcoin.org/en/developer-documentation Developer Documentation on bitcoin.org]<br />
* Bitcoin dissectors for Wireshark: https://github.com/lbotsch/wireshark-bitcoin https://github.com/op-sig/bitcoin-wireshark-dissector<br />
<br />
==References==<br />
<references /><br />
<br />
[[zh-cn:协议说明]]<br />
[[Category:Technical]]<br />
[[Category:Developer]]</div>Superbhttps://tests.bitcoin.it/w/index.php?title=Securing_your_wallet&diff=49267Securing your wallet2014-08-01T13:17:04Z<p>Superb: </p>
<hr />
<div>==Introduction==<br />
<br />
Unless you are using a [[hardware wallet]] it is strongly recommended to read this page.<br />
<br />
Wallet security can be broken down into two independent goals:<br />
# Protecting your wallet against loss.<br />
# Protecting your wallet against theft.<br />
<br />
In the case that your current wallet hasn't been protected adequately (e.g. put online with a weaker password):<br />
# Making a new secure wallet, using appropriate long-term protection.<br />
<br />
''For a brief overview see also: [[Wallet Security Dos and Don'ts|Wallet Security Dos and Don'ts]]''<br />
<br />
==Paper Wallets==<br />
[[Paper wallet]]s can be used to store bitcoins offline in non-digital format. Using securely generated paper wallets significantly decreases the chances of your bitcoins being stolen by hackers or computer viruses.<br />
<br />
Fundamentally, a paper wallet is merely a physical record of a [[private key]] (most commonly written as a sequence of fifty-one alphanumeric characters beginning with a '5') and its corresponding [[public key]]. The private key is used to prove your right to spend the bitcoins transferred to the paper wallet, and as such should be kept hidden and secret. If the private key on a paper wallet is exposed (for example in a photograph) then the wallet may be "swept" by anyone who sees the key. To guard against accidental revelation, the private key displayed on the paper wallet may be encrypted using a password ("BIP38") or split into several different parts ("Shamir's secret sharing scheme"). At the very least, the private key should be well hidden e.g. by folding the wallet in half and sealing it shut.<br />
<br />
You can send bitcoins to the public address on your paper wallet as often as you like, and they will be inaccessible until the private key is imported into a "live" wallet. You can use a service such as [[BlockChain.info]] to verify the balance of your paper wallet, which is a matter of public record. As of version 0.6.0, the bitcoin QT software has a command line feature called "importprivkey" that can load private keys. Online exchanges and wallets such as [[Coinbase (business)|Coinbase]] and BlockChain.info have features for importing (or "sweeping") paper wallet private keys as well.<br />
<br />
=== Software for generating paper wallets ===<br />
<br />
Some [[Paper wallet|paper wallet generators]] have been written entirely in HTML/JavaScript to make it fairly easy to generate paper wallets on virtually any operating system. Although these generators use a web browser, they are generally capable of running offline since address generation happens entirely within the web browser. It's advisable to use those services from [https://en.wikipedia.org/wiki/Live_CD live disc], to ensure that private keys are not compromised by spyware. <br />
<br />
To generate a safer paper wallet, first save the paper wallet generating code to a newly-formatted USB stick and verify the integrity (SHA1 hash or PGP signature) of the code. Then "clean-boot" your computer with a bootable CD (such as a Linux Live CD) while disconnected from the Internet. Insert the USB stick and open the wallet generator's HTML file using a web browser. Print your paper wallets or store them on external media (do not save them on the computer), and then shut down the computer. You may need to load an appropriate printer driver in order to print while booted from the live CD.<br />
<br />
=== Tips for making paper wallets ===<br />
<br />
* Disconnecting from the Internet guarantees that that the paper wallet generator is truly self-contained and isn't transmitting your keys online. <br />
<br />
* Verifying the integrity of the code (and the trustworthiness of the author) is important to make sure a hacker hasn't modified the HTML so that it generates predictable addresses instead of truly random keys.<br />
<br />
* Using a very basic printer is advisable since high-end office printers may have WiFi or internal storage that keeps a cache of printed documents.<br />
<br />
* Remember, spyware and viruses often attempt to monitor your computer activities so that their authors can steal from you. They are interested in passwords to online accounts, and anything of value. Bitcoin wallets and private keys are something of value that have already been targeted by malware. If your computer is infected with spyware or viruses - even if there are no symptoms, or your antivirus isn't reporting anything - then anything you type, view, or save on your computer, could potentially be stolen by someone remotely controlling your computer. Your private key can then be intercepted while you enter it, so only enter a Bitcoin private key into your computer when your intent is to redeem its value ''immediately'' or when you want to transfer your funds into a secure [[hardware wallet]].<br />
<br />
== Hardware wallets ==<br />
[[Hardware wallet]]s are a major step to enhanced security and usability.<br />
<br />
See the [[Hardware wallet]]s page for more information on which hardware wallet solutions are currently available.<br />
<br />
==Importance of security updates==<br />
<br />
No software is perfect, and from time to time there may be security vulnerabilities found in your Bitcoin client as well.<br />
Be sure you keep your client updated with the latest bug fixes, especially when a new vulnerability is discovered.<br />
We maintain a [[CVEs|list a known vulnerabilities]] on this wiki - you can watch that page to get updates.<br />
Note that you ''don't'' need to be running the latest major client version: some clients, including the popular Bitcoin-Qt, have older versions available with bugfix-only updates.<br />
<br />
==Securing the Bitcoin-QT or bitcoind wallet==<br />
<br />
Bitcoin transactions send Bitcoins to a specific public key. A Bitcoin address is an encoded hash of a public key. In order to use received Bitcoins, you need to have the private key matching the public key you received with. This is sort of like a super long password associated with an account (the account is the public key). Your Bitcoin wallet contains all of the private keys necessary for spending your received transactions. If you delete your wallet without a backup, then you no longer have the authorization information necessary to claim your coins, and the coins associated with those keys are lost forever.<br />
<br />
The wallet contains a pool of queued keys. By default there are 100 keys in the [[key pool]]. The size of the pool is configurable using the "-keypool" command line argument. When you need an address for whatever reason (send, “new address”, generation, etc.), the key is not actually generated freshly, but taken from this pool. A brand new address is generated to fill the pool back to 100. So when a backup is first created, it has all of your old keys plus 100 unused keys. After sending a transaction, it has 99 unused keys. After a total of 100 new-key actions, you will start using keys that are not in your backup. Since the backup does not have the private keys necessary for authorizing spends of these coins, restoring from the old backup will cause you to lose Bitcoins.<br />
<br />
Creating a new address generates a new pair of public and private keys, which are added to your wallet. Each keypair is mostly random numbers, so they cannot be known prior to generation. If you backup your wallet and then create more than 100 new addresses, the keypair associated with the newest addresses will not be in the old wallet because the new keypairs are only known after creating them. Any coins received at these addresses will be lost if you restore from the backup.<br />
<br />
The situation is made somewhat more confusing because the receiving addresses shown in the UI are not the only keys in your wallet. Each Bitcoin generation is given a new public key, and, more importantly, each sent transaction also sends some number of Bitcoins back to yourself at a new key. When sending Bitcoins to anyone, you generate a new keypair for yourself and simultaneously send Bitcoins to your new public key and the actual recipient's public key. This is an [[Anonymity & Security|anonymity]] feature – it makes tracking Bitcoin transactions much more difficult.<br />
<br />
So if you create a backup, do more than 100 things that cause a new key to be used, and then restore from the backup, some Bitcoins will be lost. Bitcoin has not deleted any keys (keys are never deleted) – it has created a new key that is not in your old backup and then sent Bitcoins to it.<br />
<br />
== Making a new Bitcoin-QT or bitcoind wallet ==<br />
<br />
If a wallet or an encrypted wallet's password has been compromised, it is wise to create a new wallet and transfer the full balance of bitcoins to addresses contained only in the newly created wallet. Examples of ways a wallet may be compromised are through password re-use, minimal strength passwords, computer hack or virus attack.<br />
<br />
There are a number of ways to create a new wallet with Bitcoin-QT or bitcoind but this is a process that has been tested with bitcoind 0.6.3. We use the copy command to minimize the chance of any data loss but you are warned to make backups of any wallet.dat that holds a balance for you.<br />
<br />
:1. Shut down the Bitcoin program.<br />
:2. Find and make a backup of the "compromised" wallet.dat file and rename it, perhaps adding a short description:<br />
:::wallet.dat -> wallet-compromised.dat<br />
:Depending on your OS, the wallet file will be located at:<br />
:::Windows: %APPDATA%\Bitcoin\<br />
:::Linux: ~/.bitcoin/<br />
:::Mac: ~/Library/Application Support/Bitcoin/<br />
:3. Start the Bitcoin program and it will create a new wallet.dat. You may then encrypt the wallet as desired and make a new backup.<br />
:4. Once you've made a new wallet, you can obtain one or more addresses and copy them into a text editor. After obtaining the new address(es), shut down the Bitcoin program, make a backup of the new wallet.dat file and copy it to a new file named wallet-new.dat.<br />
:5. Copy the wallet-compromised.dat file back to wallet.dat, start the Bitcoin program and transfer your balance to the new address(es) you put in your text editor. Once the balance is back to 0 for your compromised wallet, you may want to wait a couple minutes or for a confirmation or check block explorer to be sure the transactions have been broadcasted. Then you may shut down the Bitcoin program.<br />
:6. Rename wallet.dat to wallet-compromised.dat. <br />
:7. Rename wallet-new.dat to wallet.dat.<br />
<br />
You should now have a new wallet with all the bitcoins from the old wallet.<br />
<br />
==Making a secure workspace==<br />
<br />
Unless you are using a [[hardware wallet]], you must take care that the system is free of malware, viruses, keyloggers, remote access tools, and other tools that may be used to make remote copies of your wallet, Bitcoin-related passwords, or Bitcoin private keys. When your computer is compromised, the precautions taken below may provide additional protection.<br />
<br />
A [[hardware wallet]] typically holds the private keys on its internal storage that is not accessible by any malware. The device signs the transactions internally and only transmits the signed transactions to the computer. The separation of the private keys from the vulnerable environment allows the user to spend bitcoins on a compromised computer without any risk. <br />
<br />
<br />
===Debian-based Linux===<br />
<br />
==== Store all into an encrypted folder (Tomb) ====<br />
<br />
Tomb is a simple tool to manage encrypted storage on GNU/Linux. Among its features are bind-hooks to set up a tomb's contents in the place where other programs expect them, for example in our case mount -o bind the .bitcoin directory in a user's home.<br />
<br />
First install tomb from https://files.dyne.org/tomb (homepage is on http://www.dyne.org/software/tomb)<br />
<br />
Among the requirements: zsh, cryptsetup, pinentry-curses, gnupg, sudo.<br />
<br />
Recommended: wipe, dcfldd, steghide, qrencode.<br />
<br />
Then create a tomb (we name it bitcoin) with three commands:<br />
<br />
<code>tomb dig -s 100 bitcoin.tomb</code><br />
<br />
<code>tomb forge bitcoin.tomb.key</code><br />
<br />
<code>tomb lock bitcoin.tomb -k bitcoin.tomb.key</code><br />
<br />
Then open it<br />
<br />
<code>tomb open bitcoin.tomb</code><br />
<br />
This will require you to input again the password you selected.<br />
<br />
Once open the tomb contents are in /media/bitcoin.tomb<br />
<br />
Move there your bitcoin wallet:<br />
<br />
<code>mv ~/.bitcoin /media/bitcoin.tomb/my-safe-wallet</code><br />
<br />
Then create a file "/media/bitcoin.tomb/bind-hooks" and put a single line:<br />
<br />
<code>my-safe-wallet .bitcoin</code><br />
<br />
Which means that every time the tomb is open, the directory my-safe-wallet needs to be bound to ~/.bitcoin. Just make sure an empty ~/.bitcoin directory exists in your home.<br />
<br />
Now close the tomb and store its keys safely, make sure you memorize the password. Have a look at Tomb's documentation, there is a number of things you can do like steganography or printing out keys on a paper to hide and such.<br />
<br />
That's it. Every time you like to access your wallet open the tomb and the .bitcoin will be in place. One can also store the bitcoin binary inside the tomb and even start the bitcoin client using the exec-hooks. Tomb's manual page "man tomb" explains the possibilities.<br />
<br />
The advantage of this approach over an encrypted home is that it becomes extremely portable across computers and even online shells: a Tomb is just a file and its key can be stored far away, on different shells, usb sticks or mobile phones.<br />
<br />
<br />
<br />
<br />
==== Secure the whole user home directory ====<br />
The first step is to make a [http://www.howtogeek.com/howto/ubuntu/add-a-user-on-ubuntu-server/ new user]. In order for that new user to have an encrypted home directory, you'll first need the encryption utility. Run:<br />
<br />
<code>sudo apt-get install ecryptfs-utils</code><br />
<br />
Now you're ready to create a new user<br />
<br />
<code>sudo adduser --encrypt-home new_user_name</code><br />
<br />
You'll need to come up with a [[#Choosing_A_Strong_Password|secure]] new password for that user.<br />
<br />
When you get to the prompt 'Enter the new value, or press ENTER for the default', just keep hitting ENTER.<br />
<br />
Then switch user to the new user. To get to the new user you can use the switch user icon for your system, which on Ubuntu is in the 'System/Quit' screen, or if there is no switch icon on your system you can log out and log back in as the new user.<br />
<br />
Since the home folder of this user is encrypted, if you're not logged in as that user, data that is saved there can't be browsed, even by a root user. If something goes wrong with your system, and you need to decrypt the new user's files, you'll need its decryption key.<br />
<br />
<code>ecryptfs-unwrap-passphrase</code><br />
<br />
It will ask you for your user's password and give you the decryption key. '''WRITE DOWN OR SAVE THE CODE IT RETURNS''' because you will need it if you ever have to pull your data off while the OS is not working. (You can run it again later if you need to, but run it now so that you can get your data if your Linux install gets botched.)<br />
<br />
The encrypted folder data is not encrypted while it's in memory, and so if it's ever sent to the swap partition it can be stolen from there unless that too is encrypted - be aware that this will mean you cannot use Hibernate anymore, as the bootloader won't be able to restore the hibernation data.<br />
<br />
<code>ecryptfs-setup-swap</code><br />
<br />
Then click on a folder in the new user to display the file browser, then keep going up folders until you see the new user home directory, then right click to bring up the Properties dialog, then click on the Permissions tab, then in the Others section, set the folder access to None.<br />
<br />
For secure browsing, open Firefox, and then go into the Edit menu and click Preferences. Starting from the left, click on the General tab, and in the 'Startup/When Firefox starts' pop up menu, choose 'Show a Blank Page'. Then click on the Content tab, and deselect 'Load images automatically' and deselect 'Enable JavaScript'. Then click on the Privacy tab, and in the 'History/Firefox will' pop up menu, choose 'Never remember history'. Then click on the Security tab, and in the Passwords section, deselect 'Remember passwords for sites' and deselect 'Use a master password'. Then click on the Advanced tab, then click on the Update tab, and then in the 'Automatically check for updates to' section, deselect 'Add-ons' and 'Search Engines'.<br />
<br />
When JavaScript is disabled, the [http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.23/bitcoin-0.3.23-linux.tar.gz/download Linux download page] will not download automatically, so you'll have to click on the 'direct link' part of the "Problems with the download? Please use this 'direct link' or try another mirror." line.<br />
<br />
===Mac===<br />
This solution '''does not scale'''; the amount of needed space can grow beyond the image size.<br />
<br />
===Windows===<br />
<br />
Due to the frequency with which Windows computers are compromised, it is advised to encrypt your wallet or to keep your wallet on an encrypted disk image created by third-party software, such as [http://www.truecrypt.org/ TrueCrypt] (open source) or [http://www.jetico.com/encryption-bestcrypt/ Jetico BestCrypt] (commercial). This also applies to the storage of passwords, private keys and other data that can be used to access any of your Bitcoin balances.<br />
<br />
Assuming that you have installed the Windows Bitcoin client and run it at least once, the process is described below.<br />
<br />
<p><b>To mount the Bitcoin data directory on an encrypted drive</b></p><br />
<ol start=1 type=1><br />
<li>Use the third-party disk image encryption program of your choice to create and mount an encrypted disk image of at least 5GB in size. This procedure stores the entire block chain database with the wallet.dat file so the required size of the encrypted disk image required may grow in the future.</li><br />
<li>Locate the Bitcoin data directory, and copy the directory with all contents to the encrypted drive.<br />
<p>For help finding this directory, see <b>[[Securing_your_wallet#Locating_Bitcoin_s_data_directory|Locating Bitcoin's Data Directory]]</b>.</p></li><br />
<li>Create a Windows shortcut that starts Bitcoin with the <code>-datadir</code> parameter and specifies the encrypted drive and directory.<br />
<p>For example, if you installed Bitcoin in the default directory, mounted your Bitcoin encrypted drive as <code>E:\</code>, and stored your Bitcoin data directory on it as <code>Bitcoin</code>, you would type the following command as the shortcut Target:</p><br />
<blockquote><code>C:\Program Files\Bitcoin\bitcoin.exe -datadir=E:\Bitcoin</code></blockquote></li><br />
<li>Open Bitcoin's settings and configure it <b>NOT</b> to start automatically when you start Windows.<br />
<p>This is to allow you to mount the Bitcoin encrypted disk image before starting Bitcoin.</p></li><br />
<li>Shut down Bitcoin, and then restart it from the new shortcut.</li><br />
</ol><br />
<br />
After doing this, any time you want to use Bitcoin, you must first mount the Bitcoin encrypted disk image using the same drive designation, and then run Bitcoin from the shortcut that you created, so that it can find its data and your wallet.<br />
<br />
<br />
=== General Solutions ===<br />
<br />
Your wallet.dat file is not encrypted by the Bitcoin program by default but the most current release of the Bitcoin client provides a method to encrypt with a passphrase the private keys stored in the wallet. Anyone who can access an unencrypted wallet can easily steal all of your coins. Use one of these encryption programs if there is any chance someone might gain access to your wallet.<br />
* [http://www.7-zip.org/ 7-zip] - Supports strongly-encrypted archives.<br />
* [http://www.axantum.com/axcrypt/ AxCrypt by Axantum]<br />
* [http://lrzip.kolivas.org lrzip] - Compression software for Linux and OSX that supports very high grade password protected encryption<br />
* [http://www.truecrypt.org/ TrueCrypt] - Volume-based on-the-fly encryption (for advanced users)<br />
<br />
There is also a list of [[OpenSourceEncryptionSoftware|open source encryption software.]]<br />
<br />
Decrypting and encrypting the wallet.dat every time you start or quit the Bitcoin client can be ''tedious'' (and outright error-prone). If you want to keep your wallet encrypted (except while you're actually running the Bitcoin client), it's better to relegate the automation to a [http://lorelei.kaverit.org/bitcoin.sh small shell script] that handles the en/decryption and starting up Bitcoin client for you (Linux and OSX). <br />
<br />
There is also a method to print out and encrypt your wallet.dat as a special, scannable code. See details here: [[WalletPaperbackup]]<br />
<br />
==== Password Strength ====<br />
Brute-force password cracking has come a long way. A password including capitals, numbers, and special characters with a length of 8 characters can be trivially solved now (using appropriate hardware). The recommended length is '''at least''' 12 characters long. You can also use a multi-word password and there are techniques to increase the strength of your passwords without sacrificing usability. [http://www.baekdal.com/tips/password-security-usability The Usability of Passwords] <br />
<br />
However, simply using dictionary words is also insecure as it opens you up to a dictionary attack. If you use dictionary words, be sure to include random symbols and numbers in the mix as well.<br />
<br />
If you use keyfiles in addition to a password, it is unlikely that your encrypted file can ever be cracked using brute-force methods, even when even a 12 character password might be too short.<br />
<br />
Assume that any encrypted files you store online (eg. Gmail, Dropbox) will be stored somewhere forever and can never be erased.<br />
<br />
===== Choosing A Strong Password =====<br />
Make sure you pick at least one character in each group:<br /><br />
<br />
Lowercase: abcdefghijklmnopqrstuvwxyz<br />
Uppercase: ABCDEFGHIJKLMNOPQRSTUVWXYZ<br />
Number: 1234567890<br />
Symbol: `~!@#$%^&*()-_=+\|[{]};:'",<.>/? (space)<br />
<br />
<9 char = unsuitable for use<br />
09 char = insecure<br />
10 char = low security<br />
11 char = medium security<br />
12 char = good security (good enough for your wallet)<br />
13 char = very good, enough for anything.<br />
<br />
You might want to read [http://security.stackexchange.com/questions/662/what-is-your-way-to-create-good-passwords-that-can-actually-be-remembered What is your way to create good passwords that can actually be remembered?] and [http://security.stackexchange.com/questions/6095/xkcd-936-short-complex-password-or-long-dictionary-passphrase XKCD #936: Short complex password, or long dictionary passphrase?]<br />
<br />
== Backing up your wallet ==<br />
<br />
Backing up your wallet is not necessary if you use a wallet with implemented [[BIP 0032]] (hierarchical deterministic wallet). Today, only [[TREZOR]], [[Electrum]] and [[CarbonWallet]] fully support BIP 0032.<br />
<br />
For advise on the backup process see [[Backingup_your_wallet|Backing up your wallet]].<br />
<br />
==Erasing Plain-text Wallets==<br />
<br />
In most operating systems, including Windows, Linux, and Mac OS X, simply deleting a wallet.dat file will ''not'' generally destroy it. It is likely that advanced tools can still be used to recover the wallet.dat file, even after it has been deleted.<br />
<br />
The Linux '''shred''' command can be used to overwrite the wallet file with random data prior to deleting; this particular copy of the file will then be practically impossible to recover. Using shred (and similar tools on Windows) however does not guarantee that still other copies don't exist somewhere hidden on your HD. That will depend on your system configuration and what packages you have installed. Some system restore and backup tools, for instance, create periodic snapshots of your filesystem, duplicating your wallet.dat.<br />
<br />
In Mac OS, the equivalent of '''shred''' is '''srm''' (introduced in Leopard). Using the Finder to remove files, clicking "Secure Empty Trash" in the Finder menu will shred the contents of the trash can. As with any OS this doesn't guarantee that there are not other copies elsewhere on your system.<br />
<br />
For Windows, the built-in command ''cipher /W'' will shred all previously-deleted files. [http://www.cylog.org/utilities/cybershredder.jsp CyberShredder] can securely deleted individual files.<br />
<br />
==Online and Mobile Wallets==<br />
<br />
Thus far, this article has been discussing the security of a wallet file for Bitcoin-QT or bitcoind that is under your sole control. <br />
<br />
<br />
Online wallets have a number of pros and cons to consider. For example, you can access your wallet on any computer in the world, but you are essentially storing your private keys or wallet with the provider of the online wallet. <br />
Depending on the level of security of such service, your bitcoins may be lost if the service is compromised. <br />
<br />
The invention of [[hardware wallet]]s makes it possible to use online wallets in a more secure manner.<br />
A hardware wallet keeps your private keys apart from the computer and internet. An online wallet compatible with a hardware wallet (such as [http://mytrezor.com myTREZOR.com]) then does not need to store any sensitive data (private keys, passwords or email addresses) and only serves as tool for broadcasting transactions signed in the hardware wallet out to the blockchain. <br />
<br />
<br />
Mobile wallet applications are available for Android devices that allow you to send bitcoins by QR code or NFC, but this opens up the possibility of loss if mobile device is compromised. It may be possible to encrypt and backup the wallet or private keys on a mobile device but it is not advisable to store a large amount of bitcoins there without doing your own research and testing. Mobile wallets are useful for small spending and not for storing your bitcoin savings.<br />
<br />
==See Also==<br />
<br />
* [[Anonymity & Security]]<br />
* [[Data directory]]<br />
* [[How to import private keys]]<br />
* [http://bitcoinx.io/wallets/ Where to get a Bitcoin wallet]<br />
* [http://startbitcoin.com/how-to-create-a-secure-bitcoin-wallet/ Secure Bitcoin Wallet Tutorial]<br />
* [[How to set up a secure offline savings wallet]]<br />
* [http://arimaa.com/bitcoin/ Bitcoin Gateway - A Peer-to-peer Bitcoin Vault and Payment Network]<br />
* [http://blog.cyplo.net/2012/04/01/bitcoin-wallet-recovery-photorec/ Find lost wallet eg. after disk format, using Photorec]<br />
* [https://docs.google.com/document/d/1dNZ7N_lQXHQp0jWkeN7dW4bWNMpcTBRM4iEoSuQwLho/edit# The Ultimate Guide to Web Wallet Security]<br />
<br />
[[Category:Security]]<br />
<br />
[[de:Sichere deine Geldbörse]]<br />
[[ru:Bitcoin и безопасность]]<br />
[[es:Cómo asegurar su monedero]]<br />
[[zh-cn:保护你的钱包]]</div>Superbhttps://tests.bitcoin.it/w/index.php?title=Anonymity_%26_Security&diff=49240Anonymity & Security2014-07-31T18:05:08Z<p>Superb: </p>
<hr />
<div>== [http://anonymity.co.in/mixing_services.html Mixing services] ==<br />
<br />
[http://anonymity.co.in/mixing_services.html Mixing services] are used to avoid compromising of privacy and security. Mixing services provide to periodically exchange your bitcoins for different ones which cannot be associated with the original owner.<br />
<br />
== [[Transactions]] ==<br />
<br />
<br />
While using bitcoins is an excellent way to make your purchases, donations, and p2p payments, without losing money through inflated transaction fees, transactions are never truly anonymous. Buying Bitcoin you pass identification, Bitcoin transactions are stored publicly and permanently on the network, which means anyone can see the balance and transactions of any Bitcoin address. Bitcoin activities are recorded and available publicly via the [[blockchain]], a comprehensive database which keeps a record of bitcoin transactions.<br />
<br />
== Buying/selling bitcoins ==<br />
<br />
<br />
All exchanges require the user to scan ID documents, and large transactions must be reported to the proper governmental authority. When you use Bitcoin to pay for goods and services, you will of course need to provide your name and address to the seller for delivery purposes.<br />
<br />
This means that a third party with an interest in tracking your activities can use your visible balance and ID information as a basis from which to track your future transactions or to study previous activity. In short, you have compromised your [[security]] and [[privacy]].<br />
<br />
== See also ==<br />
* [http://anonymity.co.in/mixing_services.html Mixing services]<br />
* [http://bitcoinhelp.net/know/more/top-seven-ways-your-identity-can-be-linked-to-your-bitcoin-address Top Seven Ways Your Identity Can Be Linked to Your Bitcoin Address]<br />
* [[Privacy]]<br />
* [[Security]]<br />
<br />
[[Category:Anonymity]]</div>Superbhttps://tests.bitcoin.it/w/index.php?title=Help:Introduction&diff=48698Help:Introduction2014-07-08T13:47:32Z<p>Superb: /* Anonymity */</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 must 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 need 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, or their balance partially or wholly confiscated.<br />
* Banks and other payment processors like PayPal, Visa, and Mastercard may refuse to process payments for certain 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 />
<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, for a given unit of time 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 create 25 new 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%. Originally the block reward was 50 bitcoins; it halved in November 2012. 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 whoever finds the next block. Paying this fee will encourage miners to include the transaction in a block more quickly.<br />
<br />
===Sending payments===<br />
<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 to Alice.<br />
* Alice adds Bob’s address and the amount of bitcoins to transfer to a message: a 'transaction' message.<br />
* Alice signs the transaction with her private key, and announces her public key for signature verification.<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 address and the amount of bitcoins to transfer to a message: a 'transaction' message.<br />
* Bob signs the transaction with his private key, and announces his public key for signature verification.<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 address with her address, 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 />
<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 & Security]]===<br />
<br />
Bitcoin could be interpreted as a ‘pseudo-anonymous’ network. It is anonymous in the sense that you can hold a Bitcoin address without revealing anything about your identity in that address. One person could hold multiple addresses, and in theory, there would be nothing to link those addresses together, or to indicate that the person owned them.<br />
<br />
A [[Address|Bitcoin address]] mathematically corresponds to a public key and looks like this:<br />
<br />
:1PHYrmdJ22MKbJevpb3MBNpVckjZHt89hz<br />
<br />
There is another side to Bitcoin. Everything that happens in the Bitcoin world is trackable. Thanks to the way that the algorithm is structured, every Bitcoin-based transaction is logged in the blockchain.<br />
<br />
All exchanges require the user to scan ID documents, and large transactions must be reported to the proper governmental authority. When you use Bitcoin to pay for goods and services, you will of course need to provide your name and address to the seller for delivery purposes.<br />
<br />
This means that a third party with an interest in tracking your activities can use your visible balance and ID information as a basis from which to track your future transactions or to study previous activity. In short, you have compromised your [[security]] and [[privacy]].<br />
<br />
===Capitalization / Nomenclature===<br />
<br />
Since Bitcoin is both a currency and a protocol, capitalization can be confusing. Accepted practice is to use ''Bitcoin'' (singular with an upper case letter B) to label the protocol, software, and community, and ''bitcoins'' (with a lower case b) to label units of the currency.<br />
<br />
==Where to see and explore==<br />
<br />
You can directly explore the system in action by visiting [https://www.biteasy.com/ Biteasy.com], [http://blockchain.info/ Blockchain.info], [http://btc.blockr.io/ Blokr.io Bitcoin Block Explorer] 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 />
* [http://bitcoinhelp.net Bitcoin Help] &mdash; the simple guide to Bitcoin.<br />
* Learn the entire history of Bitcoin in the interactive timeline at [http://historyofbitcoin.org History of Bitcoin].<br />
* Get started buying bitcoins at [http://coinbase.com/ Coinbase].<br />
* [http://bitcoinX.io BitcoinX.io] Website Dedicated to Providing Users with the Best Information on Where to Buy, Sell and Trade Bitcoins. Covers all of the Major Exchanges.<br />
* [[File:MCS_200by200_logo-01.png|20px|link=http://www.mycoinsolution.com]][http://www.mycoinsolution.com My Coin Solution] - For business that want to learn more about Bitcoin<br />
* [https://www.trybtc.com/ TryBTC] easiest way to get started using bitcoin. Gives you free coins to create a bitcoin wallet and start spending.<br />
* [http://www.youtube.com/watch?v=Um63OQz3bjo What is Bitcoin?] video introduction<br />
* Installing Bitcoin [[getting started]] <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 />
* [http://dpassport.com/free-reports/Free-Bitcoin-Report.pdf Free Bitcoin report] by Brad Gosse and Jennifer Wozniak<br />
<br />
[[zh-cn:简介]]<br />
<br />
[[de:Einführung]]<br />
[[fr:Introduction]]</div>Superbhttps://tests.bitcoin.it/w/index.php?title=Bitcoin&diff=48697Bitcoin2014-07-08T13:41:51Z<p>Superb: </p>
<hr />
<div>'''Bitcoin''' is a decentralized [[digital currency]] created by developer [[Satoshi Nakamoto]]. It does not rely on a central server to process transactions or store funds. There are a maximum of 2,099,999,997,690,000 Bitcoin elements (called satoshis), which are currently most commonly measured in units of 100,000,000 known as BTC. Stated another way, no more than 21 million BTC can ever be created.<br />
<br />
{{As of|April 2014}}, it is the most widely used alternative currency,<ref name="Quantitative Analysis of the Full Bitcoin Transaction Graph">{{cite web|title=Quantitative Analysis of the Full Bitcoin Transaction Graph|url=http://eprint.iacr.org/2012/584.pdf|publisher=Cryptology ePrint Archive|accessdate=18 October 2012|author=Ron Dorit|coauthors=Adi Shamir|page=17|quote=The Bitcoin system is the best known and most widely used alternative payment scheme,...}}</ref><ref name="Mt.Gox data">{{Cite web|title=Mt.Gox data|url=http://bitcoincharts.com/markets/mtgoxUSD.html|publisher=Bitcoincharts}}</ref> now with the total market cap over 6 billion US dollars<ref>{{cite web|title=Market Capitalization|url=https://blockchain.info/charts/market-cap|publisher= [[BlockChain.info]] |accessdate=21 April 2014}}</ref>.<br />
<br />
Bitcoin has no central issuer; instead, the peer-to-peer network regulates Bitcoins, transactions and issuance according to consensus in network software.<br />
Bitcoins are issued to various nodes that verify transactions through computing power;<br />
it is established that there will be a limited and scheduled release of no more than 21 million BTC worth of coins, which will be fully issued by the year 2140.<br />
<br />
Internationally, Bitcoins can be exchanged and managed through various websites and [[software]] along with physical banknotes and coins.<ref>{{Cite web|title=Physical Bitcoins by Casascius|url=https://www.casascius.com/|publisher=Casascius Coins|accessdate=29 September 2012}}</ref><ref>{{Cite web|title=Bitbills|url=http://www.bitbills.com/|publisher=Bitbills|accessdate=29 September 2012}}</ref><br />
<br />
==History==<br />
:Main article: [[History]]<br />
<br />
A cryptographic system for untraceable payments was first described by David Chaum in 1982.<ref>[http://blog.koehntopp.de/uploads/Chaum.BlindSigForPayment.1982.PDF David Chaum, Blind signatures for untraceable payments], Advances in Cryptology - Crypto '82, Springer-Verlag (1983), 199–203.</ref> In 1990 Chaum extended this system to create the first cryptographic anonymous electronic cash system.,<ref>{{cite journal|journal=Lecture Notes in Computer Science|last1=Chaum|first1=David|last2=Fiat|first2=Amos|last3=Naor|first3=Moni|title=Untraceable Electronic Cash|url=http://blog.koehntopp.de/uploads/chaum_fiat_naor_ecash.pdf}}</ref> which became known as ecash.<br />
<ref>{{cite web|url=http://www.wired.com/wired/archive/2.12/emoney.html|publisher=Wired|title=E-Money (That's What I Want)|date=1994–2012|author=Steven Levy}}</ref> In 1998 Wei Dai published a description of an anonymous, distributed electronic cash system which he called "b-money".<ref>{{cite web|title=B-Money|url=http://www.weidai.com/bmoney.txt|author=Wei Dai|year=1998}}</ref> Around the same time, Nick Szabo created ''bit gold''.<ref>{{cite web|url=http://spectrum.ieee.org/computing/software/bitcoin-the-cryptoanarchists-answer-to-cash/0|title=Bitcoin: The Cryptoanarchists’ Answer to Cash|publisher=IEEE Spectrum|quote=Around the same time, Nick Szabo, a computer scientist who now blogs about law and the history of money, was one of the first to imagine a new digital currency from the ground up. Although many consider his scheme, which he calls “bit gold,” to be a precursor to Bitcoin}}</ref><ref name="bitgold">{{cite web|title=Bit gold|url=http://unenumerated.blogspot.co.uk/2005/12/bit-gold.html|author=Nick Szabo|quote=My proposal for bit gold is based on computing a string of bits from a string of challenge bits, using functions called variously "client puzzle function," "proof of work function," or "secure benchmark function.". The resulting string of bits is the proof of work.... The last-created string of bit gold provides the challenge bits for the next-created string.}}</ref> Like Bitcoin, ''Bit gold'' was a currency system where users would compete to solve a [[proof of work]] function, with solutions being cryptographically chained together and published via a distributed property title registry. A variant of ''Bit gold'', called ''Reusable Proofs of Work'', was implemented by Hal Finney.<ref name="bitgold"/><br />
<br />
In 2008, Satoshi Nakamoto published a [[Bitcoin_white_paper|paper]]<ref name="whitepaper">{{cite web<br />
|last= Nakamoto<br />
|first= Satoshi<br />
|title= Bitcoin: A Peer-to-Peer Electronic Cash System<br />
|url= http://www.cs.kent.edu/~JAVED/class-P2P12F/papers-2012/PAPER2012-p2p-bitcoin-satoshinakamoto.pdf<br />
|accessdate = 14 December 2010<br />
|date= 24 May 2009<br />
|postscript=<br />
}}</ref><ref>{{cite web<br />
|url= http://article.gmane.org/gmane.comp.encryption.general/12588/<br />
|title= Bitcoin P2P e-cash paper<br />
}}</ref> on The Cryptography Mailing list at metzdowd.com<ref>[http://www.mail-archive.com/search?l=cryptography@metzdowd.com&q=from:%22Satoshi+Nakamoto%22 Satoshi's posts to Cryptography mailing list]</ref> describing the Bitcoin protocol.<br />
<br />
The Bitcoin network came into existence on 3 January 2009 with the release of the first Bitcoin client, [[wxBitcoin]], and the issuance of the first Bitcoins.<ref>{{cite web |title=Block 0 – Bitcoin Block Explorer |url=http://blockexplorer.com/block/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f }}</ref><ref>{{cite web |url=http://www.mail-archive.com/cryptography@metzdowd.com/msg10142.html |title=Bitcoin v0.1 released}}</ref><ref>{{cite web |url=http://sourceforge.net/news/?group_id=244765 |title=SourceForge.net: Bitcoin}}</ref><br />
A year after, the initial exchange rates for Bitcoin were set by individuals on the bitcointalk forums.{{Citation needed|date=October 2012}} The most significant transaction involved a 10,000 BTC pizza.<ref>{{cite web|title=The Rise and Fall of Bitcoin|url=http://www.wired.com/magazine/2011/11/mf_bitcoin/|publisher=Wired|accessdate=13 October 2012}}</ref><br />
Today, the majority of Bitcoin exchanges occur on the [[Bitstamp]] Bitcoin exchange.<ref>{{cite web | title = Exchange volume distribution | work = by market | publisher = [[Bitcoin Charts]] | date = April 15, 2014 | url = http://bitcoincharts.com/charts/volumepie/ | accessdate = 2014-04-15 }}</ref><br />
<br />
In 2011, Wikileaks,<ref>{{cite news<br />
|last= Greenberg<br />
|first= Andy<br />
|url= http://blogs.forbes.com/andygreenberg/2011/06/14/wikileaks-asks-for-anonymous-bitcoin-donations/<br />
|title= WikiLeaks Asks For Anonymous Bitcoin Donations – Andy Greenberg – The Firewall – Forbes<br />
|publisher= Blogs.forbes.com<br />
|date= 2011-06-14<br />
|accessdate = 2011-06-22<br />
}}</ref> [[Freenet]],<ref>{{cite web<br />
|url= https://freenetproject.org/donate.html<br />
|title= /donate<br />
|publisher= The Freenet Project<br />
|date=<br />
|accessdate = 2011-06-22<br />
}}</ref> Singularity Institute,<ref>[http://singinst.org/donate/ SIAI donation page]</ref> Internet Archive,<ref>[http://www.archive.org/donate/index.php Internet Archive donation page]</ref> Free Software Foundation<ref>[https://my.fsf.org/donate/other/ Other ways to donate]</ref> and others, began to accept donations in Bitcoin. The Electronic Frontier Foundation did so for a while but has since stopped, citing concerns about a lack of legal precedent about new currency systems, and because they "generally don't endorse any type of product or service."<ref>{{cite web<br />
|url= https://www.eff.org/deeplinks/2011/06/eff-and-bitcoin<br />
|title= EFF and Bitcoin &#124; Electronic Frontier Foundation<br />
|publisher= Eff.org<br />
|date= 2011-06-14<br />
|accessdate = 2011-06-22<br />
}}</ref> Some small businesses had started to adopt Bitcoin. LaCie, a public company, accepts Bitcoin for its Wuala service.<ref>{{Cite web|url=http://www.wuala.com/en/bitcoin |title=Secure Online Storage – Backup. Sync. Share. Access Everywhere |publisher=Wuala |date= |accessdate = 2012-01-24}}</ref><br />
<br />
In 2012, BitPay reports of having over 1000 merchants accepting Bitcoin under its payment processing service.<ref>{{cite web|title=BitPay Signs 1,000 Merchants to Accept Bitcoin Payments|url=http://www.americanbanker.com/issues/177_176/bitpay-signs-1000-merchants-to-accept-bitcoin-payments-1052538-1.html|publisher=American Banker|accessdate=12 October 2012}}</ref><br />
<br />
==Administration==<br />
Bitcoin is administered through a decentralized peer-to-peer network.<ref name="whitepaper"/> Cryptographic technologies and the peer-to-peer network of computing power enables users to make and verify irreversible, instant online Bitcoin payments, without an obligation to trust and use centralized banking institutions and authorities. Dispute resolution services are not made directly available. Instead it is left to the users to verify and trust the parties they are sending money to through their choice of methods. <br />
<br />
Bitcoins are issued according to rules agreed to by the majority of the computing power within the Bitcoin network. The core rules describing the predictable issuance of Bitcoins to its verifying servers, a voluntary and competitive transaction fee system and the hard limit of no more than 21 million BTC issued in total.<ref name="whitepaper"/><br />
<br />
Bitcoin does not require a central bank, State,<ref>{{cite web<br />
|url= http://spectrum.ieee.org/computing/software/bitcoin-the-cryptoanarchists-answer-to-cash/3<br />
|title= Bitcoin: The Cryptoanarchists' Answer to Cash<br />
|publisher= IEEE.org<br />
|date= June 2012<br />
|accessdate = 2012-06-05<br />
}}</ref> or incorporated backers.<br />
<br />
==Services==<br />
:Main article: [[Wallet]]<br />
<br />
Bitcoins are sent and received through software and websites called wallets. They send and confirm transactions to the network through Bitcoin addresses, the identifiers for users' Bitcoin wallets within the network.<ref name="whitepaper"/><br />
<br />
===Bitcoin addresses===<br />
:Main article: [[Address]]<br />
<br />
Payments are made to Bitcoin "addresses": human-readable strings of numbers and letters around 33 characters in length, always beginning with the digit 1 or 3, as in the example of ''31uEbMgunupShBVTewXjtqbBv5MndwfXhb''.<br />
<br />
Users obtain new Bitcoin addresses from their Bitcoin software. Creating a new address can be a completely offline process and require no communication with the Bitcoin network.<br />
<br />
===Transaction fees===<br />
:Main article: [[Transaction fees]]<br />
Transaction fees may be included with any transfer of Bitcoins. {{As of|2012}} many transactions are processed in a way which makes no charge for the transaction. For transactions which consume or produce many coins (and therefore have a large data size), a small transaction fee is usually expected.<br />
<br />
===Confirmations===<br />
:Main article: [[Confirmation]]<br />
<br />
The network's software confirms a transaction when it records it in a block. Further blocks of transactions confirm it even further. After six confirmations/blocks, a transaction is confirmed beyond reasonable doubt.<br />
<br />
The network must store the whole transaction history inside the blockchain, which grows constantly as new records are added and never removed. Nakamoto conceived that as the database became larger, users would desire applications for Bitcoin that didn't store the entire database on their computer. To enable this, the blockchain uses a [[merkle tree]] to organize the transaction records in such a way that client software can locally delete portions of its own database it knows it will never need, such as earlier transaction records of Bitcoins that have changed ownership multiple times.<br />
<br />
==Economics==<br />
<br />
===Initial distribution===<br />
<br />
Bitcoin has no centralized issuing authority.<ref name="ars-06-08-11"><br />
{{Cite news<br />
|first= Thomas<br />
|last= Lowenthal<br />
|title= Bitcoin: inside the encrypted, peer-to-peer digital currency<br />
|newspaper= Ars Technica<br />
|date= 8 June 2011<br />
|url= http://arstechnica.com/tech-policy/news/2011/06/bitcoin-inside-the-encrypted-peer-to-peer-currency.ars<br />
}}</ref><ref>{{cite news<br />
|author= Sponsored by<br />
|url= http://www.economist.com/blogs/babbage/2011/06/virtual-currency<br />
|title= Virtual currency: Bits and bob<br />
|publisher= The Economist<br />
|date=<br />
|accessdate = 2011-06-22<br />
}}</ref><ref>{{cite web<br />
|last= Geere<br />
|first= Duncan<br />
|url= http://www.wired.co.uk/news/archive/2011-05/16/bitcoin-p2p-currency<br />
|title= Peer-to-peer currency Bitcoin sidesteps financial institutions (Wired UK)<br />
|publisher= Wired.co.uk<br />
|date=<br />
|accessdate = 2011-06-22<br />
}}</ref> The network is programmed to increase the money supply as a geometric series until the total number of Bitcoins reaches 21 million BTC.<ref name="Quantitative Analysis of the Full Bitcoin Transaction Graph"/> {{As of|2012|10}} slightly over 10 million of the total 21 million BTC had been created; the current total number created is available online.<ref>{{cite web<br />
|title= Total Number of Bitcoins in Existence<br />
|url= http://blockexplorer.com/q/totalbc<br />
|work= Bitcoin Block Explorer<br />
|accessdate = 2012-10-03<br />
}}</ref> By 2013 half of the total supply will have been generated, and by 2017, three-quarters will have been generated. To ensure sufficient granularity of the [[money supply]], clients can divide each BTC unit down to eight decimal places (a total of 2.1&nbsp;×&nbsp;10<sup>15</sup> or 2.1 quadrillion units).<ref name="lwn">{{Cite news<br />
|author= Nathan Willis<br />
|date= 2010-11-10<br />
|title= Bitcoin: Virtual money created by CPU cycles<br />
|publisher= LWN.net<br />
|url= http://lwn.net/Articles/414452/<br />
}}</ref><br />
<br />
The network {{As of|2012|lc=on}} required over one million times more work for confirming a block and receiving an award (25 BTC {{As of|2012|2|lc=on}}) than when the first blocks were confirmed.<br />
The difficulty is automatically adjusted every 2016 blocks based on the time taken to find the previous 2016 blocks such that one block is created roughly every 10 minutes.<br />
<br />
Those who chose to put computational and electrical resources toward mining early on had a greater chance at receiving awards for block generations. This served to make available enough processing power to process blocks. Indeed, without miners there are no transactions and the Bitcoin economy comes to a halt.<br />
<br />
===Exchange rate===<br />
Prices fluctuate relative to goods and services more than more widely accepted currencies;<br />
the price of a Bitcoin is not static.<br />
<br />
In August 2012, 1 BTC traded at around $10.00 USD. Taking into account the total number of Bitcoins mined, the monetary base of the Bitcoin network stands at over 110 million USD.<ref>[http://www.bitcoinwatch.com/ http://www.bitcoinwatch.com/] Bitcoin statistics</ref><br />
<br />
== Anonymity ==<!--Please keep as starting template--><br />
:Main article: [[Anonymity & Security|Anonymity]]<br />
<br />
=== Transactions ===<br />
<br />
While using bitcoins is an excellent way to make your purchases, donations, and p2p payments, without losing money through inflated transaction fees, transactions are never truly anonymous. Buying Bitcoin you pass identification, Bitcoin transactions are stored publicly and permanently on the network, which means anyone can see the balance and transactions of any Bitcoin address. Bitcoin activities are recorded and available publicly via the [[blockchain]], a comprehensive database which keeps a record of bitcoin transactions.<br />
<br />
=== Buying/selling bitcoins ===<br />
<br />
All exchanges require the user to scan ID documents, and large transactions must be reported to the proper governmental authority. When you use Bitcoin to pay for goods and services, you will of course need to provide your name and address to the seller for delivery purposes.<br />
<br />
This means that a third party with an interest in tracking your activities can use your visible balance and ID information as a basis from which to track your future transactions or to study previous activity. In short, you have compromised your [[security]] and [[privacy]].<br />
<br />
=== Mixing services ===<br />
<br />
[http://anonymity.co.in/mixing_services.html Mixing services] are used to avoid compromising of privacy and security. Mixing services provide to periodically exchange your bitcoins for different ones which cannot be associated with the original owner.<br />
<br />
== Security ==<!--Please keep as starting template--><br />
:Main article: [[Weaknesses]]<br />
<br />
In the history of bitcoin, there have been a few [[incidents]], caused by problematic as well as malicious transactions. In the worst such incident, and the only one of its type, a person was able to pretend that he had a practically infinite supply of bitcoins, for almost 9 hours.<br />
<br />
Bitcoin relies, among other things, on [http://en.wikipedia.org/wiki/Public-key_cryptography public key cryptography] and thus may be vulnerable to [http://en.wikipedia.org/wiki/Elliptic_curve_cryptography#Quantum_computing_attacks quantum computing attacks] if and when practical quantum computers can be constructed.<br />
<br />
If multiple different software packages, whose usage becomes widespread on the Bitcoin network, disagree on the protocol and the rules for transactions, this could potentially cause a fork in the block chain, with each faction of users being able to accept only their own version of the history of transactions. This could influence the price of bitcoins.<br />
<br />
A global, organized campaign against the currency or the software could also influence the demand for bitcoins, and thus the exchange price.<br />
<br />
==Bitcoin mining==<br />
:Main article: [[Mining]]<br />
<br />
Bitcoin mining nodes are responsible for managing the Bitcoin network.<br />
<br />
Bitcoins are awarded to Bitcoin nodes known as "miners" for the solution to a difficult [[proof-of-work]] problem which confirms transactions and prevents double-spending. This incentive, as the Nakamoto white paper describes it, encourages "nodes to support the network, and provides a way to initially distribute coins into circulation, since no central authority issues them."<ref name="whitepaper" /><br />
<br />
Nakamoto compared the generation of new coins by expending CPU time and electricity to gold miners expending resources to add gold to circulation.<ref name="whitepaper"/><br />
<br />
===Node operation===<br />
<br />
The node software for the Bitcoin network is based on peer-to-peer networking, digital signatures and cryptographic proof to make and verify transactions. Nodes broadcast transactions to the network, which records them in a public record of all transactions, called the ''blockchain'', after validating them with a [[proof-of-work|proof-of-work system]].<br />
<br />
Satoshi Nakamoto designed the first Bitcoin node and mining software<ref name="processors">{{Cite news<br />
|last= Davis<br />
|first= Joshua<br />
|title= The Crypto-Currency<br />
|url= http://www.wired.com/magazine/2011/11/mf_bitcoin/all<br />
|accessdate = 11 November 2011<br />
|newspaper= Wired Magazine<br />
|date= 10 November 2011<br />
}}</ref> and developed the majority of the first implementation, Bitcoind, from 2007 to mid-2010.<ref name="code_start">{{cite web<br />
|url= https://bitcointalk.org/index.php?topic=13.msg46#msg46<br />
|title= Questions about Bitcoin<br />
|publisher= Bitcoin forum<br />
|date= 2009-12-10<br />
}}</ref><br />
<br />
Node implementations include core software such as Bitcoind/Bitcoin-Qt, [[libbitcoin]], [[cbitcoin]]<ref>{{Cite web|title=cbitcoin|url=https://github.com/MatthewLM/cbitcoin|accessdate=3 October 2012}}</ref> and [[BitCoinJ|bitcoinj]].<ref>{{cite web<br />
|url= http://news.slashdot.org/story/11/03/23/0210207/Google-Engineer-Releases-Open-Source-Bitcoin-Client<br />
|title= Google Engineer Releases Open Source Bitcoin Client<br />
|author= angry tapir, timothy<br />
|date= 23 March 2011<br />
|publisher= Slashdot<br />
|accessdate = 2011-05-18<br />
}}</ref><ref>{{cite web<br />
|url= http://www.javaworld.com/javaworld/jw-01-2012/120110-bitcoin-for-beginners-3.html?page=1<br />
|title= Bitcoin for beginners: The BitcoinJ API<br />
|author= Dirk Merkel<br />
|date= 10 January 2012<br />
|publisher= JavaWorld<br />
|accessdate = 2012-08-03<br />
}}</ref><br />
<br />
Every node in the Bitcoin network collects all the unacknowledged transactions it knows of in a file called a ''block'', which also contains a reference to the previous valid block known to that node. It then appends a [[nonce]] value to this previous block and computes the SHA-256 cryptographic hash of the block and the appended nonce value. The node repeats this process until it adds a nonce that allows for the generation of a hash with a value lower than a specified ''target''. Because computers cannot practically reverse the hash function, finding such a nonce is hard and requires on average a predictable amount of repetitious trial and error. This is where the ''[[proof-of-work]]'' concept comes in to play. When a node finds such a solution, it announces it to the rest of the network. Peers receiving the new solved block validate it by computing the hash and checking that it really starts with the given number of zero bits (i.e., that the hash is within the target). Then they accept it and add it to the chain.<br />
<br />
===Mining rewards===<br />
In addition to receiving the pending transactions confirmed in the block, a generating node adds a ''generate'' transaction, which awards new Bitcoins to the operator of the node that generated the block. The system sets the payout of this generated transaction according to its defined inflation schedule. The miner that generates a block also receives the fees that users have paid as an incentive to give particular transactions priority for faster confirmation.<br />
<br />
The network never creates more than a 50&nbsp;BTC reward per block and this amount will decrease over time towards zero, such that no more than 21 million BTC will ever exist.<ref name="lwn" /> As this payout decreases, the incentive for users to run block-generating nodes is intended to change to earning [[#Transaction fees|transaction fees]].<br />
<br />
===Mining pools===<br />
:Main article: [[Pooled mining]]<br />
<br />
Bitcoin users often pool computational effort to increase the stability of the collected fees and subsidy they receive.<ref name="We Use Coins Mining">{{cite web|title=About Bitcoin Mining|url=http://www.weusecoins.com/mining-guide.php|publisher=We Use Coins|accessdate=18 October 2012}}</ref><br />
<br />
===Mining difficulty===<br />
:Main article: [[Difficulty]]<br />
<br />
In order to throttle the creation of blocks, the difficulty of generating new blocks is adjusted over time. If mining output increases or decreases, the difficulty increases or decreases accordingly.<br />
<br />
The adjustment is done by changing the threshold that a hash is required to be less than. A lower threshold means fewer possible hashes can be accepted, and thus a higher degree of difficulty. The target rate of block generation is one block every 10 minutes, or 2016 blocks every two weeks. Bitcoin changes the difficulty of finding a valid block every 2016 blocks, using the difficulty that would have been most likely to cause the prior 2016 blocks to have taken two weeks to generate, according to the timestamps on the blocks. Technically, this is done by modeling the generation of Bitcoins as Poisson process. All nodes perform and enforce the same difficulty calculation.<br />
<br />
Difficulty is intended as an automatic stabilizer allowing mining for Bitcoins to remain profitable in the long run for the most efficient miners, independently of the fluctuations in demand of Bitcoin in relation to other currencies.<br />
<br />
===Mining hardware===<br />
:Main article: [[Mining Hardware Comparison]]<br />
<br />
Bitcoins used to be mined through Intel/AMD CPUs. {{As of | 2012}}, mining has gradually moved to [[GPU]] and [[FPGA]] hardware.<ref name="bitcoinmag-butterfly" /> [[Application-specific integrated circuit|ASIC]]-based hardware for Bitcoin mining has been announced by several manufacturers who intend to ship products from late 2012 to early 2013.<ref name="bitcoinmag-butterfly">{{Cite web|title=Bitpay Breaks Daily Volume Record with Butterfly ASIC mining release|url=http://bitcoinmagazine.net/bitpay-breaks-daily-volume-record-with-butterfly-asic-mining-release/|publisher=Bitcoin Magazine}}</ref><br />
<br />
==Concerns==<br />
<br />
===As an investment===<br />
Bitcoin describes itself as an experimental digital currency. Reuben Grinberg has noted that Bitcoin's supporters have argued that Bitcoin is neither a security or an investment because it fails to meet the criteria for either category.<ref name="grinberg">{{cite web | url=http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1817857 | title=Bitcoin: An Innovative Alternative Digital Currency | publisher=SSRN | date=9 December 2011 | accessdate=4 December 2012 | author=Grinberg, Reuben}}</ref> Although it is a virtual currency, some people see it as an investment<ref name="cnbc">{{cite web | url=http://www.cnbc.com/id/45030812/The_Pros_And_Cons_Of_Biting_on_Bitcoins | title=The Pros And Cons Of Biting on Bitcoins | publisher=CNBC | date=23 November 2011 | accessdate=4 December 2012 | author=Gustke, Constance}}</ref> or accuse it of being a form of investment fraud known as a Ponzi scheme.<ref>{{cite web |url=http://www.theregister.co.uk/2011/06/08/bitcoin_under_attack/ |title=US senators draw a bead on Bitcoin |last1=Chirgwin |first1=Richard |date=8 June 2011 |publisher=The Register |accessdate=14 November 2012}}</ref><ref>{{cite web |url=http://uk.reuters.com/article/2012/04/01/uk-traders-bitcoin-idUKBRE8300JL20120401 |title=Bitcoin, the City traders' anarchic new toy |last1=O'Leary |first1=Naomi |date=2 April 2012 |publisher=Reuters |accessdate=14 November 2012}}</ref> A report by the European Central Bank, using the U.S. Securities and Exchange Commission's definition of a Ponzi scheme, found that the use of bitcoins shares some characteristics with Ponzi schemes, but also has characteristics of its own which contradict several common aspects of Ponzi schemes.<ref name="ecbreport">{{cite web | url=http://www.ecb.europa.eu/pub/pdf/other/virtualcurrencyschemes201210en.pdf | title=Virtual Currency Schemes | publisher=European Central Bank | date=October 2012 | accessdate=4 December 2012}}</ref><br />
<br />
===Privacy===<br />
Because transactions are broadcast to the entire network, they are inherently public. Unlike regular banking,<ref>{{cite web<br />
|url= http://spectrum.ieee.org/computing/software/bitcoin-the-cryptoanarchists-answer-to-cash/0<br />
|title= Bitcoin: The Cryptoanarchists' Answer to Cash<br />
|publisher= IEEE.org<br />
|date= June 2012<br />
|accessdate = 2012-06-05<br />
}}</ref> which preserves customer privacy by keeping transaction records private, loose transactional privacy is accomplished in Bitcoin by using many unique addresses for every wallet, while at the same time publishing all transactions. As an example, if Alice sends 123.45 BTC to Bob, the network creates a public record that allows anyone to see that 123.45 has been sent from one address to another. However, unless Alice or Bob make their ownership of these addresses known, it is difficult for anyone else to connect the transaction with them. However, if someone connects an address to a user at any point they could follow back a series of transactions as each participant likely knows who paid them and may disclose that information on request or under duress.<br />
<br />
It can be difficult to associate Bitcoin identities with real-life identities.<ref name="An Analysis of Anonymity in the Bitcoin System">Fergal Reid and Martin Harrigan (24 July 2011). [http://anonymity-in-bitcoin.blogspot.com/2011/07/bitcoin-is-not-anonymous.html An Analysis of Anonymity in the Bitcoin System]. An Analysis of Anonymity in the Bitcoin System.</ref> This property makes Bitcoin transactions attractive to sellers of illegal products.<ref name="Forbes">Andy Greenberg (20 April 2011). [http://www.forbes.com/forbes/2011/0509/technology-psilocybin-bitcoins-gavin-andresen-crypto-currency.html Crypto Currency]. Forbes Magazine.</ref><ref>{{cite web<br />
|last= Madrigal<br />
|first= Alexis<br />
|title= Libertarian Dream? A Site Where You Buy Drugs With Digital Dollars<br />
|publisher= The Atlantic Monthly<br />
|date= 2011-06-01<br />
|url= http://www.theatlantic.com/technology/archive/2011/06/libertarian-dream-a-site-where-you-buy-drugs-with-digital-dollars/239776/<br />
|accessdate = 2011-06-05<br />
}}</ref><br />
<br />
===Illicit use===<br />
<br />
====Cracking====<br />
The cracking organization "LulzSec" accepted donations in Bitcoin, having said that the group "needs Bitcoin donations to continue their hacking efforts".<ref name="CNET">{{cite web<br />
|last= Reisinger<br />
|first= Don<br />
|url= http://news.cnet.com/8301-13506_3-20070268-17/senators-target-bitcoin-currency-citing-drug-sales/<br />
|title= Senators target Bitcoin currency, citing drug sales &#124; The Digital Home – CNET News<br />
|publisher= News.cnet.com<br />
|date= 2011-06-09<br />
|accessdate = 2011-06-22<br />
}}</ref><ref>{{cite news<br />
|last= Olson<br />
|first= Parmy<br />
|url= http://blogs.forbes.com/parmyolson/2011/06/06/lulzsec-hackers-posts-sony-dev-source-code-get-7k-donation/<br />
|title= LulzSec Hackers Post Sony Dev. Source Code, Get $7K Donation – Parmy Olson – Disruptors – Forbes<br />
|publisher= Blogs.forbes.com<br />
|date= 6 June 2011<br />
|accessdate = 2011-06-22<br />
}}</ref><br />
<br />
====Silk Road====<br />
[[Silk Road]] is an anonymous black market that uses only the Bitcoin.<ref name="npr-06-12-11"><br />
{{Cite news<br />
|url= http://www.npr.org/2011/06/12/137138008/silk-road-not-your-fathers-amazon-com<br />
|date= 12 June 2011<br />
|newspaper= NPR<br />
|title= Silk Road: Not Your Father's Amazon.com<br />
|author= Staff<br />
}}</ref> <br />
<br />
In a 2011 letter to Attorney General Eric Holder and the Drug Enforcement Administration, senators Charles Schumer of New York and Joe Manchin of West Virginia called for an investigation into Silk Road and the Bitcoin.<ref name="npr-06-12-11"/><br />
Schumer described the use of Bitcoins at Silk Road as a form of money laundering.<ref name="ars-06-08-11"/><br />
<br />
====Botnet mining====<br />
In June 2011, Symantec warned about the possibility of botnets engaging in covert "mining" of Bitcoins,<ref>{{Cite web|author=Updated: 17 June 2011 | Translations available: 日本語 |url=http://www.symantec.com/connect/blogs/bitcoin-botnet-mining |title=Bitcoin Botnet Mining &#124; Symantec Connect Community |publisher=Symantec.com |date=2011-06-17 |accessdate = 2012-01-24}}</ref><ref>{{Cite web|url=http://www.zdnet.com/blog/security/researchers-find-malware-rigged-with-bitcoin-miner/8934 |title=Researchers find malware rigged with Bitcoin miner |publisher=ZDNet |date=2011-06-29 |accessdate = 2012-01-24}}</ref> consuming computing cycles, using extra electricity and possibly increasing the temperature of the computer. Later that month, the Australian Broadcasting Corporation caught an employee using the company's servers to generate Bitcoins without permission.<ref>{{Cite web|url=http://thenextweb.com/au/2011/06/23/abc-employee-caught-mining-for-bitcoins-on-company-servers/ |title=ABC employee caught mining for Bitcoins on company servers |publisher=The Next Web |date=2011-06-23 |accessdate = 2012-01-24}}</ref> Some malware also uses the parallel processing capabilities of the GPUs built into many modern-day video cards.<ref>{{Cite news |url=http://www.theregister.co.uk/2011/08/16/gpu_bitcoin_brute_forcing/ |title=Malware mints virtual currency using victim's GPU |date=16 August 2011<!-- 20:00 GMT -->|first=Dan |last=Goodin }}</ref> In mid August 2011, Bitcoin miner botnets were found;<ref>{{Cite web|url=http://www.infosecurity-magazine.com/view/20211/researcher-discovers-distributed-bitcoin-cracking-trojan-malware/ |title=Infosecurity – Researcher discovers distributed bitcoin cracking trojan malware |publisher=Infosecurity-magazine.com |date=2011-08-19 |accessdate = 2012-01-24}}</ref> trojans infecting Mac OS X have also been uncovered.<ref>{{Cite web|url=http://www.techworld.com.au/article/405849/mac_os_x_trojan_steals_processing_power_produce_bitcoins |title=Mac OS X Trojan steals processing power to produce Bitcoins – sophos, security, malware, Intego – Vulnerabilities – Security |publisher=Techworld |date=2011-11-01 |accessdate = 2012-01-24}}</ref><br />
<br />
===Theft and fraud===<br />
On 19 June 2011, a security breach of the Mt.Gox (an acronym for ''M''agic: ''T''he ''G''athering ''O''nline E''x''change, its original purpose) Bitcoin Exchange caused the price of a Bitcoin to briefly drop to US$0.01 on the Mt.Gox exchange (though it remained unaffected on other exchanges) after a hacker allegedly used credentials from a Mt.Gox auditor's compromised computer to illegally transfer a large number of Bitcoins to him- or herself and sell them all, creating a massive "ask" order at any price. Within minutes the price rebounded to over $15 before Mt.Gox shut down their exchange and canceled all trades that happened during the hacking period.<ref>[https://mtgox.com/press_release_20110630.html Clarification of Mt Gox Compromised Accounts and Major Bitcoin Sell-Off]</ref><ref>[http://www.youtube.com/watch?v=T1X6qQt9ONg YouTube. Bitcoin Report]</ref> The exchange rate of Bitcoins quickly returned to near pre-crash values.<ref name="mick">Jason Mick, 19 June 2011, [http://www.dailytech.com/Inside+the+MegaHack+of+Bitcoin+the+Full+Story/article21942.htm Inside the Mega-Hack of Bitcoin: the Full Story], DailyTech</ref><ref>Timothy B. Lee, 19 June 2011, [http://arstechnica.com/tech-policy/news/2011/06/bitcoin-price-plummets-on-compromised-exchange.ars Bitcoin prices plummet on hacked exchange], Ars Technica</ref><ref>Mark Karpeles, 20 June 2011, [https://support.mtgox.com/entries/20208066-huge-bitcoin-sell-off-due-to-a-compromised-account-rollback Huge Bitcoin sell off due to a compromised account – rollback], Mt.Gox Support</ref><ref name="register1">{{Cite news<br />
|title= Bitcoin collapses on malicious trade – Mt Gox scrambling to raise the Titanic<br />
|url= http://www.theregister.co.uk/2011/06/19/bitcoin_values_collapse_again/<br />
|date= 2011-06-19<br />
|author= Chirgwin, Richard<br />
|publisher= The Register<br />
}}</ref> Accounts with the equivalent of more than USD 8,750,000 were affected.<ref name="mick" /><br />
<br />
In July 2011, The operator of Bitomat, the third largest Bitcoin exchange, announced that he lost access to his wallet.dat file with about 17,000 BitCoins (roughly equivalent to 220,000 USD at that time). He announced that he would sell the service for the missing amount, aiming to use funds from the sale to refund his customers.<ref>[http://siliconangle.com/blog/2011/08/01/third-largest-bitcoin-exchange-bitomat-lost-their-wallet-over-17000-bitcoins-missing/ Third Largest Bitcoin Exchange Bitomat Lost Their Wallet, Over 17,000 Bitcoins Missing]. SiliconAngle</ref><br />
<br />
In August 2011, MyBitcoin, one of popular Bitcoin transaction processors, declared that it was hacked, which resulted in it being shut down, with paying 49% on customer deposits, leaving more than 78,000 BitCoins (roughly equivalent to 800,000 USD at that time) unaccounted for.<ref>[http://betabeat.com/2011/08/mybitcoin-spokesman-finally-comes-forward-what-did-you-think-we-did-after-the-hack-we-got-shitfaced/ MyBitcoin Spokesman Finally Comes Forward: “What Did You Think We Did After the Hack? We Got Shitfaced”]. BetaBeat</ref><ref>[http://betabeat.com/2011/08/search-for-owners-of-mybitcoin-loses-steam/ Search for Owners of MyBitcoin Loses Steam]. BetaBeat</ref><br />
<br />
In early August 2012, a lawsuit was filed in San Francisco court against Bitcoinica, claiming about 460,000 USD from the company. Bitcoinica was hacked twice in 2012, which led to allegations of neglecting the safety of customers' money and cheating them out of withdrawal requests.<ref>[http://arstechnica.com/tech-policy/2012/08/bitcoinica-users-sue-for-460k-in-lost-bitcoins/ Bitcoinica users sue for $460k in lost Bitcoins]. Arstechnica</ref><ref>[http://spectrum.ieee.org/tech-talk/computing/networks/first-bitcoin-lawsuit-filed-in-san-francisco First Bitcoin Lawsuit Filed In San Francisco]. IEEE Spectrum</ref><br />
<br />
In late August 2012, Bitcoin Savings and Trust was shut down by the owner, allegedly leaving around $5.6 million in debts; this led to allegations of the operation being a Ponzi scheme.<ref>{{Cite web|title=Bitcoin ponzi scheme – investors lose $5 million USD in online hedge fund|url=http://rt.com/usa/news/investors-currency-digital-fund-868/|publisher=RT}}</ref><ref>{{Cite web|last=Jeffries|first=Adrianne|title=Suspected multi-million dollar Bitcoin pyramid scheme shuts down, investors revolt|url=http://www.theverge.com/2012/8/27/3271637/bitcoin-savings-trust-pyramid-scheme-shuts-down|publisher=The Verge}}</ref><ref>{{Cite web|last=Mick|first=Jason|title="Pirateat40" Makes Off $5.6M USD in BitCoins From Pyramid Scheme|url=http://www.dailytech.com/Pirateat40+Makes+Off+56M+USD+in+BitCoins+From+Pyramid+Scheme/article25538.htm|publisher=DailyTech}}</ref><ref>[http://pandodaily.com/2012/08/31/bitcoin-how-a-virtual-currency-became-real-with-a-5-6m-fraud/ Bitcoin: How a Virtual Currency Became Real with a $5.6M Fraud]. PandoDaily</ref> In September 2012, it was reported that U.S. Securities and Exchange Commission has started an investigation on the case.<ref>[http://blogs.telegraph.co.uk/technology/willardfoxton2/100007836/bitcoin-pirate-scandal-sec-steps-in-amid-allegations-that-the-whole-thing-was-a-ponzi-scheme/ Bitcoin 'Pirate' scandal: SEC steps in amid allegations that the whole thing was a Ponzi scheme ]. The Telegraph</ref><br />
<br />
In September 2012, Bitfloor Bitcoin exchange also reported being hacked, with 24,000 BitCoins (roughly equivalent to 250,000 USD) stolen. As a result, Bitfloor suspended operations.<ref>[http://www.bbc.co.uk/news/technology-19486695 Bitcoin theft causes Bitfloor exchange to go offline]. BBC</ref><ref>[http://www.theverge.com/2012/9/5/3293375/bitfloor-bitcoin-exchange-suspended-theft Bitcoin exchange BitFloor suspends operations after $250,000 theft Bitcoin exchange BitFloor suspends operations after $250,000 theft]. The Verge</ref> The same month, Bitfloor resumed operations, with its founder saying that he reported the theft to FBI, and that he is planning to repay the victims, though the time frame for such repayment is unclear.<ref>[http://www.pcworld.com/article/2010586/bitcoin-exchange-back-online-after-hack.html?tk=rel_news Bitcoin exchange back online after hack]. PCWorld</ref><br />
<br />
===Taxation===<br />
In September 2012, the Intra-European Organization of Tax Administrations (IOTA), in Tbilisi, Georgia, held a workshop titled "Auditing Individuals and Legal Entities in the Use of e-Money." The workshop was attended by representatives from 23 countries.<ref name="BitCoin Tax issues Oct 2012">{{cite journal | title=2012 TNT 209-4 NEWS ANALYSIS: VIRTUAL CURRENCY: A NEW WORRY FOR TAX ADMINISTRATORS?. (Release Date: OCTOBER 17, 2012) (Doc 2012-21516) | author=Stewart, David D. and Soong Johnston, Stephanie D. | journal=Tax Notes Today | year=2012 | month=October 29 | volume=2012 TNT 209-4 | issue=2012 TNT 209-4}}</ref> Jerry Taylor, IOTA's technical taxation expert, said, "There's an awful lot happening on the Internet environment which is fascinating at the moment and introducing new challenges for auditors when it comes to virtual currency."<ref name="BitCoin Tax issues Oct 2012">{{cite journal | title=2012 TNT 209-4 NEWS ANALYSIS: VIRTUAL CURRENCY: A NEW WORRY FOR TAX ADMINISTRATORS?. (Release Date: OCTOBER 17, 2012) (Doc 2012-21516) | author=Stewart, David D. and Soong Johnston, Stephanie D. | journal=Tax Notes Today | year=2012 | month=October 29 | volume=2012 TNT 209-4 | issue=2012 TNT 209-4}}</ref> Bitcoin was mentioned during the workshop.<ref name="BitCoin Tax issues Oct 2012">{{cite journal | title=2012 TNT 209-4 NEWS ANALYSIS: VIRTUAL CURRENCY: A NEW WORRY FOR TAX ADMINISTRATORS?. (Release Date: OCTOBER 17, 2012) (Doc 2012-21516) | author=Stewart, David D. and Soong Johnston, Stephanie D. | journal=Tax Notes Today | year=2012 | month=October 29 | volume=2012 TNT 209-4 | issue=2012 TNT 209-4}}</ref> <br />
<br />
Matthew Elias, founder of the [[Cryptocurrency Legal Advocacy Group]] (CLAG) published "Staying Between the Lines: A Survey of U.S. Income Taxation and its Ramifications on Cryptocurrencies", which discusses "the taxability of cryptocurrencies such as bitcoin."<ref name="BitCoin Tax issues Oct 2012">{{cite journal | title=2012 TNT 209-4 NEWS ANALYSIS: VIRTUAL CURRENCY: A NEW WORRY FOR TAX ADMINISTRATORS?. (Release Date: OCTOBER 17, 2012) (Doc 2012-21516) | author=Stewart, David D. and Soong Johnston, Stephanie D. | journal=Tax Notes Today | year=2012 | month=October 29 | volume=2012 TNT 209-4 | issue=2012 TNT 209-4}}</ref> CLAG "stressed the importance for taxpayers to determine on their own whether taxes are due on a bitcoin-related transaction based on whether one has "experienced a realization event."<ref name="BitCoin Tax issues Oct 2012">{{cite journal | title=2012 TNT 209-4 NEWS ANALYSIS: VIRTUAL CURRENCY: A NEW WORRY FOR TAX ADMINISTRATORS?. (Release Date: OCTOBER 17, 2012) (Doc 2012-21516) | author=Stewart, David D. and Soong Johnston, Stephanie D. | journal=Tax Notes Today | year=2012 | month=October 29 | volume=2012 TNT 209-4 | issue=2012 TNT 209-4}}</ref> Such examples are "when a taxpayer has provided a service in exchange for bitcoins, a realization event has probably occurred, and any gain or loss would likely be calculated using fair market values for the service provided."<ref name="BitCoin Tax issues Oct 2012">{{cite journal | title=2012 TNT 209-4 NEWS ANALYSIS: VIRTUAL CURRENCY: A NEW WORRY FOR TAX ADMINISTRATORS?. (Release Date: OCTOBER 17, 2012) (Doc 2012-21516) | author=Stewart, David D. and Soong Johnston, Stephanie D. | journal=Tax Notes Today | year=2012 | month=October 29 | volume=2012 TNT 209-4 | issue=2012 TNT 209-4}}</ref><br />
<br />
[[Peter Vessenes]], [[Bitcoin Foundation|Bitcoin Foundation's]] executive director, said, since the foundation is trying to pay for everything in bitcoin, including salaries, "How do we W-2 someone for their bitcoins? Do we mark-to-market every time a transfer happens? Payroll companies cringe."<ref name="BitCoin Tax issues Oct 2012">{{cite journal | title=2012 TNT 209-4 NEWS ANALYSIS: VIRTUAL CURRENCY: A NEW WORRY FOR TAX ADMINISTRATORS?. (Release Date: OCTOBER 17, 2012) (Doc 2012-21516) | author=Stewart, David D. and Soong Johnston, Stephanie D. | journal=Tax Notes Today | year=2012 | month=October 29 | volume=2012 TNT 209-4 | issue=2012 TNT 209-4}}</ref> The Bitcoin Foundation hopes "to push for solid guidance about its legal and tax treatment." [[Patrick Murck]], legal counsel for the Bitcoin Foundation, said he would like "to help regulators understand the technology better so they can make better decisions."<ref name="BitCoin Tax issues Oct 2012">{{cite journal | title=2012 TNT 209-4 NEWS ANALYSIS: VIRTUAL CURRENCY: A NEW WORRY FOR TAX ADMINISTRATORS?. (Release Date: OCTOBER 17, 2012) (Doc 2012-21516) | author=Stewart, David D. and Soong Johnston, Stephanie D. | journal=Tax Notes Today | year=2012 | month=October 29 | volume=2012 TNT 209-4 | issue=2012 TNT 209-4}}</ref> Murck said, "Bitcoin has the potential to become much more than a niche currency, but it needs the guidance and understanding of regulators." and "The full potential of bitcoin could be realized through clearer guidelines and a better understanding by financial and tax regulators." and "Part of making that happen is to talk to regulators, the IRS, and tax professionals and helping them understand that bitcoin is not this nefarious thing, it's just software, it's a community, and there's nothing inherently nefarious about either of those things."<ref name="BitCoin Tax issues Oct 2012">{{cite journal | title=2012 TNT 209-4 NEWS ANALYSIS: VIRTUAL CURRENCY: A NEW WORRY FOR TAX ADMINISTRATORS?. (Release Date: OCTOBER 17, 2012) (Doc 2012-21516) | author=Stewart, David D. and Soong Johnston, Stephanie D. | journal=Tax Notes Today | year=2012 | month=October 29 | volume=2012 TNT 209-4 | issue=2012 TNT 209-4}}</ref><br />
<br />
==See Also==<br />
* [[Introduction]]<br />
* [[Getting started]]<br />
* [[Using_Bitcoin|Detailed tutorial]]<br />
* [[FAQ]]<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Digital currencies]]</div>Superbhttps://tests.bitcoin.it/w/index.php?title=Privacy&diff=48696Privacy2014-07-08T13:34:29Z<p>Superb: </p>
<hr />
<div>While the Bitcoin technology [http://www.bitcointalk.org/index.php?topic=241.0 can support] strong anonymity, the current implementation is usually not very anonymous.<br />
<br />
__TOC__<br />
<br />
The main problem is that every transaction is publicly logged. Anyone can see the flow of Bitcoins from address to address (see first image). Alone, this information can't identify anyone because the addresses are just random numbers. However, if ''any'' of the addresses in a transaction's past or future can be tied to an actual identity, it might be possible to work from that point and guess who may owns all of the other addresses. This identity information might come from network analysis, surveillance, or just Googling the address. The officially-encouraged practice of using a new address for every transaction is designed to make this attack more difficult.<br />
[[File:Unknownaddress.png|thumb|The flow of Bitcoins is highly public.]]<br />
<br />
The second image shows a simple example. Someone runs both a money exchanger and a site meant to trap people. When Mr. Doe buys from the exchanger and uses those same coins to buy something from the trap site, the attacker can '''prove''' that these two transactions were made by the same person. The block chain would show:<br />
[[File:knownaddress.png|thumb|Finding an "identity anchor" allows you to ruin the anonymity of the system.]]<br />
* Import coins from address A. Send 100 to B. Authorized by (signature).<br />
* Import coins from address B. Send 100 to C. Authorized by (signature).<br />
Bitcoin transactions do not have a "from" address but if the attacker believes that address B is controlled by Mr. Doe because the attacker received $5 from Mr. Doe's Paypal account and then sent 100 BTC to that address then they can infer the identity of the party sending to C. This assumption is not always correct because address B may have been an address held on behalf of Mr. Doe by a third party and the transaction to C may have been unrelated.<br />
<br />
Another example: someone is scammed and posts the address they were using on the Bitcoin forum. It is possible to see which address they sent coins to. When coins are sent which were previously send to this (the scammer's) address, the addresses that receive them can also be easily found and posted on the forum. In this way, all of these coins are marked as "dirty", potentially over an infinite number of future transactions. When some smart and honest person notices that his address is now listed, he can reveal who he received those coins from. The Bitcoin community can now ask some pointed questions, "Who did you receive these coins from? What did you create this address for?" Eventually the original scammer will be found. Clearly, this becomes more difficult the more addresses that exist between the "target" and the "identity point".<br />
<br />
You might be thinking that this attack is not feasible. But consider this case:<br />
* You live in China and want to buy a "real" newspaper for Bitcoins.<br />
* You join the Bitcoin forum and use your address as a signature. Since you are very helpful, you manage to get 30 BTC after a few months.<br />
* Unfortunately, you choose poorly in who you buy the newspaper from: you've chosen a government agent! Maybe you are under the mistaken impression that Bitcoin is perfectly anonymous.<br />
* The government agent looks at the block chain and Googles (or Baidus) every address in it. He finds your address in your signature on the Bitcoin forum. You've left enough personal information in your posts to be identified, so you are now scheduled to be "reeducated".<br />
<br />
You need to protect yourself from both forward attacks (getting something that identifies you using coins that you got with methods that must remain secret, like the scammer example) and reverse attacks (getting something that must remain secret using coins that identify you, like the newspaper example).<br />
<br />
==Staying Anonymous==<br />
<br />
By necessity the history of all the bitcoins must be highly public. However, if one has bitcoins on paid to address, one can theoretically choose the coins they spend in a way that will minimize the amount of information they leak. Choosing personally generated coins or an address that you know doesn't reveal information would protect you. Unfortunately, the default Bitcoin client doesn't support this currently, so you must assume that your entire balance can identify you if any of the addresses can.<br />
<br />
You may consider a bitcoin to be "less-anonymous" when an attacker could feasibly find the true identity of a very recent owner of the bitcoin, perhaps because one of the bitcoin addresses was posted to a website, or because he knows some identifying information through other means. <br />
<br />
If your balance has been contaminated by both anonymous and non-anonymous coins, you may take action to make it "clean". <br />
<br />
Recommended way of anonymizing your balance:<br />
* Send however many coins you want to anonymize to a new [[eWallet]] account as a lump sum. There are other [[eWallet]] services however the more widely used the greater the potential for anonymity. <font color="red">This is not an endorsement of trust in the use of [[eWallet]] services. There are no guarantees that any eWallet service won't one day take all your bitcoins and disappear. Use at your own risk.</font> <br />
<br />
With this method an attacker will have to gain access to the eWallet service's transaction logs to continue to follow you in the transaction history. <br />
<br />
The protection that this method offers is significantly reduced if you are trying to anonymize more than about 10% of the total number of Bitcoins that the eWallet service holds. You'll end up getting your own coins back instead of other users' coins. Withdrawing Bitcoins more slowly and in smaller increments will help reduce this problem. Sending coins to an eWallet service in the largest single transfer possible will also help.<br />
<br />
To further enhance your anonymity, you can:<br />
* Send Bitcoins from one EWallet sevice to another and ''then'' to yourself. Each transfer needs to be painstakingly investigated and many transfers will present insurmountable difficulty.<br />
<br />
Once you have an anonymous balance set up, be sure to keep your anonymous and non-anonymous balances completely separate.<br />
<br />
A future version of the client will have more control which will allow the sender to specify which coins to use in a transaction<ref>[http://bitcointalk.org/index.php?topic=24784.msg307661#msg307661 Patching The Bitcoin Client To Make It More Anonymous]</ref>.<br />
<br />
In the future, trusted relay servers operating on the [[friendly addresses with enhanced privacy]] protocol could provide bitcoin users strong anonymity with increased convenience, thereby eliminating the need to make a trade-off between privacy and ease of use.<br />
<br />
===Helping other people stay anonymous===<br />
* Set up a real [http://www.bitcointalk.org/index.php?topic=241.0 external mixing service]. Make it like an eWallet service but make sure that a user never withdraws the same coins that are put in. Also delete empty addresses and transaction logs. <br />
* Even if you're not a programmer, you can make a slightly less secure version of an external mixing service (as a Tor hidden service, preferably):<br />
** Set up two Bitcoin installations.<br />
** Put some amount of BTC in installation B. This is the maximum amount of BTC you can deal with at once (for all customers).<br />
** Customers send BTC to installation A. You send them an equal number of coins (or minus a fee) from installation B. Send as 10-50 BTC increments.<br />
** Send all coins from A to B when '''all''' orders are satisfied. You can't send coins from A to B if you have any orders that have not been satisfied from B.<br />
** This can be automated, or you can do everything manually.<br />
* Put lots of Bitcoins in an eWallet service and keep it there. If anyone uses the anonymization method described in "staying anonymous" above, this will enhance it. Send in smaller increments if a large amount is transferred.<br />
<br />
==Legality==<br />
Obviously, using Bitcoin anonymity techniques for the purposes of [[Wikipedia:money laundering|money laundering]] is illegal, but participating or running schemes which others use for money laundering may also be illegal or at least leave the participant vulnerable to accusations of aiding criminals and terrorists. Bitcoin anonymity techniques involving bitcoins worth large amounts of money (over some value between FJ$1,100 and US$58,000, depending on your jurisdiction) is illegal in most jurisdictions, being in violation of [[Wikipedia:Structuring|anti-structuring laws]].<br />
<br />
==See Also==<br />
<br />
* [[Anonymity & Security]]<br />
* [[:Category:Mixing Services|Mixing Services]] category<br />
* [http://www.bitcointalk.org/index.php?topic=2893.0 RFC: Bitcoin Mixnet]<br />
* [http://www.bitcointalk.org/index.php?topic=241.0 anonymity]<br />
* [http://www.bitcointalk.org/index.php?topic=24784.0 Patching The Bitcoin Client To Make It More Anonymous]<br />
* [http://arxiv.org/abs/1107.4524 An Analysis of Anonymity in the Bitcoin System] research by Fergal Reid, Martin Harrigan ([http://bitcointalk.org/index.php?topic=31539.0 discussion])<br />
* [http://bitcoinhelp.net/know/more/top-seven-ways-your-identity-can-be-linked-to-your-bitcoin-address Top Seven Ways Your Identity Can Be Linked to Your Bitcoin Address]<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Technical]]<br />
[[Category:Anonymity]]</div>Superbhttps://tests.bitcoin.it/w/index.php?title=Template:MainPage_Topics&diff=48695Template:MainPage Topics2014-07-08T13:29:55Z<p>Superb: </p>
<hr />
<div><!--<br />
First table is for tutorials. Left column = pages written for end users. Right column = pages for developers.<br />
Second table is for categories.<br />
--><br />
<br />
{|cellpadding="2" style="background-color: inherit;"<br />
|-<br />
| scope="col" style="width: 200px;" |<br />
* [[Introduction]]<br />
* [[Getting started]]<br />
* [[Myths]]<br />
<br />
* [[Securing your wallet]]<br />
* [http://bitcoincharts.com/ Bitcoin Statistics]<br />
| scope="col" style="width: 200px;" |<br />
* [[:Category:Technical|Technical articles]]<br />
* [[Protocol specification]]<br />
* [[Secure Trading|Best practices for traders]]<br />
* [[Bitcoin Improvement Proposals]]<br />
|}<br />
<br />
{|cellpadding="2" style="background-color: inherit;"<br />
|-<br />
! scope="col" style="width: 200px;" |<br />
! scope="col" style="width: 200px;" |<br />
|-<br />
|<br />
<br />
* [[Anonymity & Security]]<br />
* [[Software]]<br />
* [[Mining]]<br />
* [[:Category:Exchanges|Exchanges]]<br />
* [[:Category:Directories|Local Directories]]<br />
* [[:Category:Marketing|Marketing resources]]<br />
* [[People]]<br />
|<br />
* [[:Category:Clients|Clients]] / [[:Category:Frontends|Frontends]]<br />
* [[:Category:Economics|Economics]]<br />
* [[Trade|Businesses (Trade)]]<br />
* [[:Category:Games|Games]]<br />
* [[Real world shops|Real world merchants map]]<br />
* [[Donation-accepting_organizations_and_projects|Donation-accepting sites]]<br />
* [[Meetups]]<br />
|}<br />
<br />
<div style="text-align: right;" class="noprint"><span class="plainlinks">[{{fullurl:Template:MainPage_Topics|action=edit}} '''Edit''']</span> &ndash; '''[[Special:Categories|See More]]'''</div></div>Superbhttps://tests.bitcoin.it/w/index.php?title=Anonymity_%26_Security&diff=48694Anonymity & Security2014-07-08T13:24:31Z<p>Superb: Created page with "== Transactions == While using bitcoins is an excellent way to make your purchases, donations, and p2p payments, without losing money through inflated transaction fees,..."</p>
<hr />
<div>== [[Transactions]] ==<br />
<br />
<br />
While using bitcoins is an excellent way to make your purchases, donations, and p2p payments, without losing money through inflated transaction fees, transactions are never truly anonymous. Buying Bitcoin you pass identification, Bitcoin transactions are stored publicly and permanently on the network, which means anyone can see the balance and transactions of any Bitcoin address. Bitcoin activities are recorded and available publicly via the [[blockchain]], a comprehensive database which keeps a record of bitcoin transactions.<br />
<br />
== Buying/selling bitcoins ==<br />
<br />
<br />
All exchanges require the user to scan ID documents, and large transactions must be reported to the proper governmental authority. When you use Bitcoin to pay for goods and services, you will of course need to provide your name and address to the seller for delivery purposes.<br />
<br />
This means that a third party with an interest in tracking your activities can use your visible balance and ID information as a basis from which to track your future transactions or to study previous activity. In short, you have compromised your [[security]] and [[privacy]].<br />
<br />
== [http://anonymity.co.in/mixing_services.html Mixing services] ==<br />
<br />
[http://anonymity.co.in/mixing_services.html Mixing services] are used to avoid compromising of privacy and security. Mixing services provide to periodically exchange your bitcoins for different ones which cannot be associated with the original owner.<br />
<br />
== See also ==<br />
* [http://anonymity.co.in/mixing_services.html Mixing services]<br />
* [http://bitcoinhelp.net/know/more/top-seven-ways-your-identity-can-be-linked-to-your-bitcoin-address Top Seven Ways Your Identity Can Be Linked to Your Bitcoin Address]<br />
* [[Privacy]]<br />
* [[Security]]<br />
<br />
[[Category:Anonymity]]</div>Superb