https://tests.bitcoin.it/w/api.php?action=feedcontributions&user=Rubensayshi&feedformat=atomBitcoin Wiki - User contributions [en]2024-03-28T15:38:19ZUser contributionsMediaWiki 1.30.0https://tests.bitcoin.it/w/index.php?title=Controlled_supply&diff=61379Controlled supply2016-07-29T10:00:52Z<p>Rubensayshi: latest halving date added</p>
<hr />
<div><blockquote>A fixed money supply, or a supply altered only in accord with objective and calculable criteria, is a necessary condition to a meaningful just price of money.<ref>[https://www.scribd.com/doc/138347161/Bernard-W-Dempsey-1903-1960-Interest-and-Usury-With-an-Introduction-by-Joseph-a-Schumpeter-1948#page220 <i>Interest and Usury</i> p. 220] by [https://www.jstor.org/stable/29769582 Fr. Bernard W. Dempsey, S.J.] (1903-1960); cf. John Horvat II [http://returntoorder.org/ <i>Return to Order</i>] ch. 37 "The Backing of Money"</ref><br />
<p align="right">—[https://www.jstor.org/stable/29769582 Fr. Bernard W. Dempsey, S.J.] (1903-1960)</p></blockquote><br />
<br />
In a centralized economy, currency is issued by a central bank at a rate that is supposed to match the growth of the amount of goods that are exchanged so that these goods can be traded with stable prices. The <br />
[[wikipedia:monetary base|monetary base]] is controlled by a central bank. In the United States, the [[wikipedia:Federal Reserve System|Fed]] increases the monetary base by issuing currency, increasing the amount banks have on reserve, and more recently, printing money electronically in a process called [[wikipedia:Quantitative Easing|Quantitative Easing]].<br />
<br />
In a fully decentralized monetary system, there is no central authority that regulates the monetary base. Instead, currency is created by the nodes of a peer-to-peer network. The Bitcoin generation algorithm defines, in advance, how currency will be created and at what rate. Any currency that is generated by a malicious user that does not follow the rules will be rejected by the network and thus is worthless.<br />
<br />
==Currency with Finite Supply==<br />
[[Image:Controlled supply-block reward halving.png|160px|thumb|right| Block reward halving]]<br />
[[Image:Controlled supply-supply over block height.png|160px|thumb|right| Controlled supply]]<br />
Bitcoins are created each time a user discovers a new [[block]]. <br />
The rate of block creation is adjusted every 2016 blocks to aim for a constant two week adjustment period (equivalent to 6 per hour.) The number of bitcoins generated per block is set to decrease geometrically, with a 50% reduction every 210,000 blocks, or approximately four years. The result is that the number of bitcoins in existence is not expected to exceed 21 million.<ref>[http://www.bitcointalk.org/index.php?topic=3366.msg47522#msg47522 21 million cap]</ref> Speculated justifications for the unintuitive value "21 million" are that it matches a 4-year reward halving schedule; or the ultimate total number of Satoshis that will be mined is close to the maximum capacity of a 64-bit floating point number. Satoshi has never really justified or explained many of these constants.<br />
<br />
[[File:ControlledSupply.png]]<br />
<br />
This decreasing-supply algorithm was chosen because it approximates the rate at which commodities like gold are mined. Users who use their computers to perform calculations to try and discover a block are thus called [[Mining|''Miners'']].<br />
<br />
See also: https://plot.ly/~BashCo/5.embed?share_key=ljQVkaTiHXjX2W41UiqzCn<br />
<br />
==Projected Bitcoins Short Term ==<br />
This chart shows the number of bitcoins that will exist in the near future. The ''Year'' is a forecast and may be slightly off.<br />
{| class="wikitable"<br />
|-<br />
! Date reached!!Block!!Reward Era!! BTC/block!! Year (estimate)!! Start BTC!! BTC Added!! End BTC!! BTC Increase|| End BTC % of Limit<br />
|-<br />
|2009-01-03||0||1||50.00||2009||0||2625000||2625000||infinite||12.500%<br />
|-<br />
|2010-04-22||52500||1||50.00||2010||2625000||2625000||5250000||100.00%||25.000%<br />
|-<br />
|2011-01-28||105000||1||50.00||2011*||5250000||2625000||7875000||50.00%||37.500%<br />
|-<br />
|2011-12-14||157500||1||50.00||2012||7875000||2625000||10500000||33.33%||50.000%<br />
|-<br />
|[[Halving day 2012|2012-11-28]]||210000||2||25.00||2013||10500000||1312500||11812500||12.50%||56.250%<br />
|-<br />
|2013-10-09||262500||2||25.00||2014||11812500||1312500||13125000||11.11%||62.500%<br />
|-<br />
|2014-08-11||315000||2||25.00||2015||13125000||1312500||14437500||10.00%||68.750%<br />
|-<br />
|2015-07-29||367500||2||25.00||2016||14437500||1312500||15750000||9.09%||75.000%<br />
|-<br />
|2016-06-09||420000||3||12.50||2017||15750000||656250||16406250||4.17%||78.125%<br />
|-<br />
|||472500||3||12.50||2018||16406250||656250||17062500||4.00%||81.250%<br />
|-<br />
|||525000||3||12.50||2019||17062500||656250||17718750||3.85%||84.375%<br />
|-<br />
|||577500||3||12.50||2020||17718750||656250||18375000||3.70%||87.500%<br />
|-<br />
|||630000||4||6.25||2021||18375000||328125||18703125||1.79%||89.063%<br />
|-<br />
|||682500||4||6.25||2022||18703125||328125||19031250||1.75%||90.625%<br />
|-<br />
|||735000||4||6.25||2023||19031250||328125||19359375||1.72%||92.188%<br />
|-<br />
|||787500||4||6.25||2024||19359375||328125||19687500||1.69%||93.750%<br />
|}<br />
''* In Block 124724, user midnightmagic mined a solo block to himself which underpaid the reward by a single Satoshi and simultaneously destroyed the block's fees. This the the only known reduction in the total mined supply of Bitcoin. Therefore, from block 124724 onwards, all total supply estimates must technically be reduced by 1 Satoshi.<br />
<br />
==Projected Bitcoins Long Term ==<br />
[[Image:Controlled supply-timeline estimation.png|160px|thumb|right| Supply timeline estimation]]<br />
Because the number of bitcoins created each time a user discovers a new block - the block reward - is halved based on a fixed interval of blocks, and the time it takes on average to discover a block can vary based on [[mining]] power and the network [[difficulty]], the exact time when the block reward is halved can vary as well. Consequently, the time the last Bitcoin will be created will also vary, and is subject to speculation based on assumptions.<br />
<br />
If the mining power had remained constant since the first Bitcoin was mined, the last Bitcoin would have been mined somewhere near October 8th, 2140. Due to the mining power having increased overall over time, as of block 367,500 - assuming mining power remained constant from that block forward - the last Bitcoin will be mined on May 7th, 2140.<br />
<br />
As it is very difficult to predict how mining power will evolve into the future - i.e. whether technological progress will continue to make hardware faster or whether mining will hit a a technological wall; or whether or not faster methods of SHA2 calculation will be discovered - putting an exact date or even year on this event is difficult.<br />
<br />
The total number of bitcoins, as mentioned earlier, has an asymptote at 21 million, due to a technical limitation in the data structure of the blockchain - specifically the integer storage type of the [[Transaction#general_format_.28inside_a_block.29_of_each_output_of_a_transaction_-_Txout|transaction output]], this exact value would have been 20,999,999.9769 bitcoin. Should this technical limitation be adjusted by changing the width of the field, the total number will still only approach or be a maximum of 21 million.<br />
<br />
{| class="wikitable" style="text-align:right"<br />
|-<br />
! Block!!Reward Era!! BTC/block!! Start BTC!! BTC Added!! End BTC!! BTC Increase|| End BTC % of Limit<br />
|-<br />
| 0|| 1|| 50.00000000|| 0.00000000|| 10500000.00000000|| 10500000.00000000*|| infinite|| 50.00000006%<br />
|-<br />
| 210000|| 2|| 25.00000000|| 10500000.00000000|| 5250000.00000000|| 15750000.00000000|| 50.00000000%|| 75.00000008%<br />
|-<br />
| 420000|| 3|| 12.50000000|| 15750000.00000000|| 2625000.00000000|| 18375000.00000000|| 16.66666667%|| 87.50000010%<br />
|-<br />
| 630000|| 4|| 6.25000000|| 18375000.00000000|| 1312500.00000000|| 19687500.00000000|| 7.14285714%|| 93.75000010%<br />
|-<br />
| 840000|| 5|| 3.12500000|| 19687500.00000000|| 656250.00000000|| 20343750.00000000|| 3.33333333%|| 96.87500011%<br />
|-<br />
| 1050000|| 6|| 1.56250000|| 20343750.00000000|| 328125.00000000|| 20671875.00000000|| 1.61290323%|| 98.43750011%<br />
|-<br />
| 1260000|| 7|| 0.78125000|| 20671875.00000000|| 164062.50000000|| 20835937.50000000|| 0.79365079%|| 99.21875011%<br />
|-<br />
| 1470000|| 8|| 0.39062500|| 20835937.50000000|| 82031.25000000|| 20917968.75000000|| 0.39370079%|| 99.60937511%<br />
|-<br />
| 1680000|| 9|| 0.19531250|| 20917968.75000000|| 41015.62500000|| 20958984.37500000|| 0.19607843%|| 99.80468761%<br />
|-<br />
| 1890000|| 10|| 0.09765625|| 20958984.37500000|| 20507.81250000|| 20979492.18750000|| 0.09784736%|| 99.90234386%<br />
|-<br />
| 2100000|| 11|| 0.04882812|| 20979492.18750000|| 10253.90520000|| 20989746.09270000|| 0.04887585%|| 99.95117198%<br />
|-<br />
| 2310000|| 12|| 0.02441406|| 20989746.09270000|| 5126.95260000|| 20994873.04530000|| 0.02442599%|| 99.97558604%<br />
|-<br />
| 2520000|| 13|| 0.01220703|| 20994873.04530000|| 2563.47630000|| 20997436.52160000|| 0.01221001%|| 99.98779307%<br />
|-<br />
| 2730000|| 14|| 0.00610351|| 20997436.52160000|| 1281.73710000|| 20998718.25870000|| 0.00610426%|| 99.99389658%<br />
|-<br />
| 2940000|| 15|| 0.00305175|| 20998718.25870000|| 640.86750000|| 20999359.12620000|| 0.00305194%|| 99.99694833%<br />
|-<br />
| 3150000|| 16|| 0.00152587|| 20999359.12620000|| 320.43270000|| 20999679.55890000|| 0.00152592%|| 99.99847420%<br />
|-<br />
| 3360000|| 17|| 0.00076293|| 20999679.55890000|| 160.21530000|| 20999839.77420000|| 0.00076294%|| 99.99923713%<br />
|-<br />
| 3570000|| 18|| 0.00038146|| 20999839.77420000|| 80.10660000|| 20999919.88080000|| 0.00038146%|| 99.99961859%<br />
|-<br />
| 3780000|| 19|| 0.00019073|| 20999919.88080000|| 40.05330000|| 20999959.93410000|| 0.00019073%|| 99.99980932%<br />
|-<br />
| 3990000|| 20|| 0.00009536|| 20999959.93410000|| 20.02560000|| 20999979.95970000|| 0.00009536%|| 99.99990468%<br />
|-<br />
| 4200000|| 21|| 0.00004768|| 20999979.95970000|| 10.01280000|| 20999989.97250000|| 0.00004768%|| 99.99995236%<br />
|-<br />
| 4410000|| 22|| 0.00002384|| 20999989.97250000|| 5.00640000|| 20999994.97890000|| 0.00002384%|| 99.99997620%<br />
|-<br />
| 4620000|| 23|| 0.00001192|| 20999994.97890000|| 2.50320000|| 20999997.48210000|| 0.00001192%|| 99.99998812%<br />
|-<br />
| 4830000|| 24|| 0.00000596|| 20999997.48210000|| 1.25160000|| 20999998.73370000|| 0.00000596%|| 99.99999408%<br />
|-<br />
| 5040000|| 25|| 0.00000298|| 20999998.73370000|| 0.62580000|| 20999999.35950000|| 0.00000298%|| 99.99999706%<br />
|-<br />
| 5250000|| 26|| 0.00000149|| 20999999.35950000|| 0.31290000|| 20999999.67240000|| 0.00000149%|| 99.99999855%<br />
|-<br />
| 5460000|| 27|| 0.00000074|| 20999999.67240000|| 0.15540000|| 20999999.82780000|| 0.00000074%|| 99.99999929%<br />
|-<br />
| 5670000|| 28|| 0.00000037|| 20999999.82780000|| 0.07770000|| 20999999.90550000|| 0.00000037%|| 99.99999966%<br />
|-<br />
| 5880000|| 29|| 0.00000018|| 20999999.90550000|| 0.03780000|| 20999999.94330000|| 0.00000018%|| 99.99999984%<br />
|-<br />
| 6090000|| 30|| 0.00000009|| 20999999.94330000|| 0.01890000|| 20999999.96220000|| 0.00000009%|| 99.99999993%<br />
|-<br />
| 6300000|| 31|| 0.00000004|| 20999999.96220000|| 0.00840000|| 20999999.97060000|| 0.00000004%|| 99.99999997%<br />
|-<br />
| 6510000|| 32|| 0.00000002|| 20999999.97060000|| 0.00420000|| 20999999.97480000|| 0.00000002%|| 99.99999999%<br />
|-<br />
| 6720000|| 33|| 0.00000001|| 20999999.97480000|| 0.00210000|| 20999999.97690000|| 0.00000001%|| 100.00000000%<br />
|-<br />
| 6930000|| 34|| 0.00000000|| 20999999.97690000|| 0.00000000|| 20999999.97690000|| 0.00000000%|| 100.00000000%<br />
|}<br />
''Note: The number of bitcoins are presented in a floating point format. However, these values are based on the number of satoshi per block originally in integer format to prevent compounding error.''<br />
<br />
''* In block 124724, user midnightmagic solo mined a block which caused one less Satoshi to be created than would otherwise have come into existence. Therefore, all calculations from this block onwards must now, to be accurate, include this underpay in total Bitcoins in existence.''<br />
<br />
==Spendable Supply==<br />
The theoretical total number of bitcoins, 21 million, should not be confused with the total spendable supply. The total spendable supply is always lower than the theoretical total supply, and is subject to accidental loss, willful destruction, and technical peculiarities.<br />
<br />
One way to see a part of the destruction of coin is by collecting a sum of all unspent transaction outputs, using a [[API reference (JSON-RPC)|Bitcoin RPC]] command <code>gettxoutsetinfo</code>. The ''total_amount'' value returned is the sum of all outputs that the client deems technically spendable but not currently spent. Note however that this does not take into account outputs that are exceedingly unlikely to be spent as is the case in loss and destruction via constructed addresses, for example.<br />
===Miner Underpay===<br />
<br />
The algorithm which decides whether a block is valid only checks to verify whether the total amount of the reward '''exceeds''' the reward plus available fees. Therefore it is possible for a miner to deliberately choose to underpay himself by any value: not only can this destroy the fees involved, but also the reward itself, which can prevent the total possible bitcoins that can come into existence from reaching its theoretical maximum. This is a form of underpay which the reference implementation recognises as impossible to spend. Some of the other types below are not recognised as officially destroying Bitcoins; it is possible for example to spend the 1BitcoinEaterAddressDontSendf59kuE if a corresponding private key is used (although this would imply that Bitcoin has been broken.)<br />
<br />
===Loss of bitcoin===<br />
Bitcoins may be lost if the conditions required to spend them are no longer known. For example, if you made a transaction to an [[address]] that requires a private key in order to spend those bitcoins further, had written that private key down on a piece of paper, but that piece of paper was lost. In this case, that bitcoin may also be considered lost, as the odds of randomly finding a matching private key are such that it is generally considered impossible.<br />
<br />
===Willful destruction of bitcoin===<br />
Bitcoins may also be willfully 'destroyed' - for example by attaching conditions that make it impossible to spend them.<br />
<br />
A common method is to send bitcoin to an address that was constructed and only made to pass validity checks, but for which no private key is actually known. An example of such an address is "1BitcoinEaterAddressDontSendf59kuE", where the last "f59kuE" is text to make the preceding constructed text pass validation. Finding a matching private key is, again, generally considered impossible. For an example of how difficult this would be, see [[Vanitygen#Use_of_vanitygen_to_try_to_attack_addresses|Vanitygen]].<br />
<br />
Another common method is to send bitcoin in a transaction where the conditions for spending are not just unfathomably unlikely, but literally impossible to meet. For example, a transaction that is made [[Script#Provably_Unspendable.2FPrunable_Outputs|provably unspendable using OP_RETURN]], or uses script operations that requires the user to prove that 1+1 equals 3.<br />
<br />
A lesser known method is to send bitcoin to an address based on private key that is outside the [[Private_key#Range_of_valid_ECDSA_private_keys|range of valid ECDSA private keys]]. For example, the address 16QaFeudRUt8NYy2yzjm3BMvG4xBbAsBFM has a known matching private key of value 0 (zero), which is outside the valid range.<br />
<br />
===Technical peculiarities preventing spending of bitcoin===<br />
There are also technical peculiarities that prevent the spending of some bitcoin.<br />
<br />
The first {{btc}}50, included in the [[genesis block]], cannot be spent as its transaction is not in the global database.<br />
<br />
In older versions of the bitcoin reference code, a miner could make their coinbase transaction (block reward) have the exact same ID as used in a previous block<ref>https://github.com/bitcoin/bitcoin/issues/612</ref>. This effectively caused the previous block reward to become unspendable. Two known such cases<ref>{{cite tx|e3bf3d07d4b0375638d5f1db5255fe07ba2c4cb067cd81b84ee974b6585fb468|used in blocks 91722 and 91880}}</ref><ref>{{cite tx|d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599|used in blocks 91812 and 91842</ref> are left as special cases in the code<ref>https://github.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9c86bb2043c24f0f377f1cf514</ref> as part of [[BIP 0030]] changes that fixed this issue. These transactions were {{btc}}50 each.<br />
<br />
==Money Supply==<br />
While the number of bitcoins in existence will never exceed 21 million, the [[wikipedia:money supply|money supply]] of bitcoins can exceed 21 million due to [[wikipedia:Fractional-reserve banking|Fractional-reserve banking]].<br />
<br />
==Deflation==<br />
<br />
Because the monetary base of bitcoins cannot be expanded, the currency would be subject to severe deflation if it becomes widely used. <br />
Keynesian economists argue that [[Deflationary spiral|deflation]] is bad for an economy because it incentivises individuals and businesses to save money rather than invest in businesses and create jobs. The [[wikipedia:Austrian school|Austrian school]] of thought counters this criticism, claiming that as deflation occurs in all stages of production, entrepreneurs who invest benefit from it. As a result, profit ratios tend to stay the same and only their magnitudes change. In other words, in a deflationary environment, goods and services decrease in price, but at the same time the cost for the production of these goods and services tend to decrease proportionally, effectively not affecting profits. Price deflation encourages an increase in hoarding &mdash; hence savings &mdash; which in turn tends to lower interest rates and increase the incentive for entrepreneurs to invest in projects of longer term.<br />
<br />
==See also==<br />
<br />
* [http://www.econlib.org/library/Columns/y2006/Friedmantranscript.html Milton Friedman interview], where he proposed to replace the central bank with a computer, and to fix the money supply growth at 4% annually<br />
* [[Deflationary spiral]]<br />
* [http://blockchain.info/charts/total-bitcoins Chart of total bitcoins in circulation]<br />
* [[Inflation]]<br />
* [[Prohibited changes]]<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Economics]]</div>Rubensayshihttps://tests.bitcoin.it/w/index.php?title=PHP_developer_intro&diff=53734PHP developer intro2015-01-09T10:10:54Z<p>Rubensayshi: list alternative libraries to use</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 />
It is however recommended to use one of the [[#Alternative_Libs_For_RPC|Alternative Libraries]] listed below instead, since they are slightly more sofisticated.<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 [[#Alternative_Libs_For_RPC|Alternative Libraries]] listed below are similar in function to JSON-RPC PHP but do 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 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 />
==Alternative Libs For RPC==<br />
There are alternative PHP libraries for connecting to the bitcoind RPC which are recommended over using the plain jsonRPCClient.php class.<br />
They do not rely on magic __call, use cURL instead of fopen and have better error handling (and can be installed using composer).<br />
<br />
* [https://github.com/nbobtc/bitcoind-php NboBTC Bitcoind-PHP]<br />
* [https://github.com/aceat64/EasyBitcoin-PHP EasyBitcoin-PHP]<br />
<br />
==See Also==<br />
<br />
* [[API reference (JSON-RPC)]]<br />
* [[Lazy_API]]<br />
* [https://github.com/cryptoapi/Payment-Gateway Bitcoin-PHP Payment library]<br />
* [[Merchant Howto]]<br />
* [[https://github.com/Bit-Wasp/bitcoin-lib-php Bitcoin-Lib-PHP - PHP Lib implementing signing of transactions, BIP32, etc]]<br />
<br />
[[es:Introducción para desarrolladores de PHP]]<br />
[[de:Einführung_für_PHP-Entwickler]]<br />
<br />
[[Category:Developer]]</div>Rubensayshihttps://tests.bitcoin.it/w/index.php?title=PHP_developer_intro&diff=53730PHP developer intro2015-01-08T10:35:15Z<p>Rubensayshi: /* See Also */</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 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 />
* [[API reference (JSON-RPC)]]<br />
* [[Lazy_API]]<br />
* [https://github.com/cryptoapi/Payment-Gateway Bitcoin-PHP Payment library]<br />
* [[Merchant Howto]]<br />
* [[https://github.com/Bit-Wasp/bitcoin-lib-php Bitcoin-Lib-PHP - PHP Lib implementing signing of transactions, BIP32, etc]]<br />
<br />
[[es:Introducción para desarrolladores de PHP]]<br />
[[de:Einführung_für_PHP-Entwickler]]<br />
<br />
[[Category:Developer]]</div>Rubensayshihttps://tests.bitcoin.it/w/index.php?title=PHP_developer_intro&diff=53729PHP developer intro2015-01-08T10:34:47Z<p>Rubensayshi: /* See Also */</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 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 />
* [[API reference (JSON-RPC)]]<br />
* [[Lazy_API]]<br />
* [https://github.com/cryptoapi/Payment-Gateway GoUrl Bitcoin-PHP Payment library]<br />
* [[Merchant Howto]]<br />
* [[https://github.com/Bit-Wasp/bitcoin-lib-php GoUrl Bitcoin-Lib-PHP - PHP Lib implementing signing of transactions, BIP32, etc]]<br />
<br />
[[es:Introducción para desarrolladores de PHP]]<br />
[[de:Einführung_für_PHP-Entwickler]]<br />
<br />
[[Category:Developer]]</div>Rubensayshihttps://tests.bitcoin.it/w/index.php?title=Invoice_address&diff=53125Invoice address2014-11-18T09:59:50Z<p>Rubensayshi: Mention testnet different prefixes</p>
<hr />
<div>A '''Bitcoin address''', or simply '''address''', is an identifier of 26-35 alphanumeric characters, beginning with the number 1 or 3, that represents a possible destination for a Bitcoin payment.<br />
Addresses can be generated at no cost by any user of Bitcoin.<br />
For example, using [[Bitcoin-Qt]], one can click "New Address" and be assigned an address.<br />
It is also possible to get a Bitcoin address using an account at an exchange or online wallet service.<br />
<br />
An example of a Bitcoin address is <code>3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy</code><!-- anyone-can-spend, null script -->.<br />
<br />
==A Bitcoin address is a single-use token==<br />
Like e-mail addresses, you can send bitcoins to a person by sending bitcoins to one of their addresses.<br />
However, ''unlike'' e-mail addresses, people have many different Bitcoin addresses and a unique address should be used for each transaction.<br />
Most Bitcoin software and websites will help with this by generating a brand new address each time you create an invoice or payment request.<br />
<br />
==Addresses can be created offline==<br />
Creating addresses can be done without an Internet connection and does not require any contact or registration with the Bitcoin network.<br />
It is possible to create large batches of addresses offline using freely available software tools.<br />
Generating batches of addresses is useful in several scenarios, such as e-commerce websites where a unique pre-generated address is dispensed to each customer who chooses a "pay with Bitcoin" option.<br />
Newer "HD wallets" can generate a "seed" token which can be used to allow untrusted systems (such as webservers) to generate an unlimited number of addresses without the ability to spend the bitcoins received.<br />
<br />
==Addresses are case sensitive and exact==<br />
Bitcoin addresses are case-sensitive. Bitcoin addresses should be copied and pasted using the computer's clipboard wherever possible. If you hand-key a Bitcoin address, and each character is not transcribed exactly - including capitalization - the incorrect address will most likely be rejected by the Bitcoin software. You will have to check your entry and try again.<br />
<br />
The probability that a mistyped address is accepted as being valid is 1 in 2<sup>32</sup>, that is, approximately 1 in 4.29 billion.<br />
<br />
==Proving you receive with an address==<br />
Most Bitcoin wallets have a function to "sign" a message, proving the entity receiving funds with an address has agreed to the message.<br />
This can be used to, for example, finalise a contract in a cryptographically provable way prior to making payment for it.<br />
<br />
Some services will also piggy-back on this capability by dedicating a specific address for authentication only, in which case the address should never be used for actual Bitcoin transactions.<br />
When you login to or use their service, you will provide a signature proving you are the same person with the pre-negotiated address.<br />
<br />
It is important to note that these signatures only prove one receives with an address.<br />
Since Bitcoin transactions do not have a "from" address, you cannot prove you are the ''sender'' of funds.<br />
<br />
Current standards for message signatures are only compatible with "version zero" bitcoin addresses (that begin with the number 1).<br />
<br />
==Address validation==<br />
If you would like to validate a Bitcoin address in an application, it is advisable to use a method from [https://bitcointalk.org/index.php?topic=1026.0 this thread] rather than to just check for string length, allowed characters, or that the address starts with a 1 or 3.<br />
<br />
==Multi-signature addresses==<br />
Addresses can be created that require a combination of multiple private keys.<br />
Since these take advantage of newer features, they begin with the newer prefix of 3 instead of the older 1.<br />
These can be thought of as the equivalent of writing a check to two parties - "pay to the order of somebody AND somebody else" - where both parties must endorse the check in order to receive the funds.<br />
<br />
The actual requirement (number of private keys needed, their corresponding public keys, etc.) that must be satisfied to spend the funds is decided in advance by the person generating this type of address, and once an address is created, the requirement cannot be changed without generating a new address.<br />
<br />
==What's in an address==<br />
Most Bitcoin addresses are 34 characters.<br />
They consist of random digits and uppercase and lowercase letters, with the exception that the uppercase letter "O", uppercase letter "I", lowercase letter "l", and the number "0" are never used to prevent visual ambiguity.<br />
<br />
Some Bitcoin addresses can be shorter than 34 characters (as few as 26) and still be valid.<br />
A significant percentage of Bitcoin addresses are only 33 characters, and some addresses may be even shorter.<br />
Every Bitcoin address stands for a number.<br />
These shorter addresses are valid simply because they stand for numbers that happen to start with zeroes, and when the zeroes are omitted, the encoded address gets shorter.<br />
<br />
Several of the characters inside a Bitcoin address are used as a checksum so that typographical errors can be automatically found and rejected.<br />
The checksum also allows Bitcoin software to confirm that a 33-character (or shorter) address is in fact valid and isn't simply an address with a missing character.<br />
<br />
==Testnet==<br />
Addresses on the Bitcoin Testnet are generated with a different address version, which results in a different prefix.<br />
See [[List of address prefixes]] and [[Testnet]] for more details.<br />
<br />
==Misconceptions==<br />
===Address reuse===<br />
<br />
Addresses are not intended to be used more than once, and doing so has numerous problems associated.<br />
See the dedicated article on [[address reuse]] for more details.<br />
<br />
===Address balances===<br />
<br />
Addresses are not wallets nor accounts, and do not carry balances.<br />
They only receive funds, and you do not send "from" an address at any time.<br />
Various confusing services and software display ''bitcoins received with an address, minus bitcoins sent in random unrelated transactions'' as an "address balance", but this number is not meaningful: it does not infer the recipient of the bitcoins sent to the address has spent them, nor that they still have the bitcoins received.<br />
<br />
==="From" addresses===<br />
Bitcoin transactions do not have any kind of origin-, source- or "from" address. See the dedicated article on "[[From address|from address]]" for more details.<br />
<br />
==See Also==<br />
* [[Technical background of Bitcoin addresses]]<br />
* [[List of address prefixes]]<br />
* [[Exit Address]]<br />
<br />
== References ==<br />
<references/><br />
<br />
[[Category:Vocabulary]]<br />
<br />
[[es:Dirección]]<br />
[[de:Adresse]]</div>Rubensayshihttps://tests.bitcoin.it/w/index.php?title=Invoice_address&diff=53124Invoice address2014-11-18T09:56:40Z<p>Rubensayshi: P2SH address can be 35 characters and on testnet they always are</p>
<hr />
<div>A '''Bitcoin address''', or simply '''address''', is an identifier of 26-35 alphanumeric characters, beginning with the number 1 or 3, that represents a possible destination for a Bitcoin payment.<br />
Addresses can be generated at no cost by any user of Bitcoin.<br />
For example, using [[Bitcoin-Qt]], one can click "New Address" and be assigned an address.<br />
It is also possible to get a Bitcoin address using an account at an exchange or online wallet service.<br />
<br />
An example of a Bitcoin address is <code>3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy</code><!-- anyone-can-spend, null script -->.<br />
<br />
==A Bitcoin address is a single-use token==<br />
Like e-mail addresses, you can send bitcoins to a person by sending bitcoins to one of their addresses.<br />
However, ''unlike'' e-mail addresses, people have many different Bitcoin addresses and a unique address should be used for each transaction.<br />
Most Bitcoin software and websites will help with this by generating a brand new address each time you create an invoice or payment request.<br />
<br />
==Addresses can be created offline==<br />
Creating addresses can be done without an Internet connection and does not require any contact or registration with the Bitcoin network.<br />
It is possible to create large batches of addresses offline using freely available software tools.<br />
Generating batches of addresses is useful in several scenarios, such as e-commerce websites where a unique pre-generated address is dispensed to each customer who chooses a "pay with Bitcoin" option.<br />
Newer "HD wallets" can generate a "seed" token which can be used to allow untrusted systems (such as webservers) to generate an unlimited number of addresses without the ability to spend the bitcoins received.<br />
<br />
==Addresses are case sensitive and exact==<br />
Bitcoin addresses are case-sensitive. Bitcoin addresses should be copied and pasted using the computer's clipboard wherever possible. If you hand-key a Bitcoin address, and each character is not transcribed exactly - including capitalization - the incorrect address will most likely be rejected by the Bitcoin software. You will have to check your entry and try again.<br />
<br />
The probability that a mistyped address is accepted as being valid is 1 in 2<sup>32</sup>, that is, approximately 1 in 4.29 billion.<br />
<br />
==Proving you receive with an address==<br />
Most Bitcoin wallets have a function to "sign" a message, proving the entity receiving funds with an address has agreed to the message.<br />
This can be used to, for example, finalise a contract in a cryptographically provable way prior to making payment for it.<br />
<br />
Some services will also piggy-back on this capability by dedicating a specific address for authentication only, in which case the address should never be used for actual Bitcoin transactions.<br />
When you login to or use their service, you will provide a signature proving you are the same person with the pre-negotiated address.<br />
<br />
It is important to note that these signatures only prove one receives with an address.<br />
Since Bitcoin transactions do not have a "from" address, you cannot prove you are the ''sender'' of funds.<br />
<br />
Current standards for message signatures are only compatible with "version zero" bitcoin addresses (that begin with the number 1).<br />
<br />
==Address validation==<br />
If you would like to validate a Bitcoin address in an application, it is advisable to use a method from [https://bitcointalk.org/index.php?topic=1026.0 this thread] rather than to just check for string length, allowed characters, or that the address starts with a 1 or 3.<br />
<br />
==Multi-signature addresses==<br />
Addresses can be created that require a combination of multiple private keys.<br />
Since these take advantage of newer features, they begin with the newer prefix of 3 instead of the older 1.<br />
These can be thought of as the equivalent of writing a check to two parties - "pay to the order of somebody AND somebody else" - where both parties must endorse the check in order to receive the funds.<br />
<br />
The actual requirement (number of private keys needed, their corresponding public keys, etc.) that must be satisfied to spend the funds is decided in advance by the person generating this type of address, and once an address is created, the requirement cannot be changed without generating a new address.<br />
<br />
==What's in an address==<br />
Most Bitcoin addresses are 34 characters.<br />
They consist of random digits and uppercase and lowercase letters, with the exception that the uppercase letter "O", uppercase letter "I", lowercase letter "l", and the number "0" are never used to prevent visual ambiguity.<br />
<br />
Some Bitcoin addresses can be shorter than 34 characters (as few as 26) and still be valid.<br />
A significant percentage of Bitcoin addresses are only 33 characters, and some addresses may be even shorter.<br />
Every Bitcoin address stands for a number.<br />
These shorter addresses are valid simply because they stand for numbers that happen to start with zeroes, and when the zeroes are omitted, the encoded address gets shorter.<br />
<br />
Several of the characters inside a Bitcoin address are used as a checksum so that typographical errors can be automatically found and rejected.<br />
The checksum also allows Bitcoin software to confirm that a 33-character (or shorter) address is in fact valid and isn't simply an address with a missing character.<br />
<br />
==Misconceptions==<br />
===Address reuse===<br />
<br />
Addresses are not intended to be used more than once, and doing so has numerous problems associated.<br />
See the dedicated article on [[address reuse]] for more details.<br />
<br />
===Address balances===<br />
<br />
Addresses are not wallets nor accounts, and do not carry balances.<br />
They only receive funds, and you do not send "from" an address at any time.<br />
Various confusing services and software display ''bitcoins received with an address, minus bitcoins sent in random unrelated transactions'' as an "address balance", but this number is not meaningful: it does not infer the recipient of the bitcoins sent to the address has spent them, nor that they still have the bitcoins received.<br />
<br />
==="From" addresses===<br />
Bitcoin transactions do not have any kind of origin-, source- or "from" address. See the dedicated article on "[[From address|from address]]" for more details.<br />
<br />
==See Also==<br />
* [[Technical background of Bitcoin addresses]]<br />
* [[List of address prefixes]]<br />
* [[Exit Address]]<br />
<br />
== References ==<br />
<references/><br />
<br />
[[Category:Vocabulary]]<br />
<br />
[[es:Dirección]]<br />
[[de:Adresse]]</div>Rubensayshi