https://tests.bitcoin.it/w/api.php?action=feedcontributions&user=Tcatm&feedformat=atomBitcoin Wiki - User contributions [en]2024-03-29T04:44:40ZUser contributionsMediaWiki 1.30.0https://tests.bitcoin.it/w/index.php?title=Promotional_graphics&diff=24585Promotional graphics2012-03-11T16:53:52Z<p>Tcatm: </p>
<hr />
<div>Bitcoin-related graphics used for promoting bitcoin either for online use, retail display or other promotional purpose.<br />
<br />
==Bitcoin Accepted Here==<br />
[[{{ns:file}}:BC_Rnd_64px.png]]<br />
[[{{ns:file}}:BC 64px.png]]<br />
[[{{ns:file}}:BC nBG 64px.png]]<br />
[[{{ns:file}}:BC RnBG 64px.png]]<br />
<br />
==Logos==<br />
[[{{ns:file}}:BC Logo .png]]<br />
[[{{ns:file}}:BC Logotype.png]]<br />
[[{{ns:file}}:BC Logotype Reverse.png]]<br />
[[{{ns:file}}:Bitcoin euro.png]]<br />
[[{{ns:file}}:Bitcoin.png]]<br />
<br />
==Love Bitcoin Graphics==<br />
[[{{ns:file}}:Lv BCorg 128px.png]]<br />
[[{{ns:file}}:WeLv BC 48px.png]]<br />
[[{{ns:file}}:WeLv BC 128px.png]]<br />
[[{{ns:file}}:WeLv BC Badge 128px.png]]<br />
<br />
==Ƀ Another Bitcoin Identity==<br />
* [[{{ns:file}}:CircleBitcoin.png]] <br />
* [[{{ns:file}}:Pennant.png]]<br />
* [[{{ns:file}}:RibbonDonateBitcoin.png]]<br />
* [[{{ns:file}}:GoldenAcceptedHereBitcoin.png]]<br />
<br />
<br />This graphic elements are available in SVG format on the dedicated [http://www.ecogex.com/bitcoin/ project page].<br />
<br />
==External Links==<br />
<br />
* [https://bitcointalk.org/index.php?topic=38865.0 Set of BTC Icons and Logos]<br />
* [https://bitcointalk.org/index.php?topic=64.msg7415#msg7415 New icon/logo] (SVG of the gold bitcoin / logo)<br />
* [https://bitcointalk.org/index.php?topic=4331.0 Bigger "B" versions of Bitcoin logotypes]<br />
* [https://bitcointalk.org/index.php?topic=9562.20 Ƀ Another Bitcoin identity]<br />
* [https://bitcointalk.org/index.php?topic=1631.0 More Bitcoin logos, buttons, and also some other graphics]<br />
* [https://bitcointalk.org/index.php?topic=45.msg479#msg479 Make your "we accept Bitcoin" logo]<br />
* [http://img340.imageshack.us/img340/7210/onwhitem.jpg Bitcoin Decentralized P2P Currency logo]<br />
* [http://agora.io/wp-content/uploads/2011/03/BitcoinFreeMoney250x100.png Liberty starts with free money logo]<br />
* [https://bitcointalk.org/index.php?topic=6412.0 Made a Bitcoin icon, PDF included]<br />
* [https://bitcointalk.org/index.php?topic=6455.0 In cryptography we trust (yet another Bitcoin icon)]<br />
* [http://bitbash.blogspot.com/2011/04/bitcoin-icons.html Bitcoin icons] from Bitbash<br />
* [http://lts.cr/d8d Bitcoin Graphics] zip<br />
* [http://www.promotionalcodes.org.uk/26970/what-is-bitcoin/ What is Bitcoin? (Infographic)] <br />
* [http://carbonism.deviantart.com/gallery carbonism's deviantART gallery]<br />
* [http://handsomecode.tumblr.com/post/6565610892/designing-a-better-bitcoin-identity Handsome Code Better Bitcoin]<br />
* [https://bitcointalk.org/index.php?topic=32273.0 Public Domain Bitcoin Icons/Graphics for you!]<br />
<br />
[[Category:Marketing]]</div>Tcatmhttps://tests.bitcoin.it/w/index.php?title=Promotional_graphics&diff=24584Promotional graphics2012-03-11T16:53:25Z<p>Tcatm: </p>
<hr />
<div>Bitcoin-related graphics used for promoting bitcoin either for online use, retail display or other promotional purpose.<br />
<br />
==Bitcoin Accepted Here==<br />
[[{{ns:file}}:BC_Rnd_64px.png]]<br />
[[{{ns:file}}:BC 64px.png]]<br />
[[{{ns:file}}:BC nBG 64px.png]]<br />
[[{{ns:file}}:BC RnBG 64px.png]]<br />
<br />
==Logos==<br />
[[{{ns:file}}:BC Logo .png]]<br />
[[{{ns:file}}:BC Logotype.png]]<br />
[[{{ns:file}}:BC Logotype Reverse.png]]<br />
[[{{ns:file}}:Bitcoin euro.png]]<br />
[[{{ns:file}}:bitcoin530.png]]<br />
<br />
==Love Bitcoin Graphics==<br />
[[{{ns:file}}:Lv BCorg 128px.png]]<br />
[[{{ns:file}}:WeLv BC 48px.png]]<br />
[[{{ns:file}}:WeLv BC 128px.png]]<br />
[[{{ns:file}}:WeLv BC Badge 128px.png]]<br />
<br />
==Ƀ Another Bitcoin Identity==<br />
* [[{{ns:file}}:CircleBitcoin.png]] <br />
* [[{{ns:file}}:Pennant.png]]<br />
* [[{{ns:file}}:RibbonDonateBitcoin.png]]<br />
* [[{{ns:file}}:GoldenAcceptedHereBitcoin.png]]<br />
<br />
<br />This graphic elements are available in SVG format on the dedicated [http://www.ecogex.com/bitcoin/ project page].<br />
<br />
==External Links==<br />
<br />
* [https://bitcointalk.org/index.php?topic=38865.0 Set of BTC Icons and Logos]<br />
* [https://bitcointalk.org/index.php?topic=64.msg7415#msg7415 New icon/logo] (SVG of the gold bitcoin / logo)<br />
* [https://bitcointalk.org/index.php?topic=4331.0 Bigger "B" versions of Bitcoin logotypes]<br />
* [https://bitcointalk.org/index.php?topic=9562.20 Ƀ Another Bitcoin identity]<br />
* [https://bitcointalk.org/index.php?topic=1631.0 More Bitcoin logos, buttons, and also some other graphics]<br />
* [https://bitcointalk.org/index.php?topic=45.msg479#msg479 Make your "we accept Bitcoin" logo]<br />
* [http://img340.imageshack.us/img340/7210/onwhitem.jpg Bitcoin Decentralized P2P Currency logo]<br />
* [http://agora.io/wp-content/uploads/2011/03/BitcoinFreeMoney250x100.png Liberty starts with free money logo]<br />
* [https://bitcointalk.org/index.php?topic=6412.0 Made a Bitcoin icon, PDF included]<br />
* [https://bitcointalk.org/index.php?topic=6455.0 In cryptography we trust (yet another Bitcoin icon)]<br />
* [http://bitbash.blogspot.com/2011/04/bitcoin-icons.html Bitcoin icons] from Bitbash<br />
* [http://lts.cr/d8d Bitcoin Graphics] zip<br />
* [http://www.promotionalcodes.org.uk/26970/what-is-bitcoin/ What is Bitcoin? (Infographic)] <br />
* [http://carbonism.deviantart.com/gallery carbonism's deviantART gallery]<br />
* [http://handsomecode.tumblr.com/post/6565610892/designing-a-better-bitcoin-identity Handsome Code Better Bitcoin]<br />
* [https://bitcointalk.org/index.php?topic=32273.0 Public Domain Bitcoin Icons/Graphics for you!]<br />
<br />
[[Category:Marketing]]</div>Tcatmhttps://tests.bitcoin.it/w/index.php?title=Help:FAQ&diff=16644Help:FAQ2011-09-15T07:52:16Z<p>Tcatm: Undo vandalism</p>
<hr />
<div>Here you will find answers to the most commonly asked questions.<br />
<br />
== General ==<br />
=== What are bitcoins? ===<br />
Bitcoins are the unit of currency of the Bitcoin system. A commonly used shorthand for this is “BTC” to refer to a price or amount (eg: “100 BTC”).<br />
There are such things as [[tangible bitcoins]], but ultimately, a bitcoin is just a number associated with a [[Address|Bitcoin Address]]. A tangible bitcoin is simply an object, such as a coin, with the number carefully embedded inside. See also an [[Introduction|easy intro]] to bitcoin.<br />
<br />
=== How can I get Bitcoins? ===<br />
<br />
There are a variety of ways to acquire Bitcoins:<br />
<br />
* Accept Bitcoins as payment for goods or services.<br />
* There are several services where you can [[buying bitcoins|trade them]] for traditional currency.<br />
* Find a local trader on [http://tradebitcoin.com tradebitcoin] (or somewhere else) and trade with him in cash.<br />
* Create a new [[block]] (currently yields 50 Bitcoins).<br />
* Participate in a [[Pooled mining|mining pool]].<br />
<br />
=== Can I buy Bitcoins with Paypal? ===<br />
<br />
While it's possible to find an individual who wishes to sell Bitcoin to you via Paypal, (perhaps via [http://www.bitcoin-otc.com/ #bitcoin-otc] ) most major exchanges do not allow funding through Paypal. This is due to repeated cases where someone pays for Bitcoins with Paypal, receives their Bitcoins, and then fraudulently complains to Paypal that they never received their goods. Paypal too often sides with the fraudulent buyer in this case, and so exchangers no longer allow this method of funding.<br />
<br />
Buying Bitcoins from individuals with this method is still possible, but requires mutual trust. In this case, Bitcoin seller beware.<br />
<br />
=== Where can I find a forum of Bitcoin users? ===<br />
<br />
There is no longer an "official" forum for Bitcoin. The [[Bitcoin:Community_portal#Bitcoin_Community_Forums_on_various_platforms|Community Portal]] includes links to some forums.<br />
<br />
=== How are new Bitcoins created? ===<br />
<br />
[[File:total_bitcoins_over_time_graph.png|thumb|Number of bitcoins over time, assuming a perfect 10-minute interval.]]<br />
New coins are generated by a network node each time it finds the solution to a certain mathematical problem (i.e. creates a new [[block]]), which is difficult to perform and can demonstrate a [[proof of work]]. The reward for solving a block is [[controlled inflation|automatically adjusted]] so that in the first 4 years of the Bitcoin network, 10,500,000 BTC will be created. The amount is halved each 4 years, so it will be 5,250,000 over years 4-8, 2,625,000 over years 8-12 and so on. Thus the total number of coins will approach 21,000,000 BTC over time.<br />
<br />
Blocks should be generated every 10 minutes, on average. As the number of people who attempt to generate these new coins changes, the difficulty of creating new coins changes. This happens in a manner that is agreed upon in advance by the network as a whole, based upon the time taken to generate the previous 2016 blocks. The difficulty is therefore related to the average computing resources devoted to generate these new coins over the time it took to create these previous blocks. The likelihood of somebody creating a block is based on the calculation speed of the system that they are using compared to the aggregate calculation speed of all the other systems generating blocks on the network.<br />
<br />
=== What's the current total number of Bitcoins in existence? ===<br />
<br />
[http://blockexplorer.com/q/totalbc Current count]<br />
<br />
The number of blocks times the coin value of a block is the number of coins in existence. The coin value of a block is 50 BTC for each of the first 210,000 blocks, 25 BTC for the next 210,000 blocks, then 12.5 BTC, 6.25 BTC and so on.<br />
<br />
=== How divisible are Bitcoins? ===<br />
<br />
Technically, a Bitcoin can be divided down to 8 decimals using existing data structures, so 0.00000001 BTC is the smallest amount currently possible. Discussions about and ideas for ways to provide for even smaller quantities of Bitcoins may be created in the future if the need for them ever arises.<br />
<br />
=== What do I call the various denominations of Bitcoins? ===<br />
<br />
There is a lot of discussion about the naming of these fractions of Bitcoins. The leading candidates are:<br />
<br />
* 1 BTC = 1 Bitcoin<br />
* 0.01 BTC = 1 cBTC = 1 Centi-Bitcoin (also referred to as Bitcent)<br />
* 0.001 BTC = 1 mBTC = 1 Milli-Bitcoin (also referred to as mbit (pronounced em-bit) or millibit)<br />
* 0.000 001 BTC = 1 μBTC = 1 Micro-Bitcoin (also referred to as ubit (pronounced yu-bit) or microbit)<br />
<br />
The above follows the accepted international SI units for thousandths, millionths and billionths. There are many arguments against the special case of 0.01 BTC since it is unlikely to represent anything meaningful as the Bitcoin economy grows (it certainly won't be the equivalent of 0.01 USD, GBP or EUR). Equally, the inclusion of existing national currency denominations such as "cent", "nickel", "dime", "pence", "pound", "kopek" and so on are to be discouraged. This is a worldwide currency.<br />
<br />
One exception is the "satoshi" which is smallest denomination currently possible <br />
<br />
* 0.000 000 01 BTC = 1 Satoshi (pronounced sa-toh-shee)<br />
<br />
which is so named in honour of Satoshi Nakamoto the pseudonym of the inventor of Bitcoin.<br />
<br />
For an overview of all defined units of Bitcoin (including less common and niche units), see [[Units]].<br />
<br />
Further discussion on this topic can be found on the forums here:<br />
<br />
* [http://forum.bitcoin.org/index.php?topic=14438.msg195287#msg195287 We need names]<br />
* [http://forum.bitcoin.org/index.php?topic=8282.0 What to call 0.001 BTC]<br />
<br />
=== How does the halving work when the number gets really small? ===<br />
<br />
The reward will go from 0.00000001 BTC to 0. Then no more coins will likely be created. <br />
<br />
The calculation is done as a right bitwise shift of a 64-bit signed integer, which means it is divided by 2 and rounded down. The integer is equal to the value in BTC * 100,000,000. This is how all Bitcoin balances/values are stored internally.<br />
<br />
Keep in mind that using current rules this will take nearly 100 years before it becomes an issue and Bitcoins may change considerably before that happens.<br />
<br />
=== How long will it take to generate all the coins? ===<br />
<br />
The last block that will generate coins will be block #6,929,999. This should be generated around year 2140. Then the total number of coins in circulation will remain static at 20,999,999.9769 BTC.<br />
<br />
Even if the allowed precision is expanded from the current 8 decimals, the total BTC in circulation will always be slightly below 21 million (assuming everything else stays the same). For example, with 16 decimals of precision, the end total would be 20999999.999999999496 BTC.<br />
<br />
=== If no more coins are going to be generated, will more blocks be created? ===<br />
<br />
Absolutely! Even before the creation of coins ends, the use of [[transaction fee|transaction fees]] will likely make creating new blocks more valuable from the fees than the new coins being created. When coin generation ends, what will sustain the ability to use bitcoins will be these fees entirely. There will be blocks generated after block #6,929,999.<br />
<br />
=== But if no more coins are generated, what happens when Bitcoins are lost? Won't that be a problem? ===<br />
<br />
Because of the law of supply and demand, when fewer bitcoins are available the ones that are left will be in higher demand, and therefore will have a higher value. So, as Bitcoins are lost, the remaining bitcoins will increase in value to compensate. As the value of a bitcoin increases, the number of bitcoins required to purchase an item '''de'''creases. This is a [[Deflationary spiral|deflationary economic model]]. As the average transaction size reduces, transactions will probably be denominated in sub-units of a bitcoin such as millibitcoins ("Millies") or microbitcoins ("Mikes").<br />
<br />
The Bitcoin protocol uses a base unit of one hundred-millionth of a Bitcoin ("a Satoshi"), but unused bits are available in the protocol fields that could be used to denote even smaller subdivisions.<br />
<br />
=== If every transaction is broadcast via the network, does Bitcoin scale? ===<br />
The Bitcoin protocol allows lightweight clients that can use Bitcoin without downloading the entire transaction history. As traffic grows and this becomes more critical, implementations of the concept will be developed. Full network nodes will at some point become a more specialized service.<br />
<br />
With some modifications to the software, full Bitcoin nodes could easily keep up with both VISA and MasterCard combined, using only fairly modest hardware (a couple of racks of machines using todays hardware). It's worth noting that the MasterCard network is structured somewhat like Bitcoin itself - as a peer to peer broadcast network.<br />
<br />
Learn more about [[Scalability]].<br />
<br />
==Economy==<br />
=== Where does the value of Bitcoin stem from? What backs up Bitcoin? ===<br />
Bitcoins have value because they are accepted as payment by many. See the [[Trade|list of Bitcoin-accepting sites]].<br />
<br />
When we say that a currency is backed up by gold, we mean that there's a promise in place that you can exchange the currency for gold. In a sense, you could say that Bitcoin is "backed up" by the price tags of merchants – a price tag is a promise to exchange goods for a specified amount of currency.<br />
<br />
It's a common misconception that Bitcoins gain their value from the cost of electricity required to generate them. Cost doesn't equal value – hiring 1,000 men to shovel a big hole in the ground may be costly, but not valuable. Also, even though scarcity is a critical requirement for a useful currency, it alone doesn't make anything valuable. For example, your fingerprints are scarce, but that doesn't mean they have any exchange value.<br />
<br />
=== What if someone bought up all the existing Bitcoins? ===<br />
What if somebody bought up all the gold in the world? Well, by attempting to buy it all, the buyer would just drive the prices up until he runs out of money.<br />
<br />
Not all Bitcoins are for sale. Just as with gold, no one can buy a Bitcoin that isn't available for sale.<br />
<br />
=== Won't Bitcoin's deflationary tendencies cause a deflationary spiral? ===<br />
See the article [[Deflationary spiral]].<br />
<br />
=== Doesn't Bitcoin unfairly benefit early adopters? ===<br />
Early adopters have a large number of bitcoins now because they took a risk and invested resources in an unproven technology. By so doing, they have helped Bitcoin become what it is now and what it will be in the future (hopefully, a ubiquitous decentralized digital currency). It is only fair they will reap the benefits of their successful investment.<br />
<br />
In any case, any bitcoin generated will probably change hands dozens of time as a medium of exchange, so the profit made from the initial distribution will be insignificant compared to the total commerce enabled by Bitcoin.<br />
<br />
=== Is Bitcoin a 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. Early adopters can only profit at the expense of late adopters. Bitcoin has possible win-win outcomes. Early adopters profit from the rise in value. Late adopters profit from the usefulness of a stable and widely accepted p2p currency.<br />
<br />
The fact that early adopters benefit more doesn't alone make anything a ponzi scheme. Apple stocks aren't ponzi even though the early investors got rich.<br />
<br />
=== Is Bitcoin a bubble? ===<br />
Yes, in the same way as the euro and dollar are. They only have value in exchange and no value in use. If everyone suddenly stopped accepting your dollars, euros or bitcoins, the "bubble" would burst and their value would drop to zero. But that is unlikely to happen: even in Somalia, where the government collapsed 20 years ago, [http://en.wikipedia.org/wiki/Somali_shilling Somali shillings] are still accepted as payment.<br />
<br />
==Sending and Receiving Payments==<br />
<br />
=== Why do I have to wait 10 minutes before I can spend money I received? ===<br />
<br />
10 minutes is the average time taken to find a block. It can be significantly more or less time than that depending on luck; 10 minutes is simply the average case. <br />
<br />
Blocks (shown as "confirmations" in the GUI) are how the Bitcoin achieves consensus on who owns what. Once a block is found everyone agrees that you now own those coins, so you can spend them again. Until then it's possible that some network nodes believe otherwise, if somebody is attempting to defraud the system by reversing a transaction. The more confirmations a transaction has, the less risk there is of a reversal. Only 6 blocks or 1 hour is enough to make reversal computationally impractical. This is dramatically better than credit cards which can see chargebacks occur up to three months after the original transaction!<br />
<br />
Why ten minutes specifically? It is a tradeoff chosen by Satoshi between propagation time of new blocks in large networks and the amount of work wasted due to chain splits. If that made no sense to you, don't worry. Reading [http://www.bitcoin.org/bitcoin.pdf the technical paper] should make things clearer.<br />
<br />
=== Do you have to wait 10 minutes in order to buy or sell things with Bitcoin? ===<br />
<br />
No, it's reasonable to sell things without waiting for a confirmation as long as the transaction is not of high value.<br />
<br />
When people ask this question they are usually thinking about applications like supermarkets or snack machines, as discussed in [http://bitcointalk.org/index.php?topic=423.msg3819#msg3819 this thread from July 2010]. Zero confirmation transactions still show up in the GUI, but you cannot spend them. You can however reason about the risk involved in assuming you ''will'' be able to spend them in future. In general, selling things that are fairly cheap (like snacks, digital downloads etc) for zero confirmations will not pose a problem if you are running a well connected node.<br />
<br />
=== I sent some bitcoins and they haven't arrived yet! Where are they? ===<br />
<br />
Don't panic! There are a number of reasons why your bitcoins might not show up yet, and a number of ways to diagnose them. <br />
<br />
First of all, check the current max block count by going [http://blockexplorer.com/q/getblockcount here] and comparing that to the number in the bottom right hand corner of your client. <br />
<br />
If these numbers are different by more than 1 or 2 then you need to wait for your block chain to download. If not, then it's possible that your transaction hasn't been included in a block yet. <br />
<br />
You can check pending transactions in the network by going [http://bitcoincharts.com/bitcoin/ here] and then searching for your address. If the transaction is listed here then it's a matter of waiting until it gets included in a block before it will show in your client. <br />
<br />
Bear in mind that if the transaction is based on a coin that was in a recent transaction then it could be considered a low priority transaction take longer to transfer if the transaction fee paid isn't high enough. Very low priority transactions with 0 fees might take hours or days to be included in a block.<br />
<br />
=== Why does my Bitcoin address keep changing? ===<br />
<br />
Whenever the address listed in "Your address" receives a transaction, Bitcoin replaces it with a new address. This is meant to encourage you to use a new address for every transaction, which enhances [[anonymity]]. All of your old addresses are still usable: you can see them in ''Settings -> Your Receiving Addresses''.<br />
<br />
===How much will the transaction fee be?===<br />
<br />
Some transactions might require a [[transaction fee]] for them to get confirmed in a timely manner. The transaction fee is processed by and received by the bitcoin miner. The most recent version of the Bitcoin client will estimate an appropriate fee when a fee might be required.<br />
<br />
The fee is added to the payment amount. For example, if you are sending a 1.234 BTC payment and the client requires a 0.0005 BTC fee, then 1.2345 BTC will be subtracted from the wallet balance for the entire transaction and the address for where the payment was sent will receive a payment of 1.234 BTC.<br />
<br />
Because the fee is related to the amount of data that makes up the transaction and not to the amount of bitcoins being sent, the fee may seem extremely low (0.0005 BTC for a 1,000 BTC transfer) or unfairly high (0.004 BTC for a 0.02 BTC payment, or about 20%). If you are receiving tiny amounts (e.g., as small payments from a mining pool) then fees when sending will be higher than if your activity follows a more normal consumer or business transaction pattern.<br />
<br />
=== What happens when someone sends me a bitcoin but my computer is powered off? ===<br />
<br />
Bitcoins aren't actually "sent" to your wallet, the software only uses that term so that we can use the currency without having to learn new concepts. Your wallet is only needed when you wish to spend coins that you've received.<br />
<br />
The coins that were sent to you when the client was not running will later appear as if they were received in your wallet when you later launch the client. It will download blocks and catch up with any transactions it didn't already have.<br />
<br />
==Networking==<br />
=== Do I need to configure my firewall to run bitcoin? ===<br />
<br />
Bitcoin will connect to other nodes, usually on tcp port 8333. You will need to allow outgoing TCP connections to port 8333 if you want to allow your bitcoin client to connect to many nodes. Bitcoin will also try to connect to IRC (tcp port 6667) to meet other nodes to connect to. [[Testnet]] uses tcp port 18333 instead of 8333.<br />
<br />
If you want to restrict your firewall rules to a few ips and/or don't want to allow IRC connection, you can find stable nodes in the [[Fallback Nodes|fallback nodes list]]. If your provider blocks the common IRC ports, note that lfnet also listens on port 7777. Connecting to this alternate port currently requires either recompiling Bitcoin, or changing routing rules. For example, on Linux you can evade a port 6667 block by doing something like this:<br />
<br />
echo 173.246.103.92 irc.lfnet.org >> /etc/hosts<br />
iptables -t nat -A OUTPUT -p tcp --dest 173.246.103.92 --dport 6667 -j DNAT --to-destination :7777 -m comment --comment "bitcoind irc connection"<br />
<br />
=== How does the peer finding mechanism work? ===<br />
Bitcoin finds peers primarily by connecting to an IRC server (channel #bitcoin on irc.lfnet.org). If a connection to the IRC server cannot be established (like when connecting through TOR), an in-built node list will be used and the nodes will be queried for more node addresses.<br />
<br />
==Mining==<br />
===What is mining?===<br />
Mining is the process of spending computation power to find valid blocks and thus create new Bitcoins.<br />
<br />
Technically speaking, mining is the calculation of a [[hash]] of the a block header, which includes among other things a reference to the previous block, a hash of a set of transactions and a [[nonce]]. If the hash value is found to be less than the current [[target]] (which is inversely proportional to the [[difficulty]]), a new block is formed and the miner gets the newly generated Bitcoins (50 per block at current levels). If the hash is not less than the current target, a new nonce is tried, and a new hash is calculated. This is done millions of times per second by each miner.<br />
<br />
===Why was the "Generate coin" option of the client software removed?===<br />
<br />
In the early days of Bitcoin, it was easy for anyone to find new blocks using standard CPUs. As more and more people started mining, the [[difficulty]] of finding new blocks has greatly increased to the point where the average time for a CPU to find a single block can be many years. The only cost-effective method of mining is using a high-end graphics card with special software (see also [[Why a GPU mines faster than a CPU]]) and/or joining a [[Bitcoin Pool|mining pool]]. Since solo CPU mining is essentially useless, it was removed from the GUI of the Bitcoin software.<br />
<br />
===Is mining used for some useful computation?===<br />
The computations done when mining are internal to Bitcoin and not related to any other distributed computing projects. They serve the purpose of securing the Bitcoin network, which is useful.<br />
<br />
===Is it not a waste of energy?===<br />
Spending energy on creating a free monetary system is hardly a waste. Also, services necessary for the operation of currently widespread monetary systems, such as banks and credit card companies, also spend energy, arguably more than Bitcoin would.<br />
<br />
===Why don't we use calculations that are also useful for some other purpose?===<br />
To provide security for the Bitcoin network, the calculations involved need to have some very specific features. These features are incompatible with leveraging the computation for other purposes.<br />
<br />
===How does the proof-of-work system help secure Bitcoin?===<br />
To give a general idea of the mining process, imagine this setup:<br />
<br />
payload = <some data related to things happening on the Bitcoin network><br />
nonce = 1<br />
hash = [http://en.wikipedia.org/wiki/SHA2 SHA2]( [http://en.wikipedia.org/wiki/SHA2 SHA2]( payload + nonce ) )<br />
<br />
The work performed by a miner consists of repeatedly increasing "nonce" until<br />
the hash function yields a value, that has the rare property of being below a certain<br />
target threshold. (In other words: The hash "starts with a certain number of zeroes",<br />
if you display it in the fixed-length representation, that is typically used.)<br />
<br />
As can be seen, the mining process doesn't compute anything special. It merely<br />
tries to find a number (also referred to as nonce) which - in combination with the payload -<br />
results in a hash with special properties.<br />
<br />
The advantage of using such a mechanism consists of the fact, that it is very easy to check a result: Given<br />
the payload and a specific nonce, only a single call of the hashing function<br />
is needed to verify that the hash has the required properties. Since there is no<br />
known way to find these hashes other than brute force, this can be used as a "proof of work"<br />
that someone invested a lot of computing power to find the correct nonce for this payload.<br />
<br />
This feature is then used in the Bitcoin network to secure various aspects. An attacker<br />
that wants to introduce malicious payload data into the network, will need to do the<br />
required proof of work before it will be accepted. And as long as honest miners have more<br />
computing power, they can always outpace an attacker.<br />
<br />
Also see [http://en.wikipedia.org/wiki/SHA2 SHA2] and [http://en.wikipedia.org/wiki/Proof-of-work_system Proof-of-work system] on Wikipedia.<br />
<br />
==Help==<br />
===I'd like to learn more. Where can I get help?===<br />
<br />
* Read the [[Introduction|introduction to bitcoin]] <br />
* See the videos, podcasts, and blog posts from the [[Press]]<br />
* Read and post on the [[Bitcoin:Community_portal#Bitcoin_Community_Forums|forums]]<br />
* Chat on one of the [[Bitcoin:Community_portal#IRC_Chat|Bitcoin IRC]] channels<br />
* Listen to [http://omegataupodcast.net/2011/03/59-bitcoin-a-digital-decentralized-currency/ this podcast], which goes into the details of how bitcoin works<br />
* Ask questions on the [http://bitcoin.stackexchange.com Bitcoin Stack Exchange]<br />
<br />
==See Also==<br />
<br />
* [[Man page]]<br />
* [[Introduction]]<br />
<br />
[[de:FAQ]]<br />
[[zh-cn:FAQ]]<br />
[[fr:FAQ]]<br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]</div>Tcatmhttps://tests.bitcoin.it/w/index.php?title=Main_Page&diff=16643Main Page2011-09-15T07:47:12Z<p>Tcatm: Undo revision 16639 by Hong99 (talk)</p>
<hr />
<div>{| id="mp-topbanner" style="width:100%; background:#f6f6f6; margin-top:1.2em; border:1px solid #ddd;"<br />
| style="width:61%; color:#000;" |<br />
<!-- "WELCOME TO BITCOIN" AND ARTICLE COUNT --><br />
{| style="width:100%; border:none; background:none;"<br />
| style="text-align:center; white-space:nowrap; color:#000;" |<br />
<div style="font-size:162%; border:none; margin:0; padding:.1em; color:#000;">Welcome to the [[Bitcoin]] wiki,</div><br />
<div style="top:+0.2em; font-size:95%;">For all your bitcoin information needs.</div><br />
<div id="articlecount" style="width:100%; text-align:center; font-size:85%;">[[Special:Statistics|{{NUMBEROFARTICLES}}]] articles.</div><br />
'''Improve [[:Category:Stubs|this wiki]] and [[Bitcoin:Contributors Award|earn bitcoins]].'''<br />
|}<br />
<!-- PORTAL LIST ON RIGHT-HAND SIDE --><br />
| style="width:13%; font-size:120%;" |<br />
* <span class="plainlinks">[http://bitcoin.org Frontpage]</span><br />
| style="width:13%; font-size:120%;" |<br />
* <span class="plainlinks">[[Forums]]</span><br />
| style="width:13%; font-size:120%; padding-right: 40px;" |<br />
* <span class="plainlinks">[[IRC channels|Chatrooms]]</span><br />
|}<br />
<br />
<!-- TODAY'S FEATURED ARTICLE; DID YOU KNOW --><br />
{| id="mp-upper" style="width: 100%; margin:6px 0 0 0; background:none; border-spacing: 0px;"<br />
| class="MainPageBG" style="width:55%; border:1px solid #cef2e0; background:#f6e5f1; vertical-align:top; color:#000;" |<br />
{| id="mp-left" style="vertical-align:top; background:#f6e5f1;"<br />
! style="padding:2px;" | <h2 id="mp-tfa-h2" style="margin:3px; background:#e9caef; font-size:120%; font-weight:bold; border:1px solid #a3bfb1; text-align:left; color:#000; padding:0.2em 0.4em;">Bitcoin</h2><br />
|-<br />
| style="color:#000;" | <div id="mp-tfa" style="padding:2px 5px">{{MainPage_Intro}}</div><br />
|-<br />
! style="padding:2px" | <h2 id="mp-dyk-h2" style="margin:3px; background:#e9caef; font-size:120%; font-weight:bold; border:1px solid #a3bfb1; text-align:left; color:#000; padding:0.2em 0.4em;">Why</h2><br />
|-<br />
| style="color:#000;padding:2px 5px 5px" | <div id="mp-dyk">{{MainPage_Reasons}}</div><br />
|}<br />
| style="border:1px solid transparent;" |<br />
<!-- IN THE NEWS; ON THIS DAY --><br />
| class="MainPageBG" style="width:45%; border:1px solid #cedff2; background:#f6e5f1; vertical-align:top;"|<br />
{| id="mp-right" style="width:100%; vertical-align:top; background:#f6e5f1;"<br />
! style="padding:2px" | <h2 id="mp-otd-h2" style="margin:3px; background:#efc1e2; font-size:120%; font-weight:bold; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em;">Topic central</h2><br />
|-<br />
| style="color:#000;padding:2px 5px 5px" | <div id="mp-otd">{{MainPage_Topics}}</div><br />
|-<br />
! style="padding:2px" | <h2 id="mp-otd-h2" style="margin:3px; background:#efc1e2; font-size:120%; font-weight:bold; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em;">FAQ</h2><br />
|-<br />
| style="color:#000;padding:2px 5px 5px" | <div id="mp-otd">{{MainPage_FAQ}}</div><br />
|}<br />
|}<br />
<br />
== Other pages ==<br />
<br />
* '''[[mw:Help:Formatting|Help]]''' - Documentation on wiki editing.<br />
* '''[[Bitcoin.it Wiki|About]]''' - Information on this site.<br />
<br />
[[de:Hauptseite]]<br />
[[es:Página Principal]]<br />
[[fr:Accueil]]<br />
[[it:Pagina principale]]<br />
[[pl:Strona główna]]<br />
[[ru:Заглавная страница]]<br />
[[zh-cn:首页]]<br />
<br />
__NOTOC____NOEDITSECTION__</div>Tcatmhttps://tests.bitcoin.it/w/index.php?title=BIP_0020&diff=1813BIP 00202011-01-12T23:30:00Z<p>Tcatm: amount is optional</p>
<hr />
<div>This is about creating a URI scheme for bitcoin.<br />
Previous discussion in the forum http://www.bitcoin.org/smf/index.php?topic=55.0<br />
x-btc specification at [[x-btc]]<br />
<br />
==RFC 3986==<br />
'''the following is taken from wikipedia'''<br />
<br />
Internet standard [http://rfc.net/std0066.html STD 66] (also RFC 3986) defines the generic syntax to be used in all URI schemes. Every URI is defined as consisting of four parts, as follows:<br />
<br />
<code><nowiki><scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]</nowiki></code><br />
<br />
The '''scheme name''' consists of a letter followed by any combination of letters, digits, and the plus ("+"), period ("."), or hyphen ("-") characters; and is terminated by a colon (":").<br />
<br />
The '''hierarchical part''' of the URI is intended to hold identification information hierarchical in nature. Usually this part begins with a double forward slash ("//"), followed by an ''authority'' part and an optional ''path''. <br />
<br />
* The '''authority''' part holds an optional user information part terminated with "@" (e.g. <code><nowiki>username:password@</nowiki></code>), a hostname (i.e. domain name or IP address), and an optional port number preceded by a colon ":".<br />
<br />
* The '''path''' part is a sequence of segments (conceptually similar to directories, though not necessarily representing them) separated by a forward slash ("/"). Each segment can contain parameters separated from it using a semicolon (";"), though this is rarely used in practice.<br />
<br />
The '''query''' is an optional part separated with a question mark, which contains additional identification information which is not hierarchical in nature. The query string syntax is not generically defined, but is commonly organized as a sequence of <code><nowiki><key>=<value></nowiki></code> pairs separated by a semicolon<ref><br />
RFC 1866 section 8.2.1 : by Tim Berners-Lee in 1995 encourages CGI authors to support ';' in addition to '&'.<br />
</ref><ref><br />
[http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.2.2 HTML 4.01 Specification: Implementation, and Design Notes]: "CGI implementors support the use of ";" in place of "&" to save authors the trouble of escaping "&" characters in this manner."<br />
</ref><ref><br />
[http://www.w3.org/MarkUp/html-spec/html-spec_foot.html#FOOT26 Hypertext Markup Language - 2.0]<br />
"CGI implementors are encouraged to support the use of ';' in place of '&' " <br />
</ref> or separated by an ampersand, for example:<br />
Semicolon: <code><nowiki>key1=value1;key2=value2;key3=value3</nowiki></code><br />
Ampersand: <code><nowiki>key1=value1&key2=value2&key3=value3</nowiki></code><br />
<br />
The '''fragment''' is an optional part separated from the front parts by a hash ("#"). It holds additional identifying information that provides direction to a secondary resource, e.g. a section heading in an article identified by the remainder of the URI. When the primary resource is an HTML document, the '''fragment''' is often an <code>id</code> attribute of a specific element and web browsers will make sure this element is visible.<br />
<br />
==tcatm, modified by LukeJr==<br />
<br />
I propose a scheme like this:<br />
<br />
[] means optional, <> are placeholders<br />
<br />
bitcoin:<address>[?amount=<size>][&label=<label>][&message=<message>]<br />
<br />
=== Variables ===<br />
<br />
*label: Label for that address (e.g. name of receiver)<br />
*address: bitcoin address<br />
*message: optional message that is shown to the user after scanning the QR code<br />
*size: amount of base bitcoin units (uBTCents/TBCᵇ-- NOT full DecimalBitCoins/BTC); this number can be prefixed with the letter "x" to signify a hexadecimal number; it can be appended with "X" <digits> to signify an exponent to the base multiplier (that is, 'X8' moves your number 8 positional places to the left-- if specifying decimal units (without an "x" prefix), this means the standard BTC unit; if specifying hexadecimal units (with an "x" prefix), this means ᵇTBC units). If exponent is omitted, X8 is assumet. I.e. amount=50.00 is 50 BTC. Use X0 to specify bitcoin base units.<br />
<br />
=== Examples ===<br />
<br />
Just the address:<br />
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo<br />
<br />
Address with name:<br />
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?label=Luke-Jr<br />
<br />
Request to send 20.30 BTC to Luke-Jr:<br />
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=20.3X8&label=Luke-Jr<br />
<br />
Request to send 400 TBC to Luke:<br />
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=x400X4<br />
<br />
Request to send 5 uBTC:<br />
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=500<br />
<br />
Request to send 50 BTC with message:<br />
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=5X9&label=Luke-Jr&message=Donation%20for%20project%20xyz<br />
<br />
Characters must be URI encoded properly.<br />
<br />
=== BNF syntax ===<br />
<br />
bitcoinurn = "bitcoin:" bitcoinaddress [ ";version=" bitcoinversion ] [ "?" bitcoinparams ]<br />
bitcoinaddress = FIXME :)<br />
bitcoinversion = "1.0"<br />
bitcoinparams = *bitcoinparam<br />
bitcoinparam = amountparam | labelparam | messageparam<br />
amountparam = "amount=" amount<br />
amount = amountdecimal | amounthex<br />
amountdecimal = digits [ "X" digits ]<br />
amounthex = "x" hexdigits [ "X" hexdigits ]<br />
labelparam = "label=" *uchar<br />
messageparam = "label=" *uchar<br />
<br />
=== Parsing amount ===<br />
==== ECMAScript ====<br />
reAmount = /^(([\d.]+)(X(\d+))?|x([\da-f]*)(\.([\da-f]*))?(X([\da-f]+))?)$/i;<br />
function parseAmount(txt) {<br />
var m = txt.match(reAmount);<br />
return m[5] ? (<br />
(<br />
parseInt(m[5], 16) +<br />
(m[7] ? (parseInt(m[7], 16) * Math.pow(16, -(m[7].length))) : 0)<br />
) * (<br />
m[9] ? Math.pow(16, parseInt(m[9], 16)) : 1e8<br />
)<br />
) : (<br />
m[2]<br />
*<br />
(m[4] ? Math.pow(10, m[4]) : 1e8)<br />
);<br />
}<br />
<br />
=== Criticism ===<br />
<br />
==marcusaurelius==<br />
<br />
===Payment identifiers, not person identifiers===<br />
in my opinion, the most basic idea of the URI scheme (as this is a currency) is to facilitate payment. so the URIs should represent first and foremost payments. if it represents something else, this needs to be specified. Thus<br />
<code><br />
bitcoin:13guMzcGPvdD3qjQvCoNc1w5XAgJ638KaQ<br />
</code><br />
represent a '''payment''' to me using my bitcoin adress, not my bitcoin adress itself. So after parsing the URI (via link/qr/whatever) the application should open a transaction window with the adress filled in. you then need to add an amount and confirm the payment.<br />
If your application is smart, it will also have a button "just store the adress". But the point i am trying to make, is that the default use of the URI should be for payment, nor for exchanging adresses.<br />
<br />
===Accessibility===<br />
'''imported from the forum:''' I like the simplicity of bitcoin:xxxxxxxxxxxxx plus very much approve of its accessibility. Should someone from the outside happen to see such a uri, the protocol name already gives a description. A quick google search should then do the rest. x-btc sounds much more cryptic, the chance that s/1 gooogles that out of curiosity are much slimmer. Also, very likely, what s/he will find are mostly technical specifications. Not a good introduction to bitcoin.<br />
<br />
for the same reason i am for using '&' as a delimiter for key-value-pairs. people know it from urls. make it easy for people to understand what is going on.<br />
<br />
===Keep it simple===<br />
don't explicitly write down information that can be inferred. don't mark the address as an address. if there is no address, this does lose much of its utility. we could, however, specify 'address' as a reserved word, so that <code><br />
bitcoin:address?amount=50<br />
</code><br />
would initiate a transaction with the amount filled in, but with a blank address. I am not convinced that there is a use case, though.<br />
<br />
===Use-cases===<br />
before the URI scheme is finalised one should think long and hard about use-cases. in what circumstances will who use this for what?<br />
* an online shop has a 'buy this'-link, which uses the URI scheme. <br />
**PROBLEM: click on the link opens the application. how does the merchant notice this.<br />
***POSSIBLE SOLUTION: javascript can detect the click.<br />
***POSSIBLE SOLUTION: the checkout site checks its bitcoin account for payment via httprequest <br />
**PROBLEM: the time problem (~10minutes) is very apparent here. nobody wants to wait 10minutes for the transaction to be confirmed.<br />
* a person only has an online client, no actual application<br />
**PROBLEM: how to redirect the URI, so that the online client gets a notice?<br />
<br />
===Backwards compatibility===<br />
we want URIs generated in 2011 to still work in 2036. think about extensibility. of course we can make only educated guesses (and nothing more!) about the future, but don't act as if there is none. this should be the best we can do, but it should not be seen as forever set in stone. make it possible for later generations to improve our work, to mend our errors, without breaking the URIs created now. Version incompatibility is the easiest thing to drive users crazy: "i now upgraded to this shiny new version. what? it doesn't support the old format? AAAAAAARRRGH!"<br />
<br />
==References==<br />
<references/></div>Tcatmhttps://tests.bitcoin.it/w/index.php?title=BIP_0020&diff=1809BIP 00202011-01-12T23:21:45Z<p>Tcatm: moved Schema to URI Scheme</p>
<hr />
<div>This is about creating a URI scheme for bitcoin.<br />
Previous discussion in the forum http://www.bitcoin.org/smf/index.php?topic=55.0<br />
x-btc specification at [[x-btc]]<br />
<br />
==RFC 3986==<br />
'''the following is taken from wikipedia'''<br />
<br />
Internet standard [http://rfc.net/std0066.html STD 66] (also RFC 3986) defines the generic syntax to be used in all URI schemes. Every URI is defined as consisting of four parts, as follows:<br />
<br />
<code><nowiki><scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]</nowiki></code><br />
<br />
The '''scheme name''' consists of a letter followed by any combination of letters, digits, and the plus ("+"), period ("."), or hyphen ("-") characters; and is terminated by a colon (":").<br />
<br />
The '''hierarchical part''' of the URI is intended to hold identification information hierarchical in nature. Usually this part begins with a double forward slash ("//"), followed by an ''authority'' part and an optional ''path''. <br />
<br />
* The '''authority''' part holds an optional user information part terminated with "@" (e.g. <code><nowiki>username:password@</nowiki></code>), a hostname (i.e. domain name or IP address), and an optional port number preceded by a colon ":".<br />
<br />
* The '''path''' part is a sequence of segments (conceptually similar to directories, though not necessarily representing them) separated by a forward slash ("/"). Each segment can contain parameters separated from it using a semicolon (";"), though this is rarely used in practice.<br />
<br />
The '''query''' is an optional part separated with a question mark, which contains additional identification information which is not hierarchical in nature. The query string syntax is not generically defined, but is commonly organized as a sequence of <code><nowiki><key>=<value></nowiki></code> pairs separated by a semicolon<ref><br />
RFC 1866 section 8.2.1 : by Tim Berners-Lee in 1995 encourages CGI authors to support ';' in addition to '&'.<br />
</ref><ref><br />
[http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.2.2 HTML 4.01 Specification: Implementation, and Design Notes]: "CGI implementors support the use of ";" in place of "&" to save authors the trouble of escaping "&" characters in this manner."<br />
</ref><ref><br />
[http://www.w3.org/MarkUp/html-spec/html-spec_foot.html#FOOT26 Hypertext Markup Language - 2.0]<br />
"CGI implementors are encouraged to support the use of ';' in place of '&' " <br />
</ref> or separated by an ampersand, for example:<br />
Semicolon: <code><nowiki>key1=value1;key2=value2;key3=value3</nowiki></code><br />
Ampersand: <code><nowiki>key1=value1&key2=value2&key3=value3</nowiki></code><br />
<br />
The '''fragment''' is an optional part separated from the front parts by a hash ("#"). It holds additional identifying information that provides direction to a secondary resource, e.g. a section heading in an article identified by the remainder of the URI. When the primary resource is an HTML document, the '''fragment''' is often an <code>id</code> attribute of a specific element and web browsers will make sure this element is visible.<br />
<br />
==tcatm, modified by LukeJr==<br />
<br />
I propose a scheme like this:<br />
<br />
[] means optional, <> are placeholders<br />
<br />
bitcoin:<address>?amount=<size>[&label=<label>][&message=<message>]<br />
<br />
=== Variables ===<br />
<br />
*label: Label for that address (e.g. name of receiver)<br />
*address: bitcoin address<br />
*message: optional message that is shown to the user after scanning the QR code<br />
*size: amount of base bitcoin units (uBTCents/TBCᵇ-- NOT full DecimalBitCoins/BTC); this number can be prefixed with the letter "x" to signify a hexadecimal number; it can be appended with "X" <digits> to signify an exponent to the base multiplier (that is, 'X8' moves your number 8 positional places to the left-- if specifying decimal units (without an "x" prefix), this means the standard BTC unit; if specifying hexadecimal units (with an "x" prefix), this means ᵇTBC units). If exponent is omitted, X8 is assumet. I.e. amount=50.00 is 50 BTC. Use X0 to specify bitcoin base units.<br />
<br />
=== Examples ===<br />
<br />
Just the address:<br />
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo<br />
<br />
Address with name:<br />
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?label=Luke-Jr<br />
<br />
Request to send 20.30 BTC to Luke-Jr:<br />
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=20.3X8&label=Luke-Jr<br />
<br />
Request to send 400 TBC to Luke:<br />
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=x400X4<br />
<br />
Request to send 5 uBTC:<br />
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=500<br />
<br />
Request to send 50 BTC with message:<br />
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=5X9&label=Luke-Jr&message=Donation%20for%20project%20xyz<br />
<br />
Characters must be URI encoded properly.<br />
<br />
=== BNF syntax ===<br />
<br />
bitcoinurn = "bitcoin:" bitcoinaddress [ ";version=" bitcoinversion ] [ "?" bitcoinparams ]<br />
bitcoinaddress = FIXME :)<br />
bitcoinversion = "1.0"<br />
bitcoinparams = *bitcoinparam<br />
bitcoinparam = amountparam | labelparam | messageparam<br />
amountparam = "amount=" amount<br />
amount = amountdecimal | amounthex<br />
amountdecimal = digits [ "X" digits ]<br />
amounthex = "x" hexdigits [ "X" hexdigits ]<br />
labelparam = "label=" *uchar<br />
messageparam = "label=" *uchar<br />
<br />
=== Parsing amount ===<br />
==== ECMAScript ====<br />
reAmount = /^(([\d.]+)(X(\d+))?|x([\da-f]*)(\.([\da-f]*))?(X([\da-f]+))?)$/i;<br />
function parseAmount(txt) {<br />
var m = txt.match(reAmount);<br />
return m[5] ? (<br />
(<br />
parseInt(m[5], 16) +<br />
(m[7] ? (parseInt(m[7], 16) * Math.pow(16, -(m[7].length))) : 0)<br />
) * (<br />
m[9] ? Math.pow(16, parseInt(m[9], 16)) : 1e8<br />
)<br />
) : (<br />
m[2]<br />
*<br />
(m[4] ? Math.pow(10, m[4]) : 1e8)<br />
);<br />
}<br />
<br />
=== Criticism ===<br />
<br />
==marcusaurelius==<br />
<br />
===Payment identifiers, not person identifiers===<br />
in my opinion, the most basic idea of the URI scheme (as this is a currency) is to facilitate payment. so the URIs should represent first and foremost payments. if it represents something else, this needs to be specified. Thus<br />
<code><br />
bitcoin:13guMzcGPvdD3qjQvCoNc1w5XAgJ638KaQ<br />
</code><br />
represent a '''payment''' to me using my bitcoin adress, not my bitcoin adress itself. So after parsing the URI (via link/qr/whatever) the application should open a transaction window with the adress filled in. you then need to add an amount and confirm the payment.<br />
If your application is smart, it will also have a button "just store the adress". But the point i am trying to make, is that the default use of the URI should be for payment, nor for exchanging adresses.<br />
<br />
===Accessibility===<br />
'''imported from the forum:''' I like the simplicity of bitcoin:xxxxxxxxxxxxx plus very much approve of its accessibility. Should someone from the outside happen to see such a uri, the protocol name already gives a description. A quick google search should then do the rest. x-btc sounds much more cryptic, the chance that s/1 gooogles that out of curiosity are much slimmer. Also, very likely, what s/he will find are mostly technical specifications. Not a good introduction to bitcoin.<br />
<br />
for the same reason i am for using '&' as a delimiter for key-value-pairs. people know it from urls. make it easy for people to understand what is going on.<br />
<br />
===Keep it simple===<br />
don't explicitly write down information that can be inferred. don't mark the address as an address. if there is no address, this does lose much of its utility. we could, however, specify 'address' as a reserved word, so that <code><br />
bitcoin:address?amount=50<br />
</code><br />
would initiate a transaction with the amount filled in, but with a blank address. I am not convinced that there is a use case, though.<br />
<br />
===Use-cases===<br />
before the URI scheme is finalised one should think long and hard about use-cases. in what circumstances will who use this for what?<br />
* an online shop has a 'buy this'-link, which uses the URI scheme. <br />
**PROBLEM: click on the link opens the application. how does the merchant notice this.<br />
***POSSIBLE SOLUTION: javascript can detect the click.<br />
***POSSIBLE SOLUTION: the checkout site checks its bitcoin account for payment via httprequest <br />
**PROBLEM: the time problem (~10minutes) is very apparent here. nobody wants to wait 10minutes for the transaction to be confirmed.<br />
* a person only has an online client, no actual application<br />
**PROBLEM: how to redirect the URI, so that the online client gets a notice?<br />
<br />
===Backwards compatibility===<br />
we want URIs generated in 2011 to still work in 2036. think about extensibility. of course we can make only educated guesses (and nothing more!) about the future, but don't act as if there is none. this should be the best we can do, but it should not be seen as forever set in stone. make it possible for later generations to improve our work, to mend our errors, without breaking the URIs created now. Version incompatibility is the easiest thing to drive users crazy: "i now upgraded to this shiny new version. what? it doesn't support the old format? AAAAAAARRRGH!"<br />
<br />
==References==<br />
<references/></div>Tcatmhttps://tests.bitcoin.it/w/index.php?title=Schema&diff=1810Schema2011-01-12T23:21:45Z<p>Tcatm: moved Schema to URI Scheme</p>
<hr />
<div>#REDIRECT [[URI Scheme]]</div>Tcatmhttps://tests.bitcoin.it/w/index.php?title=Talk:BIP_0020&diff=1811Talk:BIP 00202011-01-12T23:21:45Z<p>Tcatm: moved Talk:Schema to Talk:URI Scheme</p>
<hr />
<div>See [[Talk:Main_Page#Header_capitalisation]] before continuing ;) [[User:Genjix|Genjix]] 08:02, 10 January 2011 (GMT)<br />
<br />
Also, consider using SI prefixes. They are standard throughout the world (except America). [[User:Genjix|Genjix]] 08:04, 10 January 2011 (GMT)<br />
* SI/decimal is the inferior competition/enemy of the superior Tonal system. That is, to be avoided. (Chinese is a standard language throughout most of the world too! And whatever the currency of China is-- should we not use bitcoins??) [[User:Luke-jr|Luke-jr]] 15:05, 10 January 2011 (GMT)<br />
<br />
Can someone fix the name of the page? It's "Scheme", not "Schema". [[User:Luke-jr|Luke-jr]] 15:35, 10 January 2011 (GMT)<br />
: maybe even "URI scheme" to be more precise? since there can be many differenct schemes about stuff. :) --[[User:Nanotube|Nanotube]] 05:48, 12 January 2011 (GMT)</div>Tcatmhttps://tests.bitcoin.it/w/index.php?title=Talk:Schema&diff=1812Talk:Schema2011-01-12T23:21:45Z<p>Tcatm: moved Talk:Schema to Talk:URI Scheme</p>
<hr />
<div>#REDIRECT [[Talk:URI Scheme]]</div>Tcatmhttps://tests.bitcoin.it/w/index.php?title=BIP_0020&diff=1793BIP 00202011-01-12T21:21:41Z<p>Tcatm: modified to use exponent 8 by default</p>
<hr />
<div>This is about creating a URI scheme for bitcoin.<br />
Previous discussion in the forum http://www.bitcoin.org/smf/index.php?topic=55.0<br />
x-btc specification at [[x-btc]]<br />
<br />
==RFC 3986==<br />
'''the following is taken from wikipedia'''<br />
<br />
Internet standard [http://rfc.net/std0066.html STD 66] (also RFC 3986) defines the generic syntax to be used in all URI schemes. Every URI is defined as consisting of four parts, as follows:<br />
<br />
<code><nowiki><scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]</nowiki></code><br />
<br />
The '''scheme name''' consists of a letter followed by any combination of letters, digits, and the plus ("+"), period ("."), or hyphen ("-") characters; and is terminated by a colon (":").<br />
<br />
The '''hierarchical part''' of the URI is intended to hold identification information hierarchical in nature. Usually this part begins with a double forward slash ("//"), followed by an ''authority'' part and an optional ''path''. <br />
<br />
* The '''authority''' part holds an optional user information part terminated with "@" (e.g. <code><nowiki>username:password@</nowiki></code>), a hostname (i.e. domain name or IP address), and an optional port number preceded by a colon ":".<br />
<br />
* The '''path''' part is a sequence of segments (conceptually similar to directories, though not necessarily representing them) separated by a forward slash ("/"). Each segment can contain parameters separated from it using a semicolon (";"), though this is rarely used in practice.<br />
<br />
The '''query''' is an optional part separated with a question mark, which contains additional identification information which is not hierarchical in nature. The query string syntax is not generically defined, but is commonly organized as a sequence of <code><nowiki><key>=<value></nowiki></code> pairs separated by a semicolon<ref><br />
RFC 1866 section 8.2.1 : by Tim Berners-Lee in 1995 encourages CGI authors to support ';' in addition to '&'.<br />
</ref><ref><br />
[http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.2.2 HTML 4.01 Specification: Implementation, and Design Notes]: "CGI implementors support the use of ";" in place of "&" to save authors the trouble of escaping "&" characters in this manner."<br />
</ref><ref><br />
[http://www.w3.org/MarkUp/html-spec/html-spec_foot.html#FOOT26 Hypertext Markup Language - 2.0]<br />
"CGI implementors are encouraged to support the use of ';' in place of '&' " <br />
</ref> or separated by an ampersand, for example:<br />
Semicolon: <code><nowiki>key1=value1;key2=value2;key3=value3</nowiki></code><br />
Ampersand: <code><nowiki>key1=value1&key2=value2&key3=value3</nowiki></code><br />
<br />
The '''fragment''' is an optional part separated from the front parts by a hash ("#"). It holds additional identifying information that provides direction to a secondary resource, e.g. a section heading in an article identified by the remainder of the URI. When the primary resource is an HTML document, the '''fragment''' is often an <code>id</code> attribute of a specific element and web browsers will make sure this element is visible.<br />
<br />
==tcatm, modified by LukeJr==<br />
<br />
I propose a scheme like this:<br />
<br />
[] means optional, <> are placeholders<br />
<br />
bitcoin:<address>?amount=<size>[&label=<label>][&message=<message>]<br />
<br />
=== Variables ===<br />
<br />
*label: Label for that address (e.g. name of receiver)<br />
*address: bitcoin address<br />
*message: optional message that is shown to the user after scanning the QR code<br />
*size: amount of base bitcoin units (uBTCents/TBCᵇ-- NOT full DecimalBitCoins/BTC); this number can be prefixed with the letter "x" to signify a hexadecimal number; it can be appended with "X" <digits> to signify an exponent to the base multiplier (that is, 'X8' moves your number 8 positional places to the left-- if specifying decimal units (without an "x" prefix), this means the standard BTC unit; if specifying hexadecimal units (with an "x" prefix), this means ᵇTBC units). If exponent is omitted, X8 is assumet. I.e. amount=50.00 is 50 BTC. Use X0 to specify bitcoin base units.<br />
<br />
=== Examples ===<br />
<br />
Just the address:<br />
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo<br />
<br />
Address with name:<br />
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?label=Luke-Jr<br />
<br />
Request to send 20.30 BTC to Luke-Jr:<br />
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=20.3X8&label=Luke-Jr<br />
<br />
Request to send 400 TBC to Luke:<br />
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=x400X4<br />
<br />
Request to send 5 uBTC:<br />
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=500<br />
<br />
Request to send 50 BTC with message:<br />
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=5X9&label=Luke-Jr&message=Donation%20for%20project%20xyz<br />
<br />
Characters must be URI encoded properly.<br />
<br />
=== BNF syntax ===<br />
<br />
bitcoinurn = "bitcoin:" bitcoinaddress [ ";version=" bitcoinversion ] [ "?" bitcoinparams ]<br />
bitcoinaddress = FIXME :)<br />
bitcoinversion = "1.0"<br />
bitcoinparams = *bitcoinparam<br />
bitcoinparam = amountparam | labelparam | messageparam<br />
amountparam = "amount=" amount<br />
amount = amountdecimal | amounthex<br />
amountdecimal = digits [ "X" digits ]<br />
amounthex = "x" hexdigits [ "X" hexdigits ]<br />
labelparam = "label=" *uchar<br />
messageparam = "label=" *uchar<br />
<br />
=== Parsing Amount ===<br />
==== ECMAScript ====<br />
reAmount = /^(([\d.]+)(X(\d+))?|x([\da-f]*)(\.([\da-f]*))?(X([\da-f]+))?)$/i;<br />
function parseAmount(txt) {<br />
var m = txt.match(reAmount);<br />
return m[5] ? (<br />
(<br />
parseInt(m[5], 16) +<br />
(m[7] ? (parseInt(m[7], 16) * Math.pow(16, -(m[7].length))) : 0)<br />
) * (<br />
m[9] ? Math.pow(16, parseInt(m[9], 16)) : 1e8<br />
)<br />
) : (<br />
m[2]<br />
*<br />
(m[4] ? Math.pow(10, m[4]) : 1e8)<br />
);<br />
}<br />
<br />
=== Criticism ===<br />
<br />
==marcusaurelius==<br />
<br />
===payment identifiers, not person identifiers===<br />
in my opinion, the most basic idea of the URI scheme (as this is a currency) is to facilitate payment. so the URIs should represent first and foremost payments. if it represents something else, this needs to be specified. Thus<br />
<code><br />
bitcoin:13guMzcGPvdD3qjQvCoNc1w5XAgJ638KaQ<br />
</code><br />
represent a '''payment''' to me using my bitcoin adress, not my bitcoin adress itself. So after parsing the URI (via link/qr/whatever) the application should open a transaction window with the adress filled in. you then need to add an amount and confirm the payment.<br />
If your application is smart, it will also have a button "just store the adress". But the point i am trying to make, is that the default use of the URI should be for payment, nor for exchanging adresses.<br />
<br />
===accessibility===<br />
'''imported from the forum:''' I like the simplicity of bitcoin:xxxxxxxxxxxxx plus very much approve of its accessibility. Should someone from the outside happen to see such a uri, the protocol name already gives a description. A quick google search should then do the rest. x-btc sounds much more cryptic, the chance that s/1 gooogles that out of curiosity are much slimmer. Also, very likely, what s/he will find are mostly technical specifications. Not a good introduction to bitcoin.<br />
<br />
for the same reason i am for using '&' as a delimiter for key-value-pairs. people know it from urls. make it easy for people to understand what is going on.<br />
<br />
===keep it simple===<br />
don't explicitly write down information that can be inferred. don't mark the address as an address. if there is no address, this does lose much of its utility. we could, however, specify 'address' as a reserved word, so that <code><br />
bitcoin:address?amount=50<br />
</code><br />
would initiate a transaction with the amount filled in, but with a blank address. I am not convinced that there is a use case, though.<br />
<br />
===use-cases===<br />
before the URI scheme is finalised one should think long and hard about use-cases. in what circumstances will who use this for what?<br />
* an online shop has a 'buy this'-link, which uses the URI scheme. <br />
**PROBLEM: click on the link opens the application. how does the merchant notice this.<br />
***POSSIBLE SOLUTION: javascript can detect the click.<br />
***POSSIBLE SOLUTION: the checkout site checks its bitcoin account for payment via httprequest <br />
**PROBLEM: the time problem (~10minutes) is very apparent here. nobody wants to wait 10minutes for the transaction to be confirmed.<br />
* a person only has an online client, no actual application<br />
**PROBLEM: how to redirect the URI, so that the online client gets a notice?<br />
<br />
===backwards-compatibility===<br />
we want URIs generated in 2011 to still work in 2036. think about extensibility. of course we can make only educated guesses (and nothing more!) about the future, but don't act as if there is none. this should be the best we can do, but it should not be seen as forever set in stone. make it possible for later generations to improve our work, to mend our errors, without breaking the URIs created now. Version incompatibility is the easiest thing to drive users crazy: "i now upgraded to this shiny new version. what? it doesn't support the old format? AAAAAAARRRGH!"<br />
<br />
==References==<br />
<references/></div>Tcatmhttps://tests.bitcoin.it/w/index.php?title=BIP_0020&diff=1791BIP 00202011-01-12T20:39:46Z<p>Tcatm: removed my scheme proposal, as I won't use it anyway</p>
<hr />
<div>This is about creating a URI scheme for bitcoin.<br />
Previous discussion in the forum http://www.bitcoin.org/smf/index.php?topic=55.0<br />
x-btc specification at [[x-btc]]<br />
<br />
==RFC 3986==<br />
'''the following is taken from wikipedia'''<br />
<br />
Internet standard [http://rfc.net/std0066.html STD 66] (also RFC 3986) defines the generic syntax to be used in all URI schemes. Every URI is defined as consisting of four parts, as follows:<br />
<br />
<code><nowiki><scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]</nowiki></code><br />
<br />
The '''scheme name''' consists of a letter followed by any combination of letters, digits, and the plus ("+"), period ("."), or hyphen ("-") characters; and is terminated by a colon (":").<br />
<br />
The '''hierarchical part''' of the URI is intended to hold identification information hierarchical in nature. Usually this part begins with a double forward slash ("//"), followed by an ''authority'' part and an optional ''path''. <br />
<br />
* The '''authority''' part holds an optional user information part terminated with "@" (e.g. <code><nowiki>username:password@</nowiki></code>), a hostname (i.e. domain name or IP address), and an optional port number preceded by a colon ":".<br />
<br />
* The '''path''' part is a sequence of segments (conceptually similar to directories, though not necessarily representing them) separated by a forward slash ("/"). Each segment can contain parameters separated from it using a semicolon (";"), though this is rarely used in practice.<br />
<br />
The '''query''' is an optional part separated with a question mark, which contains additional identification information which is not hierarchical in nature. The query string syntax is not generically defined, but is commonly organized as a sequence of <code><nowiki><key>=<value></nowiki></code> pairs separated by a semicolon<ref><br />
RFC 1866 section 8.2.1 : by Tim Berners-Lee in 1995 encourages CGI authors to support ';' in addition to '&'.<br />
</ref><ref><br />
[http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.2.2 HTML 4.01 Specification: Implementation, and Design Notes]: "CGI implementors support the use of ";" in place of "&" to save authors the trouble of escaping "&" characters in this manner."<br />
</ref><ref><br />
[http://www.w3.org/MarkUp/html-spec/html-spec_foot.html#FOOT26 Hypertext Markup Language - 2.0]<br />
"CGI implementors are encouraged to support the use of ';' in place of '&' " <br />
</ref> or separated by an ampersand, for example:<br />
Semicolon: <code><nowiki>key1=value1;key2=value2;key3=value3</nowiki></code><br />
Ampersand: <code><nowiki>key1=value1&key2=value2&key3=value3</nowiki></code><br />
<br />
The '''fragment''' is an optional part separated from the front parts by a hash ("#"). It holds additional identifying information that provides direction to a secondary resource, e.g. a section heading in an article identified by the remainder of the URI. When the primary resource is an HTML document, the '''fragment''' is often an <code>id</code> attribute of a specific element and web browsers will make sure this element is visible.<br />
<br />
==tcatm, modified by LukeJr==<br />
<br />
I propose a scheme like this:<br />
<br />
[] means optional, <> are placeholders<br />
<br />
bitcoin:<address>?amount=<size>[&label=<label>][&message=<message>]<br />
<br />
=== Variables ===<br />
<br />
*label: Label for that address (e.g. name of receiver)<br />
*address: bitcoin address<br />
*message: optional message that is shown to the user after scanning the QR code<br />
*size: amount of base bitcoin units (uBTCents/TBCᵇ-- NOT full DecimalBitCoins/BTC); this number can be prefixed with the letter "x" to signify a hexadecimal number; it can be appended with "X" <digits> to signify an exponent to the base multiplier (that is, 'X8' moves your number 8 positional places to the left-- if specifying decimal units (without an "x" prefix), this means the standard BTC unit; if specifying hexadecimal units (with an "x" prefix), this means ᵇTBC units)<br />
<br />
=== Examples ===<br />
<br />
Just the address:<br />
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo<br />
<br />
Address with name:<br />
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?label=Luke-Jr<br />
<br />
Request to send 20.30 BTC to Luke-Jr:<br />
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=20.3X8&label=Luke-Jr<br />
<br />
Request to send 400 TBC to Luke:<br />
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=x400X4<br />
<br />
Request to send 5 uBTC:<br />
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=500<br />
<br />
Request to send 50 BTC with message:<br />
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=5X9&label=Luke-Jr&message=Donation%20for%20project%20xyz<br />
<br />
Characters must be URI encoded properly.<br />
<br />
=== BNF syntax ===<br />
<br />
bitcoinurn = "bitcoin:" bitcoinaddress [ ";version=" bitcoinversion ] [ "?" bitcoinparams ]<br />
bitcoinaddress = FIXME :)<br />
bitcoinversion = "1.0"<br />
bitcoinparams = *bitcoinparam<br />
bitcoinparam = amountparam | labelparam | messageparam<br />
amountparam = "amount=" amount<br />
amount = amountdecimal | amounthex<br />
amountdecimal = digits [ "X" digits ]<br />
amounthex = "x" hexdigits [ "X" hexdigits ]<br />
labelparam = "label=" *uchar<br />
messageparam = "label=" *uchar<br />
<br />
=== Parsing Amount ===<br />
==== ECMAScript ====<br />
reAmount = /^(([\d.]+)(X(\d+))?|x([\da-f]*)(\.([\da-f]*))?(X([\da-f]+))?)$/i;<br />
function parseAmount(txt) {<br />
var m = txt.match(reAmount);<br />
return m[5] ? (<br />
(<br />
parseInt(m[5], 16) +<br />
(m[7] ? (parseInt(m[7], 16) * Math.pow(16, -(m[7].length))) : 0)<br />
) * (<br />
m[9] ? Math.pow(16, parseInt(m[9], 16)) : 1<br />
)<br />
) : (<br />
m[2]<br />
*<br />
(m[4] ? Math.pow(10, m[4]) : 1)<br />
);<br />
}<br />
<br />
=== Criticism ===<br />
<br />
==marcusaurelius==<br />
<br />
===payment identifiers, not person identifiers===<br />
in my opinion, the most basic idea of the URI scheme (as this is a currency) is to facilitate payment. so the URIs should represent first and foremost payments. if it represents something else, this needs to be specified. Thus<br />
<code><br />
bitcoin:13guMzcGPvdD3qjQvCoNc1w5XAgJ638KaQ<br />
</code><br />
represent a '''payment''' to me using my bitcoin adress, not my bitcoin adress itself. So after parsing the URI (via link/qr/whatever) the application should open a transaction window with the adress filled in. you then need to add an amount and confirm the payment.<br />
If your application is smart, it will also have a button "just store the adress". But the point i am trying to make, is that the default use of the URI should be for payment, nor for exchanging adresses.<br />
<br />
===accessibility===<br />
'''imported from the forum:''' I like the simplicity of bitcoin:xxxxxxxxxxxxx plus very much approve of its accessibility. Should someone from the outside happen to see such a uri, the protocol name already gives a description. A quick google search should then do the rest. x-btc sounds much more cryptic, the chance that s/1 gooogles that out of curiosity are much slimmer. Also, very likely, what s/he will find are mostly technical specifications. Not a good introduction to bitcoin.<br />
<br />
for the same reason i am for using '&' as a delimiter for key-value-pairs. people know it from urls. make it easy for people to understand what is going on.<br />
<br />
===keep it simple===<br />
don't explicitly write down information that can be inferred. don't mark the address as an address. if there is no address, this does lose much of its utility. we could, however, specify 'address' as a reserved word, so that <code><br />
bitcoin:address?amount=50<br />
</code><br />
would initiate a transaction with the amount filled in, but with a blank address. I am not convinced that there is a use case, though.<br />
<br />
===use-cases===<br />
before the URI scheme is finalised one should think long and hard about use-cases. in what circumstances will who use this for what?<br />
* an online shop has a 'buy this'-link, which uses the URI scheme. <br />
**PROBLEM: click on the link opens the application. how does the merchant notice this.<br />
***POSSIBLE SOLUTION: javascript can detect the click.<br />
***POSSIBLE SOLUTION: the checkout site checks its bitcoin account for payment via httprequest <br />
**PROBLEM: the time problem (~10minutes) is very apparent here. nobody wants to wait 10minutes for the transaction to be confirmed.<br />
* a person only has an online client, no actual application<br />
**PROBLEM: how to redirect the URI, so that the online client gets a notice?<br />
<br />
===backwards-compatibility===<br />
we want URIs generated in 2011 to still work in 2036. think about extensibility. of course we can make only educated guesses (and nothing more!) about the future, but don't act as if there is none. this should be the best we can do, but it should not be seen as forever set in stone. make it possible for later generations to improve our work, to mend our errors, without breaking the URIs created now. Version incompatibility is the easiest thing to drive users crazy: "i now upgraded to this shiny new version. what? it doesn't support the old format? AAAAAAARRRGH!"<br />
<br />
==References==<br />
<references/></div>Tcatmhttps://tests.bitcoin.it/w/index.php?title=BIP_0020&diff=1649BIP 00202011-01-10T00:45:16Z<p>Tcatm: Created page with "I propose a scheme like this: () means optional, $* are placeholders <pre> bitcoin:($label@)$address(?$query)(#$message) </pre> === Variables === <pre> label: Label for that ..."</p>
<hr />
<div>I propose a scheme like this:<br />
<br />
() means optional, $* are placeholders<br />
<br />
<pre><br />
bitcoin:($label@)$address(?$query)(#$message)<br />
</pre><br />
<br />
=== Variables ===<br />
<br />
<pre><br />
label: Label for that address (e.g. name of receiver)<br />
address: bitcoin address<br />
query: pairs of key=value seperated by &<br />
message: optional message that is shown to the user after scanning the QR code<br />
</pre><br />
<br />
=== Query keys ===<br />
<pre><br />
amount: amount of BTC<br />
<br />
</pre><br />
== Examples ==<br />
<br />
Just the address:<br />
<pre><br />
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt<br />
</pre><br />
<br />
Address with name:<br />
<pre><br />
bitcoin:tcatm@18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt<br />
</pre><br />
<br />
Request to send 20.30 BTC to me:<br />
<pre><br />
bitcoin:tcatm@18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=20.30<br />
</pre><br />
<br />
Request to send 50 BTC with message:<br />
<pre><br />
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=50#Payment%20for%20product%20xyz<br />
</pre><br />
<br />
Characters must be URI encoded.</div>Tcatmhttps://tests.bitcoin.it/w/index.php?title=Mining_hardware_comparison&diff=755Mining hardware comparison2010-12-24T01:14:24Z<p>Tcatm: Moved GPU data into tables</p>
<hr />
<div>{{stub}}<br />
<br />
Below are some statistics about the mining performance of various hardware. The GPU lists were originally compiled by ArtForz.<br />
<br />
The table shows stock clock numbers. 10-20% performance improvement can be achieved via overclocking.<br />
<br />
=Graphics cards=<br />
<br />
==Nvidia==<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Model !! Mhash/s !! Mhash/W !! W !! Clock !! SP <br />
|-<br />
| 9300GE || 1.57 || - || - || 1300 || 8<br />
|-<br />
| 9300GS || 1.69 || - || - || 1400 || 8<br />
|-<br />
| 9400GT || 3.37 || 0.067 || 50 || 1400 || 16<br />
|-<br />
| 9500GT || 6.75 || 0.135 || 50 || 1400 || 32<br />
|-<br />
| 9600GSO || 19.88 || 0.237 || 84 || 1375 || 96<br />
|-<br />
| 9600GSO512 || 11.75 || 0.131 || 90 || 1625 || 48<br />
|-<br />
| 9600GT || 15.66 || 0.165 || 95 || 1625 || 64<br />
|-<br />
| 9800GT || 30.36 || 0.289 || 105 || 1800 || 112<br />
|-<br />
| 9800GTX || 32.54 || 0.232 || 140 || 1688 || 128<br />
|-<br />
| 9800GTX+ || 35.39 || 0.251 || 141 || 1836 || 128<br />
|-<br />
| 9800GX2 || 57.83 || 0.294 || 197 || 1500 || 256<br />
|-<br />
| G210 || 3.38 || 0.111 || 30.5 || 1402 || 16<br />
|-<br />
| GT220 || 9.83 || 0.170 || 58 || 1360 || 48<br />
|-<br />
| GT240 || 19.37 || 0.281 || 69 || 1340 || 96<br />
|-<br />
| GTS250 || 35.39 || 0.244 || 145 || 1836 || 128<br />
|-<br />
| GTX260 || 35.91 || 0.178 || 202 || 1242 || 192<br />
|-<br />
| GTX260c216 || 40.40 || 0.236 || 171 || 1242 || 216<br />
|-<br />
| GTX275 || 50.75 || 0.232 || 219 || 1404 || 240<br />
|-<br />
| GTX280 || 46.84 || 0.198 || 236 || 1296 || 240<br />
|-<br />
| GTX285 || 53.35 || 0.262 || 204 || 1476 || 240<br />
|-<br />
| GTX295 || 89.78 || 0.311 || 289 || 1242 || 480<br />
|-<br />
| GT430 || 20.24 || 0.413 || 49 || 1400 || 96<br />
|-<br />
| GTS450 || 45.28 || 0.427 || 106 || 1566 || 192<br />
|-<br />
| GTX460SE || 56.39 || 0.376 || 150 || 1300 || 288<br />
|-<br />
| GTX460 || 68.31 || 0.427 || 160 || 1350 || 336<br />
|-<br />
| GTX465 || 64.41 || 0.322 || 200 || 1215 || 352<br />
|-<br />
| GTX470 || 81.98 || 0.381 || 215 || 1215 || 448<br />
|-<br />
| GTX480 || 101.28 || 0.405 || 250 || 1401 || 480<br />
|-<br />
| GTX570 || 105.83 || 0.483 || 219 || 1464 || 480<br />
|-<br />
| GTX580 || 119.06 || 0.488 || 244 || 1544 || 512<br />
|-<br />
|}<br />
<br />
==ATI==<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Model !! Mhash/s !! Mhash/W !! W !! Clock !! SP <br />
|-<br />
| 4350 || 6.93 || 0.346 || 20 || 575 || 80 <br />
|- <br />
| 4550 || 7.23 || 0.289 || 25 || 600 || 80 <br />
|- <br />
| 4650 || 31.33 || 0.653 || 48 || 650 || 320 <br />
|- <br />
| 4670 || 36.14 || 0.613 || 59 || 750 || 320 <br />
|- <br />
| 4730 || 72.29 || 0.657 || 110 || 750 || 640 <br />
|- <br />
| 4770 || 72.29 || 0.904 || 80 || 750 || 640 <br />
|- <br />
| 4830 || 55.42 || 0.583 || 95 || 575 || 640 <br />
|- <br />
| 4850 || 75.30 || 0.685 || 110 || 625 || 800 <br />
|- <br />
| 4860 || 67.47 || 0.519 || 130 || 700 || 640 <br />
|- <br />
| 4870 || 90.36 || 0.602 || 150 || 750 || 800 <br />
|- <br />
| 4890 || 102.41 || 0.539 || 190 || 850 || 800 <br />
|- <br />
| 4850X2 || 150.60 || 0.602 || 250 || 625 || 1600 <br />
|- <br />
| 4870X2 || 180.72 || 0.632 || 286 || 750 || 1600 <br />
|- <br />
| 5450 || 11.99 || 0.631 || 19 || 650 || 80 <br />
|- <br />
| 5550 || 40.59 || 1.041 || 39 || 550 || 320 <br />
|- <br />
| 5570 || 59.96 || 1.538 || 39 || 650 || 400 <br />
|- <br />
| 5670 || 71.49 || 1.117 || 64 || 775 || 400 <br />
|- <br />
| 5750 || 116.24 || 1.352 || 86 || 700 || 720 <br />
|- <br />
| 5770 || 156.83 || 1.452 || 108 || 850 || 800 <br />
|- <br />
| 5830 || 206.64 || 1.181 || 175 || 800 || 1120 <br />
|- <br />
| 5850 || 240.77 || 1.595 || 151 || 725 || 1440 <br />
|- <br />
| 5870 || 313.65 || 1.668 || 188 || 850 || 1600 <br />
|- <br />
| 5970 || 535.06 || 1.820 || 294 || 725 || 3200 <br />
|- <br />
| 6850 || 171.59 || 1.351 || 127 || 775 || 960 <br />
|- <br />
| 6870 || 232.47 || 1.540 || 151 || 900 || 1120 <br />
|- <br />
|}<br />
<br />
=CPUs=<br />
<br />
==AMD==<br />
<br />
==Intel==<br />
<br />
[[Category:Mining]]</div>Tcatm